Quote:
Originally Posted by The Lucas
If your code messes up and throws a watchdog, it is hard to recover while connected to FMS.
|
This isn't true with FMS in my experience.
Most of the teams at SBPLI and NJ, the two events I volunteered at, went to Watchdog not Fed by the end of Autonomous simply when their drive code ran out early or when they had no autonomous code. There's nothing unusual with that. It's perfectly fine.
The user code on the cRIO continues to run. It isn't interrupted at all. Just the cRIO control outputs, e.g., PWM, are disabled by an unfed Watchdog.
Once you feed the watchdog again, the Watchdog re-enables the control outputs. That's why robots experience the momentary stalls when the Watchdog times out only for a second, but then come back again. There's nothing the Watchdog is doing that slows or otherwise blocks your code, and FMS isn't involved. The Watchdog has to work if FMS goes offline after all. It wouldn't be real useful if FMS or the field access point crashed and all the robots went bonkers...
One possibility is slow or marginally slow code. FMS does monitor the packet send times and there are quite a few instances I've seen or heard of where the robot packet times were 10 times slower than the other robots on the field. The cases where I was able to investigate turned out to be slow code or unbalanced parallel tasks.
Not directed at Brian, because I know he writes good code, but to the general CD readership...
It doesn't help to boost the Watchdog delay period. That's like turning up the car radio as a fix for that odd engine noise your car is making.
If you need to do that then something in your code needs to be streamlined. The Watchdog is there to help you discover those kinds of problems.
All that said, I agree with Brian about using the Watchdog for development and debugging purposes, not for competition use.
Misused, it causes more grief than it saves robots, and there's always the E-stop button which
is an FMS control.