Timer Question
 

Hi, our incredible plans to create an autonomous mode has failed (once again :D ) and im thinking we will have to rely on timers again. Last year, we used EasyC, but this year we're using MPLab. We have the idea of having a timer based on the number of loops. We believe each loop is 26.2 ms, so can we take this number and loop it xx times and increasing a counter each loop until it reaches the specific time?

example, we want to move 5 seconds forward
5s = 5000ms = 190 loops.

static int timer = 0;
**move forward**;
if (timer <190)
timer = timer +1 ;
if (timer >=190)
**stop**;

Thanks!!

Re: Timer Question
 

That would work except that I think your autonomous code will start running a little before the disabled_mode is turned off so it will time out faster as a result. You could add

if (disabled_mode)
timer = 0;

in your autonomous loop and then it will not actually start to increment until the autonomous period actually starts.


If you want you can use a more capable e timer capability. I posted the team 116 timer library which allows you to run up to 10 software elapsed timers and 10 event timers that actually will call a routine when they time out. If you are interested in that look toward the bottom of this thread.

http://www.chiefdelphi.com/forums/sh...dware+t imers

Good luck,

Greg

Re: Timer Question
 

Yes, that will work.

About 38 cycles = a second so you could do something like:

int delaySeconds = 38 * sec;
int counter = 0;
MOVE_FOWARD;

if(counter < delaySeconds) {
counter++;
}else{
STOP_MOVING;
}

Remember to declare the int's at the top of the routine and good luck! :)

Note: You could use software timers like the one posted above, but just for simplicity, fastness, and realiblity, it won't matter if you choice either one.

Re: Timer Question
 

wow thats a lot. we'd definately consider it if we had the time :) but we are VERY short on time, planning to program this on the spot so we have a moving robot in autonomous =D (even if it does nothing useful). so i think its best for us to stick with a simple timer code. By the way, u said there may be some problems with disabled mode? is the

if (disabled_mode)
timer = 0;

the actual code for it? as in, can we use this exact code and ensure the program will work? thanks

Re: Timer Question
 

thanks for the suggestion, the delaySecond assignment is definately useful. :P

Re: Timer Question
 

There is a global variable named "disabled_mode" that is set true for a while after autonomous_mode is set to true and your autonomous code will start. What will happen is you will turn on PWM output for the motors but nothing will happen because the robot is disabled. The 15 sec autonomous period does not start until disabled_mode is set to false.

Check out Mark's post on this thread.

http://www.chiefdelphi.com/forums/sh... onomous_mode

"
Re: _mode flag summary??

--------------------------------------------------------------------------------

Last year we reset our autonomous whenever the robot was disabled. The drivers didn't have to remember to reset for the second practice match.

Last year the actual sequence at the SBPLI Regional was:
Disable bit set before the match started
Both disable and autonomous bits set
Then disable was turned off to start the autonomous mode
Finally the autonomous bit went off as the user_mode came on
One team had their autonomous timer ticking off while the robot was disabled at the beginning of the match, so the robot always thought it was partway or completely through the 15 seconds, before they were enabled and allowed to move."

Re: Timer Question
 

That is an excellent idea. Here's how I've been implementing it for the last few years; first the code, then an explination:

First off, I have two macros, all defined in auto_next.h
("DEBUG" is a macro defined elsewhere which will either call printf, or do nothing)

Somewhere above your autonomous function, declare these variables:


And finally, in your slow loop autonomous function, do something like this:

In your slow loop function, you basically have a simple state machine. First your robot does whatever it does while in state 0, then state 1, etc. In the pseudo-code above, in state 0 it will drive straight forward at half speed; in state 1 it will turn to 90 degrees; in state 2, it stops.

The two variables, auto_step and auto_counter keep track of the state. The macros help manipulate them. AUTO_NEXT_STEP two paramaters, a time, and a string which is the name of the current mode. Each time through the slow loop, the auto_counter gets incremented. If it reaches the time paramater of AUTO_NEXT_STEP, the counter gets reset to 0 and the auto_step gets incremented.

The advantage to doing it this way over something like a bunch of chained if statements
is that you can easily change the time spent in one step without having to change the time in any of the other steps. Suppose you decide that you only want to drive forward for 100 counts rather than 120 counts. With this two-variable macro approach, you simply change the argument to AUTO_NEXT_STEP to 100 instead of 120. With the chained ifs, you have to change every single value.

The AUTO_NEXT_STEP_COND macro is like AUTO_NEXT_STEP, except that it also takes a condition. If you have a function like "robot_turn(90)" which returns a boolean value of TRUE when it is completed and FALSE when it is not, then you can use AUTO_NEXT_STEP_COND to advance to the next state as soon as a condition is met, rather than waiting for a time. This is particularly useful if you have functions to drive a certain distance based on encoder counts, or move an arm to a certain position, etc.

Good luck!

--AJY

Re: Timer Question
 

ahh sorry im new to C, and so is everybody on my team. so by writing:

if (disabled_mode)
timer = 0;

is the same as:

if (disabled_mode == true)
timer = 0;

right? thanks again :P.

Re: Timer Question
 

For practical purposes, yes,

if(disabled_mode) // not disable_mode - my bad

is really the same as if(disabled_mode != 0)

If you look at ifi_default.h you will see the following defines:

#define FALSE 0
#define TRUE !FALSE

It might make more sense if the way you coded it was simply in your logic to increment timer

if(!disabled_mode) // disabled_mode == FALSE
timer += 1;

Re: Timer Question
 

If true = 1, then yes.

Re: Timer Question
 

Contrary to what Mark McLeod describes in his post two years ago, I have never seen both the disabled and autonomous flags simultaneously. When we close the "disable" switch on our competition port dongle, the robot controller goes into disabled/teleoperated mode, regardless of the state of the "enable autonomous" switch. The User_Autonomous() function does not get called until the robot is enabled with the "autonomous" pin active.

Re: Timer Question
 

thanks for all of your help guys :P. im going to.. try out an autonomous tomorrow (GTR regionals :D). i doubt we'll do so well but FIRST isnt all about winning right? :yikes:

Re: Timer Question
 

Alan,

I don't know for a fact what the competition port sequence is this year but User_Autonomous_Code() gets called from main() if autonomous_mode is set regardless of the independent disabled_mode flag. It seems to me that to insure that Process_Data_From_Master_uP() is never called until the end of autonomous mode then disabled_mode and autonomous_mode would have to be set true at the same time. Maybe not for long but autonomous_mode has to already be set before disabled_mode is turned off.

We aren't taking any chances so we wait until disabled_mode is turned off and autonomous_mode is turned on to start our autonomous play.

Do you know what the timing is for 2007?

Re: Timer Question
 

My testing two years ago shows that the flags are not independent. When the "disable" pin on the competition port is grounded, the disabled_mode flag goes active as expected, but the autonomous_mode flag remains inactive whether or not the "autonomous" pin is grounded. I can state with absolute certainty that User_Autonomous_Code does not get called until disabled_mode goes away, indicating that being disabled keeps autonomous_mode from being true.
The timing of the pins is not particularly important. The "autonomous" pin obviously activates some time before the "disable" pin is released, but your code will see the flags change state simultaneously at the beginning of the match (and at the end of the autonomous period).

Re: Timer Question
 

Thanks for that information. Given that the default user code does not support that behavior and Mark's post I assumed that the flags as the user processor saw them were a direct reflection of the OI competition port pins. We need to take another look at our logic to latch the OI autonomous play and initial position switches and the "hand pointed" camera pixel offsets for one or both targets.

Re: Timer Question
 

My post applied to earlier field control. I found it to have changed to what Alan saw 2005 and after.

(I'm waiting for my teenager to leave for our regional this morning. Did I ever take this long to get ready in the morning?)