What to do with autonomous

[Rickertsen2]

What are your plans for autonomous this year? Will you choose to track the IR beacon? If so, how do you plan on finding your ball without knocking over the opponent's? The beacon is in betwen the two?

Line tracking?

Dead reckoning based on timing?

Dead reckoning based on encoders?

Dead reckoning based on gyros and accelerometers?

Something else entirely?

Whatever is is you are doing, please explain.


Our team is doing an encoder based dead reckoning system somewhat similar to what wildstang did last year, only it is expected to be much more precise. We have a seperate PIC18F252 dedicated to nothing but counting encoder pulses and computing the trig transforms necessary to figure out where we are. We have figured out a rather clever way of doing trig functions extremely fast, but don't expect any leaks on that. The IFI processor will take the position data from the secondary processor, and run a rather complex control algorythm to make the robot follow preprogrammed paths.

[Cory]

Dont do line following!!!!!!!!!!!!!! I cannot emphasize how slow line following really is. We tweaked our bot enough last year that we got it to do it just about as fast as you could, and it took the entire 15 seconds. Sure, it won us Driving Tommorow's Technology, but it was the stem of many problems.

Cory

[Powers]

The infrared beacon is in between the two balls, so yours is always inbetween the robot and beacon and opponents is opposite beacon.

[Dave Flowerday]

Originally Posted by Rickertsen2

Our team is doing an encoder based dead reckoning system somewhat similar to what wildstang did last year, only it is expected to be much more precise. We have a seperate PIC18F252 dedicated to nothing but counting encoder pulses and computing the trig transforms necessary to figure out where we are. We have figured out a rather clever way of doing trig functions extremely fast, but don't expect any leaks on that. The IFI processor will take the position data from the secondary processor, and run a rather complex control algorythm to make the robot follow preprogrammed paths.

We'll be interested to hear how you've managed to make this setup more accurate than ours, as you seem to be duplicating it directly (your description of your setup matches ours exactly, with the exception that we used a Motorola processor instead of a PIC). Our custom circuit was able to compute our position on the field to within less than 1 inch last year, however the accuracy of the data passed to the robot controller was intentionally reduced to a 2 inch granularity, since that was more than enough accuracy for what we needed to do.

BTW, we were not computing our trig in the conventional way. We employed many optimizations on these calculations that I would consider standard for this situation, and the result was that converting our heading and distance to an (x,y) coordinate took only a few clock cycles.

[Joe Ross]

Originally Posted by Cory

Dont do line following!!!!!!!!!!!!!! I cannot emphasize how slow line following really is. We tweaked our bot enough last year that we got it to do it just about as fast as you could, and it took the entire 15 seconds. Sure, it won us Driving Tommorow's Technology, but it was the stem of many problems.

Just because it didn't work last year doesn't mean it won't work this year. This year's controller is much better able to handle faster sensor input, which would mean that your robot will be able to go faster.

[Cory]

That is true, however, the problem we saw wasnt the sensors, it was that if you wanted to run the robot at a speed significant enough to get anywhere quickly, you would overrun the line, and never be able to get back, although now that I think about it, since the line is far straighter, you might be able to get it to work well. I would still lean towards another mode, however. Especially with these IR sensors. It seemed as if Woodie was hinting that we would *need* to be able to use sensors in the coming years (Or was it Dave?).

$0.02

[Rickertsen2]

Originally Posted by Dave Flowerday

We'll be interested to hear how you've managed to make this setup more accurate than ours, as you seem to be duplicating it directly (your description of your setup matches ours exactly, with the exception that we used a Motorola processor instead of a PIC). Our custom circuit was able to compute our position on the field to within less than 1 inch last year, however the accuracy of the data passed to the robot controller was intentionally reduced to a 2 inch granularity, since that was more than enough accuracy for what we needed to do.

BTW, we were not computing our trig in the conventional way. We employed many optimizations on these calculations that I would consider standard for this situation, and the result was that converting our heading and distance to an (x,y) coordinate took only a few clock cycles.

Please don't take this the wrong way. Sub 1" accuracy? I retract my statement then. Somewhere i heard like +- at least 6". You should take it as a complement that your team was the first to do something like this, and that people think its soo cool that they want to do something like it. Actaully i had a similar idea last year, independently inspired by:http://www.seattlerobotics.org/encod...ing_a_pid.html , we just didn't have the time or resources to make it happen.

If we are duplicating your design, i promise, this is not intentional. I am the one responsible for the design of our system and if it is turning out like yours then thats probably because we followed similar descision paths and came to similar conlusion about how to effectively implement such a system.

[Bremma]

I belive it was Dave who hinted at the IR use. I am not sure what our team is planning yet, if anything. We probably wont go for the ten point ball. We may use dead reconing to move under the ball drop, for a possible bot design for catching the balls. Well, if we can figure out dead reckoning, being our main porgrammer left us. If anyone can help me learm more about it, it would be greatly appriecated.

[RoboCoder]

Since the line is much less "Curvy" this year, line following could be optimized to go faster than last year. HOWEVER, I would strongly recommend against that if possible. In many applications, not just FIRST I have tried line following and have not been satisfied with the results. Most of the time it is either too slow or loses the line too easily. Granted, there are applications where line following IS a very viable option, but I'm pretty sure that this is not one of them, especially since FIRST gives you the sensors and code to use the IR beacons, especially since they seem determined to make sure they are fully utilized in the future. So, of course, ultimately it is up to the individual teams, but personally, if you ask me, then it is not your best option.

[Joe Ross]

Originally Posted by Cory

That is true, however, the problem we saw wasnt the sensors, it was that if you wanted to run the robot at a speed significant enough to get anywhere quickly, you would overrun the line, and never be able to get back, although now that I think about it, since the line is far straighter, you might be able to get it to work well.

You're right, the problem wasn't the sensors, it was the RC. It could only read the sensors 38 times a second. If you robot moved off the line in 1/38 of a second, you were hosed. This year however, you can read the sensors much much faster. You still have the problem of momentum, but the task has become much easier.

[Dave Flowerday]

Originally Posted by Rickertsen2

If we are duplicating your design, i promise, this is not intentional. I am the one responsible for the design of our system and if it is turning out like yours then thats probably because we followed similar descision paths and came to similar conlusion about how to effectively implement such a system.

I have no problem at all with you using our design, or ideas from our design, or anything, and I'm not trying to imply that you're copying us (if you don't mean to). We'd be glad to help any way we can, too. I just wanted to make sure you didn't have unrealistic expectations for the performance of your device.

As for the 6 inch accuracy, that comes from somewhere else. While we know our position with much better accuracy than that, we would consider to have hit a waypoint if we were within a 6" square around it. This is necessary to prevent the robot from reaching a waypoint and then overshooting it due to coasting, and then having it try to keep getting closer and closer to it. I imagine you'll find that you need a similar concept as well.

[Rickertsen2]

Originally Posted by Joe Ross

You're right, the problem wasn't the sensors, it was the RC. It could only read the sensors 38 times a second. If you robot moved off the line in 1/38 of a second, you were hosed. This year however, you can read the sensors much much faster. You still have the problem of momentum, but the task has become much easier.

I would speculate that while the sensors were an issue, the phase lag between motor corrections and physical system response is a far greater issue. I saw some teams usign an aray of sensors last year to avoid loosign the line.

[bheller]

It looks like there is the potential this year to use the IR beacons for triangulation. I would LOVE to see a robot use triangulation instead of dead reckoning for navigation. A ball-collector robot could knock down both teams' 10pt balls, then navigate to their side of the field, run patterns to collect balls and return to the team's original side of the field - all during the autonomous period!

There are two ways to do this triangulation, and both assume two pairs of IR detectors constantly tracking an IR beacon, similar to the setup demonstrated during the kickoff, but for each side of the robot. Method one would use the intensity measurement from each beacon to estimate the distance to each beacon, solving positions from a 3-known sides triangle. Method two would use the angle between the two sensors to determine position. There would be multiple solutions with this method, but constantly tracking position could help out.

That said, both methods would blow in real life. The IR beacon's line of sight to the receiver could be blocked by another robot or all the poles in the way. Not to mention calibration and multiple equation solutions... dead reckoning would be easier and more reliable.

Still, it'd be cool to see.

MUCH more useful would be the ability to alter a preprogrammed (dead-reckoned / line-followed) course if another autonomous robot was in the way. This could be done with an IR sender/receiver pair or more easily with Sharp GP2D12 IR Distance Sensors from Digikey. However, this sensing tech could be much more insidious, and used to lock-onto and disrupt the motion of an opposing autonomous robot.

Hmmmm....

-Brandon Heller
Team 449 Alum mentoring Team 931

[KevinB]

Team 538 is also planning on using an "educated" positioning system similar to the ones mentioned by Rickertson of #1139 and the system used by Wildstang (#111 i think?) last year. I'm going to try to use accelerometers instead of shaft encoders, but fears about noise may eventually force us into encoders as well.

Good luck to all the teams who choose to implement autonomous! I hope everybody gets the chance to develop a decent autonomous program. I think we learned last year that it isnt too fun to get partnered with a robot that's dead in auto mode!

[Rickertsen2]

Originally Posted by KevinB

Team 538 is also planning on using an "educated" positioning system similar to the ones mentioned by Rickertson of #1139 and the system used by Wildstang (#111 i think?) last year. I'm going to try to use accelerometers instead of shaft encoders, but fears about noise may eventually force us into encoders as well.

Good luck to all the teams who choose to implement autonomous! I hope everybody gets the chance to develop a decent autonomous program. I think we learned last year that it isnt too fun to get partnered with a robot that's dead in auto mode!

We initially considered going entirely inertial, but decided that it makes things alot more complex at little extra benefit. In the end, if we have time, we may experiment with adding a gyro to help w/angular position.