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.

An unseasonal post: Automating Halloween Props

This post is more suited to Halloween then the coming Yule, but I finally got around to writing it, and besides, as I write this, there’s only 327 days left to next Halloween!  There are several options for controlling animated props, including prop controllers specifically designed for this purpose.  A recent addition to the market is the MonsterShield, an Arduino-based prop controller with open source code you can modify.  I haven’t tried one out, but thought it was work a mention.  In my props, I just use a handy micro-controllers, such as an Arduino, along with sensors such as a PIR.  The PIR (or pressure mat, or whatever sensor you choose) sends a signal to the microcontroller when it detects someone, and then your microcontroller can trigger a whole sequence of pre-programmed actions.  I had two such props in my Halloween display this year.  The first is a classic “Monster in a Box“.  I use a PIR sensor to detect when someone comes near.  When this happens,a Teensy sends out an output to a Power Switch Tail to turn on the power to a wall wart that delivers 12V power to the windshield wiper motor, as well as to a green light inside the box.  I use a Power Switch Tail so that I don’t have to worry about any safety issues dealing with house current directly.  The motor sequence has several stops and stop in it, of differing lengths, so that the action is more natural.  After it triggers, there’s a dead time, so that it doesn’t keep restarting while trick-or-treaters are standing in front watching it.

Closed Monster in a box, showing the box with the PIR and Arduino that triggers the box.

Inside view of the Monster in a Box, showing the wiper motor and irregular cam.

 

The other prop where I use a PIR and an Arduino is my scarecrow skeletons, who do a little talking and singing routine when triggered.  Here, an Arduino controls two Cowlacious audio boards that in turn drive the servo boards that control the jaw servo and lights in the skulls (also from Cowlacious).  I’ve had the audio boards for some time.  They work fine, and have a wide host of control options (including the ability to be triggered directly from a PIR).  However if I was remaking this prop, I’d probably just wire up some really cheap mp3 players. The video shows the two skeletons doing their routine. Sorry for the quality, my video editor is refusing to save the edited version.