Hi
I’m trying to figure out the changes to this year’s Autonomous code template.
I know it’s really important for the robot to cease all activity at the end of Autonomous, and it appears that this is the “intent” of the new “Place code here for the end of autonomous” block, but I don’t see how this has the desired effect.
First, let me say that I know there are concerns about robots running on at the end of Autonomous, but there are already code safeguards in place to prevent this (namely the motor disable mutex in FTCDisableRobot.vi).
What confuses me is how this year's new "disable" code is wired into the system.
The fact that the new “Wait for Disable” loop is wired in parallel to the” Autonomous code” frame would indicate to me that there is no guarantee that the loop will run before the Autonomous frame exits. Given this logic, then it’s hardly adding any extra safeguard against a program that just implements a driving sequence with no waits in it. Furthermore, if the autonomous frame does have some “wait’s” which enable the “wait for disable” loop to detect the end of autonomous, there is still nothing stopping the ”Autonomous” frame from continuing on to issue more drive commands after the “end of autonomous” has turned off the motors.
The “end of autonomous” frame would be just as effective wired directly after the “Autonomous” frame, so at least it shuts down the motors for good.
I believe that the fact that some robots still run on after Autonomous (despite the fact that they pass software inspections), is caused by a completely different “race condition”.
At the end of autonomous, the FCS first issues a disable command, and then it terminates the Autonomous program. This seems like a pretty foolproof way to stop the robot, but in fact, IF the NXT acts on the “direct” terminate command before the Autonomous program has had time to see and respond to the disable message, then the motor controllers will continue to process their last command for up to 2.5 seconds.
I don’t know how long the FCS waits before sending the terminate command, but I maintain it’s not long enough. My experience is that a heavily burdened Autonomous program (running several motor and servo controllers) can get bogged down in processing long enough to totally miss the Disable message before being shut down.
It’s worth noting that this same race condition can be observed in Teleop if there are too many motor/servo commands in the main loop.
Since this is a critical issue for fairness AND robot safety, I just thought it was worth mentionin this possible issue.
Phil.
Get a life? This IS my life!
