Noisy Accelerometer

[Tanner]

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

[jee7s]

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

[Tanner]

Originally Posted by jee7s

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

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

[EricVanWyk]

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

[Felipe Sagui]

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.

[Tanner]

Originally Posted by EricVanWyk

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

How exactly does one do this?

Originally Posted by Felipe Sagui

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.

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

[Russ Beavis]

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

[Tanner]

Originally Posted by Russ Beavis

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

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

[Felipe Sagui]

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.

[Tanner]

Originally Posted by Felipe Sagui

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.

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

[Acshi]

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.

[Tanner]

Originally Posted by Acshi

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.

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

[Jared Russell]

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.

[martin417]

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

[Al Skierkiewicz]

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.