Is there any true reason for having the part of code that is “myRobot.SetSafetyEnabled(true);” ?
Or is this pointless code? Cause in the Autonomous it is set to “false” by default.
I think it’s there for if you get stuck in an infinite loop and all your motors happen to be set at 100% power. Mostly to keep it from running into something if the code stops paying attention.
Sometimes though it can be a pain.
I used to think that too. But then I saw sample code such as SimpleRobot template that disables safety in Autonomous. So I asked myself, why did it do that? Thinking more about it, then I realize if you have buggy code, your buggy code can still cause the robot to run away with 100% power. You just call MyRobot.ArcadeDrive(1.0, 0.0) in an infinite loop that doesn’t respond to anything else. By doing that, you will make the watchdog happy. So then what good is MotorSafety? There are only a couple reasons I can come up with.
- Make sure your teleop code is “responsive” to the joystick control. In case you are processing something else, this will make sure you will read the joystick in a timely manner.
- Make sure if you lose communication with your robot in TeleOp mode, it won’t run away with the last joystick reading. Having said that, I was trying to confirm if the WPILib is doing anything else to guard against communication lost to "zero out the m_controlData structure but since there is no source code available for FrcComm.cpp, I can’t say for sure.
Because of the above two reasons, it makes sense motor safety is more relevant to TeleOp mode than Autonomous. With that reasoning, is there a reason why we should still enable MotorSafety in Autonomous? We have been enabling it up till now. Like you said, it’s a pain. In fact, we still can’t explain why we still get some of those “Output not updated often enough” messages, even though our robot is very responsive to joystick and never stop working. We even had timing code put into the robot loop to tell us how long each loop takes and make sure it is nowhere near the limit of the SetExpiration period. But it is still happening occasionally. Recently, the MotorSafety cut off the RobotDrive motors saying we did not update it ofen enough but our “loop timing” code tells us that we did not exceed the Expiration period. It only happens when we “trigger” the vision processing code. But this is impossible because our vision processing code is in a separate task so it should not affect the main robot task. What is the vxwork time slice period anyway? Just in case that the vxwork time slice is long enough and preempt the main task frequent enough that our main robot loop exceeds the expiration period, we set it to 1 second to test the theory. It’s still triggering the “watchdog”. The interesting thing is that this doesn’t happen all the time. We could have the code running perfectly for a while then all the sudden it started to happen with the watchdog. We are still trying to isolate the cause of this. I suspect it may have something to do with the camera task. Have anybody experienced similar scenario?
Another reason for the motor safety is to make sure that the robot doesn’t run away if you are debugging and at a break point.
I am not familiar with the WindRiver debugger but my understanding is that debugger usually freezes all tasks when hitting a breakpoint. If not, it would be difficult to debug multi-tasking issues since other tasks keep running. If the other tasks are frozen, so is the task that checks the “watchdog”. In other words, even if you have MotorSafety on, if you hit a breakpoint, the robot still runs away. The only real motor safety is if it is implemented in hardware.
Ideally, you would write the autonomous code so that you wouldn’t need to disable the safety update mechanism. But it is your robot, and you can disable it completely if you like.
The safety update is just a watchdog timer. If your code isn’t in control of the robot, sending updates it could be something serious like a breakpoint, an infinite loop, an exception, or other serious issues. It could also be slow code, or code that doesn’t care to update the speed – not really a safety issue, but the code can’t tell the difference.
If you are pretty sure that the code is safe, you may choose to turn off the safety. If you would instead like to put in loops to do updates, you don’t need to turn it off.
As for the breakpoint issue. I believe the WR debugger can be set both ways. LV, leaves parallel tasks in other diagrams running, by the way, so the robot comms is still going, I/O still enabled. I don’t know what the default is for WR. I don’t know how Java behaves at a breakpoint.
So, the HW safety mechanism is triggered by a loss of comms, and tthe Safety config is another layer of safety specific to the SW updates.
Greg McKaskle