Quote:
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.