Noisy Accelerometer

[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.

[EricVanWyk]

Originally Posted by Al Skierkiewicz

Lastly, have you insulated both the accelerometer and the CRIO? Sneak current through the robot frame will introduce noise as well.

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.

[Felipe Sagui]

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.

[Tanner]

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

[jee7s]

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

[Russ Beavis]

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

[EricVanWyk]

-5G is probably 0V. This means you are either not powering the module or are not receiving the signal back.

Is the LED on the analog breakout lit?