Robot move unexpectedly after network disconnect

[SuperBK]

Hi,

Our robot has "taken off" unexpectedly a few times. I think it may have to do with the lost of communications between the driver's station and the CRIO. So though I would FORCE some communication losses and see what happens.

For the moment, ignore why a loss might occur. We will move the wireless bridge on the robot to a better place for the competition.

It seems the controller on the robot remembers the last values of its motor drives when it looses communcations. If you turn on a motor and unplug the network cable from the drivers station to the router, the robot stops and goes into no communications mode (fast blinking robo signal light). When it establishes communication again, it runs the motor a short time and then cuts it off (if it the joystick is centered).

If you start a motor and then turn off the driver station and or router while the motor is running, it immediately turns off the motor which is good. When the driver's station and router are turned back on, it takes around 30 seconds to reestablish communications. When it does, whatever motors were running when communications were lost come back on. The motor(s) then run for 10-15 seconds before an update from the driver's station arrives and turns the motor off. The controls don't work at that point, only the disabled switch will stop it.

Finally a question: Is there a way to detect the no communications mode and turn off the motors. We are currently using the Simple template but have played with the Iterative robot base class. The robot is not disabled so I'm not sure the DisabledInit() method would be called.

My theory is that a short loss of communication will cause the robot to run out of control for 10-15 seconds.

Thanks,
Brian

[CorbinH]

Hi Brian,

Something I would be interested in knowing is if the same thing happens if you take the wireless out of the picture. One thing that might be happening is that the system watchdog is what trips and then potentially the robot could pick up communication and continue. What I would suggest doing is using the User Watchdog. You could use a watchdog to turn off all the motors when communication has been lost. You can find more information about the watchdogs here: http://decibel.ni.com/content/docs/DOC-2957

[sciencewhiz]

When you did these tests, was the cRIO using the latest image (v11)? Was the DS using the latest firmware (2-10)? What programming environment were you using (it sounds like C++)?

There have been several fixes for these types of problems that have been released over time. I would expect these types of problems on earlier versions (in fact, they are warned about in section 3 of the control system manual).

[SuperBK]

Yes, all the latest images. I made sure of that. We are using C++. I was somewhat surprised to find that the robot does this and that its not happening to other teams. We kept the control board and we will be looking at this as soon as we recover from the build season in a couple of days. I will also try using the watchdog timer. Its currentlly disabled. Our code is basically the two color demo (based on SimpleRobot) with additions for our extra motors.

Thanks,

Brian