Timer Question

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

[ay2b]

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)

#ifndef __AUTO_NEXT_H__
#define __AUTO_NEXT_H__

#define AUTO_NEXT_STEP(x,name)                                              \
    if (auto_counter >= x)                                                  \
    {                                                                       \
        DEBUG((name "\r\n"));                                               \
        DEBUG(("auto_counter(%d) >= %d    ", auto_counter, x));             \
        ++auto_step;                                                        \
        DEBUG(("advancing to state %d\r\n", auto_step));                    \
        auto_counter = 0;                                                   \
    }

#define AUTO_NEXT_STEP_COND(x,y,name)                                       \
    AUTO_NEXT_STEP(x,name)                                                  \
    else if (y)                                                             \
    {                                                                       \
        DEBUG((name "\r\n"));                                               \
        DEBUG((#y));                                                        \
        DEBUG((" (%d)  ", auto_counter));                                   \
        ++auto_step;                                                        \
        DEBUG(("advancing to state %d\r\n", auto_step));                    \
        auto_counter = 0;                                                   \
    }

#endif // __AUTO_NEXT_H__

Somewhere above your autonomous function, declare these variables:

// These are used for state in autonomous mode
static unsigned int auto_counter = 0;
static char auto_step = 0;

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

void User_Autonomous_Slow_Loop(void)
{
    auto_counter++;

    switch (auto_step)
    {
      case 0:
        robot_drive(127,192);
        AUTO_NEXT_STEP(120, "drive forward");
        break;

      case 1:
        {
            bool turn;
            turn = robot_turn_to_angle(90);
            AUTO_NEXT_STEP_COND(400, turn, "turn robot");
        }
        break;

      case 2:
        robot_all_stop();
        break;
    }
}

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

if (timer < 120)
{
    // drive forward
} else if (timer < 400)
{
    // turn
}

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