Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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:

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.

Re: Simple dead-reckoning autonomous
 

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

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.

Re: Simple dead-reckoning autonomous
 

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:

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.

Re: Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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...

Re: Simple dead-reckoning autonomous
 

:) 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.:)

Re: Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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?

Re: Simple dead-reckoning autonomous
 

So whoever places the keeper first gets the points.

Re: Simple dead-reckoning autonomous
 

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).

Re: Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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.

Re: Simple dead-reckoning autonomous
 

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