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 "
")); \
DEBUG(("auto_counter(%d) >= %d ", auto_counter, x)); \
++auto_step; \
DEBUG(("advancing to state %d
", auto_step)); \
auto_counter = 0; \
}
#define AUTO_NEXT_STEP_COND(x,y,name) \
AUTO_NEXT_STEP(x,name) \
else if (y) \
{ \
DEBUG((name "
")); \
DEBUG((#y)); \
DEBUG((" (%d) ", auto_counter)); \
++auto_step; \
DEBUG(("advancing to state %d
", 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
) 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?
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