getting stuck in autonomous or hybrid on the field

[GrimmReaper]

Hi everyone,

I just wanted to add a note from 2046's issues in Portland last weekend. We had some major problems with our autonomous mode while on the field in Portland. The diagnosis from the FTA was that our robot was getting "stuck in autonomous mode" and "not exiting autonomous mode" looking at the charts tab of our driver station we could see where FMS requested autonomous mode then requested teleop mode, however it also showed our driver station go into autonomous mode, but never switch to teleop mode - our driver station stayed in autonomous mode throughout the entire teleop mode. Our bot was motionless after it finished it's autonomous routine - very sad.

Additionally several other teams had suffered similar issues with autonomous not "exiting" properly. Some of them simply disabled their autonomous routines others found problems when simply running their autonomous manually and were able to fix those in the pits. Ours was a bit different as everything worked manually - even in practice mode, but not when FMS controlled.

we spent all day friday trying to work out the possible causes. We luckily had an extra laptop and a copy of FMS Light handy - we configured that laptop as an FMS server with the correct IP 10.0.0.5 and tethered it to the robot along with our driver station in the pit - we were able to replicate the scenario that way where we saw FMS request teleop but the robot stayed in autonomous.

We found two possible causes of the issue during our testing. We're programming in c++ this year and our while loop for autonomous originally looked like this :

		while(IsAutonomous())
		{
			if(IsEnabled())
			{
				...				
			}
			Wait(0.005);
		}

Skunkworks 1983 came over to lend a pair of eyes to the problem (thanks Skunks!) and noted that they had both checks for autonomous and enabled as conditions for the while loop, so that if either was not true it would exit which made good sense and appeared to be a possible source of the problem - when autonomous is over it gets disabled, then switched to teleop - i believe we got disabled but never saw the driver station switch to teleop mode, so this change forces the autonomous routine to exit once disabled even though the driver station feels it is in autonomous mode still. So the updated loop looks like:

		while(IsAutonomous() && IsEnabled())
		{
			...			
			Wait(0.005);
		}

That seemed to alleviate some of our issues with the autonomous getting stuck, additionally we did find one part of our imaging stuff which was mostly for troubleshooting that appeared to be throwing errors occasionally. our theory was that might have been throwing an exception during autonomous and thus stopping the robot from reacting to further instructions... We got rid of that piece to be safe.

After these changes we were working fine and we were able to have a very productive Saturday.

Hopefully no one else will run into similar issues, but if you do I hope this helps.

Good luck everyone!

[Greg McKaskle]

You don't mention whether this was done, but I highly highly recommend trying a practice session. From what I've seen, it doesn't usually take an FMSLite setup to provoke the error. Bugs are never good, but reproducible bugs are the best kind ... of bugs.

Greg McKaskle

[GrimmReaper]

that's a good point. I know we had run practice mode successfully just before Friday, so i think our minds skipped right over that when trying to reproduce the issue, and we did just so happen to have everything we needed for an FMS Lite setup - so it was pretty simple to test that.

But I agree it would have been good to know if it would have had the same issues in practice mode as well.

thanks!
Jon

[gnunes]

I will bet a cup of coffee that your problem was caused by the fact that your Autonomous VI ended on its own. When your Auton code has finished doing everything it has to do, put it into an infinite loop (containing a 10 or 20 millisecond delay) so that the VI never stops.

I saw this exact problem at a Mid-Atlantic regional event (on somebody else's robot). The problem went away when they added that infinite loop as I outlined above.

The problem comes when the robot code tries to stop an Autonomous VI that is already stopped. Looking at the Framework code, I can find no reason why this should be a problem, but nevertheless it appears to be one that only appears when connected to the FMS.

[joelg236]

Just curious (never looked at c++), does the wpilib for c++ have two classes like in Java? (SimpleRobot, IterativeRobot) If you used IterativeRobot, you could use teleopPeriodic() and autonomousPeriodic(), and not ever worry about bugs like this. (from your code, it looks identical to the purpose of Periodic methods)

[Greg McKaskle]

To clarify, the original post wasn't about LV, and there is really no issue with the auto VI finishing early. It shouldn't matter either way, but it is not required to keep the auto VI running, and I wouldn't see how this would resolve any "getting stuck" issues.

If you do not keep it running, the abort code will fail and will then start executing teleop as usual. The default LV code most years does end early, and we have never seen issues with that.

One issue that LV had last year that may have been involved in your issue had to do with CAN. If a robot used CAN during auto, there was a chance that the CAN session was locked when auto was aborted. This would result in the CAN device not being available during tele and would often lock up the entire robot. It wouldn't be stuck in auto, but in the first packet of tele. That issue was corrected for 2013. The abort procedure will now acquire all CAN sessions before it aborts -- ensuring no other code has them. And after the abort it releases all. If a team starts to use semaphores in its own construction, beware that abort doesn't know about them and the same thing could happen.

Greg McKaskle