Accelerometer use
 

Hello,

I have seen in more than one place where people have used an accelerometer to integrate into a gyro signal, cancelling drift. Umm...how?:confused:

I have no idea what the algorithm would be.

Thanks for any insight you can provide,
JBot

Re: Accelerometer use
 

not sure, but could you offset or blend the gyro values with the accel values to give heading? or for every degree off on the accel, take a percentage off of the gyro value. although, unless your robot is on its side, there shouldn't be too much drift or error in the gyro. honestly, for most applications you should be fine. it's kind of like a compass: it's accutate until you're near the earth's poles, then it's useless. my guess is that there shouldn't be much gyro error on a slant, but if there is, i can't really see how an accel would help that much....i'm guessing that a gyro would be sufficient; i havn;t heard of any complaints of drift....

if worse comes to worse, juat make a joystick button that, when pressed, resets the gyro heading angle. that way, if something really goes wrong, you could reset it. or, a fail-safe for that, substitute raw joystick values to the motor, skipping the gyro completely.

Re: Accelerometer use
 

Just yesterday I was reading on a combat robots forum about how to do that... I'll look for a link now...

I've been out of the more advanced programming for a while so I'm not entirely sure, but I think he compared the accelerometer's reading to the rate of rotation, or the derivative of that (rate makes more sense to me...). Could someone expand on this?

Re: Accelerometer use
 

I've heard of people using a "Kalman Filter" to integrate gyro and accelerometer readings, but I don't know if I'm remembering right or how you would do it.

A search found this wiki entry.

What are you suing it for?

Re: Accelerometer use
 

We have used an accelerometer for the last 3 years to cancel drift on our drive system. I don't know if there is any integration involved, however I believe the we do use a PD loop to get rid of the drift.

We feed a desired value and an incoming offset into the PD loop to get the drive motor correction. I know that there is some calculations that the code does to determine the incoming offset but I don't have the code in front of me.

I'll either look into it or get someone who knows the code better to post sometime soon.

Alex

Re: Accelerometer use
 

I've been contemplating this for a while too, as I used the difference between the two values coming back from the encoders on the drive train for detecting and preventing drift. However, in threory*, the acceleration measured from the accelerometer can be used as a internal GPS system. With a known starting speed (0 m/s) when the robot initializes, and with a known acceleration each time through the loop, you should be able to ascertain the exact speed and direction of your robot at any time.

With the initial velocity, acceleration, and time, you can use simple physics to determine the final velocity. If you keep a running counter in your code to track time between executions of the loop, as well as the output speed from the previous time through the loop, you can keep running this code to find the current velocity of the robot, as well as the distance covered from the previous location.

If you include the gyro, it gets a lot more complicated, as now you have to deal with trigonometry and more vectors, but you still should be able to run your current data through physics equations to get the current location, orientation, and position of the robot relative to the origin.

* I've never actually tried this; this is just an educated guestimate from what "should" be feasible on paper. Whether the controller is powerful enough to handle that many floating-point math problems (co-processor anyone?) is another story. I apologize if what I wrote here is really off-base. :)

Re: Accelerometer use
 

What exactly are you trying to do?

Combining a singly gyro and a single accelerometer is fantastic for giving position and direction on a non-holonomic (aka KitBot) robot. Unfortunately, it doesn't sound like that is what you want.

Canceling noise is hard. Canceling drift is harder. Noise assumes that the data we are getting back is essentially Gaussian, which means we can do fun filtering . Drift is inherently more evil, as it implies that the sensor tends to one side. I don't know of a good way to handle drift without using some side-band information. In other words, if your sensor has drift, something else better compensate for it.

One thing you might consider doing is finding out when you KNOW your gyro better be reading 0s. If you ain't moving, you ain't spinning. Perhaps you should keep a note of how your gyro handles sitting still, convert that to a DC offset, and subtracting it out.

Another method (less good) is to make your accelerometer into a craptacular gyro. Place it as far forward or backward as you can, in the middle of the bot, and rotate it to point side to side. Now when you spin, the accelerometer picks it up. However, it also picks up when you get slammed into, and it totally bombs for accuracy because it in no way compensates for your turning radius.

More info = more answers.

Re: Accelerometer use
 

Well I'm guessing you could place the accelerometer so that it is perpendicular to the direction your robot travels.
When the accelerometer reads ~0 you are at your 0 acceleration reading f or the Gyro(there is often a gap between true 0 and 127). This way you could recenter the gyro in real time. I would probably integrate the accelerometer reading for a few seconds and if it steadily sums to a 0 reading then you can be fairly sure the data is correct and that the current gyro reading is also a 0.

Furthermore you know that the accelerometer isn't biased towards a single side, so when you turn in two different directions you can figure out how much bias is in the gyro by looking at the integrals of the accelerometer over time and based on this you can probably calculate how to re-scale the gyro output by comparing the two different sets of integrals for each side.

I don't think noise should be too much of a problem, we are taking so many readings per second that if it is fairly random it will average out to zero over a short period.

I'm assuming the accelerometer supports acceleration in two directions??? is this true?

Re: Accelerometer use
 

Yes. I assume that he will be using the kit accelerometer which is a DAA.

Re: Accelerometer use
 

You're talking about an Inertial Navigation System. GPS relies on external references; INS is fully self-contained.

Other people have tried it on FIRST robots. There's too much noise (mechanical, mostly) for anyone to have made it work reliably...yet.

Re: Accelerometer use
 

Here is some info on a Filter you can use to help cancel out noise if you are interested:
http://en.wikipedia.org/wiki/Kalman_filter

It is kind of dense and hard to understand, but I think it would be possible to implment if you got some outside help.

You may also be interested in page 668 of this article:
http://robots.stanford.edu/papers/thrun.stanley05.pdf

I think it might be better to get creative and come up with your own way of filtering out noise, you can use multiple sources (Gyro, Encoders, accelerometer) and based on correlations figure out which ones are accurate and which ones aren't

Re: Accelerometer use
 

I am reasonably sure that that is exactly what a Kalman Filter does: Take a whole bunch of noisy measurements and boil them down into one less noisy measurement. Unfortunately, I think that using an accelerometer as a noisy gyro is weak at best. I do like the use of encoders though.

Please take what I say with a hefty grain of salt, as my education for Kalman filters is hilariously spotty. I was helping to interview candidates for a position at Olin, and as a result I heard 4 or 5 introductions to SLAM (Simultaneous Localization and Mapping). Each professor would then gloss over Kalman Filtering with varying degrees of success.

I think it would be a great project to do a white paper on Kalman Filtering as applied to an IMU for FIRST. Take a kit bot, add a gyro, accelerometer and a pair of encoders. This gives you some degree of redundancy, as either the gyro/accelerometer pair or the encoder pair could do all of the work. Then you can combine their data for a more robust system.

Enjoy

Re: Accelerometer use
 

If anyone is interested here is an excellent (and much easier to understand) paper on kalmann filtering :
http://www.cs.unc.edu/~welch/media/pdf/maybeck_ch1.pdf

Re: Accelerometer use
 

I've seen that chapter referenced before so I'm glad someone posted it. I'll have to do more than just skim through it at some point, but I have a question:

The Kalman filter seems to deal with noise - specifically Gaussian white noise. That is, given two estimates of a state, say position, and a general idea of how noisy the estimates are, it will yield an optimal combination with less error than either of the two estimates alone. How does this apply to drift? Drift would seem to violate the Gaussian noise assumption, since the mean estimation error (not zero), integrated in time, is what causes the drift in the first place. That is, you could have a very clean signal that has still drifted away from the true position due to the integration. Wouldn't you still need a zero reference at some point?

I like the idea of using the accelerometer to signal a zero-reference update. It can tell when you are not spinning, so why not recalibrate the gyroscope to zero velocity then. Of course, that doesn't help with position directly. Also consider a vertical example: Say you want to cancel drift from the gyro on a Segway's primary axis. With a two-axis accelerometer oriented so that the third axis is the gyro axis, you can be fairly certain of when you are not moving because the resultant acceleration from both axes will be just gravity. When you see this condition for more than some period of time, recalibrate the gyroscope based on the trig of the two accelerometer readings. I'm thinking you can also do this on the fly with some trickier math, but I'm not sure.

Re: Accelerometer use
 

Yes, you're right. A kalmann filter is only really effective when dealing White Gaussian noise. The noise we are dealing with in the gyro is still of this quality, It is integrated over time yes, but the noise in the measurement from the gyro itself is not non-gaussian. Based on this principle as the time variable increases the probability distribution of the estimate produced by the gyro "widens" ... it's measurement simply becomes more and more unreliable. Now if the Gyro happened to have different levels of noise at different levels of acceleration we would have a real problem... but it since the noise distribution from the sensor itself is white and gaussian Kalmann filtering will work. (not as effectively of course... but it can be used)

BTW
For those of you who don't know what that is here's a simple explanation:
White noise basically means that the noise in the current state has no bearing on noise in the next. Basically it means that the noise is "random".
Gaussian relates to the amplitude of the noise. A gaussian distribution is basically a "bell curve". If noise is gaussian it means the probability distribution of the amplititude of the noise will be a bell shaped gaussian curve.

I don't think there's an effective way to account for drift using Kalmann filters alone, Although since you know when you are standing still (with almost 100% certainity) you can basically give the Gyro a very narrow probability distribution at the start along with the somewhat wide distribution of wheel encoders, then as you build a better model through the kalmann filter re-adjust the gyro bias to lineup with your best estimate (using measurement from both sources: wheel encoders AND gyro itself). It's rough at best but certainly better than just integrating the gyro to read an angle.

Also the Kalmann filter does take into account integrated estimation error by basically "widening" the probability distribution over time, if a gyro is off by a little bit it's error will be summed over time... This is how it can be used when dealing with velocities