Noisy Accelerometer

Technical Programming
1

Hello,

We’ve wired up the 2009 KOP accelerometer and coded up a graph displaying the acceleration to make sure everything works and to get a idea of what goes on when (note: X-Axis only). However, our accelerometer appears to be quite noisy, when the robot is accelerating (X-Axis pointing direction of forward robot motion), the acceleration returned “noisily” goes up and down (including both positive and negative ranges). Though, when the robot is still, or we turn the accelerometer to face gravity or look away, it works fine, going smoothly with the correct values.

So, do we have a broken/odd accelerometer or a really, really bumpy drivetrain?

Thanks
-Tanner

2

You may have neither.

If there is a lot of vibration, you could expect there to be added interference (it isn’t strictly speaking noise) from the vibrations. You can limit this by isolating the chip using some foam.

You will certainly have noise, simply because you have a wire in the open. The source of that noise could be from your environment, or it could be from your motors if you have mounted it on the robot. Again, the interference from the motor PWM signal isn’t strictly noise, but it will look like noise. To isolate this, you can use a shielded cable, like coax.

Another potentially more likely problem is that your sample rate is improper. If you are sampling too slowly without band limiting (filtering) the input signal, you’ll run into a phenomenon called aliasing. So, make sure your sample rate is set to match the rate that you are actually gathering data. There is an analog filter on the board, but you may want to build one of your own. The cutoff of that filter will go a long way to determining your sample rate.

-Jeff Erickson, FRC 41

3

I don’t believe there could be too much vibrations, as we’re using a old drivetrain with the new wheels on it. Then again, a block of foam won’t do anyone harm…

Could be wire “noise”. We wired the accelerometer using a normal PWM cable and mounted it to the robot using velcro. Motors are near the rear of the robot, so I don’t believe much EM noise would make it that far as the sensor is on the front end.

Not exactly sure how to change the sample rate in LabView.

This may be the first year we’ll be using a accelerometer, that is if we can figure out how to get rid of this “noise”. We’ve never played with one before.

Thanks
-Tanner

4

You can also turn up the oversampling in the analog input. I’ve used 8 bits of oversample with good results.

5

A solution to eliminate this “noise”…you can create a range on programming based on the vibrations signals received when the robot is stopped. with this range you can determine if the software will calculate something or not.

6

How exactly does one do this?

Sounds like a good theory, but the signal is flat/normal when the robot is still and only really begins when the robot begins moving. We’ve thought about averaging the signal, but dismissed it due to the large range of values.

Thanks
-Tanner

7

This may be a bit of a stretch but when you’re using graphs in LabVIEW, look out for autoscaling of axes. Is it possible that you’re not really seeing noise but are instead observing a change in the acceleration axis’ scale?

In LabVIEW, if you right-click on a graph’s axis, you can change a number of parameters such as autoscaling and linear/log scaling.

Just a thought.

Has another else observed noisy accelerometer readings while driving motors?

Another test to run - put your robot on a stand so that it’s not moving at all and observe the accelerometer readings with the motors off and motors running. Is there a difference even though the robot is on a stand? If so, you’re probably coupling some motor current noise into your accelerometer reading (or into the power supply for the accelerometer).

Russ

8

We had the graphs at autoscale, but realized how stupid that was for differentiating between really tiny noise and actual values. They now are at a range at like -5 to 5 or -20 to 20. I can’t remember.

The immobile robot motor test sounds like a good test. We’ll have to try that on Saturday to see if the motors actually affect the sensor.

Thanks
-Tanner

9

Another solution to solve it…you can filter the signal using an empiric constant, this constant will multiply the accelerometer value and it result an a “filtered signal” without vibrations or with less “noise” than the direct value from the sensor. Based on this new signal you can do more reliable calcs.

10

Quick Google search on “empiric constant” shows me its something a bit over my head. Not exactly sure how to go from there… Can’t find any results here on this constant either.

-Tanner

11

Try integrating the accelerations to find velocity, and use that instead. Remember that acceleration is the change in velocity, so if your robot is at an almost constant speed, you should expect values to be hovering around 0 acceleration, some above, some below.

Haven’t set this up with my team’s bot yet though, but the velocity should be make more sense than straight acceleration values.

12

We worked on integrating the accleration to get the velocity, but my calculus help had some hard time explaining it to us and “converting” it to LabView. We got something, but it definitely isn’t a velocity…

-Tanner

13

You can try a simple low pass filter. I think LabView has VIs for these built in.

A simple one-pole IIR low pass filter in pseudocode could be:


double acceleration_filtered = 0.0;
double gain = (constant on the range 0 to 1);
while( robot_is_on )
{
  double acceleration = read_accelerometer();
  acceleration_filtered = (gain)*acceleration + (1.0 - gain)*acceleration_filtered;
  // Do stuff with our filtered acceleration value...
}

Setting gain to a small value will smooth your reading significantly. Setting it to a higher number will smooth less.

14

I assume you are driving the bot with kit motors? DC motors are very noisy, and can cause interference. Put a 1 microfarad disk capacitor across the motor leads, as close to the motor as possible. It may or may not help, but it definitely won’t hurt.

Martin

15

According to the schematic doc on the First website there are three capacitors (C4-C6) on the board that limit the bandwidth to below 200 Hz. On the off chance that one got by without these inserted, have you checked the board to be sure they are in place?
Noise can easily be generated by loose electrical connections. Be sure all your connections are tight at PD, in and out of the speed controllers and any other electrical connectors you are using. Look also at the path your signal wiring is following. Does it pass by the wireless access, a sidecar or around the CRIO? A simple move to a different path may be all you need.
Lastly, have you insulated both the accelerometer and the CRIO? Sneak current through the robot frame will introduce noise as well.

16

Good Call, Al. It is good practice to check for chassis faults when this sort of thing happens.

LabVIEW has filters in its Signal Processing pallette, I’ll try to write a blurb about them when I get time.

17

If you read the accelerometer datasheet, the output signal can have a noise according with the internal frequency…or the noise from power supply

it’s on page 7 on datasheet.

For most applications, a single 0.1 μF capacitor, CDC, placed
close to the ADXL335 supply pins adequately decouples the
accelerometer from noise on the power supply. However, in
applications where noise is present at the 50 kHz internal clock
frequency (or any harmonic thereof), additional care in power
supply bypassing is required as this noise can cause errors in
acceleration measurement. If additional decoupling is needed,
a 100 Ω (or smaller) resistor or ferrite bead can be inserted in
the supply line. Additionally, a larger bulk bypass capacitor
(1 μF or greater) can be added in parallel to CDC. Ensure that
the connection from the ADXL335 ground to the power supply
ground is low impedance because noise transmitted through
ground has a similar effect as noise transmitted through VS.

18

Quick update on our situation.

Today we accomplished many tests. Got assistance from another team who aided us in debugging our situation. There is not a current going through the robot. The “noisy-ness” still occurs whether we push the robot (without power) or drive the robot (with power). However, the noise does not occur when we “swing” the robot with our humans. We also let the robot sit in free-space and in a anti-static bags and it did not fix it. We tried a foam attachment to cancel out vibrations, not much help there. So we have found nothing to filter out this “noise”, and we believe to have “broken” our accelerometer, as it returns nothing now but -5 G’s (which apparently FIRST won’t be selling).

So… we’re out of ideas…

-Tanner

19

If you are getting noise when the wheels are turning (by pushing or battery) but not getting it when the wheels are not turning, then it is most likely noise from your motor power lines. When you push the bot, the motors generate electricity because a DC motor is both a motor and a generator (depending on how you use it).

To reduce this problem, it would be best to locate the sensor near the controller to minimize the wire length. Also, avoid putting any major power supply line near the sensor. Consider shielding the sensor and the signal lines as well (an antistatic bag with an open end is not a quality shield).

If you need a replacement, there are many retailers who sell accelerometers. Sparkfun.com is a good supplier at a reasonable cost. However, this would count against your non-KoP spending limit.

-Jeff Erickson, FRC 41

20

It doesn’t sound as if you’ve run the “up on blocks” test that I recommended - lift the robot off the ground and electrically spin the wheels. In this configuration, you should read zero acceleration (with the exception of gravity and any vibrations that couple the motors to the accelerometer).

Reading -5G is obviously an indication that something is broken. You’ll need to either fix that problem (broken PWM cable?) or replace it before doing anything else.

Russ