Hello
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:
autonomous_mode=0;
thanks a lot,
Nir.
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”
let me noe if that helps u
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.
ok thanks… so i just need to write my code, and it will be ended automaticly? i wont have to end it? ok… that really helps.
thanks again, Nir.
For testing, you can just get a dongle to plug into the competition port on your Operator Interface to turn the autonomous mode on and off.
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.
So basically, refrain from using loops within your code. You will not get the intended results.
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.
Look in main.c to see how the switch from autonomous to operator control is performed.
…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.
Hence ‘in a pinch.’
main.c determines how the autonomous code and the user code is called.
The autonomous routine actually has it’s own internal loop (at least it did previously). The key is that the loop calls getdata() and putdata().
If you’re new to this, just stick with this: never use a for() or a while().
If you’ve done this before: use only very short (eg, to iterate through an array of 5) for() and while()'s.
If you know what you’re doing: just ignore me and do your thing.
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.
Yes, I’m quite aware of that. See the third item.
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.
assume the worst. include a deadmans switch on the controller, just in case. that way, if the program works, you smile!
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
Ok but How can I test it at school?