Time to the top...

[Solace]

One thing I would like to hear about are the robots how have arms that reach over the wall to knock down the bins without actually moving. How fast do those work? There haven't been any of those at the regionals that I've witnessed.

[Yan Wang]

At Annapolis, 25 was the fastest at < 4 seconds.

Our team got there between 4 to 4.5 seconds and was among the fastest. Most teams used dead reckoning. Depending on how the bot was build, a bin placed by a human player in the robot's path could have disastrous or no effects.

[Austin]

I'm not sure excatly what our time is, but at Pittsburgh we met with the thunderchickens at the top of the ramp, virtually the excat same time, although that was with HP bins placed in front of the ramp on their auto side. Ha!

[Joe3]

If anyone has video of these 3-4 second runs to the top of the ramp, I'd like to see it. Sorry, but I'm just having trouble visualizing it. Also, how are you guys timing this...are you going my the FIRST official clock, or indepenent timing meathods. Also, I seem to remember team 25 more in the 5-6 second time range based on the FIRST clock. I dunno, but if anyone has video I'd appreciate it.

[sevisehda]

Here is the link for the video of BAE autonomous periods.

BAE AUTO Video

[Solace]

yeah, and does anybody have movies of the robots at UTC? We were too stupid to tape them ourselves.

[Wayne C.]

for the record-

team 25 goes from activation to top of ramp in 3.6 sec one direction, 3.2 secs in the other. We actually slowed it down late in the game to put less stress on the drills but were still under 4. This is based on the second counter in my videos and a stopwatch the officials were using during our practice rounds.
(remember that there is a brief lag between the time the countdown ends and actual activation with the horn)

In either case it goes pretty fast and from Fri afternoon on we hit the wall as planned every time- and I think we can hold it together now!!!

WC

[JasonStern]

Our team taped the most of utc (we ran out of tape fri night ), but most of us are on spring break right now. however, I might be able to digitize select portions of the matches, if you have anything in particular you want to view....

[Serg]

I can prove team 25 at less than 4. They were over at the practice ramp testing there autonomous. They made it to the top of the HDPE with there robot in 3.5 seconds. Now there arm sticks out about 2 feet after deployment, making there bot reach the wall before there robot got there. Id say they pulled off 3 and a quarter.

[KenWittlief]

I gave the tape I had of Cleveland matches to someone else on our team. We timed our bot from the tape, from the time it started moving till we saw the first box flinch. It was consistant at 4.5 second. And yes, that one team that beat us to the wall was 3.0 seconds (I am humble in their awesome presence :c)

There was a bot at Cleveland that had a wally-arm - it took a little over 3.5 seconds to deploy and hit the wall, but it didnt take many boxes out, and it didnt knock them very far.

We started our auton mode using 7 (yes count em) retro banner sensors under the bot to follow the line. We had to stay late to test it - when the whole team was there they wanted to practice driving, or were tinkering with the trannies, so the sparkies were there till after midnight a few times.

Then AFTER the bot shipped I realized a better way is to do the V turn - start out backwards pointing towards the center of the operator stations- go back about a second, turn 45°, then warp speed scotty!

We use the gyro for closed loop steering - and was a simple step to simply add the output number in a 16bit variable ( VAR WORD) - always subtracting 127 to normalize it - and use that accumulated number as a compass heading. 45° comes out to be approx 3000. We can turn 45° dead on every time - the only drawback is you have to turn a little bit slower than you would without it (to keep below 75°/second sensor max) - but since we are only turning 45° - it doesnt take long. If you try to do a half circle with the gyro as compass, then it will take you 3 seconds just to make the 180° turn.

maybe we will give dead recogning a shot (without the gyro) at toronto if we have time to play with the timing of it.

[PMGRACER]

After 2 regionals, our Auton mode seems to work pretty well. We did fight with R/C controler issues at the GLR all weekend though. We have ordered a new one and should be ready to roll for Nats. Our time to the bins has been a consistant 3.2 seconds. We did add some code to drop the arm to pickup more rows, and may have our wrist rotate out to pickup another row. We are only running at 80% power. We still can turn it up if we need to. Dead reckoning has been working consistantly for us. Sometimes, simplicity may not be pretty, but it can be extremely effective.

[Joe Johnson]

I have heard a lot of folks say they are using "dead reckoning."

I am confused by the term.

It seems to me that some folks mean they output PWM values of PWM1 for T1 seconds, and then output a value of PWM2 for T2, etc. This entire process only requires a clock and uses no sensors whatever. (Note to the purist out there: PWMi is a vector of dim 16)

For others, they have rotational sensors on their wheels that they used to infer robot motion (distance and perhaps orientation). In this case, teams would vary their PWM output based on location. For example, PWM values PWM1 until X1, then PWM2 until X2, etc. (There are fancier control schemes with could plan paths, use proportion control, etc. but you get the idea).

Still others are using rotational velocity sensors (a.k.a. gyros a.k.a. yaw rate sensors) and inertial sensors (e.g. accelerometers) that they integrate (twice in the case of the inertial sensors) to get position. In this case, teams use the position information similarly to the way the rotational sensors are used.

In any case, I always wonder what a team means when they say they are using "dead reckoning" to control their robot.

Having seen them work so well in Ypsilanti, I am especially curious to learn what team Rush (#27) means by the term. It is hard for me to believe they could be as repeatable and effective as they were by using just time, but I admit I have been wrong once or twice in the past.

Joe J.

[Jeff_Rice]

dead reckoning
n.
A method of estimating the position of an aircraft or a ship (or, in our case, a robot) without astronomical observations(sensor inputs), as by applying to a previously determined position the course and distance traveled since.

I think this definition works; if you have no sensor inputs, then you know you started in the gray area, and you know to get up the ramp you have to go around the edge of the ramp. If a robot uses sensors that indicate its position, then it isn't a dead reckoning. For example, you're on a ship with Captain Nathaniel Bowditch. He sights the sun, and you are in the Atlantic, knowing precisely your position. Fog comes up, and it is so thick you cannot see. He can only guess his approximate speed and heading. That is dead reckoning.

[DougHogg]

Originally posted by Solace
One thing I would like to hear about are the robots how have arms that reach over the wall to knock down the bins without actually moving. How fast do those work? There haven't been any of those at the regionals that I've witnessed.

We move a bin in the stack with our arm at 1.97 seconds (59 frames in our video at 30 frames per second).

Here's a picture from our first match at the Arizona Regional with the big screen in the background showing the official clock at 1:58 and our arm bumping the stack.

(We were 4th seed in Arizona. We would have been higher; We didn't make any "arrangements".)

Our robot, "Yoda", making first contact at the Arizona Regional

There are some videos on our team web site:

Team 980

For anyone coming to Los Angeles for the S. Calif. Regional next week, see you here.

Otherwise, look for us in Houston.

[PMGRACER]

Originally posted by Joe Johnson
I have heard a lot of folks say they are using "dead reckoning."


Having seen them work so well in Ypsilanti, I am especially curious to learn what team Rush (#27) means by the term. It is hard for me to believe they could be as repeatable and effective as they were by using just time, but I admit I have been wrong once or twice in the past.

Joe J.

Hey Joe. I am not the programmer, just the designer/fabricator/machinist/whatever needs to done guy. I donot know all the particulars of the code, but the way we define dead reckoning is this. We have a segment disc (4 Black, 4 White segments) attached to both the front wheels and use a Banner sensor for each. We have the program set to drive x direction so many "transitions" then change direction, drop the arm and scream forward so many "transitions". I believe it is something similar to how the Chiefs count the number of rotations on the Bosch motor. Although you guys have a higher precision sensing device.

The Electronics and Programming sub teams had discussed using some sort of encoder to keep track of the wheel poisition, but decided it was simpler to use the Banner Sensor. Granted you have some variation in the precise postion of the 'Bot due to carpet adhesion, battery voltage, initial machine position, but how close do you have to be? After all, we are not trying to dock the Space Shuttle. Our method has been consistant. As in most anything, consistantcy is the key. And believe it or not, we were really concerned before the season started with FIRST giving us the EduBots and the sensors a month early. We knew they would have something complicated for us to do. We did not want to be the ones left out in the cold, not knowing how to apply the sensor technology to the game. So we went to work for the next 10 weeks, exploring how Banner sensors worked and what code you needed to write to make the 'bot do what we wanted it to. I think we took our biggest weakness and turned it into one of our best strengths.