Timer Question

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