View Single Post
  #84   Spotlight this post!  
Unread 18-05-2012, 01:09
JB987 JB987 is offline
Registered User
AKA: Joe Barry
FRC #0987 (HIGH ROLLERS)
Team Role: Coach
 
Join Date: May 2006
Rookie Year: 2002
Location: LAS VEGAS
Posts: 1,175
JB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond reputeJB987 has a reputation beyond repute
Re: FIRST is really looking into the Einstein problems

Quote:
Originally Posted by Hjelstrom View Post
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.
Thanks Greg...so much better than my second hand translation
Reply With Quote