Hey all, one of our programmers made a fix to the RobotC joystick driver that cuts down on robot damage in the event of a Wi-Fi disconnect.
We ran into this a couple times this last season. We would lose connection to the field, and the robot would keep running the last command it was given. So if we were driving, it would keep driving. The major issue came up when it kept running a mechanism that was not supposed to be run past a certain point, and the mechanism was severely damaged.
With this fix, the robot just stops dead when it disconnects.
I’m not much of a programmer at all, but if you have any questions, I can pass them on to him.
Apparently it can be found here (again, not a programmer, I know very little about GitHub)
It looks like the only difference between the “standard” JoystickDriver.c and your “improved” one is that the variable nNoMessageCounterLimit is initialized to 50 in your version instead of 750 in the standard version. This variable multiplied by around 4ms represents the timeout after which a lost connection will result in setting all the motors to zero. So your version will timeout after around 0.2 seconds while the standard one will timeout after around 3 seconds.
I would suggest that instead of using this different JoystickDriver.c, you simply initialize nNoMessageCounterLimit in your main task or InitializeRobot routine to the value you want (e.g. 50). This will override the value initialized in JoystickDriver.c. This is better because if JoystickDriver.c is ever updated with new features, you won’t need to edit the updated version to change the value again. Also, if you’re working on different machines you don’t need to make sure that all the different machines have your version of JoystickDriver.c.
Some teams will also try to create a visual or audible signal when this communications timeout happens to alert their drivers that the link is down using the related bDisconnected boolean variable in JoystickDriver.c. For example, you could have the LED on an NXT color sensor at the top of your robot light the Red LED if the link is down and the green LED if it is up. That way your drivers can just see immediately if they can drive or not in the middle of a match. Similar functionality can also be implemented by mechanical means (e.g., have a spare servo move a flag or some other visible indicator to the “comm down” position) or via the SuperPrototype boards with LEDs.
BTW, this fix works if the wifi comm link is down, but it won’t work if the NXT freezes or reboots due to static or other reasons.