Chief Delphi - What to do with autonomous

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - What to do with autonomous (http://www.chiefdelphi.com/forums/showthread.php?t=23755)

Re: What to do with autonomous

Quote:

Originally Posted by Mike Soukup

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.

Did you use a PID algorithm to get to a waypoint? It seesm like this would take care of overshoot.

Just curious.

Re: What to do with autonomous

Quote:

Originally Posted by MichalSkiba

First off, a question about the uber-accurate Wildstang Positioning System (WSP perhaps?):

It was WPS originally, but we ended up dubbing it StangPS :cool:

Quote:

How were you able to account for wheel slipping?

Very good question. Our system had no slippage detection/correction. (read on...)

Quote:

This would occur when your robot would be pushed (while wheels were locked) or sliding down the ramp (for example).

It was more of a problem on the ice (HDPE) and performing turns on the ramp.

Like Mike said in a previous post, we didn't need a whole lot of precision. If we wanted to ram a stack (whether freestanding or the group on the ramp), we just had to make sure that the stack ended up in front of our robot.

Our wheel slippage (in normal situations) was
* minimal on the carpet in normal situations
* slight climbing the ramp
* measurable on the ice (HDPE)
* negligable descending the ramp

Therefore, we didn't design programs that spent significant time on the ice. Our double-hit program (hit the left side of the stack, come back, hit the right side of the stack) consistently cleared a good portion of the bins, but was slightly inconsistent due to the slippage on the ramp.

In situations where we came head-to-head with another robot, there was a good chance that we deflected during the collision and recorrected our heading to squeeze past and continue on. If is was the type of collision that stopped us dead in our tracks, that was a different story. Luckilly, those types happened on the ice which allowed our wheels to slip and not burn motors.

Quote:

I'd immagine that such 'small' inaccuracies could addup to more then +/- 1-inch by the end of the match.

You are correct in saying that the inaccuracies would add up, but after the 15 seconds were up, the knowing our position wasn't extremely important. Had it been, we would have probably considered determining the slippage and corrected.

Re: What to do with autonomous

Quote:

Originally Posted by IrisLab

Did you use a PID algorithm to get to a waypoint? It seesm like this would take care of overshoot.

Just curious.

When you boil our algorithm down to its lowest level, it was actually quite simple: point the wheels toward the target and drive. We had a bunch of other nice features like the ability to change the robot's orientation or keep a specific orientation as the robot moved, different speeds for each leg of the path, different waypoint sizes so we could drive by quickly & not worry about hitting the point exactly, and the ability to independently move our wings at each waypoint.

But the basis of the algorithm was knowing our current position (from our custom circuit) and the position of our next point, then using some trig to get the angle to the target. After we got the target angle we figured out what angle we needed to turn our wheels to by subtracting or adding the target angle and our robot's angle relative to the field (also from the CC). This calculation ws done each time we executed our main loop, which turned out to be 3-4x slower than the 26ms IFI loop.

The theory was simple, but getting it to work consistently with the tools IFI gave us was difficult. And keeping all the PBASIC code readable & understandable was a big challenge.

Re: What to do with autonomous

Quote:

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!