I am having an issue where the robot does not stop when the match is over. All normal motors (DC) will run for 2-3 seconds after the match ends. We are using a Continuous Servo this year and this motor will never stop. It just runs and runs until you reconnect or disable power.
I always thought that the FCS sends a disable command before it terminates the program. However, this assumption does not appear to be accurate. We have logic in the disable case to stop the robot and if this was run then everything would be fine. Also, some have suggested that it is an firmware issue but I don't think so.
Can anyone explain what happens when the match ends and how to resolve this issue?
Solved! Go to Solution.
Can you post your code? It sounds like your disabled case does not have the proper stop commands and your motors continue to run until the watchdog times out.
Also the continuous rotation servo behavior has been an issue for a while but isn't really a bug. For some history, servos used to deenergize at the end of the match. This behavior became problematic during the "Bowled Over" year when teams would successfully lift a crate only to have it release the instant the match was over. NI changed the servo behavior to remain energized. As a consequence, continuous rotation servos continue to rotate. If you add a "disable servos" block to your disabled case, that should resolve the issue.
I will post the code in a little bit. I have the disable case with the correct elements (I think). What I am finding is the the disable case is never run (as far as i can tell).
Thanks for the history that makes sense. In this years version you can't use the disable command with a continuous servo. It says that it is the wrong type of connection.
Thanks for the quick response this is good stuff.
Attached is my main drive program. I was not sure the best way to include my code so I hope this works. You will be missing a few subVI's that I created, but I am assuming you can just ignore these?
Hopefully this helps.
Thanks for bringing up this problem.
This issue is not necessarily due to incorrect user code, but due to a race condition between the field control system aborting the program and the disable case in the teleop program executing.
NI is in communication with FIRST about this issue, and I'll reply here next week when we have decided on a solution or workaround.
Thanks for your quick response. I am conserned as we have a competition this weekend and I know the FTA's will have an issue if it happens during the competition. Do you or first have a suggestion on how we should proceed? Will we be disqualified during our matches?
The best way to for sure avoid this problem is to stop touching the controllers 3 seconds before the match times out (The watchdog timer on the motor controller is triggered every 2.5). Bummer! I know. This is not an acceptable long term solution, but will get you through this weekend.
I have not heard of anyone being disqualified for this reason, though that certainly doesn't mean it hasn't happened.
Do you have an update on this issue? We made it through our last competition and are now working to prepare for our state competition. Any help you can provide would be appreciated.
I'm sorry it took so long to reply to your question. I was waiting until we got an official green light.
An updated FCS software will begin sending the disable bit 0.5 seconds before the end of the match. This provides ample time for the loop to complete and for the disable code to be run for any reasonable program.
The new FCS software has been uploaded to
http://www.usfirst.org/roboticsprograms/ftc/team-resources for your practices. As far as I know, any upcoming tournaments will use this version.
If your code needs less than 0.5 seconds to complete, it is of course possible to work around this in your teleop code so that you have a bit more game time, but do so with discretion.