View Single Post
  #21   Spotlight this post!  
Unread 22-02-2010, 12:40
PaulRevere's Avatar
PaulRevere PaulRevere is offline
If FRC = True than Sleep = False
AKA: Jim Stefanik
FRC #3183 (EPIC)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Burlington, CT
Posts: 5
PaulRevere will become famous soon enough
Re: bridge/cRio communications sporadic

Team 3183 is (was?) having a very similar issue. Our robot network was fine until yesterday, when it randomly started to have stuttering video feed from our camera, even when our robot was disabled. We then enabled the robot, and our DS threw countless “Watchdog Not Fed!” errors. Along with that, our compressor’s Spike was cycling on/off like mad because the code kept being aborted and resumed at a rapid pace (every time the cRIO lost communication with our DS, it would stop the program, and resume it as soon as it saw our DS again [less than a sec. later]) In addition, when this was occurring, our RSL seemed to be indicating the correct status (disabled or enabled) but due to the cycling being so rapid, it was VERY hard to tell. We tried to drive the robot with this, and (to no surprise) we had very little to no control over it. (Which was to be expected when the code kept stopping.) After about a dozen of this cycling, the DS would just say “no robot communication”, indicating that it no longer could see the robot. After maybe 8 seconds or so, the communications link would be back up, and we could do the same thing. We disconnected our Bridge from the cRIO’s Ethernet port (#1), and tethered the robot to our router, and it was fine. But, if we switched back to wireless, it resulted in the same thing. (Code aborts, stuttering video, etc.) This morning, one of our programmers tried the wireless again, still to no avail. He then turned off the robot, went over to get a drink, came back, turned on the robot, and low and behold, the wireless link was fine! Camera worked, no watchdog errors, and he could drive it with no issue. We’re at a loss for the reason behind this. Our biggest concern is that if this happens during a match, it could be the difference between losing a regional Qualifier, or going to Atlanta. (Not to mention, we didn’t try to E-Stop it during this problem, so even if our RSL was in fact saying the right thing, we don’t know if our Robot will even care about being E-Stop’d. (Especially if the code keeps restarting itself, as it wouldn’t know the difference between an E-Stop, or a “go” from FMS (not sure how this would play out with FMS thrown in, but using our DS, we don’t know. (not tested.))
Reply With Quote