Quote:
Originally Posted by rbmj
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.
1. 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.
2. 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?