I’ve had several instances where our robot continues to run at the end of of Teleop.
It appears that the Teleop program is being killed before our program has a chance to receive or respond to the Disable command. So, if we are sending driving commands to the DC Motor controllers, they continue to run until the 2.5 Sec timeout shuts them down.
Has any one else seen this sort of thing?
We are uising Labview, and have quite a few motor controllers so the program may not be looping extemely quickly.
Also, we’ve had a couple of instances where the FCS loses connection with the Game Controllers (the FCS screen indicates that it is missing Joystick Messages) but in one instance the robot continued to drive forward, which implies that the last joystick command was being resent, despite the fact the the FCS knew it was gone. Seems like the FCS should have either stopped sending data (to cause the Robot to go offline), or it should have sent null joystick commands. As it was, the robot ran into the wall, and smoked a motor before we could shut down the FCS.
This used to happen to us all the time with LabView. We had two main problems while using LabView:
The robot would never run properly when we were using two controllers. During “Hot Shot”, if we were trying to move the robot while using our pitching-machine style shooter, and the shooter was already spinning, it would not stop spinning until the other controller stopped moving the robot, even if on controller one the spinner was stopped.
After each match, the program would keep running for a few more seconds. So, once again, in Hot Shot, we kept shooting into the offield goal even after the game was over which gave us some dirty looks from the refs
My recommendation would be to try robotC with a simple program and see if you get the error message again.
This was how the “day one” design for LabVIEW (and ROBOTC) work. And, AFAIK it is still the current implementation. ROBOTC maintains a map of which HiTechnic motor controllers are equipped and as part of the “program has ended” code stops them. LabVIEW does not keep such a map and relies on the 2.5 (or is it 2.0?) second watchdog timer in the motor controller to shut down. This occurs at the end of both autonomous and teleop.
I always thought that the LabVIEW implementation was unfair as it extra couple of seconds of motor movement might potentially allow a scoring activity to complete.
No, you’re not correct. There is code in the Labview template (it’s FTCDisableRobot.vi) for identifying which motors need to be shut down when the robot is disabled, but It seems to depend on what else is running as to whether that code gets time to execute.
I still feel that the FCS is not giving the programs enough time to execute the motor shutdown before it kills the program. I did some tests, and a simple program with not many other tetrix commands would shut down the drive correctly when the match ended. But once I added code for the other motors that ran all the time in a different loop the drive system didn’t shut down all the time. I play with adding different delays into the other loops, but I could not get reliable operation.
I guess the trade of is, if they wait too long between disbling the robot and shuttiong down the program, the team might try to take advantage of that delay to do other stuff. Still not foolproof.
If only there was a way for the NXT Firmware (not the running program) to broadcast an automatic motor shut-down whenever a program with tetrix commands was terminated.
Last year, while we were using LabVIEW this caused us some problems. We ended up coding our own stop in our program a few fractions of a second before the match was due to end. That way we stopped all the motors just before the FCS issued the stop and LabVIEW maybe, or maybe not stopped things. Giving up a few milliseconds for a clean stop was a good tradeoff for us. It’s a 2 minute round so we just ran a timer starting when we saw teleop running.
For what it’s worth, at the Annapolis MD Qualifier, the SW Inspection team was specifically checking for correct motor stops at the end of Auto and Teleop. I did see some teams fail this, and they had to go back to their code and correct it. So, ensuring is real stop is something that everyone should check before they leave for competition.
edit: In Fact, doing a complete run through the inspection check-list before you leave for competition can be a life-saver HW and SW
This tells me that FIRST should create a “Kill at 1:57:050” VI for teams to put into their code as it is obviously a big problem. Or they should out right fix the issue and do this the correct way…
Not sure exactly which “this” you are referring to, but if it’s the run-on problem, I think it’s a combination FCS timing, the labview template, and how the programmer writes their code.
This year’s LabVIEW template used button events, rather than button states, so there is not a lot of motor control code running at any time, so the program is looping pretty fast, and can shut down the motors in response to a disable command quite quickly.
If the programmer has added a bunch of loops that read buttons and control servos (sending commands all the time) the drive loop gets slowed down to the point where it sometimes doesn’t see the disable command before the FCS actually kills the program. In this instance, the Motor Controller keeps running the last issued command until it times out 2.5 seconds later.
I think a slightly longer delay between disable and kill in the FCS would solve this problem.
Just a note. RobotC does not have this issue. I have not looked at the source of “JoystickDriver.c,” but I will do so and post my findings here (Hopefully teams will be able to apply this to Labview. I would, except that I only know RobotC).
HW and SW