Inertial navigation systems
 

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

Re: Inertial navigation systems
 

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

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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 ;-))

Re: Inertial navigation systems
 

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." :)

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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)

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

wut are yaw switches

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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 :D

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

Re: Inertial navigation systems
 

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

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

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.

Re: Inertial navigation systems
 

It seems to me that much of the noise inherent to analog accelerometers could be minimized through clever use of shielding and filtering. Team 190's inertial navigation system, while quite impressive, does not appear to be particularly well shielded; the top of that housing appears to be made of Lexan or similar material, which does not provide any electromagnetic shielding. Manufacturers of analog accelerometers usually suggest leaving most of the extraneous copper unetched and grounded on whatever PCB is used, which provides a nice big ground plane surrounding the sensor and its board traces. Performing all of the integration in software would also help somewhat, as op-amp integrators are alarmingly sensitive to noise. Using a simple approximation, such as that suggested elsewhere in this thread, reduces the sample rate enough to filter out quite a bit of the high-frequency noise without compromising the accuracy of the position data. Low-pass filters should be placed on all accelerometer outputs to reduce ripple from the accelerometer's internal clock. Finally, it would be wise to make sure the power supply is VERY well filtered. By paying careful attention to reducing or eliminating noise from external sources, it should be possible to construct an inertial navigation system that is suitably free from error to provide accurate position information throughout the entire match.

Re: Inertial navigation systems
 

I have been working on a 3 axis accelrometer for a satelltie with the University of Texas, and I can offer a few tips for those that are looking to develop one:

- I reccomend doing it as a seperate circuit and then feeding it into the UART of the robot controller as a digital stream. That way you can get accurate timing, etc.

-Make absolutely sure that you filter the analog vcc line on your microcontroller (an inductor up to power and a cap down to ground), as it needs an extremely accurate 2.5v to take a comparison reading from, and if the line is noisy, it'll throw off your readings.

-Use 2 sets of acclerometers and take the average of the both of them. Thus any error is reduced significantly.

-Search the web for analog smoothing algortihms. There are some really good ones out there.

-Shielding the lines, etc can be helpful, but the biggest difference that I have seen is fildering the analog vcc line. After I did that, my system's accuracy jumped up quite alot.

-There is a good white paper on this site on using the noise from the system to gain additional resolution. It has some good tips...

More later...
Bill

Re: Inertial navigation systems
 

I suspect the circuit inside the robot controller that supplies the analog output Vcc pins and ADC reference pins is already well-filtered and supplied from a stable internal voltage reference. Failing to do this within the robot controller would be a tremendous oversight on IFI's part.

Re: Inertial navigation systems
 

Agreed, and I would be shocked if it wasn't. I was stating that you should filter it if you were building a seperate board with it's own microprocessor to take the readings and the pass them on digitally to the robot controller.

Bill