Inertial navigation systems

[patrickrd]

On Cornell's robocup team we use a gyro for local feedback on the robots. There is a camera on top of our "soccer field" that takes photos of the field and sends information to each robot about where it is and where all the friendlies, opponents, and ball are. However, the information is time-delayed, thus it is slightly out of date. To make a long story short, the gyro helps the robot determine exactly what angle it is facing, since the vision data is outdated. Equally important, it also is used to make sure the robot is achieving the commanded rotational velocity.

An application to FIRST will give you much less satisfactory results, since once the match starts, the gyros and accelerometers are the only thing telling your robot how far it's gone and in what direction. These sensors only give you accelerations, not distances, so you need to integrate twice to get where your position is at a given time. The sensors have error and uncertainty (noise), and since you are integrating twice, the error accumulates to the second power with time. Based on my experience, it is still worth it. With JUST a rate gyro for feedback I've seen a robot move forward, do a complicated maneuver, and return back 5 seconds later to the exact place it started. Calibration and good use of the feedback (how to correct the position once the feedback tells the robot it is going off course) will be key to success.

Good luck,
Patrick

[Wetzel]

In 2003 116 had some sort of internal error correction for auton mode. I belive that a white paper is planed for this.

I was not involved in it, but my breif understanding of it was that it used the gyro and separate electronics to maintain the desired heading when heading up the ramp. It detected angular change. I really should pm Sean and have him give a real answer.


Wetzel
~~~~~~~~~~
As many times as I've heard it, you'd think I'd remember.

[DaBruteForceGuy]

all i c an say is.... i'd hate to be the programmer.... this is the prescise reason i avoid such complex systems on the robot. it hard to visualize a program (though i kno it can be done) that factors in acceleration, time, direction dealing wiht two motors (and that is if we are using a simple skid drive system)... and multiple other factors. if you as me an interntail sensor might be over doing it for a FIRST robot when you could always just calculate the displacement/time......

..... but after-all, i am only the Bruteforceguy, i like things i CAN visualise in my favorite 3 dimensions (all those excluding time ;-))

[Greg McCoy]

Originally Posted by DaBruteForceGuy

all i c an say is.... i'd hate to be the programmer.... this is the prescise reason i avoid such complex systems on the robot. it hard to visualize a program (though i kno it can be done) that factors in acceleration, time, direction dealing wiht two motors (and that is if we are using a simple skid drive system)... and multiple other factors. if you as me an interntail sensor might be over doing it for a FIRST robot when you could always just calculate the displacement/time......

..... but after-all, i am only the Bruteforceguy, i like things i CAN visualise in my favorite 3 dimensions (all those excluding time ;-))

But that's what makes programming interesting! Coming up with math solutions to real-world problems and then figuring them out with computers is what programming is all about. Personally I'd rather learn more about doing this than program boring stuff like "Button C runs Motor 5."

[seanwitte]

Originally Posted by Wetzel

In 2003 116 had some sort of internal error correction for auton mode. I belive that a white paper is planed for this.

I was not involved in it, but my breif understanding of it was that it used the gyro and separate electronics to maintain the desired heading when heading up the ramp. It detected angular change. I really should pm Sean and have him give a real answer.

I don't think it really warrants a whitepaper. We used a Basic Stamp 2sx to integrate the gyro and return the relative heading as an analog input to the RC. We soldered an ADC and DAC onto the stamp carrier board so it was a self-contained system. When the robot was placed on the field the pit crew hit a reset button to set the base heading. The base heading was seen by the RC as 127, increasing clockwise and decreasing anti-clockwise. As long as the robot didn't turn too fast it worked like a compass. We used the heading to drive straight and to make repeatable turns. The robot slipped sideways on the ramp a couple of times and it was able to correct and drive to the top. There was also a button on the joystick that, when held down, would lock in the current heading and drive straight. It wasn't necessary to do this externally, but its nice to be able to swap the component between the EDUbot and the full-size robot without making any changes to it.