Kalman Filters

[dknguyen]

DOes anyone know anything about Kalman Filters? I have seen it mentioned in some projects where sensor conditioning was involved but I never knew what it did (nor bothered to look it up, I just thought it got rid of noise like other filters). But then I found an article mentioning that it could be used to "track" the drifting zero bias of a sensor and that got me pretty interested.

So far, I have been planning to recalibrate the zero bias of the gyros and accelerometers on my robot everytime it came to a stop to try and fight the bias drift, but I was wondering if using a Kalman filter "instead of"/"in addition to" steady-state calibration would make it more reliable, or more needlessly complex. I should also note that my task is time-sensitive. (I am not just taking a reading from the sensor, but also integrating it which factors in to how much more processing power would be required with the Kalman filter vs. the improvements gained).

As for how the Kalman filter actually works...the articles about it are pretty mathy, does anyone have a more conceptual explanation? Or is it just as complicated (or moreso) than the Bessel filters and the like?

 

[hjames]

I'd describe Kalman filters as where linear algebra meets statistics. (https://www.cs.unc.edu/~welch/kalman/ is a good intro to the stuff, page 6 of his https://www.electro-tech-online.com/custompdfs/2006/06/kalman_intro.pdf has a useful diagram which lays out the basic equations).

My offhand/wild-guess answer would be "no" (It's the easy answer too...)

A more detailed answer might be:

A Kalman filter requires some model of the system. In the case of an accelerometer on the robot, you would need some function which relates the actuators to the sensors. In wavy-hand talk, (A real simple) Kalman filter is going to try to cancel out the contribution of the actuators on the sensors, and is then going to perform a running average on the resulting values.

Now the tricky part is finding the relationship between the actuators and sensors - either by measurement, or more typically another Kalman filter. The problem with accelerometers is that they're going to "see" gravity, and unless you can cancel it out (oh, wait, we're trying to find bias here, aren't we), this second filter would try to figure out which way the slope is while the robot is changing orientation.

The way Kalman filters tend to be used in accel/gyro type applications is that their primary purpose is to estimate the current state - position/orientation/velocity/acceleration. Additionally more information from compasses/gps/vision are gathered and fed into the same Kalman filter. Bias values are usually pulled out as an after thought. The strength of the Kalman filter is that it can use redundant information from different inputs to constrain the state of the system to something reasonable. If you're interested in this stuff, it usually goes under the keywords "sensor fusion".

For small robot stuff, I'd recommend that you take the general concept - figure out how the actuators(motors) and sensors(accelerometers) interact, and do a first-order type correction. Encoder values would be good, but just using "pwm" values would be sufficient. Turning requires you figure out the turning radius to figure out the sideways component. - And hope that you don't go up and down any slopes while this is happening cause that'll just throw a big wrench into the works.

 

[dknguyen]

I see...so using a Kalman filter to figure out the drifting bias and using it to correct a sensor reading is a roundabout way of doing it? You can use the Kalman Filter to directly compensate for the bias drift of reading all in one step? Neat. I get the general concept, and a bit of the math. The problem is that I am just learning the type of probability used in the derivation of the equations.

And how on earth DO you remove the acceleraiton of gravity from a forward facing accelerometer on a robot? I never even thought about that- how velocities derived from accelerometer readings of a robot going down a hill would make your robot think it was travelling faster than it really was.

 

[Nigel Goodwin]

And how on earth DO you remove the acceleraiton of gravity from a forward facing accelerometer on a robot? I never even thought about that- how velocities derived from accelerometer readings of a robot going down a hill would make your robot think it was travelling faster than it really was.

An accelerometer measures acceleration (fairly obviously!), it doesn't measure velocity - and if the robot is accelerating due to gravity your sensor needs to respond to it, it's still acceleration exactly as with any other.

 

[dknguyen]

Integration

I meant derive velocities through integrating the the acceleration information provided by the accelerometer. Isn't there any way to separate static acceleration of gravity from acceleration by movement? I have an electrolytic inclinometer that might be able to pick out the direction of gravity and filter it out that way, but it splahes when you are moving around. I was thinking lowpass filter but even if the filter is an ideal DC filter, it won't account for how the component of gravity seen by the accelerometer change as the slope changes. Garr...

 

[Nigel Goodwin]

I meant derive velocities through integrating the the acceleration information provided by the accelerometer. Isn't there any way to separate static acceleration of gravity from acceleration by movement? I have an electrolytic inclinometer that might be able to pick out the direction of gravity and filter it out that way, but it splahes when you are moving around. I was thinking lowpass filter but even if the filter is an ideal DC filter, it won't account for how the component of gravity seen by the accelerometer change as the slope changes. Garr...

I don't see how you can accurately determine velocity from acceleration?, but assuming it's accurate enough for you anyway - you still need to include it's acceleration downhill - or your velocity will get even more inaccurate.

 

[hjames]

Integrating acceleration is doable, but the standard approach is to cheat and get better sensors. I'd vote for gutting an optical mouse or two and using that as your velocity/angular velocity sensor.

Typically Kalman filters are used when you have a very good model of your environment, and a lot of sensor data. It'll combine the big pile of sensor data and perform the proper statistical weighing and output some consistent answer.

For the case of a robot and accelerometer data, depending on how much the slope varies, it can either get away with some linear model of the slope (i.e. the entire "world" is tilted), or it will have to map out the heights as it stumbles along(i.e. PHD dissertation territory...). In either case, the robot would try to update its model as it drives around and changes direction - "when heading North, my accel says x, when heading South, my accel says x+k,so my bias value is equal to x+k/2, and the N-S slope component is k/2". The mapping version would just try to recalculate this with position as another input. Obviously the numbers inside the Kalman filter are going to be much more cryptic, but this would be the general (hand-wavy) concept.

 

[dknguyen]

Optical

I plan to (hopefully) someday build an optic flow sensor (after I figure out the hardware and algorithms) to work similar to an optic mouse to augment the accelerometer readings (maybe even obstacle avoidance too!). But that's a whole new ball game compared to everything else on the robot...I must just try to just buy one from CenterEye. First things first is to get that accelerometer down. I guess one way is to break down the X and Z components of my accelerometer since I know that the 9.81m/s^2 must be lurking in there somewhere and remove it.

Actually it may not be so bad because my robot is using legs and not wheels. So I could just use "odometry" for dead-reckoning. Instead of lots of vibration during travelling like with wheels, I get a lot of piece-wise smooth accelerations with walking. Not sure if the accelerometer is more easily able to keep up with that, but I'm pretty sure the electrolytic tilt sensor is going to be much more reliable.

 

[hjames]

If the intent is to do a walking robot, then I would say that a Kalman filter would fit reasonably well, but only because the problem just got that much more complex... I was working under the assumption that it was a typical wheeled platform(with fixed ground clearance). Using an optical mouse sensor is just a matter of pointing it straight down and parsing the (pretty standard) mouse protocol. If the platform itself is tilting and lifting, it'll need to be compensated for.

The main issue with accelerometers is that the value that you retrieve out of them is a second order derivative, and is going to be inherently noisier and less accurate than a sensor based on a "lower order" source. Integrating sensor data inherently causes issues with drift(as you've noticed), while differentiating data doesn't have this drawback. You can find lots of examples of this by googling for "inertial navigation".

One thing that could be done is to just use the accel. or tilt values to confirm that the walk cycle is progressing properly - and just use dead-reckoning (i.e. *no* position feedback other than tests of the stride distance) for position estimation. In general, the only real solution is to have some sort of global positioning (vision based, beacon based, passive, active, take your pick).


In general I'd say that accelerometers are useful as

1) orientation/tilt sensors
2) free-fall/bump sensors
3) augmenting a lower-frequency sensor(in order to improve response time)

 

[dknguyen]

One thing that could be done is to just use the accel. or tilt values to confirm that the walk cycle is progressing properly - and just use dead-reckoning (i.e. *no* position feedback other than tests of the stride distance) for position estimation.

That is a unique take on it that I have not considered as much as I could have. I guess I could primarily rely on "legged-odometry" using the accels just to make sure the robot is accelerating only during a stride. and just use double integration distance records as a lowest-priority position reference and as a curiousity. (possibly to further constrain a GPS measurement since my GPS is only accurate to +/-10m).