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

Re: Accelerometer use
 

Thanks. This has piqued my interest and I've been trying to read up on it. The best explanation I've found for how the Kalman filter deals with drift is that it is actually estimating an "error state" which then gets subtracted from the position as obtained from integrations. Various papers refer to it as "indirect," "error-state," or "complementary" Kalman filtering, which differs from "direct" Kalman filtering...I don't know exactly how.

I think my favorite explanation so far is from the following page: http://www.dena.demon.nl/balansbot.html

To quote,

Re: Accelerometer use
 

Here are two embedded.com articles by Dan Simon, that provide nice explanations of Kalman and H Infinity filters. Dan also provides "simple", yet practical examples. Kalman and H infinity.

*some day* , maybe, we'll get one of these running on a co-processor :cool:

Eric

Re: Accelerometer use
 

Okay, enough theory, time for some experiment:

This data comes from a test I did with an ADXL203 accelerometer and one of the old BEI Gyros from the FIRST kit. The experiment was simple: with the two sensors attached to each other, I subjected them to about +/- 10 degree tilt from vertical. The test platform was a PIC 16F877 which reported to a Visual Basic program at about 100 Hz. The Visual Basic program did all the floating point math for scaling and filtering the data, but it could all be done on the microcontroller in theory.

I went with a filter that is so simple I can show it in one line:

(gyro_rate is in [deg/sec], dt is in [sec], and x_accel is in [g], so angle is in [deg])

This is very similar, if not identical, to the one described here: http://www.dena.demon.nl/balansbot.html.

Every update, it uses with 98% weighting the previous angle plus the change in angle found by integrating the gyroscope input and 2% weighting the accelerometer-calculated angle. This puts short-term emphasis on the gyroscope estimate, but over time the accelerometer estimate takes over. I believe this is a "discrete complementary filter," but you can think of it also a just a weighted rolling average.

Here's the data over 25 seconds:



The gyroscope-only angle estimate drifts as expected so that after 25 seconds it is about 3-4 degrees off. The accelerometer gives a great long-term average, but in the short term it is subject to sideway acceleration. (You can see when I intentionally produced some sideways motion around 16-19 seconds.)

The filter takes care of both problems. In the short term, it responds quickly to gyroscope integration estimates to predict changes in angle, but in the long term it always returns to the trusty gravity-based accelerometer estimate. So you get the smoother curve of the gyro estimate, but without the drift.

Re: Accelerometer use
 

Awesome work, glad to finally see someone actually applying this stuff to solve the problem.
Is the equation supposed to have x_acceleration also multiplied by dt?

Your filter idea is very simple and seems perfect for first like applications. Have you/Can you run trials for time periods greater than say a minute? Perhaps measuring real angle vs. calculated angle. I could definitely see this being a white-paper.

Re: Accelerometer use
 

Would you mind posting the VB code you wrote that made the nice graphs or did you just log it to a file and then graph it in excel?

Re: Accelerometer use
 

Oops, I probably should have explained that. This is for a vertical tilt-sensor, like on a Segway, so it is detecting the "acceleration" (force/mass) due to gravity. As it tilts, the horizontal axis of the sensor sees a component of the gravity vector, so x_accel = 1g*sin(angle). So for small angles, this is approx. just 1g*angle. That's where
comes from.

The same filtering concept could be used for horizontal direction-finding, but you would need a different type of sensor (magnetic? wheel encoders? GPS?) to merge with the gyro and/or accelerometer reading. So far as I know there's no way to do absolute long-term horizontal positioning with just a gyro and accelerometer, because both would need to be integrated and would then be subject to drift.

But I agree, this would make a great white paper topic. My gyro is broken (one of the pins broke off, it was hanging by a thread when I found it), so I'm temporarily stalled until I fix this one, find another one, or order a new one. But then I will run some more tests and try to write something up. If anyone has more practical information on the other types of filters and how to implement them in code, I'd be happy to co-author with you.

The VB program just saves all the data into a text file that I then plotted in MATLAB (could be done just as easily in Excel). I'd be happy to send you the source files if you still want to see it, though.

Re: Accelerometer use
 

Thanks for all the info! This is a great thread.

Team 1329 is currently attempting to build a crude segway as a summer project, and I think our biggest programming obstacle is integrating the gyro and the accellerometer. We got the platform built last year, and we tested it with only an old gyro and no accellerometer. As expected, it violently "balanced" more or less and then the gyro drifted. This summer we are upgrading to a better gyro and adding a 2 axis accellerometer. I have tried reading up on kalman filters but the math is getting to me, so I think we will try something like what ZZII 527 presented above. It looks really promising.

It will be a little while before we get that far, but I will post our results when we get them.

Re: Accelerometer use
 

Any pics? A couple of guys and I are planning on building one and we are just looking at as many pics of them as possible, mostly to see what materials others use. Here's a pic one of my friends found.

Re: Accelerometer use
 

Actually, the reason I've been so interested in these different filters is because we're also attempting to build a Segway. http://www.tlb.org/scooter.html is probably the most famous one out there. It is the fifth hit on Google for the search term "segway." But that is soon to be replaced by us:

http://web.mit.edu/first/segway

We're still in the planning stage, so no pics yet, but I thought it'd be good to start thinking about control now since that is the primary challenge. Anyway, I think the filtering method presented above and on http://www.dena.demon.nl/balansbot.html is by far the simplest and will be very effective.

Maybe there should be a Summer Segway project thread started? Seems like quite a few teams are doing it. Sharing resources in the course of friendly competition...sounds familiar.

Re: Accelerometer use
 

Attached is the picture of our segway attempt. Its pretty big, but we kept the weight down where we could.

For motors we used 2 wheelchair motors found on ebay. We are controlling the entire thing using standard FIRST kit parts, with the exception that we have recently upgraded to tecel 24V controllers. The tradeoff is that we will now have to carry two 12V batteries, but I think the increase in power will justify the weight. With the new controllers, I think it will have more than enough power, but we will see when we get some control code in there.

It sounds like there should be a separate homemade segway thread, I think it is a popular project.

Re: Accelerometer use
 

Wow! Nice work. I especially like those wheels. Is it stable with no rider because of all the weight being below center of the wheels?

We are going for more of a Segway ultra-light - something like 35 lbs without the battery. My hunch is that the majority of the effective mass that the motor has to control for near-vertical stability comes from the base, not the rider. I have to think a bit more about the physics, though.

Re: Accelerometer use
 

Are those wheels off of a trick bike? They are pretty nice.

Our segway will be made using monocoque. We also have two sizes of bike wheels that we can use 24" bike wheels and 26" bike wheels. Does anyone know which on will work best, becasue right now I'm stuck between the two. They both are free and are in good shape.

Re: Accelerometer use
 

We tried to keep it light with the materials we had, but it is still well over a hundred pounds without the rider.

The center of gravity with no rider is below the axel, so it does balance itself. With only the gyro we were able to get it to balance for a short period of time with a weight that put the center of mass above the axels.

As far as I know those are just bike wheels from a small mountain bike. Im not sure of the diameter but I think it is around 24". I have no idea whether big wheels work better than small wheels, but I think it would depend mostly on your motors.

Re: Accelerometer use
 

I got a new ADXRS401 evaluation board this week. It's amazing how much smaller it is than the stuff inside the BEI gyro - MEMS technology has come a long way.

The bad news is my new sensor has a null bias problem that I can't troubleshoot. The zero reference gives a clean, precise 2.50V (512 on the analog to digital conversion), but when it is stationary the rate output gives about 2.15V (440 +/- 3 on the ADC). I don't think this is within normal tolerance, so it may be broken.

The good news is that it's perfect for testing a drift filter because the offset is so unstable. So I just picked a number near 440 and used that as my zero, then ran the same filter program. Here are the results for 90 seconds this time:



I apologize for the lack of labels: the x-axis is time in seconds, the y-axis is angle from vertical in degrees. The blue (lighter black?) data is the gyro-only estimate. The red data is the horizontal accelerometer-only estimate. The thick black line is the filtered estimate.

It's pretty clear that it won't drift even over long periods of time. The wandering gyro offset may cause it to be off by a couple degrees, but this would be a constant offset not a drifting offset, so easier to correct. And it definitely rejects horizontal accelerations. (See 25 to 45 seconds.)

I'm in the process of writing something up about this, with a bit more detail on how to set the filter constants, which I will post as a white paper soon.

Re: Accelerometer use
 

Notes on the filter idea from above, as promised:

http://www.chiefdelphi.com/media/papers/2010

Feel free to PM/email me if you have questions, comments, or catch any mistakes in the notes.