A Simple Low-Pass Filter (Concluded)

The last post covered the concept of the Exponentially Weighted Moving Average Filter and illustrated how it worked on a theoretical example, both with and without noise.  To wrap up, I want to include an actual set of data from the Devantech CMPS10 Tilt Compensated Compass on my current robot.  Although, as the name says, it has tilt compensation, I’m using the raw magnetometer output, as the robot is running on flat floors, and rotations and accelerations are liable to introduce more error than the practically non-existent tilt.

In my code, I’ve set α to a fairly high value of 0.33.  Here’s a plot of both the raw and filtered output for a case where the robot stayed fixed, then was manually rotated rather quickly to a new position:

As you can see form the plot, the filtered response, as expected, lags the raw response after the turn.  However, the raw output overshoots (I’m not sure why), so the lag actually results in the filtered output more closely matching reality, even right after the turn.  It’s not possible to see the effects of the filter on the noise from this plot, so this second graph shows just the raw and filtered data before the rotation, with the scale blown up:

The filter’s ability to modulate the noise is clearly evident.  The raw output bounces around +/- about 4.6 degrees, while the filtered output jumps within the much narrower range of +/- 1.5 degrees.

Filtering Noise from Sensor Readings: A Simple Low Pass Filter

In a perfect world, a sensor’s output would exactly match the input it is sensing.  In the real world, there are a number of errors introduced, including bias, time lags in response, and noise.  This article discusses one of the simplest filters for reducing noise: the Exponentially Weighted Moving Average (EWMA) filter.  Despite its long name, it’s about the simplest and most efficient filter you can implement.  The name comes from the concept that the filter’s output, y, is the weighted average of the current input and each previous inputs, with the weighting decreasing exponentially:

Yt = α (Xt + (1 – α) Xt-1 + (1-α)2 Xt-2 + (1-α)3 Xt-3 + ….

where Yt is the current output from the filter, and Xt is the current input, and the other X’s are each preceding value.  The weighting is shown in the figure:

(graph courtesy of Kevin Ryde, licensed under the Creative Commons Attribution-Share Alike 3.0 Unported license.)

This averaging tends to smooth out the response and reduce noise.  Of course, this formula would be cumbersome and time consuming to implement in an embedded system.  Even if only a small number of past values were used.  Some math can show that the formula can be rewritten as a recursive formula using the past output from the filter:

Yt = α Yt-1  + (1 – α) Xt for all values of t > 0, or, re-arranging terms:

Yt =  Xt  + α ( Yt-1 – Xt)

This means that all you need to store is the immediate past output of the filter, which already has the weighted average of all previous values calculated in. This is simpler and takes less storage than, for example, averaging the current and past 4 values of the sensor.  It will also respond more quickly to actual changes that you are trying to measure.

Limits

You can choose a value for α ranging between 0 and 1.  At 0, the output is just the raw input: no filtering occurs.  The output will respond instantly both to noise and to true changes in the system.

At 1, the output becomes equal to the past value: it never changes, eliminating all noise and all real signal changes!  Clearly one wants to select a value in between these extremes.

Selecting α

The correct value will depend on your situation.  The higher the a, the more noise if filtered out, but also the more lag that is introduced in reacting to real system changes.  This is shown in the following figures:

This figure shows the response of two filters to a unit step function.  The red curve is for α = 0.3, and the green curve is forα = 0.6.

This graph shows the output of the filters to a noisy sensor, with Gaussian noise with a standard deviation of 0.1.  One can see from the graph that a value of 0.3 reduces the noise somewhat, but leaves a lot in.  A value of 0.6 greatly reduces the noise, at the expense of greater lag.

Initializing the Filter

The formulas work for all values after the initial run of the filter.  Like any recursive formula there needs to be a starting value.  My rather rough and informal scanning of the literature identified three common methods:

  • For the first pass, set the output equal to the input (same as no filtering)
  • Take a small number of readings, e.g.,  5, and use a straight average of these as the initial output.   This is what I did for compass readings in my current robotic vehicle.
  • For control processes, an alternative is to set the initial output at the desired control point (figuring, I suppose, that if the control system is working, the average should be at the control point).

Summary

The simple EWMA routing can be summarized as:

For t= 0:

Yt = Xt

Else:

Yt =  Xt  + α ( Yt-1 – Xt)

Further Reading

There are many different types of filters, each with advantages and disadvantages. No one filter is best for all applications.  I’m just a hobbyist, and don’t pretend to have much knowledge in this area, but there is a wealth of information out there.

As always, any feedback, additional comments, or corrections are welcomed.

Entering the Well… Duh Zone: Refrigerator Magnet(ism)

My vehicle originally relied solely on odometry for dead reckoning, with rather poor precision for turns, which quickly leads to large errors. So I added an electronic compass for determining the heading. This didn’t improve things as much as I thought, with the vehicle often heading off in what was clearly the wrong direction. I determined that at least once source of the problem was sensor lag. When the vehicle pivoted in place to turn to it’s next heading, it turns fairly quickly, and the compass lags a fair bit. So the vehicle would overshoot the desired heading without realizing it. The technical term for this lag is rate dependent hysteresis.

To address this problem, I added a rough check on the heading, and if in the right ballpark, the vehicle stops, waits a bit for the compass to settle, then redetermines it’s heading. If not pointed in the right direction, it slowly turns by small increments, with pauses in between, until it is on the correct heading. This isn’t fast, but it seemed to work fine in preliminary tests in in my finished basement, which is carpeted. However the tracks didn’t get great traction when moving, while at the same time, had a lot of friction during turns. So, set the waypoints further apart and move to a wood laminate floor in the kitchen where the robot runs great. The result: worse then when using just odometry! The vehicle kept thinking it was veering well off course when it was traveling almost in a straight line, and the bearings were way off reality.

As you might guess from the title of this post, the problem is obvious in retrospect: lots of large metal objects in the kitchen, including the fridge about 18″ from where I was starting the vehicle. This threw the compass off by a fair bit. Once I realized this and retested outside, all worked fine.

Now that the compass is finally working, here are my plans:

  1. 1) Add PID control as the vehicle travels. Right now, it determines a heading, and drives off with equal power to both motors. It just runs open loop until either reaching the waypoint, traveling the calculated distance to the waypoint, or traveling a preset max. distance. At that point it checks its own location versus the waypoint and re-orients. This isn’t bad if running on an even surface, although it still tends to turn a bit. But if one tread slides or has different traction, it heads off in the wrong direction for some time. I want to close the loop with PID control.
  2. 2) Once that works, switch over or add a GPS for heading as an option, just to checkout the GPS unit and programming to interface to it. The main use of the GPS will be for a faster, outdoor autonomous vehicle to be developed after this.