2005 Autonomous Scripting Manual

Technical Programming
1

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

2

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.

3

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.

4

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?

5

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.

6

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:

7

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.

8

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.

[EDIT] 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 [/EDIT]

9

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.

10

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.

11

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?

12

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.

13

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?

14

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?

15

A gyro and some kind of quadrature setup is needed. A PID loop is a code thing and provided.

16

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

17

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:

18

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

19

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]

20

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?