Sample Autonomous Modes

[NextPerception]

I consider myself an ok programmer, but I am no where near the level that some of the programmers here are at. The evidence of this is some of the astounding autonomous modes that where left and right last year. I was hoping for some examples of code y'all had last year because i frankly wouldn't know where to begin with a code like that. I figure that if maybe I can see some peoples final products I can know what to strive for. I would really appreciate it.

[Tottanka]

Actually, coding wasnt the problem in navigation...
U just get the location of the bot in comparison to the light using the CMUcam2, and then u know where to turn, as in to make the gap between bot and light smaller and smaller till it reaches zero, and then u simply shoot...
The problem isnt programming, but setting the CMUcam2 correctly, which includes a lot of testings...


As of my team, we had a cannon, which was set to change his angle automatically during the game moving between 30 and 55 degrees. what gave us an awesome range...
WE just tested what angle is needed for a 3m distance,4m, 5m, 6m etc... Put it in the code beeing depanded on inputs fromc amers that sais the distance from the target, and according to it knowing the needed angle using the Gyrometer....

It really helped us, and one of my best moments in the competition was our second regional semi final when we were located 3M from ceter goal, shot 2 balls in, and then a strong but low bot pushed us all the way back to our ramp, and during his push we kept on shooting and it got in, with the cannon automaticaly adjuting its angle according to the distance...was very very beautifull...

oh yea, and Kevin is also very usefull =]

[NextPerception]

Originally Posted by Tottanka

Actually, coding wasnt the problem in navigation...
U just get the location of the bot in comparison to the light using the CMUcam2, and then u know where to turn, as in to make the gap between bot and light smaller and smaller till it reaches zero, and then u simply shoot...
The problem isnt programming, but setting the CMUcam2 correctly, which includes a lot of testings...


As of my team, we had a cannon, which was set to change his angle automatically during the game moving between 30 and 55 degrees. what gave us an awesome range...
WE just tested what angle is needed for a 3m distance,4m, 5m, 6m etc... Put it in the code beeing depanded on inputs fromc amers that sais the distance from the target, and according to it knowing the needed angle using the Gyrometer....

It really helped us, and one of my best moments in the competition was our second regional semi final when we were located 3M from ceter goal, shot 2 balls in, and then a strong but low bot pushed us all the way back to our ramp, and during his push we kept on shooting and it got in, with the cannon automaticaly adjuting its angle according to the distance...was very very beautifull...

oh yea, and Kevin is also very usefull =]

that is sort of what I had attempted to do. Our robot had adjustable shooting angle between 0 and 45 degrees freedom that was hooked up to a potentiometer. then you aimed left and right with the whole robot. what I attempted to do was make a lookup table so that if the camera was reading X on the tilt axes, it would make the shooter go to Y Degrees.
I never got it to work because at first the potentiometer wasn't working correctly and then I wasn't able to figure out how to make a PID before we had to ship the robot.

[Tottanka]

Originally Posted by NextPerception

that is sort of what I had attempted to do. Our robot had adjustable shooting angle between 0 and 45 degrees freedom that was hooked up to a potentiometer. then you aimed left and right with the whole robot. what I attempted to do was make a lookup table so that if the camera was reading X on the tilt axes, it would make the shooter go to Y Degrees.
I never got it to work because at first the potentiometer wasn't working correctly and then I wasn't able to figure out how to make a PID before we had to ship the robot.

Yea, we did the table thing to...
Only out of it we build a Linear Graph in excel, got its equation and put it in the code so the RC always knew what should be his cannon angle compared to the location of the target...

Our cannon was actually based on 2 points. one stable in the back, where the balls got into it, and annother point in the other side of the cannon, which was a gear that went up or down using a spike...
I believe it was using the Globe Motor.
we just moved one end of the cannon up and down, while the other point is stabling it... The cannon was about half a meter long, so it ddnt create problems, but if it was a 20 CM cannon, then it would have created more problems, cause then we had to make 2 moving points beeing depandanant on each other,,,and that would have been one crazy formula...

Some teams also made a rotating cannon, bout 120 degrees, meaning that they could shoot from anywhere, without depanding on their wheel position. WE didnt even try it, thought it was way too complicated for 6 members team to make...
Actually, we have even removed the X-axis servo from our CMUcam2, so it only moved up and down, and didnt move left right, which made finding the target much much faster for the camera...

Before the matches began and we suffered some bad ramming, u could actually see our camera moving along with the cannon, as if they were using the same servo (BTW thought of giving them the same servo and attaching them, but gave it up, dont remember why ).

[Astronouth7303]

Our robot last year was designed to not move, and so most of its operations were supposed to be autonomous.

Of course, there were issues that prevented this idealized vision. However, it should give you an idea of how it works.

Here's how I recommend approaching the issue. Autonomous and user mode just change where you get your inputs. They should be feeding the same routines. This allows you to use any advanced stuff you develop in both autonomous and user mode. These common routines, hardware control code, should present a fairly high-level interface. Saying that numbers are in m/s is a little excessive, but you should be getting an idea.

Last year's robot followed this, even though most of the inputs were for override modes. (And we had plans for things like power management and such. "These devices should be killed when voltage gets this low", etc.)

As for autonomous: Don't code at the lowest level you can. Instead, code at a higher level. Write functions to handle all the fancy bits. Don't implement the "drive n feet" code 5 times. You don't have to go all-out with the scripting stuff from kevin.

The single most helpful tip: Writing too many helper functions/macros is better than not enough.

[JBotAlan]

So are you saying that it is bad to have the infamous

pwm01 = p1_y;
pwn02 = p2_y;

lines that have been used in my code in the past? I'm thinking the velocity control stuff is really cool, but overkill for anything but auton.

If I did use the velocity control (which I now fully intend to implement this year) I would use a lookup table for joystick values matching to velocity settings. But like I said, that seems a bit overkill.

A little off-topic, but I have to teach a newbie this year, and I want to do some really advanced stuff. Should I walk him through it at the expense of getting it done, or do I go as fast as I can like I would if I was doing it by myself, and explain later? I just see advanced programs hard to do when I am programming to teach.

JBot

[Astronouth7303]

Originally Posted by JBotAlan

So are you saying that it is bad to have the infamous

pwm01 = p1_y;
pwn02 = p2_y;

lines that have been used in my code in the past? I'm thinking the velocity control stuff is really cool, but overkill for anything but auton.

If that was what was the interface, then it's perfectly ok. It's just sorta limiting. Something like

#define SetVelocity(left,right) pwm01 = left, pwm02 = right

is preferred for this change factor. (EDIT: Typos fixed)

If I did use the velocity control (which I now fully intend to implement this year) I would use a lookup table for joystick values matching to velocity settings. But like I said, that seems a bit overkill.

It might be overkill, but why spend 20hrs writing it for only 10s of the match?

This is especially helpful the drive motors are not symetric--they're biased.

Just one word of advice. If you get into fancy motor control loops, I recommend calibrating the victors to absolute. Subtle bugs appear when 127 - 7 drives but 127 + 7 doesn't. You can use my small program to do this.

[JBotAlan]

Originally Posted by Astronouth7303

If that was what was the interface, then it's perfectly ok. It's just sorta limiting. Something like

#define SetVelocity(left,right) pwm01 = p1_y, pwn02 = p2_y

is preferred for this change factor.

Warning to those who copy and paste, there's a typo, it's pwm, not pwn
Anyhow, if I'm going to be calling a SetVelocity function at all, I'm going to write a feedback loop, or at least a PWM output-to-velocity lookup table because it's fun to be exact (whoo, I guess my obsessive-compulsive is taking over ).

Originally Posted by Astronouth7303

It might be overkill, but why spend 20hrs writing it for only 10s of the match?

This is especially helpful the drive motors are not symetric--they're biased.

Ahh, good point. Note to self: separate lookup tables between left and right drive.

Originally Posted by Astronouth7303

Just one word of advice. If you get into fancy motor control loops, I recommend calibrating the victors to absolute. Subtle bugs appear when 127 - 7 drives but 127 + 7 doesn't. You can use my small program to do this.

Will do. I just pulled down the file, the description for it, and IFI's manual for the Victors (which I'm sure I have somewhere already, I just am not sure where. I need to get my obsessive-compulsive focused on that *mess* of a downloads folder...it clocks in at 14.7GB with 2995 files in it... )

Thanks,
JBot

[EHaskins]

Here is a copy of 1103's software. Kevin's files have been removed so you will need to download his Camera Simple v1.

To run the software:
1. Download my software here.

2. Download Kevin Watson's Camera Simple v1 software here.

3. copy these files from kevin's code into my project's directory;
camera.c/.h,
terminal.c/.h,
tracking.c/.h,
serial ports.c/.h

4. build the project

5. Read the jumpers.txt file. it includes a description of the different option for autonomous mode.

6. Set the proper jumpers on the robot controller.

7. Download/Run

If you have any question or problems PM or e-mail me.

Here is the link to my software.

Originally Posted by Tottanka

Actually, coding wasnt the problem in navigation...
U just get the location of the bot in comparison to the light using the CMUcam2, and then u know where to turn, as in to make the gap between bot and light smaller and smaller till it reaches zero, and then u simply shoot...
The problem isnt programming, but setting the CMUcam2 correctly, which includes a lot of testings...

Thats true. I spent more time getting that @#^&$ Camera to work than I did programming!

Hope this helps,
Eric Haskins

[Tom Bottiglieri]

It's all about feedback control and modular control functions. Once you have these two things in place, you are free to develop autonomous motion routines at a very fast and efficient pace.

Feedback control allows you to change the way you control your robot from something very abstract, such as PWM values and time intervals, to something very simple and easy to grasp, such as absolute velocity and position. So, you tell the robot what to do (ex: travel at 7 ft/s) and the brains of the bot handles the rest. Popular control structures, like PID, make it possible for you to be able to tune your system to respond as quickly and efficiently as you like.

Once your robot has the capability to be controlled via feedback, you will want to develop some modular control functions. These functions should be able to be called globally, and have complete control over the robots hardware. Some control functions I have found useful in the past are:

• DriveDistance(inches)
• TurnToHeading(radians)
• LockDrivetrain()
• Drive(velocity, turn rate)

These functions are pretty self explanatory, and really allow you to do some cool stuff you wouldn't have been able to do beforehand. Because controlling the output of your robot is now entirely simple, you can create different pieces of code that access these control functions in different places with the same end result. Your resulting control code will be much simpler and much more reliable.

For example, you would like to create an autonomous mode that drives 5 feet forward, turns 45 degrees, then drives another 10 feet. Using a dead reckoning approach, this would be hard to achieve with a high level of accuracy and repeatability. You would have to worry about battery level, efficiency of each side of the drivetrain, obstacles you may run into, etc. With a modular feedback control system in place, you can create this routine in 3 commands. Every time the robot goes out on the field, it will run through these commands, correcting itself as it goes. Because you have spent so much time perfecting the "back end" of the system, the "front end" becomes much simpler and much more efficient.

You can also start moving into much more complex control schemes as well. You can create code to make your robots motion command based, where on the successful execution of one command, the robot will move on and execute the next. You can create a database on your robot of possible command scripts. You can even goes as far as storing them on an SD card or syncing them via serial. Now, you can create software on a computer that generates scripts for the robot to run.

Last year, my team took the route I have described and were very successful. Once we had the feedback control system in place, we created a command parser on the robot which would read a "script" stored in EEPROM. This "script" was handled by another piece of code on the robot which synced it with commands sent over a serial cable. On the other side of the serial cable, we had a Windows application running on a pocket PC which allowed us to draw out our path on the field (via way points), add functionality, and simply send a set of commands to the bot. The source code on the robot never changed when we wanted to change autonomous modes, which made for a very robust system.

If you have any further questions, don't hesitate to ask. Good luck!