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
*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,
MatthewUbergeeks **
Here ya go… this should help.
http://www.innovationfirst.com/FIRSTRobotics/documentation.htm
-Greg The Great
We have been reading the manual from innovation first but I was hoping to look at some code examples of working autonomous code.
*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
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. 
*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
ok, it goes something like this (in my mind)
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 .
The output variables for the PWM outputs are PWM01 - PWM08. A simple statement like
PWM01 = 255;
PWM02 = 255;
should work.
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)
*Originally posted by Noah *
**ok, it goes something like this (in my mind)
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 .
The output variables for the PWM outputs are PWM01 - PWM08. A simple statement like
PWM01 = 255;
PWM02 = 255;
should work.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 PWM02and 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
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 
)
Anyway, if you have any specific questions, just PM me, I’m more than willing to help with any programming issues anyone’s having.
*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)
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
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.
*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 outIf 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
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
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.
*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
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!
*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
Not quite…
This program writes something…
I built a small edu with just 2 motors and a marker in the middle…
*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
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?)