Simple dead-reckoning autonomous

[JimGRobot]

This message is a little late, and I suspect there are other similar posts, I just couldn't find them...

Anyway, I have watched hundreds of competition videos, and participated in 2 regionals, and I was very surprised at how few robots attempted any sort of autonomous operations. I have to admit that when I first looked at Rack 'n' Roll autonomous, I thought that anything other than scoring had no value in the game.

However, after watching a lot of games, I came to the conclusion that even just driving forward and blocking the path between the rack and the wall could delay the opposing alliance enough to get some extra scoring done before they start pushing your alliance robots around.

What I hope to do with this post is give some teams a little push, and some helpful information to get going with a simple autonomous program.

The first step is calculating the wheel RPMs needed to achieve the desired distance and turn. I have attached an Excel spreadsheet that tries to help with this. It is not 100% accurate, but I think close enough, but I haven't tested these numbers on an actual robot.

The next step is measuring the wheel RPM. I picked up a LASER tachometer on eBay for about $30, and it does a great job of mesuring wheel speeds. Here is where I got mine, you might find others: (eBay is acting up right now and I can't provide a link, but here is a good search string "digital laser photo tach os".

The third step is adding some sequencing code to your robot program. If you're using EasyC is should be easy to output a value to the motors, wait a little bit, then turn them off. If you're using MPLAB, I have attached a short C file that can be #included in the user_routines_fast.c file, right above the User_Autonomous() function. Inside of this function, call Autonmous_Tick() where it says "put your code here".

This file implements a simple state machine for sequencing through some steps that output to PWMs, or anything else you want. It is a simple version that can be used in a number of applications.

I hope this all makes sense, and that it helps get some teams to try autonomous operations, even this late in the game.

Good luck.

[theycallhimtom]

Good post. I think that many teams could put just a little work into a simple autonomous mode and get some benefit. As he said something as simple as driving forward and blocking an area can be helpful.

There is one thing I would like to point out. From my experience calculating RPMs has not worked. In theory it should work, but it doesn't. For simply going straight there is still the issue of getting up to speed and slowing back down. Attempting to calculate the desired motor values to any reasonable degree of accuracy is impossible. Turning creates even more significant error. There really is no good way to calculate how far the robot should go based on motor values from the code.

The easiest way to go forward some distance or rotate some angle (without sensors, encoders or a gyro would make it a lot easier) is just trial and error. Try driving forward for 2 seconds, if that is too far then try 1.5 seconds and keep on narrowing it down until your happy with it. An example would be:


void autonomousFunction(void){
static int timer = 0;//Note: this function is called ~38 times a second
//So divide timer by 38 to get time in seconds
if(timer < 38*2){ //go forward for 2 seconds change this depending on how
// far the robot goes
LEFTMOTOR=RIGHTMOTOR=255;
}else{
LEFTMOTOR=RIGHTMOTOR=127;
}
timer++;
}


There is a small bonus for autonomous even with dead reckoning. You can get closer to the rack, get to the far side of the field to play defense, or block someone with a scoring autonomous. Heck even using dead reckoning to score works occasionally, and it is a lot easier than working with the camera.

[Bomberofdoom]

Don't know if it's related to dead-reckoning atuonomous, but our autonomous went like this:

if(ARM_LEVEL < CHUTE LEVEL)
pwm03=240;;
else
pwm03=127;

And we used by putting our robot in front of the chute and it really helped because our arm took time to rise or lower itself so it saved us time in the teleoperated mode.

[BenThompson]

I agree that more teams should try to get autonomous into their bots. Even if it's nothing complex, you can still use it to get ready for the teleoperated period. Also, on the issue of how far the bot goes, I think a trial and error type thing works best, like Tom said. For the actual autonomous code, I find that a simple counter works best:

int autonomous_counter = 0;

void User_Autonomous_Code(void) {

...

autonomous_counter++;
if(autonomous_counter < value) {
do_something;
}
else if(autonomous_counter < second_value) {
do_something_else;
}

And basically just increment the counter each loop and check what its value is. For teams who don't know, the processor loops every 26.2 ms, or approximately 38 times per second.

Just wanted to add my two cents into this. If more teams added even simple autonomous programs that prepared them for teleloperated period, then autonomous would be a lot more interesting to watch.

[popnbrown]

right now to save our operator some time, we have our arm opening up moving up, and our claw do the same thing. Really pissed that the camera didint work I was excited at first about it.

[bcieslak]

Team 1675 just updated their autonomous programming tool - AutoFlex2..no more messy cables and dangling laptops.

With a couple mods to your code, you basically push a record button on your OI then drive for 15 seconds. Whatever you recorded is what your robot will do during the autonomous mode. The input commands are stored in the RC's internal EEPROM.

Just go to the practice field, hit the record button, drive up to the rack and score the goal. Now its in memory. Make sure you start from the same position out on the playing field.

Its quick and easy. It takes about 15 minute to integerate into your code and learn to use.

We have modified a version of the default code you can use as an example for modifying your code along with some documentation.
Drop us an email at K9WIS@yahoo.com or stop buy our pit in Atalnta we'll have you up and runnning in no time.

Brian
Team 1675

PS it also works with VEX...

[Teched3]

:) Just to help a little in undersanding why so many robots may look as if they are not doing autonomous, I offer the following information:

When the camera is scanning for the light, and can't find it, our robot is programmed to stay put. In my opinion, many of the teams are trying hard to get autonomous to work, and could easily program dead reckoning. However, that's not the challenge - getting the camera to work in guiding the robot to a score is. Winning isn't necessarily related to who scores the most points. Hopefully camera calibration on the playing field will help to make this work. It's how we learn to get better. As an aside, I cannot understand how FIRST expects us to go through our practice matches on thursday without calibration opportunity and a chance to try it out, and then compete on Friday in Qualification matches on Friday on a calibration setting that hasn't been tried on the field.:)



This message is a little late, and I suspect there are other similar posts, I just couldn't find them...

Anyway, I have watched hundreds of competition videos, and participated in 2 regionals, and I was very surprised at how few robots attempted any sort of autonomous operations. I have to admit that when I first looked at Rack 'n' Roll autonomous, I thought that anything other than scoring had no value in the game.

However, after watching a lot of games, I came to the conclusion that even just driving forward and blocking the path between the rack and the wall could delay the opposing alliance enough to get some extra scoring done before they start pushing your alliance robots around.

What I hope to do with this post is give some teams a little push, and some helpful information to get going with a simple autonomous program.

The first step is calculating the wheel RPMs needed to achieve the desired distance and turn. I have attached an Excel spreadsheet that tries to help with this. It is not 100% accurate, but I think close enough, but I haven't tested these numbers on an actual robot.

The next step is measuring the wheel RPM. I picked up a LASER tachometer on eBay for about $30, and it does a great job of mesuring wheel speeds. Here is where I got mine, you might find others: (eBay is acting up right now and I can't provide a link, but here is a good search string "digital laser photo tach os".

The third step is adding some sequencing code to your robot program. If you're using EasyC is should be easy to output a value to the motors, wait a little bit, then turn them off. If you're using MPLAB, I have attached a short C file that can be #included in the user_routines_fast.c file, right above the User_Autonomous() function. Inside of this function, call Autonmous_Tick() where it says "put your code here".

This file implements a simple state machine for sequencing through some steps that output to PWMs, or anything else you want. It is a simple version that can be used in a number of applications.

I hope this all makes sense, and that it helps get some teams to try autonomous operations, even this late in the game.

Good luck.

[Kims Robot]

right now to save our operator some time, we have our arm opening up moving up, and our claw do the same thing. Really pissed that the camera didn't work I was excited at first about it.

Not sure what you mean about "the camera didnt work". Several teams in Boston got their cameras to somewhat work (if only they would have turned off all the LED banners!! ugh!). When the rack was properly rotated, we had our camera working, just never had quite enough time testing to get it working perfectly.

To be honest, Im not sure why more teams didnt just try dead reckoning autonomous... with a consistant autonomous, even if you dont make it on all the time, there isnt much to loose... you get closer to the rack and closer to keeping your opponents from your side of the field.

[gburlison]

:) Just to help a little in undersanding why so many robots may look as if they are not doing autonomous, I offer the following information:

When the camera is scanning for the light, and can't find it, our robot is programmed to stay put. In my opinion, many of the teams are trying hard to get autonomous to work, and could easily program dead reckoning. However, that's not the challenge - getting the camera to work in guiding the robot to a score is. Winning isn't necessarily related to who scores the most points. Hopefully camera calibration on the playing field will help to make this work. It's how we learn to get better. As an aside, I cannot understand how FIRST expects us to go through our practice matches on thursday without calibration opportunity and a chance to try it out, and then compete on Friday in Qualification matches on Friday on a calibration setting that hasn't been tried on the field.:)

I agree completely, even after calibration, our camera has a lot of problems finding the lights on the field. Prior to shipping, we almost had autonomous working. Our problems were more mechanical than programming because we were having problems overstressing the gearbox. So here we are at the Colorado Regional and even after calibration, most of the time our camera just scans and it never finds the light. So our robot just sits there scanning until the 15 seconds is over.

[Astronouth7303]

We would have done something at WMR, but a simple "d'oh!" bug with auton selection, which screwed up driving, scared off the mechanical mentors (which outnumber the EE/CS mentor 5:1) from even entertaining the idea.

Fortunately, after losing the semifinals I spent some time fixing it, so I can now add a arbitrary dead recon in little time.

For example, I find that WildStang's autonomous is getting in the way. And they consistently hang on the left/right side. We see we're playing against them in the next match. So I can write an auton to crash into them, and maybe even drop a keeper in front of them. (Warning to 111: If it wasn't for that bug, this may have been a true story.)

OT: How is it scored if two keepers are dropped on the same leg?

[theycallhimtom]

<G13> KEEPER advantage - KEEPERS that have been SCORED can not be covered by another GAME PIECE and can not be negated by a SPOILER. Any GAME PIECE placed in a HANGING position on the same SPIDER LEG after a KEEPER (including another KEEPER) will be ignored when determining the match score. In all other aspects, KEEPERS are treated the same as RINGERS.

So whoever places the keeper first gets the points.

[ericand]

I was impressed that some teams in Las Vegas had non-scoring auto modes. I think it is cool that teams take what they can do and make the best of it.

One team I saw had a defensive blocking auto mode, where it drove all the way around the rack and crossed in front of the opponent's home zone (attempthing to disrupt an auto mode score there. Another team which we had trouble with (in auto-mode) would repeatedly bump the rack (causing the spider legs to sway, making scoring difficult).

[Tom Line]

I have to wonder. How many teams complaining that their camera was having trouble finding the light were trying to:

1. Find the light from the starting position.
2. Find the light while moving.

We noticed early on that tracking the light while the robot was moving at a decent speed, or even finding the light from the starting position was generally problematic.

We solved it by driving up to about 6 feet away then stopping and getting a single fix from the camera. We forced the camera to only search across 1 tilt level and had it on a vastly increase pan-speed.

That single fix gave us both the amount we needed to turn, and the distance we had to travel to score.

Early on, we actually did it in two steps - we turned first then got our second fix to get the distance. It was slightly more accurate (1-2 inches) than geting the distance then turning - but we need to speed it up to avoid the defense in West Michigan.

[Tom Line]

I have to wonder. How many teams complaining that their camera was having trouble finding the light were trying to:

1. Find the light from the starting position.
2. Find the light while moving.

We noticed early on that tracking the light while the robot was moving at a decent speed, or even finding the light from the starting position was generally problematic.

We solved it by driving up to about 6 feet away then stopping and getting a single fix from the camera. We forced the camera to only search across 1 tilt level and had it on a modified pan-speed with a lower confidence interval.

That single fix gave us both the amount we needed to turn, and the distance we had to travel to score.

At first, we decided to get the turn angle, turn, then get the distance to drive. However, we would occasionally lose our camera lock during the turn so we went to do both at the same time.

[Benedictine1]

could we get that "teach/run" code from you? I am the team coach, so I might ask some questions about implementing it, but I think it could really help!
Thanks

[rachal]

I'm surprised I didn't see any robots dead-reckoning for the side of the rack...there's so little sideways variation caused by rotating the rack (about 6 inches I think) that you should be able to score a nontrivial percentage of attempts by charging forward and slamming the tube into the spider foot.

I never had a chance to try out this autonomous at competition though, so correct me if I'm wrong.

[EricH]

I'm surprised I didn't see any robots dead-reckoning for the side of the rack...there's so little sideways variation caused by rotating the rack (about 6 inches I think) that you should be able to score a nontrivial percentage of attempts by charging forward and slamming the tube into the spider foot.

I never had a chance to try out this autonomous at competition though, so correct me if I'm wrong.You mean, audience or scoring side? Harder than it seems. 330 tried a few times during Curie eliminations. We didn't make it very much (one match, we slammed it on, but it bounced off.) Also, there is the horizontal translation to reckon with.