FIRST is really looking into the Einstein problems

[Hjelstrom]

Originally Posted by linuxboy

When you say that the computer processing the Kinect data sent key data to the cRIO over the router, I'm assuming you mean the switch on the bridge, right? The only real device with routing tables in the standard control system is the field access point.

Ok, forgive me if I describe anything incorrectly, this was our team's first experiment with writing our own network communications code (among many other things this year). We have a Pandaboard on the robot and it has an ethernet cable connecting it to the bridge. We use TCP/IP packets and the Pandaboard acts as a listening server and the cRio as a client (C++). Packets are only sent from the Pandaboard to the cRio when the cRio sends a packet requesting information. There should be no extraneous packets being sent and its all over the wire, not wireless. We've used it this way in every match all year at two regionals and at worlds. The only problem we had was one match in Las Vegas where our Pandaboard did not power up and the cRio waits up to 30s trying to establish a connection. We know the behavior of that problem and that is not what happened on Einstein. We also had one match in Curie where we did not plug our robot battery all the way in. So we had no "unknown" problems even in practice matches all year until Einstein. I don't know if any of us ever looked at what firmware our bridge is running.

I think what Joe was referring to was that we also went to extra effort this year to minimize the data we were sending from the cRio to the driver station. We set up a toggle button on the driver station controls that enables and disables data sending (disabled by default). The reason for this is that we noticed that the driver station quickly becomes very "laggy" when we send data to it (this is using SmartDashboard and NetworkTables). First we tried to solve this by upgrading the laptop but it still happened. So we worked around the problem by not sending data unless we really needed to "debug". Even with our data sending enabled, we were using a timer to drastically limit how often we send data. It seems very odd to me that the small amount of data being sent from the robot to the DS could make any difference in the DS performance.

We stuck with SmartDashboard because for another part of our tele-op control system, the flexibility of being able to send a small amount of data from the SmartDashboard to the robot was so useful (i.e. the functionality of NetworkTables). It was worth all of the trouble we had to go through and all of the workarounds like restarting our DS before each match.