Inertial navigation systems

[Greg Needel]

I was curious about these systems for first and another robotics endeavor I am working on (DARPA grand challenge). I know that team 190 made/used one last year but I was wondering if there were any specs on the actual system as a whole. I found this pic online and it really peaked my interests. .

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

[Craig Putnam]

Team 42 (P.A.R.T.S.) has done some off-season R&D in this area since last year's competition. Suffice it to say that, integrating accelerometer output twice to derive position data *without feedback* quickly results in a lot of accumulated error.

We have also experimented with using the output of an optical mouse along with the rate gyro. We have had some success in this area using the old BS2SX-based EDU-bot controller. We are continuing our work in this area and are very excited by the capabilities of the new PIC microprocesssor.

We have white paper that goes into a fair amount of detail regarding both methods for navigation control. Unfortunately, the paper is too large to upload here. Contact me directly if you would like a copy.

[KenWittlief]

last year we used the supplied yaw rate sensor to figure out our compass heading - you can do it with ONE line of code!

when the bot is not turning the output of the yaw rate sensor was 127 - when you turn in one direction the number goes up, the other, the number goes down (yaw rate sensor wired directly to analog input - no external circuits/filters or anything else)

start off with a 16 bit variable initialized to 32000. then somewhere in your code add the value of the sensor to that heading variable, and subtract 127 (to correct for zero being 127)

THATS IT! thats all it takes - as your bot turns in one direction, the heading variable will increase - as it turns the other way, it decreases. If you turn 180° right, then turn 180° left, it will go back to 32000

it works EXTREEMLY well - the errors tend to cancle themselves out - the only refinement you might want to add is to let the bot sit for minute while its not moving, and see if zero is 126, 127, 128... and use that as your zero offset.

with a little testing you can find out how many counts in the heading register is equal to 1 degree - turn the bot 90° right and read the register. but dont bother dividing the heading register by a constant to work in degrees - just use whatever units the register comes out to be - for example, if 32,000 is zero heading, maybe 45,153 will be +90° and so on.

thats all there is too it - since the SW loop runs at a consistant rate, simply adding the sensor signal to the variable is all you need to do to intergrate degrees/second into degrees!

if someone wants to cut and paste this into a white paper, knock yourself out :c)

[Mike Soukup]

Originally Posted by Craig Putnam

Team 42 (P.A.R.T.S.) has done some off-season R&D in this area since last year's competition. Suffice it to say that, integrating accelerometer output twice to derive position data *without feedback* quickly results in a lot of accumulated error.

Quite true, just ask 190 how far their robot thought it moved while it was sitting still on a table. Accelerometers have a lot of noise and the noise is magnified greatly when it's integrated twice. If you want to use an inertial system for position you need a way to get rid of the noise or another way to correct your position when the noise throws you off.

[shsdragon]

wut are yaw switches

[WernerNYK]

Yes, there was a lot of noise within our system. And yes, it began to drift while sitting still, and the double integration only further compounds the error. However, our team of people working on the INS applies many many filters and was able to reduce most of the error. It was more than good enough for 15 seconds of autonomous, however I think after something like an hour or something it thought it was heading towards the moon or something (I dunno, I'm a mechanical guy, but I think that's what I overheard, hehe).

After the season, one of our team members (who ironically did not work on the INS), completed his MQP (Major Qualifiying Project) on an INS for Autonomous robot navigation. I believe he was able to vastly improve upon our design and reduce the noise to almost negligible levels. But again, I am not sure.

[Greg Needel]

Originally Posted by shsdragon

wut are yaw switches

yaw rate sensors are also called gyros they can measure the degree of lean in a direction. think of them as a virtual cup of coffie the coffie stays level to the ground but the cup changes. from this your can have it do corrections on directions and lean and a whole bunch of other functions. take last year for instance. if a team knows what the angel your robot is in when it is going striaght up the ramp some teams would write code that would auto correct the direction for autonomus code so that they could go straight up the ramp....there are alot of other uses take the segway for example

for specifics on how to program them i'm sure someone else in this fourm is more qualified to let you know how to do it


hope that helps

[generalbrando]

I'm wondering - for those who have used these sensors (mainly the accelerometers), did you shield the system (as in shielded cables)? I'm not really saying this as a suggestion - my team is planning out a design for position tracking and I was wondering if that would help fix the noise problem.

Thanks

[KevinB]

Originally Posted by generalbrando

I'm wondering - for those who have used these sensors (mainly the accelerometers), did you shield the system (as in shielded cables)? I'm not really saying this as a suggestion - my team is planning out a design for position tracking and I was wondering if that would help fix the noise problem.

Thanks

I toyed with the idea of an accelerometer-based system around the beginning of the year. I bought some, hooked them up to the EDUcontroller, and played with them for a while. I tried everything I could think of to reduce the noise, but it was still far too great to be worth anything for positioning. Some things I tried: different capacitors between the +5v and GND, different wire lengths, different types of filters on the output.

The reason for that (as I now finally have proven to myself) is because the acceleration would have to be integrated twice to achieve position information. The noise from the accelerometer would cause your velocity calculation to drift -- as the noise built up, your system would think you're going faster and faster (in one direction or the other). This is enough to totally throw off the position calculation.

[blindguyinanorg]

this noise we are talking about, what couses it. to me it seems that if the yaw sensor is reset every so often that would eliminate the errors.