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.

[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

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

[Tomas]

Originally Posted by 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.

I made some tests following the line, actualy, many of them. The best results came out using six sensors! Use them in V, and put them as far as you can from the robot's rotation center, keeping a distance of 6'-7' between the center sensors, so the robot can go with two or three corrections only. In 30 times we got there everytime between 7 and 8 seconds, never loosing the line. The limit is your drive system!

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

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

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

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

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

[IrisLab]

Originally Posted by Dave Flowerday

[cut]
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.

I was thinking about this for our design as well. How did you reach the 6" rule? Arbitrary? I was looking at 2.5 times our accuracy. 2 times to account for sampling and .5 as a slush.

It's not a big deal, but I hate to not have a reason. :-)

Thanks.

[Mike Soukup]

Originally Posted by IrisLab

I was thinking about this for our design as well. How did you reach the 6" rule? Arbitrary? I was looking at 2.5 times our accuracy. 2 times to account for sampling and .5 as a slush.

It's not a big deal, but I hate to not have a reason. :-)

Because we tried it and it worked the first time Seriously, we chose 6" because we figured that it got us "close enough" to our point. Last year's game didn't require much precision, just a quick turn and dash up the ramp. If we were a couple of inches off it didn't really matter much. We wanted to run full speed the whole time and not worry about going back to a waypoint if we overshot it. We didn't do much testing, we just picked a box that was big enough to work. We made this number configurable per waypoint so changing it just required updating the range in our waypoint list.