Timer Question

[lightning_blast]

Hi, our incredible plans to create an autonomous mode has failed (once again ) 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!!

[yoyodyne]

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

[lightning_blast]

Originally Posted by yoyodyne

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

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

[pheadxdll]

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.

[lightning_blast]

Originally Posted by pheadxdll

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.

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

[yoyodyne]

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."

[lightning_blast]

Originally Posted by yoyodyne

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."

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 .

[yoyodyne]

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;

[Stvn]

Originally Posted by lightning_blast

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 .

If true = 1, then yes.

[Alan Anderson]

Originally Posted by yoyodyne

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...

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.

[lightning_blast]

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

[yoyodyne]

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?

[Alan Anderson]

Originally Posted by yoyodyne

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.

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.

Do you know what the timing is for 2007?

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).

[yoyodyne]

Originally Posted by Alan Anderson

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.

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.

[Mark McLeod]

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?)