Inertial navigation systems

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

[ahecht]

Originally Posted by Greg Needel

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.

Not quite. The yaw rate sensor doesn't measure degree of lean, it measures how fast you are leaning. Imagine if someone put a spedometer on the surface of the coffee that measured the speed between that surface and the mug.

The name Yaw Rate sensor come from the naming conventions for the 6 degrees of motion, heave (sliding up and down), surge (sliding forward and backward), sway (sliding side to side), roll (rotating side to side), pitch (rotating forward and backward) and yaw (rotating side to side). Since yaw referrs to side to side turning, so a Yaw Rate sensor measures the rate of side to side turning.

[Joe Johnson]

Originally Posted by shsdragon

wut are yaw switches

A Yaw Rate Sensor is an angular rate sensor -- it returns a voltage propotional to the rate of rotation of the sensor.

They are pricey ($100 for one from Analog Devices -- ADXRS150 -- mounted on an evaluation PCB -- the chip has a ball grid array interface which is not that easy to use for most teams), but they can be very useful.

Joe J.

[ahecht]

I'd definately agree that the accelerometers were the weak link in the INS system. We didn't get much more than 10 or 15 seconds of good postition data from them, and it took under an hour for the INS to report a velocity greater than the speed of light while sitting on a table. The gyros (which were not kit gyros, as the 75 degree/sec limit of those wasn't enough for us), however, were much more accurate, and should make a return on this year's robot.

Commercial INS systems, which are accurate over a time period of hours, can cost tens of thousands of dollars, and for good reason.