FIRST's statement on Einstein

[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.