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.