FIRST's statement on Einstein

[Astrokid248]

Originally Posted by EricH

I remember one match where both 1717 and 330 were immobile at the same time. Both came back later in the match, but I want to say that 1717 dropped again shortly afterwards.

Our scouters were bellowing "1717'S DEAD! 1717'S DEAD!" in the quarters and the semis. I'm pretty certain 1717 was dead for most of both semifinal matches, and I remember Beachbots dying in a match as well.

[Grim Tuesday]

Originally Posted by Astrokid248

Our scouters were bellowing "1717'S DEAD! 1717'S DEAD!" in the quarters and the semis. I'm pretty certain 1717 was dead for most of both semifinal matches, and I remember Beachbots dying in a match as well.

I wonder why these issues only surface in eliminations? I can't remember another time 1717 wasn't working. Makes me think back to Leeland's comments in other threads, proposing something to do with the increased network bandwidth of highly capable teams (image processing, cameras, etc...)

[Astrokid248]

Originally Posted by Grim Tuesday

I wonder why these issues only surface in eliminations? I can't remember another time 1717 wasn't working. Makes me think back to Leeland's comments in other threads, proposing something to do with the increased network bandwidth of highly capable teams (image processing, cameras, etc...)

That's the current thought here in Houston. We had two cameras, six light sensors, two string pots, and at least three encoders. No matter how you slice it, that's a lot of data. I can only assume other teams had even more going on, especially with 1717's swerve and dual intake. However, this theory falls apart with 4334, who didn't have the same number of sensors and still had comms drop. Perhaps the other two robots hogging the data dropped them, but I don't know enough about networks to be 100% sure. This is just what I hear from our programmers. I would like to investigate it further, but as I said somewhere else, at Lone Star we couldn't replicate either Connecticut's or Florida's issues. At this point I feel like FIRST should scrap the whole wireless system and start from scratch.

[Hjelstrom]

Originally Posted by Astrokid248

That's the current thought here in Houston. We had two cameras, six light sensors, two string pots, and at least three encoders. No matter how you slice it, that's a lot of data. I can only assume other teams had even more going on, especially with 1717's swerve and dual intake. However, this theory falls apart with 4334, who didn't have the same number of sensors and still had comms drop. Perhaps the other two robots hogging the data dropped them, but I don't know enough about networks to be 100% sure. This is just what I hear from our programmers. I would like to investigate it further, but as I said somewhere else, at Lone Star we couldn't replicate either Connecticut's or Florida's issues. At this point I feel like FIRST should scrap the whole wireless system and start from scratch.

There still might be something to this. In our shop we noticed that our controls could lag a little if we had all of our data running so we implemented a button on our controls that enables and disables data (and data defaults to OFF). Essentially, we don't send any data to our dashboard unless we push a certain joystick button. We also set our cameras to use the lowest quality and resolution that we can tolerate. We also made our data sending function only run a couple of times per second rather than every time through the main loop.

Essentially, we noticed that bandwidth usage could be a problem and we tried to optimize our robot's bandwidth usage down to the minimum.

Still, I don't think it can explain 118 sitting completely dead for the whole match. That was a truly tragic thing to see and I sincerely hope this problem is solved for good by next year.

[philso]

It is up to each team to ensure they design their robot to work under all relevant conditions. However, a team should not need to have five other high performance robots with high data demands and a full field to test their robot. Such system level issues should be addressed by whoever provides the FMS.

We were in a match at Alamo where 148 sat dead throughout. The probability that they made the kind of mistake that would cause this is extremely small.

It is unfortunate that it took causing so much pain to an outstanding group of teams, in such a public way, to get FIRST's attention. I hope that FIRST does fix these problems before next year to make their pain worth something.

[frdrake]

Originally Posted by Hjelstrom

There still might be something to this. In our shop we noticed that our controls could lag a little if we had all of our data running so we implemented a button on our controls that enables and disables data (and data defaults to OFF). Essentially, we don't send any data to our dashboard unless we push a certain joystick button. We also set our cameras to use the lowest quality and resolution that we can tolerate. We also made our data sending function only run a couple of times per second rather than every time through the main loop.

Essentially, we noticed that bandwidth usage could be a problem and we tried to optimize our robot's bandwidth usage down to the minimum.

Still, I don't think it can explain 118 sitting completely dead for the whole match. That was a truly tragic thing to see and I sincerely hope this problem is solved for good by next year.

As far as I know we didn't turn down any of the video quality settings for the video stream to the driver's station.

We had:
1 camera
3 encoders
2 breakbeam sensors
2 pots

But all of the processing was left to the cRIO, we didn't offload any of the processing to the driver's station. The only thing that was being output to the driver's station would be the video feed and whatever is the normal packets for sending/receiving joystick inputs.

[Citrus Dad]

Originally Posted by Grim Tuesday

I wonder why these issues only surface in eliminations? I can't remember another time 1717 wasn't working. Makes me think back to Leeland's comments in other threads, proposing something to do with the increased network bandwidth of highly capable teams (image processing, cameras, etc...)

1717 went dead in a qualifying match in which 1662 saved their gravy by scoring a zillion baskets.

An interesting question is whether the combination of so many 'bots using so much band width was higher than in a typical regional.

[Citrus Dad]

Originally Posted by Citrus Dad

1717 went dead in a qualifying match in which 1662 saved their gravy by scoring a zillion baskets.

An interesting question is whether the combination of so many 'bots using so much band width was higher than in a typical regional.

As many of you know, the real reason for 1717 going dead was deliberate wifi jamming by a rogue mentor. This was the same person who disrupted the Einstein matches.

[Jay O'Donnell]

Originally Posted by Citrus Dad

As many of you know, the real reason for 1717 going dead was deliberate wifi jamming by a rogue mentor. This was the same person who disrupted the Einstein matches.

Is there any proof of this? If I remember correctly from FIRST's statement and team 548's statement that this was never said. Also, REALLY old thread revival.

[Citrus Dad]

Originally Posted by Jay O'Donnell

Is there any proof of this? If I remember correctly from FIRST's statement and team 548's statement that this was never said. Also, REALLY old thread revival.

I was correcting my earlier statement for the record that there was a problem with the bandwidth--that turned out not to be true, so my observation was incorrect.

What FIRST or Team 548 said officially doesn't mean that they covered all of the issues. I've discussed this directly with an individual who has direct knowledge and stated that the disruption began with 1717 and then moved on to Einstein.