Now if only someone (HINT) could add in Phils battery code.
Now I have a question, Am I the only one that doesn’t believe a disable command will stop any of the templates in autonomous? It seem that anything you put in the autonomonus section will completely run before the bluetooth is checked again for a disable command. It seems some sort of parallel loop needs to be added to check the bluetooth and disable the autonomous. To me the teleop works because you continuously loop through the code and check for the disable command.
I agree 100%. I’m all for well defined rules and consistency, but these new templates are no better than the last ones.
There are some real wacky things in them: But before I start done that list… remember that they are only “Templates”. They cannot be run “as-is”, especially the Autonomous one. Therefore by definition they need stuff added to them. Since I have yet to be able to get a defined list of what is, and is not permitted in the code I don’t really see how they provide much more than a “guideline” for code development.
So to follow that up with examples…
Teleop template
The Teleop template makes the assumption that the single motor controller and single servo controller are plugged into a single NXT port.
We have two motor controllers (rule legal) and I have all three of my Hitechnic controllers plugged into different NXT ports. So right away I can’t use the template “AS-IS.” We either need to add more port/controller wires, or (as we chose to do) we encapsulate my drive and servo commands into their own VI’s so I don’t need to pass around all those constants. (Please don’t force me to dumb down our code)
The teleop template displays the words “TeleOperated Code” on the NXT screen… every time around the loop. Yet this never changes, so why waste those valuable CPU cycles. Once at startup should be enough.
In the teleop template, the Mode flag (tele/auto) from the Contol station is being passed into the inner most case block, but not being used. So, if the program was started incorrectly during the Autonomous period, it would teleop code anyway…
I can’t tell if the creator wants us to emebed Auto code in here or not… the instructions imply NO, but the code implies YES…
Auto Template
The Auto template makes the assumption that the single motor controller and single servo controller are plugged into a single NXT port. Same argument as before.
The Auto template displays the words “Autonomous code is…” on the NXT screen… every time around the loop. Same argument as before.
The Mode flag (tele/auto) from the Contol station, AND data from the gamepads is being passed into the inner most case block, but not being used. Gamepad data is clearly redundant in Auto, so why it it there?
The “Disabled” case block is clearly an “exampler” of what should be done, but since I have extra motors I need to add code. Once again… it’s only a template:)
To address the point of “Will the disable input shut down Auto code”? I’m completely in agreement with you.
What the Auto Template fails to address (and that I’ve tried to raise several times) is that if people write their auto code a one long sequence of movements (which is most natural), the inner auto block WILL NOT exit until it’s done. Which means that it will NOT see a new bluetooth command from the control station, which means it WILL NOT disable untill it’s done.
So if the “Software Inspection” terminates Auto after only 10 seconds, most programs will continute to run their course up to the full 30 (or beyond).
I agree that some additional “loop/thread” must be included so that the bluetooth and drive-code can run in parrallel. This is what I currently have, and it means that I can at least disable my code after each movement.
However, if FIRST decides that we MUST follow the template structure, then I’ll begrudgingly put it all in the main case block and wait for them “FAIL” my code because it doesn’t stop in time during auto inspection.
For anyone who doubts this analysis, I suggest you get an FTC robot with encoders on the wheels and then put a sequence of 4 “Fixed Distance.VI” commands in the Auto code section. Now see if you can stop them running by “Disabling” the robot once they have started.
The one GREAT thing in all of this is that they have released the Field Control software so we can double check our assumptions, rather than just “hoping” to be compliant.
Hi Phil (and others): And here’s where you’ll be proven wrong. At the end of Autonomous, the FMS exits the autonomous program running on the NXT. Your code will definitely stop. The question then becomes: What happens when you exit the NXT code and you have full power applied to the motors? Do the motors stop? I think so. I believe the same thing happens if the bot is disabled by the FMS as well as at the end of teleop.
OK, yeah… I didn’t think of that… but I would have discovered it when I tried the cool FMS program
If you are just issuing a regular move motor command, there is a 2.5 second timeout on the Motor controller, so it will stop fairly quickly.
However, the Fixed Position command disables this timeout, and the NXT does a 10 second timeout instead. So if the NXT gets stopped during one of these commands, the robot will continue until it gets to it’s encoder target… or forever, if it runs into something.
I know that autonomous will stop at the end when they cut the autonomous program, but…
In the write ups FIRST states they want to be able to disable your robot (I assume only one robot and the rest on the match continues) in autonomous. Certainly these templates or any other FIRST has put put will not do this with FTC Controller Station. Will it happen with the FMS??? May be if instead of disable they cut off the autonomous program on just the one robot?!?
A little story on about the old templates…
At the VA Tournament our 3165 robot always did a little spin dance when the autonomous period ended. We knew it was not in our autonomous code. This bugged me but I figured it was one of the motor controller issues. Fortunately it was short enough noone else seemed to notice. Well, when we were changing to the new templates, we notices we had some test code in the autonomous section of our teleopedated code, which evidently ran when the FMS switched to teleop.
