Since creating a new coding project and doing some programming within it, I noticed that Watchdog is no longer incorporated in any part of the program: Is it supposed to be that way?
Last year I remember getting into a lot of problems because we didn’t “feed” Watchdog and I also seem to remember it coming standard in the robot project. (I was just a backup programmer last year and only really had experience programming when we got to the Buckeye Regionals last year.) Do we need to have Watchdog active this year or, if not, do you think it would still be a good idea to have it running just in case?
I haven’t looked at this year’s LV code to tell you if the watch dog is included.
As for the second part of your post, Using a watchdog timer is a good practice to ensure you don’t get stuck in a loop you don’t want to be in. I would reccomend using a watch dog.
The quick answer is “Nope, you are free to ignore the watchdog!”
The long answer is that last year’s watchdog had a litter of watchpuppies. Each of the actuators has its own watchpuppy hidden inside of its set functions. For example: Whenever you set the speed of your lift motor, the lift motor’s watchpuppy is fed. If the lift motor code gets stuck, that motor will be shut down and a message will be displayed - but the rest of your robot is free to continue!
Watchpuppies are automatically brought online the first time an actuator is spoken to, and automatically pet each time after that. As long as your code is perfect, you shouldn’t ever get bitten by one. Here is a partial list of reasons that watchpuppies bite:
If you have your drive code in the same loop as your camera, and the camera is too slow.
If you use an actuator in autonomous but not in teleop, you will get a message and the actuator will stop moving.
It’s implemented differently this year though, so Austin, you will not be doing what you did or saw done last year.
The old Watchdog vi’s are still in the palette, but I would not use them.
They are there to maintain compatibility with last year’s code.
This year NI has incorporated Safety VI’s that are relatively invisible to you. They are optional, but enabled on the Open Drive Motors by default (not the generic Open Motor). The implementation is better than last year’s generic Watchdog.
You will see the Safety VI enable if you double-click on the Drive Open in Begin.vi.
You can enable/disable it there.
P.S. I’m a wee bit behind Eric, but have one note to add.
Warning:
These Safety vi’s force a particular style of coding and old code may no longer work correctly.
You can no longer set and leave a motor until the next change, for instance, in an autonomous flat sequence structure.
It needs to be set and reset at a fairly rapid pace, even if you’re setting it to the same value over and over again.
I’m undecided myself how or if we will use these. It can make teaching autonomous needless complex to a beginning student.
Yep. This bit us the other day when I was leading the team’s lead programmer through the “easy” way to write an autonomous routine. It took longer than I want to admit before I slapped my forehead and remembered about the safety timeouts.
Alan, I’m curious if you saw a warning or error on the driver station diagnostics. If you did see one, what the message that folks should look for that tells them their watchpuppies (Nice Eric…) are biting and they have something wrong?
Sorry, I wasn’t looking anywhere near the Driver Station during the process. I was rotating the cart the robot was sitting on while the lead programmer watched the gyro-computed heading and monitored the progress of the flat sequence we had placed in Autonomous Independent.
I take it back…
I re-checked my notes and I misremembered one part.
This is what happens when a Safety vi trips.
The status on the Driver Station remains “Autonomous Enabled” or whatever field mode we’re in.
The Diagnostics Message Window shows this error message each time it happens:
ERROR <Code> -44061 occurred at "Left and Right Motors" in the VI path: Robot Main.vi
<time>23:15:45 01/21/2011
FRC: The loop that contains RobotDrive is not running fast enough.
This error can occur if the loop contains too much code, or if one or
more other loops are starving the RobotDrive loop.
If you have an autonomous that makes several drive moves then it will:
do the first drive move for .1 second
stop and display the error above
do the second drive move for .1 second
stop and display the error above
*]etc.
If you have a bunch of moves close together you’ll think the cRIO is pulsing.
To fix it, you should analyze your code to really understand if you’ve got slow code that needs to be sped up. If your code really is laggy then it’ll be sluggish in responding to the driver controls even without the Safety vi and it must be fixed.
There’s a drop-in tool NI included with the framework this year called Elapsed Times.vi
You’ll find it in your project under the Support Code folder.
Just drop it into teleop.vi, Run the project from Robot Main.vi, and bring up the Elapsed Times.vi front panel to watch how long everything takes.
If it’s just a coding style that’s the problem, then the Safety vi can be turned off.
Inside Open 2/4 Motor (used in Begin.vi) there is an enable/disable.
The LV team fully intended to come up with a good replacement for the Delay and Feed VI. Since it never managed to be completed, I’ll relate the concept.The idea is to save a copy of Delay and Feed and create a Delay and Update. One step inside the Robot Drive VIs, you’ll find a call to Safety Update. You don’t need to wire values or anything except the refnum for RobotDrive. Add the appropriate refnums to the connector. If the correct updates are called in place of the Feed of the old VI, I believe the piecewise autonomous will work as before, and I believe that pausing a VI or hitting a breakpoint will typically halt the robot. I say typically because unlike the watchdog, it is possible to pause some of the lower level safety VIs and bypass the safety. This shouldn’t happen unless someone is way off the mark in their debugging.
Since I haven’t implemented this, and certainly haven’t tested it, please test the breakpoint in auto carefully before trusting it.