Autonomous Code Example

[Matthew_H]

We seem to be have a hard time finding where to input code for any autonomous code in the 2004 Edu controller code. Is there anyone out there that would be willing to share their code they have been working to help us get started with ours?

Thanks,
Matthew

Ubergeeks

[GregTheGreat]

Originally posted by Matthew_H
We seem to be have a hard time finding where to input code for any autonomous code in the 2004 Edu controller code. Is there anyone out there that would be willing to share their code they have been working to help us get started with ours?

Thanks,
Matthew

Ubergeeks

Here ya go... this should help.


http://www.innovationfirst.com/FIRSTRobotics/documentation.htm

-Greg The Great

[Matthew_H]

We have been reading the manual from innovation first but I was hoping to look at some code examples of working autonomous code.

[GregTheGreat]

Originally posted by Matthew_H
We have been reading the manual from innovation first but I was hoping to look at some code examples of working autonomous code.

here is the def. if that will help....

http://www.innovationfirst.com/FIRSTRobotics/pdfs/EDU_Default_Code_10-28-2003.zip

-Greg The Great

[Jeremy_Mc]

We have the default code.

We're having difficulties getting the RC to respond to anything. The PWM's just stay at 127 no matter what values we try to enter into them and/or change with code.

We downloaded the EduController from the White Papers and tried to dissect that, but it was a bit over our heads seeing as how we're not exactly the most experienced with C.

What we really need is to know WHAT to put...I think we've figured out where to put it (Mostly because it says "Put your own code here"...but yes.), so if anyone out there can show us a brief example of how to make the robot go forward. I think we're merely changing the wrong variables (clinging to my PBASIC p2_y and pwm02 variables...), but maybe I'm just inputting the code wrong?

Thanks for any help you can offer. :)

[GregTheGreat]

Originally posted by Jeremy_Mc
We have the default code.

We're having difficulties getting the RC to respond to anything. The PWM's just stay at 127 no matter what values we try to enter into them and/or change with code.

We downloaded the EduController from the White Papers and tried to dissect that, but it was a bit over our heads seeing as how we're not exactly the most experienced with C.

What we really need is to know WHAT to put...I think we've figured out where to put it (Mostly because it says "Put your own code here"...but yes.), so if anyone out there can show us a brief example of how to make the robot go forward. I think we're merely changing the wrong variables (clinging to my PBASIC p2_y and pwm02 variables...), but maybe I'm just inputting the code wrong?

Thanks for any help you can offer. :)

If you like Pbasic, see if you can get a converter. I believe they make them...try a download site, or do a websearch. Then you can run re-declare in C. It might make things simpler on you. I really have not got into the EDU programming yet, I will look into it, but I am not making any promises.

Possibility: Maybe you have a line in your code, where you declare your variables... It might be set to neutral, and whenever you go into your loop it just keeps it at neutral. Check that first, that often is the problem.

-Greg The Great

[Noah]

ok, it goes something like this (in my mind)

1. Check to see if the autonomous_mode bit is set. You may opt to skip this part while testing your auto-code, or alternatively you can try this (http://www.innovationfirst.com/FIRSTRobotics/pdfs/Competition_Port_Pinout_Guide.PDF) .

2. The output variables for the PWM outputs are PWM01 - PWM08. A simple statement like
PWM01 = 255;
PWM02 = 255;
should work.

3. You might try creating functions such as
go_forward()
{
PWM01 = 255;
PWM02 = 255;
}
turn_right()
{
PWM01 = 255;
PWM02 = 0;
}

and such. Something I suggest even more is that you create your own aliases in alias.h in ways such as

#define leftDriveMotor PWM01
#define rightDriveMotor PWM02

and then use the leftDriveMotor and rightDriveMotor variables in all of your autonomous code. That way, when your electrical guy accidentally misreads the schematics and plugs the left motor into PWM 2 and the team decides its a software bug, it's all of three keystrokes to rectify. (This seems to happen a lot in my team... grrr)

[GregTheGreat]

Originally posted by Noah
ok, it goes something like this (in my mind)

1. Check to see if the autonomous_mode bit is set. You may opt to skip this part while testing your auto-code, or alternatively you can try this (http://www.innovationfirst.com/FIRSTRobotics/pdfs/Competition_Port_Pinout_Guide.PDF) .

2. The output variables for the PWM outputs are PWM01 - PWM08. A simple statement like
PWM01 = 255;
PWM02 = 255;
should work.

3. You might try creating functions such as
go_forward()
{
PWM01 = 255;
PWM02 = 255;
}
turn_right()
{
PWM01 = 255;
PWM02 = 0;
}

and such. Something I suggest even more is that you create your own aliases in alias.h in ways such as

#define leftDriveMotor PWM01
#define rightDriveMotor PWM02

and then use the leftDriveMotor and rightDriveMotor variables in all of your autonomous code. That way, when your electrical guy accidentally misreads the schematics and plugs the left motor into PWM 2 and the team decides its a software bug, it's all of three keystrokes to rectify. (This seems to happen a lot in my team... grrr)

that looks right, (just agreeing) usually problems with programs are variables are not defined, or bits on on, etc. or programs that get caught in loops, emitting certain parts.

Check the obvious before changing the program.
Did you debug?

-Greg The Great

[Sachiel7]

That's a nice way to start, but you have to code out your autonomous routine, and that can make it harder to tweak.
The method I use is arrays. Yes, fun old arrays.
For Example:
const int Func[13][3] = {
{84, 170, 40},
{170,170,60},
{84,170,20},
{170,170,30},
{84,170,20},
{170,170,30},
{84,170,20},
{170,170,60},
{84,170,40},
{170,170,30},
{84,170,20},
{170,170,30},
{84,170,40}
};

Then you only need a simple strand of general cod in your Process_Master_uP routine:

if (F_Count < MAX_FUNC)
{
counter ++;

if (counter > Func01[F_Count][2])
{
counter =0;
F_Count ++;
}

if (F_Count == MAX_FUNC) //Comment out this if for no loop.
{
F_Count = 0;
counter = 0;
}

pwm02 = Func01[F_Count][0];
pwm01 = Func01[F_Count][1];
}

Now, you could shorten this down to a 2D array, since all the variable in Column 2 are the same. I left it open because I change that array around alot. You could increase the dimensions so several different auto modes could be within one array, and the switch could be applied to one array element.

(BTW, for those of you out there who would like to tinker a bit, what does the array listed above do? HINT: It writes something. PWM01 is the left drive(facing reverse) and PWM02 is the right)

Now, someone may come along and tell you that it's a rough process mapping out all your array values and hard coding them in, but I solve this with my own program, that I'm working on called eduCAD. The program gets a spec sheet on your edubot, generates some basic variables for use and calculation etc. Then you draw out the path of motion for the bot. It then calculates all the data to form a final array which is dumped to a custom include file that contains different auto arrays.
I plan on posting eduCAD on CD once it's more complete. I just planned on making it more usable with the full robot as well, however, and I'm working on making it a win32 prog(rather than DOS :D )

Anyway, if you have any specific questions, just PM me, I'm more than willing to help with any programming issues anyone's having.

[GregTheGreat]

Originally posted by Sachiel7
That's a nice way to start, but you have to code out youmodes could be within one array, and the switch could be applied to one array element.

(BTW, for those of you out there who would like to tinker a bit, what does the array listed above do? HINT: It writes something. PWM01 is the left drive(facing reverse) and PWM02 is the right)
making it a win32 prog(rather than DOS :D )

Anyway, if you have any specific questions, just PM me, I'm more than willing to help with any programming issues anyone's having.


Is the count automatically defined, or does it need to be custom inserted into the loop?

-Greg The Great

[Sachiel7]

I'm assuming you mean the counter variable. Upon initing the prog, it's set to 0. It counts up until it reaches the counter time limit for a specific function (the third array element)
MAX_FUNC is the total number of functions. You can modify the code by commenting out the reset routine so that it won't repeat.
Since this is in user_routines.c, it clocks every 17ms which means 58 cycles is about 1 second. The final array element is the number of cycles for the first two elements to be outputted to the motors.

ie: {127,130,60}
^ ^ ^
Left Out || Number of Cycles to output
Right out

If your'e talking about F_Count, that's just the function you want to start with. It's defined at the beginning as 0 usually, but you can have 2 different modes in one array by refining the F_Count's start value and the MAX_FUNCs value

I hope that answers your question.

[GregTheGreat]

Originally posted by Sachiel7
I'm assuming you mean the counter variable. Upon initing the prog, it's set to 0. It counts up until it reaches the counter time limit for a specific function (the third array element)
MAX_FUNC is the total number of functions. You can modify the code by commenting out the reset routine so that it won't repeat.
Since this is in user_routines.c, it clocks every 17ms which means 58 cycles is about 1 second. The final array element is the number of cycles for the first two elements to be outputted to the motors.

ie: {127,130,60}
^ ^ ^
Left Out || Number of Cycles to output
Right out

If your'e talking about F_Count, that's just the function you want to start with. It's defined at the beginning as 0 usually, but you can have 2 different modes in one array by refining the F_Count's start value and the MAX_FUNCs value

I hope that answers your question.

Thats what I thought, Can u do a "reserve" counter like a go-sub like in P-basic? I figure that I better find these things out now before build.

Thanks,

-Greg The Great

[Matthew_H]

I just received this email from FIRST.
By now most teams have received the FIRST EDUrobobtics kit or the new upgraded control system. FIRST is proud to unveil the new EDUrobotics System Guide developed specifically for FIRST by Carnegie Mellon University and The National Robotics Engineering Consortium. Please go to our homepage at www.usfirst.org and under "What's New" click on the EDUrobotics System Guide to get started. This interactive website is an excellent way for your team to learn C programming and other important FIRST Robotics content as you prepare for the upcoming competition season.

The website will be adding modules in the upcoming days. Just click on Content Updates for more learning modules and other information. All teams will receive a CDrom of this material, including Challenges you can run in your own classroom, in the kit of parts in January.

We hope you find the EDUrobotics System Guide helpful not only preparing your team but also introducing robotics to others.

Go Teams!






Matthew

Ubergeeks

[Sachiel7]

What do you mean by "reserve" counter, and how does that relate to a gosub?
You can pretty much do everything (and more) with the new controller that the old one could do.

[GregTheGreat]

Originally posted by Sachiel7
What do you mean by "reserve" counter, and how does that relate to a gosub?
You can pretty much do everything (and more) with the new controller that the old one could do.

Thats what I was refering to, having a gosub type of design as a "reserve" counter.

I am talking about compiling the code, with a "reserve" without using something simple like indicators.

-Greg The Great

[Sachiel7]

Oh, well, I suppose you could easily implement something like that. You could have it jump around based on specific timing values or such, if that's what you mean. Or if you just want event driven code (a sub for each function) that can be done as well. The main problem with Sub-Based auto modes is that you need a sub for each function you want to perform. You need to define a way to count how long it should last, and you need a way of defining the pattern it should take. This can easily begin to eat up your program and variable memory. My first auto program was set up to do this, and after it *worked* but it didn't do quite what it was supposed to, It took me a long time to tweak/fix it.
The main thing is, with this, you don't need to write any extra code, or anything. Just go to the start of the program and insert your array. That's it.
Since it's a pretty adaptive *little* program (not the excessive use of **'s :D) it doesn't take much at all to tweak. I can write out 15 different auto modes and have the program compiled within less than 5 minutes using this code.
Another thing about using arrays is that it's not Bot-specific. Basically you could have a prototype eduBot that performs a certain thing, but you'd need to change your speed/time variables for the larger one. Using the array method, you can just click and It's set for your full bot.
Anyway, I still like the idea of Sub-Structured Auto Modes, but I'm stickin' with my array code this year.
BTW, nobody's tried to guess what the sample array I posted earlier does...
Take a wild guess!

[GregTheGreat]

Originally posted by Sachiel7
Oh, well, I suppose you could easily implement something like that. You could have it jump around based on specific timing values or such, if that's what you mean. Or if you just want event driven code (a sub for each function) that can be done as well. The main problem with Sub-Based auto modes is that you need a sub for each function you want to perform. You need to define a way to count how long it should last, and you need a way of defining the pattern it should take. This can easily begin to eat up your program and variable memory. My first auto program was set up to do this, and after it *worked* but it didn't do quite what it was supposed to, It took me a long time to tweak/fix it.
The main thing is, with this, you don't need to write any extra code, or anything. Just go to the start of the program and insert your array. That's it.
Since it's a pretty adaptive *little* program (not the excessive use of **'s :D) it doesn't take much at all to tweak. I can write out 15 different auto modes and have the program compiled within less than 5 minutes using this code.
Another thing about using arrays is that it's not Bot-specific. Basically you could have a prototype eduBot that performs a certain thing, but you'd need to change your speed/time variables for the larger one. Using the array method, you can just click and It's set for your full bot.
Anyway, I still like the idea of Sub-Structured Auto Modes, but I'm stickin' with my array code this year.
BTW, nobody's tried to guess what the sample array I posted earlier does...
Take a wild guess!

I will take a guess, is it a bunch of 360's?

-Greg The Great

[Sachiel7]

Not quite....
This program writes something...
I built a small edu with just 2 motors and a marker in the middle...

[GregTheGreat]

Originally posted by Sachiel7
Not quite....
This program writes something...
I built a small edu with just 2 motors and a marker in the middle...

Well i see the inputs, I see the straight line.. I am thinking it is either your team number, or The Claw?

-Greg The Great

[Sachiel7]

Not quite...
Think "Typical intro program"...
The 1st array element is the left drive, and since the motor is backward, 0 if "forwards" for the robot. the second element is the right drive, 254 is forward for it. the final element is the timer, the number of cycles the first two elements are outputted. Try drawing it (sorta) or "cracking the code"
It's not that hard...
BTW-The first code like this I wrote was to write "RAPTAR" and it had 82 steps. Try coding THAT in sub-form! (BTW, I did, and I couldn't compile for some reason...lack of mem?)

[GregTheGreat]

I dont understand this input, is it a aliasis?

if (counter > Func01[F_Count][2])

-Greg The Great

[Sachiel7]

counter > counts the program cycles
F_Count > The Function Counter. If F_Count was 3 then your third array elements in Func would be performed.
For example:
F_Count = 5

Func[6][3] = {

{1,1,10},
{3,2,50},
{2,2,30},
{4,5,10},
{7,2,20},
{8,9,50}

};

F_Count means that we're looking at the fifth strand (7,2,20)
Func[F_Count][1] = Left Drive Variable
Func[F_Count][2] = Right Drive variable
Func[F_Count][3] = Wait until counter equals this before going on.
When Counter => Func[F_Count][3] then the counter is reset to 0 and F_Count is increased by one (++)
If F_Count = MAX_FUNC (The number of Functions, 6 in this case) then either loop or stop.

NOTE to those reading this post, particularly anyone not versed in C, C starts counting from 0 up as far as arrays are concerned.
ie: x[5] = {1,2,3,4,5}
The actual arrays of x are x[0]-x[4], while x[0]=1 and x[4] =5
That's why MAX_FUNC is the number of functions, it's checking to see if we've done everything before looping or stopping.

[GregTheGreat]

Originally posted by Sachiel7
counter > counts the program cycles
F_Count > The Function Counter. If F_Count was 3 then your third array elements in Func would be performed.
For example:
F_Count = 5

Func[6][3] = {

{1,1,10},
{3,2,50},
{2,2,30},
{4,5,10},
{7,2,20},
{8,9,50}

};

F_Count means that we're looking at the fifth strand (7,2,20)
Func[F_Count][1] = Left Drive Variable
Func[F_Count][2] = Right Drive variable
Func[F_Count][3] = Wait until counter equals this before going on.
When Counter => Func[F_Count][3] then the counter is reset to 0 and F_Count is increased by one (++)
If F_Count = MAX_FUNC (The number of Functions, 6 in this case) then either loop or stop.

NOTE to those reading this post, particularly anyone not versed in C, C starts counting from 0 up as far as arrays are concerned.
ie: x[5] = {1,2,3,4,5}
The actual arrays of x are x[0]-x[4], while x[0]=1 and x[4] =5
That's why MAX_FUNC is the number of functions, it's checking to see if we've done everything before looping or stopping.

Alright, I give up, I need to know what it is.

-Greg The Great

[Sachiel7]

The example I posted writes "HI" sorta like the typical "Hello, World!" programs. Here's A Breakdown:

{84, 170, 40}, //forward 5 inches
{170,170,60}, //Turn left 180 degrees
{84,170,20}, //forward 2.5 inches
{170,170,30}, //turn left 90 degrees
{84,170,20}, //forward 2.5 inches
{170,170,30}, //turn left 90 degrees
{84,170,20}, //forward 2.5inches
{170,170,60}, //turn left 180 degrees
{84,170,40}, //forward 5 inches
{170,170,30}, //turn left 90 degrees
{84,170,20}, //forward 2.5 inches
{170,170,30}, //turn left 90 degrees
{84,170,40} //forward 5 inches

I'll try and find some of the sheets it wrote on and post it here.

[seanwitte]

If you use the gyro and a shaft encoder then you can make your commands simpler AND scalable. Break it down into three commands: Drive, Turn, and Stop. Drive will move forward a certain number of encoder ticks and turn will rotate a certain number of degrees. Here is a sample:


#define CMD_TURN 0
#define CMD_DRIVE 1
#define CMD_STOP 3
#define FORWARD 227
#define REVERSE 27
#define NEUTRAL 127

typedef struct {
unsigned int step;
unsigned char cmd;
int progress;
int target;
unsigned char prev_encoder;
} command;

void command_turn(command *cmd, unsigned int gyro);
void command_drive(command *cmd, unsigned char encoder);
void command_stop(command *cmd);
void command_run(command *cmd);
void command_next(command *cmd);

//rotate in place until target gyro "ticks" have
//passed. A gyro tick will be the difference between
//the value read and 512. Positive values are
//clockwise and negative are anti-clockwise.
void command_turn(command *cmd, unsigned int gyro)
{
//add current rotational velocity to progress
cmd->progress += gyro;
cmd->progress -= 512;

//clockwise
if (cmd->target < 0)
{
//got to the next command when target radians have passed
if (cmd->progress <= cmd->target)
{
command_next(cmd);
}
else
{
drive_r = REVERSE;
drive_l = FORWARD;
}
}
else
{
//got to the next command when target radians have passed
if (cmd->progress >= cmd->target)
{
command_next(cmd);
}
else
{
drive_r = FORWARD;
drive_l = REVERSE;
}
}
}

//drive forward until target ticks have passed
void command_drive(command *cmd, unsigned char encoder)
{
//increment progress when encoder goes from 0 to 1
if ((cmd->prev_encoder == 0) && (encoder == 1))
{
cmd->progress++;
}

if (cmd->progress >= cmd->target)
{
command_next(cmd);
}
else
{
drive_l = FORWARD;
drive_r = FORWARD;
}
cmd->prev_encoder = encoder;
}

//stop the robot
void command_stop(command *cmd)
{
drive_r = NEUTRAL;
drive_l = NEUTRAL;
}

//run this function against the command
//variable each time through the program
//loop. it will figure out which command to
//execute
void command_run(command *cmd)
{
if (cmd->cmd == CMD_TURN)
{
command_turn(cmd, analog1);
}
else if (cmd->cmd == CMD_DRIVE)
{
command_drive(cmd, IO16);
}
else
{
command_stop(cmd);
}
}

void command_next(command *cmd)
{
// you can fill this in
// look at the current step number in cmd
// and get the next command from your
// storage array.
}


With this system you can use a 2-D array of commands and target values instead of trying to work out the timing. You'll have to play around with the values to see how many gyro "ticks" there are in 90 degrees.

Say that 20000 gyro ticks is 180 degrees. Assume your wheel is 4" in circumference with 4 transitions that the encoder can see. You want to drive 8", rotate 180 degrees clockwise, drive 8", then turn 180 degrees anti-clockwise. Your commands will be:

CMD_DRIVE, 8
CMD_TURN, 20000
CMD_DRIVE, 8
CMD_TURN, -20000
CMD_STOP, 0

I don't know that the code will work, its just off the top of my head. Just trying to give you another angle on the same problem.