2005 Autonomous Scripting Manual

[Anthony Kesich]

OK, sorry I took so long. Its been a couple of hectic days. Anywho, here are all of the default commands available in Kevin Watson's code. I plan on playing around with the disabled ones (i.e. the way points and the like) and hopefully posting code to run it.

--------------------------------------------------------------------------

CMD_SHOW_STATE; no parameters
Prints back the on-board clock time, x and y coordinates in mm, and the heading in milliradians

CMD_VELOCITY; parm_1: velocity in mm/sec
Uses the PID algorithm and encoders on the wheels to keep the motors driving at the commanded velocity

CMD_WAIT; parm_1: time to wait in milliseconds
Waits for the specified time until executing the next command on the list. Very useful after setting the velocity. (i.e. set velocity 1000mm/sec, drive for 5000 milliseconds = 5 meters).

CMD_WAIT_UNTIL; parm_1: time to wait until in milliseconds
Waits until the specified milliseconds into the match until executing the next line. Useful to delay your code so your alliance can get out of the way first.

CMD_DRIVE; parm_1: distance to drive in mm
Uses the PID code and encoders to drive the robot forward the specified distance.

CMD_TURN; parm_1: distance to turn in milliradians, parm_2: tolerance to be within goal heading in milliradians
Uses the gyro along with the PID algorithm to turn the robot the specified distance. The tolerance is the buffer as to how close it needs to be before deciding it has succeeded.

CMD_WAIT_FOR_BUMP; no parameters
Waits for a switch to be hit before continuing on to the next command.

CMD_STOP; no parameters
Stops the robot.

CMD_GYRO_BIAS; no parameters
Tells the gyro code to use the next 8 loops or so to set its bias. Usually the first line of code to be called since you want to be stationary when setting the bias.

CMD_KEEP_HEADING; parm_1: time to hold heading in milliseconds. parm_2: tolerance in milliradians
Tells to robot to keep its heading (direction) using the Gyro and the PID code to within the specified tolerance for the specified time.

CMD_JUMP; parm_1: command to jump to
Jumps to the specified command in the command list. Usefull for creating loops.

--------------------------------------------------------------------------

That's all that is complete in Kevin's code. I will try to get CMD_SET_HEADING and CMD_SET_POS done soon as they should be useful. I hope this helps anyone that needs it.

-Tony K

[jparkteach]

Is this code compatible with joystick operation of the robot? I mean, after the robot excutes the command sequence in autonomous, will it respond to the joysticks on the OI? I'm asking because I noticed the Default routine is gone and I can't find where the mappings of the pwms and joystick inputs.

[Mark McLeod]

Is this code compatible with joystick operation of the robot? I mean, after the robot excutes the command sequence in autonomous, will it respond to the joysticks on the OI? I'm asking because I noticed the Default routine is gone and I can't find where the mappings of the pwms and joystick inputs.That function has been removed, but could easily be added back in. There is plenty of space left and by calling either autonomous or the Default_Routine they won't be in conflict.
The programmers have to combine the functions they want from the various capabilities FIRST, Kevin, and company are providing.

[Anton]

The code forom Kevin's site doesn't contain some files from rhe default code from the http://www.ifirobotics.com/rc.shtml site (user_camera.c, for example).
Will it be alright if I'll just add these to Kevin's code?
By the way, is that the right place to download the code from, or was I supposed to take it from somewhere else?

[Mark McLeod]

The code forom Kevin's site doesn't contain some files from rhe default code from the http://www.ifirobotics.com/rc.shtml site (user_camera.c, for example).
will it be alright if I'll just add these to Kevin's code?
You can integrate the code you need into Kevin's code. You have to be particularly careful though when two sets of code want to use the same resources, such as controlling the serial ports or using timers or interrupts.

[nehalita]

You can integrate the code you need into Kevin's code. You have to be particularly careful though when two sets of code want to use the same resources, such as controlling the serial ports or using timers or interrupts.

has anyone already integrated the two codes together? if so, did you run into any problems? there were a few threads about integrating code together but i wasn't sure if they were talking about the same thing (i'm a newbie...). i want to integrate them but i have no idea where to start.... :confused:

[Bharat Nain]

has anyone already integrated the two codes together? if so, did you run into any problems? there were a few threads about integrating code together but i wasn't sure if they were talking about the same thing (i'm a newbie...). i want to integrate them but i have no idea where to start.... :confused: First decide what functions you want in you code, then look at the different versions of the code, cut n paste. I hope you are into it enough that you can when you copy files or parts of them you include whatever variables and files they need. If you know C, just start playing around and you will figure it out, thats where to start. And if you run into any problems you can always post.

[Tom Bottiglieri]

FIRST and Kevin Watson have provided us with great driver programs this year. By that I mean, they have wrote c files that will do things that are usually tedious to code for, such as sampling a gyro, or counting quadrature encoder ticks, and made them available to us. Now what you need to do, as Bharat said, is figure out what your robot needs, write those things down in a list. Then look at all the drivers given to us (gyro.c , encoder.c , pid.c , camera.c --and their headers!). So now that you understand what functions are in these programs, you can add what you need to your default code workspace (provided from IFI.. the one with no PID or camera support), and set your user_routines.c, or whatever file you are using to control the bot to include your newly added driver c files. When this is done, it will be easy to call any function from any of the drivers, and you will understand the code more because you helped create your robots workspace, instead of just changing values in the default code.

If you dont understand this, think of it as inlcuding an API in your win32 coding, and then calling functions from it.

Dont forget to configure your drivers, by modifying the header (.h) files (respective to that .c file, of course) If you look in the headers, there will be multiple #define statements, where you must change values that are specific to your robot and sensors, such as wheel diameter, output RPM, and gyro scale factor

[Anton]

(provided from IFI.. the one with no PID or camera support),
I don't really understand it- why the one with no camera/PID control?
also, if i can't use the code with the camera and PID support, how can i use the camera at all?
I'm sure it's a stupid question, but it's my first year in the FIRST competition(my first year of studying robotics at all, too) and it's my first year of using C too, so I'm not really good at it.

[JMac]

If I understand correctly, you want to use the code that doesn't specify for the camera or PID routine in the User_routine, and add the code or function calls that include either the camera or the PID, or both if you wanted to. I think this is so that you understand the code better... Also, keep in mind that they just pulled the camera code off the innovation first site, so it's probably got bugs. I think if you try to understand what each piece of the code and the functions do, and put it in the regular default user code, you'll be more successful at making it work.

[CJO]

has anyone already integrated the two codes together? if so, did you run into any problems? there were a few threads about integrating code together but i wasn't sure if they were talking about the same thing (i'm a newbie...). i want to integrate them but i have no idea where to start.... :confused:
I have posted a version in the white papers section. It does not really work, but it has all of the relevant files and is a starting point. I included some discussion of the conflict which occurs in the readme file. I am working on a functional version, but, I am making no headway with the serial driver. Anyone who really knows how to program the serial drivers want to take a look?

[Astronouth7303]

So what about integrating the camera into the script? (By way of new commands.) I've come up with 2 seperate APIs to do this (Both fairly thin), so I'm curious as to how others are thinking of doing it.

[Tom Bottiglieri]

So what about integrating the camera into the script? (By way of new commands.) I've come up with 2 seperate APIs to do this (Both fairly thin), so I'm curious as to how others are thinking of doing it.
I might have been able to answer you, if i was using the scripting option. The options you are given with it are very narrow. I know that you can write your own code to be available for scripts, but I dont see the point of the extra work.

Can someone prove me wrong?

[ten3brousone]

mm..to be able to use the autonomous scripting commands, a gyro, encoder(the gear teeth counter no?), and a PID(dunno what this is), are needed are they not?

[Astronouth7303]

mm..to be able to use the autonomous scripting commands, a gyro, encoder(the gear teeth counter no?), and a PID(dunno what this is), are needed are they not?
A gyro and some kind of quadrature setup is needed. A PID loop is a code thing and provided.

[Anthony Kesich]

I might have been able to answer you, if i was using the scripting option. The options you are given with it are very narrow. I know that you can write your own code to be available for scripts, but I dont see the point of the extra work.

Can someone prove me wrong?

Reusability. And ease of reading. Last year I was our teams only programmer. Other guys knew C, but I was the one that wrote all the code. We won a birth at nationals and decided to go. Everything was set. Then my grandfather died. I went to Seattle for his funeral while the guys were at Nationals. They needed to change the autonomous there. I had used some obscure coding techniques and they had to rewrite it all. If i had this scripting language, even though it would have been more initial work for me, it would have been a lot less work for the guys later on.

With scripting, I can change my autonomous code on the fly now. All i need is to have 2 or 3 or 4 or however many structures in the commands.h file and uncomment the one i want to use. No sifting through pages of code to change a single number or uncomment one block. No using multiple workspaces. If i want to delay my code three seconds, I add one scripting command. If i want to use more commands, I write them myself.

I see the scripting as a powerful tool for both rookies and veterans. Rookies have an easy system where they don't have to get too deep into interrupts and the like. Veterans can write their own calls and functions. They can write camera code that can be implemented with a single call in a header. They can change their entire autonomous with a flip of a switch without putting in a lot of if-elses or ternary operators (make the command array 2 dimensional and have one of the variables in robot.c be a switch position).

All-in-all, the scripting feature is powerful and useful in my opinion. Don't disregard it or throw it away just because it makes life too easy. We're here to build engineers and programmers. Use the tools available. No one ever won a prize for reinventing the wheel.

-Tony K

[russell]

All of this just makes me want to find the nearest brick wall and bash my head repeatedly on it. I have not the faintest clue what the terminology for any of the stuff I am doing is, and I am not even testing it, Im just writing code based upon the stuff I see in the default code and hoping it will work on one of the first three thousand tries. :rolleyes:

[Anthony Kesich]

Russell, that's what we're here for. Ask anything. Anything at all and don't feel stupid about it. I knew almost anothing about programming when I first joined robotics. The extent of my experience was playing with basic on the calculator. Fortunately, the other programmers on Chief Delphi where nice enough to help me out. So feel free to ask away. No one will think the lesser of you. The only stupid question is the one not asked.

-Tony K

[iscrc2]

I'm having a hard time seeing how cmd_drive causes any action to occur. It looks like after calculating counts in START the IN_PROGRESS just shuts down. Should there be something there that gets encoder counts and looks for when its reaching the calculated value?

[answer: yes, using set_vel calls in START and then IN_PROGRESS state check encoders counts against calculated counts, dont call pid_stop until you are ready to stop, can hack it by doing a --count if no encoder is avail'

While testing the command I had an additional problem in that the static state variable acts as if its getting initialized each time the function gets called. I'm using C18 v2.4 and IDE v7.0. Has any one else had this problem?

[answer: not an issue, but in the script command array remember that it is zero based and to return to first script command do a jump to 0]

[russell]

I bet I can prove your stupid question theory wrong. I got one just now. Last year we put autonomous code into a file that was called like autonomous.c or something, but this year there does not seem to be any such file. Do I just say while (autonomous_mode) { }, then put my autonomous stuff in the brackets? And if so does the rest of the program also run while in autonomous mode, or is it just the stuff that is in those brackets?

[iscrc2]

Russell, in the user_routines_fast.c file there is a function called:
void User_Autonomous_Code(void)

In that function there is a comment line:
/* Add your own autonomous code here. */

You can put code there. Dimond is going to be working tomorrow around noon rm109 come by and we can go over programming.

[russell]

Thanks for the offer, but I probably wont be able to make it. I managed to make that code I was working on today work sort of. I just want to make the robot always stop in the same place relative to the target, but thats just fudging numbers. Right now I have it set up so when it gets to about eight feet it slows, then when it gets to around one foot it stops altogether. Now I just have to figure out how to put it all together for autonomous. Thanks for showing me where to put it, I was really lost for a bit there.

[695programmer]

I have a question that may or may not be stupid. When i run the default code the comterminal gives me values for the x and y axis. The y axis changes when i move the joystick, but not the x. I've tried hooking up two joysticks and playing around with them to no avail. Am i just missing somthing?

[Elemist315]

I'm having trouble with the delays provided in the default code, and time is running thin fast. I just can't figure out how to use them or get them to work (I have a feeling I'm not calling them right). Would it be easier to try to integrate Kevin's code or figure out the delays, I'm really new to c (little c++ experience).

[brownster]

Hey, I had a question about Autonomous scripting, I downloaded the code from kevins site and i just can't seem to get it to do anything in autonomous. I have the automous calling the Robot_control() function and from there it just waits for a bump...the commands defined in commands.h don't seem to be working for me...am i doing something wrong?

[Moloch]

I dont understand how to call the robot_control() function. I dont know much about C at all. I need someone to tell me how to call the robot.c function desperatly. If I understand correctly you have to call the robot_control() function, which will in turn start robot.c to sift through the command.h script. I have not a single clue as to how to get this started! I need lots of help, I am the only programmer on the team willing to try anything!

[Mark McLeod]

I dont understand how to call the robot_control() function. I dont know much about C at all. I need someone to tell me how to call the robot.c function desperatly. If I understand correctly you have to call the robot_control() function, which will in turn start robot.c to sift through the command.h script. I have not a single clue as to how to get this started! I need lots of help, I am the only programmer on the team willing to try anything!There are a couple of things you'll have to do.
robot_control() should be called from User_Autonomous_Code() in the file user_routines_fast.c
If you look there in the Navigation s/w you'll see it commented out. Just add it back in.

For those of you who don't have encoders or gyros you'll need to write your own time based drive functions.

[Moloch]

We have encoders....but thats all I have to do, then write the scripts?

[Mark McLeod]

We have encoders....but thats all I have to do, then write the scripts?You'll need to tune the control PID algorithms to match the characteristics and behavior of your robot. See the descriptions and directions in the file pid.h for help in doing this.

P.S.
If you are using the Navigation code as-is, then you will need to add the Default_Routine() function in user_routines.c from the IFI default code to allow your humans to drive the robot. Add the call to Default_Routine() in Process_Data_From_Master_uP().

You also need to comment out the call to robot_control() in the routine
Process_Data_From_Master_uP() in the file user_routines.c

[Moloch]

This is all I will have to do in user_fast:

while (autonomous_mode) /* DO NOT CHANGE! */
{
if (statusflag.NEW_SPI_DATA) /* 26.2ms loop area */
{
Getdata(&rxdata); /* DO NOT DELETE, or you will be stuck here forever! */

/* Add your own autonomous code here. */

if(rc_dig_in16 == 1){

robot_control();
}
Generate_Pwms(pwm13,pwm14,pwm15,pwm16);

Putdata(&txdata); /* DO NOT DELETE, or you will get no PWM outputs! */
}
}
}


That just seems to easy to me...

[Moloch]

I wrote my own default routine....

[Astronouth7303]

Not to tred on Anthony Kesich or anything, but I would like to remind those who are a little confused about the this whole scripting thing that I wrote a (small) whitepaper on the subject. See Autonomous Scripting (http://www.chiefdelphi.com/forums/papers.php?s=&action=single&paperid=429)

I'm also thinking about writting a second revision, for those who would like it. (Think of it as a more "for dummies" edition.) If you have comments about it, I encourage you to discuss them at White Paper Discuss: Autonomous Scripting.