Inertial navigation systems

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