At the beggining of every round we have 15 seconds of autonomous code, and it need to be stopped somehow… Right?
This is my question: How to stop it? should I write at the end of the autonomous code in the “user_routines_fast.c” under
“User_Autonomous_Code()” the next line:
you dont need to stop the auto mode… when u are at the competition… ur I/O controller is hooked up to their computer…and they’ll switch it on… … if the switch is on… then User_Autonomous_Code(void) will be running… if the switch is off… then the User_Autonomous_Code(void) will not be running…
on the I/O u can trigger auto mode by connecting pins 5 and 8, i believe, on the port called “competition”
User_Autonomouse_Code() gets called every loop until the flag set by the Master Proc is unset. You don’t need to worry about ending your mode, it is done for you by the function no longer being executed. Get_Data_From_Master_uP() in User_Routines.c will be called once autonomous mode is over.
IFI has the pinout for the competition port available Here (PDF), if you’d like to construct a dongle. We used a dongle on 195, but I’ve heard it’s just as easy (in a pinch anyway) to stick a wire between the pins to access disable or autonomous mode.
razer: Are you familiar with how programming for the FRC works? it’s loop-based, not like any entry-level desktop programming (Visual Basic, .Net, PHP) you might have done. The loop is called every 23.6ms (is about, it’s been a while). so your code is executed every loop, and when autonomous mode is over, the loop is no longer called.
Correct, you (almost) never want to use a while loop in your code, since that’s not how the logic is setup. The program is based on each loop getting new data from the OI at the beginning, and setting the outputs at the END, and ONLY at the end. (Yes you could call putdata yourself, but lets not go there) A while loop will do nothing but lock up your program and eventually the watchdog timer will shut off the User proc and you’ll get a code error indicator.
razer et al: These programming PowerPoints explain some of the basic concepts of programming for the FRC. They are somewhat outdated as they seem to apply to the 2004 controller mostly, but the only real difference between the 2006/7 is a memory upgrade. These PowerPoints go through how the programming structure works, and some important things to know about.
…but don’t make a habit of doing it that way. Get a dongle. Build one yourself, or order Andymark’s. The competition port is not fused, and some pins are connected directly to the processor in the OI. If you touch the wrong two pins together, you may damage the OI.
Astronouth7303: You can use for() and while() loops much longer than 5 executions. The watchdog timer doesn’t seem to fire for a good 10ms or so. You can loop through more than 300 elements and write strings for each of them before the RC will reset itself. I’d be interested in knowing what the actual timeout is, but I don’t have access to an RC this year.
That, and a dongle is a good safety mechanism to have handy. We’ve had more than a few “runaway bots” during autonomous testing, especially when someone disconnected the shaft encoders while adjusting wiring.
Heck, I’m tempted to make a “deadman’s switch” dongle for some of our tests.
I made it a general rule that loops are NOT allowed in our code. If a loop is messed up then you have big problems on your hand. Besides why have a loop inside a loop to do the same functions a state machine can do or a timer variable