View Full Version : Noisy Accelerometer
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
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
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
15-01-2009, 20:58
You can also turn up the oversampling in the analog input. I've used 8 bits of oversample with good results.
Felipe Sagui
15-01-2009, 20:59
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.
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?
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
15-01-2009, 21:06
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
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
15-01-2009, 21:17
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.
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
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.
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
16-01-2009, 07:35
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
16-01-2009, 07:49
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
16-01-2009, 07:58
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
16-01-2009, 08:27
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
16-01-2009, 08:32
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.
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
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
18-01-2009, 08:43
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
18-01-2009, 09:05
-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?
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).
What types of shielding would be used to shield the sensor? I know what we can use for the wires, but don't know what we'd use for the sensor.
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).
Yeah, we ran that test yesterday, one of the first things we did. In that configuration we still had the noise (which probably just reinforces the fact of noise going through the motor wires).
Is the LED on the analog breakout lit?
Yes, the LED in the analog breakout is lit.
Think we'll order another sensor or two, if this is the way we'd like to go.
Thanks
-Tanner
Daniel_H
19-01-2009, 12:27
I am using a smoothing filter and it's working well, just don't try integrating it to get the velocity. The noise, insignificant on acceleration readings, always ruins velocity for me.
Btw, has anyone obtained a good velocity reading using the accelerometer? through which method?
Russ Beavis
19-01-2009, 12:39
Tanner,
Can you upload some test data that shows the noise (with sample rate/timing info)?
I'd like to see how much noise you're encountering. Please provide both "static" noise (no motors running) and "dynamic" noise (with motors running).
Also, can you put a jumper on an open analog input and measure your 5V power supply at the same time? I'd like to see that noise AND your battery voltage as well. More data is good. Maybe there is a correlation between your observed noise and noise on either the battery or 5V supply.
Russ
any accelerometer is going to give you a good deal of noise. Try using one that supports I2C. There are ports for I2C right on the digital sidecar, and I have heard that the these accelerometers eliminate most of the noise by themselves.
A affordable method I've thought about is using the Wiimote's Nunchuck. It uses the I2C protocol to interface with the wiimote, it only costs $25, and the accelerometer inside it goes for $40 last time I checked.
There are a lot of resources on the internet geared specifically towards interfacing with the nunchuck.
I am using a smoothing filter and it's working well, just don't try integrating it to get the velocity. The noise, insignificant on acceleration readings, always ruins velocity for me.
Btw, has anyone obtained a good velocity reading using the accelerometer? through which method?
Daniel,
We've gotten velocity readings from our accelerometer.
We modified the Gyro class, and made the m_analog member public. That way we can use the accumulator support in the Gyro class for the Accelerometer instead.
We manually specified accumulator centers and deadbands.
We also tweaked the averaging and oversampling bits on the analog module.
We are still having some problems with precision, but the numbers as is are useable for some basic autonomous movements. Maybe even good enough to accumulate again to get displacement data... we'll see!
weinbergmath
01-02-2009, 15:33
Hi everyone,
I'm looking to do the same thing as you SlimBoJones, but in Labview. I have attached a VI with something that started as the 'Get Gyro Angle' vi, but made the changes I could see to the inputs to look at the accelerometer instead of the Gyro. I haven't tried it, as there is an error.
Two questions come out of this:
1. How can I modify the VI that changes the accelerometer DevRef global to the AI Channel cluster so that it works? At the moment, the error dialog says it's being referenced from outside the library, so it won't run. Is there another way to do this?
2. I don't understand the process of what the VI is doing with the accumulator to come up with the integrated value...is it enough to just feed it an accelerometer rate instead of angular rate, as well as the scaling and center voltage, and hope for the best?
Thanks for any and all responses...
Evan
We're seeing the same kind of jitter in the accelerometer from this years KoP. In all directions (x, y and z) we are getting odd values for an at rest bot. The nominal values are suppose to be 1.5V at rest. X is 1.84, Y is 1.76, Z is 1.74.
I tried resting the accelerometer on the ground, away from the bot and no change. I swapped the accelerometer with one from 2005, and while there's a little jitter it's in the +/- .002 range.
Now the new on is more sensitive (300 mV/G) and it's possible that we need to replace the bandwidth filter on the board, and isolate the board better but I'm leaning more toward that the board is broke.
EricVanWyk
02-02-2009, 11:23
We're seeing the same kind of jitter in the accelerometer from this years KoP. In all directions (x, y and z) we are getting odd values for an at rest bot. The nominal values are suppose to be 1.5V at rest. X is 1.84, Y is 1.76, Z is 1.74.
I tried resting the accelerometer on the ground, away from the bot and no change. I swapped the accelerometer with one from 2005, and while there's a little jitter it's in the +/- .002 range.
Now the new on is more sensitive (300 mV/G) and it's possible that we need to replace the bandwidth filter on the board, and isolate the board better but I'm leaning more toward that the board is broke.
Your post is very informative, and a refreshing break from "It don't work". Thank You.
At rest, you shouldn't be able to see those values if everything is working - it corresponds to about 2.5g acceleration towards a corner. Something is wonky.
Do you have an oscilloscope? It could make debugging easier.
Can you plot the values over time? You may be able to see noise.
I would hold the accelerometer in each of the 6 basic positions (Z up, Z down, Y up, Y down, X up, X down) and record the values given. This may give you better insight into what is wrong.
While our team is planning on using WindRiver, I hooked up the LabView Accelerometer VI to get the pretty pictures of what was going on with the sensor. It is a very jagged plot with a +/- 0.15 V, making it virtually useless. This test is being done on a bench test setup, the cRIO is on a piece of plywood, and the sensor is using a PWM cable that is long enough so that the sensor is resting on the floor. (and it a concrete floor in a manufacturing facility) We do have an oscilloscope and could test things.
I'm a mentor, and as such I'm at work at the moment so getting data will have to wait till this evening. For us, I suspect that we're going to use the older sensor because a) it works, b) only need x and y axis, and c) I doubt that were going to see 3G accelerations to warrant messing further with the newer device.
I just wanted to add some data to the discussion. I like the theory that it's just some noise artifact that could be corrected by either software or a hardware fix. But it seems to me that the board is bad.
EricVanWyk
02-02-2009, 12:27
I just wanted to add some data to the discussion. I like the theory that it's just some noise artifact that could be corrected by either software or a hardware fix. But it seems to me that the board is bad.
I haven't gotten any data on bad accelerometer or gyro boards yet (but that doesn't mean that there is none to be had). I'd be very interested in discovering what the failure mode is. If you are willing, we could chase it down when you get a chance.
Alan Anderson
02-02-2009, 13:26
The accelerometer chip itself might be broken due to mishandling. They're not particularly robust; dropping the board from table height can be enough to do permanent damage to the sensor.
Our team was having the exact same problem, so we had an ME come in to suggest a filter. He hooked it up to his personal oscilliscope, and the graph looked beautiful compared to the noisy Labview graph. I doubt that that the boards are all broken or that the manual was wrong, he suggested using a simple IR filter:
remsignal = 0.05*newsignal + .95*remsignal
This worked well for us and the noise was drastically reduced. You can use a formula node in Labview to do this and it is quite easy.
Note: I'm a system programmer, not an EE...just know enough to be dangerous.
I attached an oscilloscope to the accelerometer last night, and it showed a swing of +/- 200 mV at the beginning of the sample and then stabilizes. I'm not sure what to make of it. Maybe I need to change the sample rate.
I dislike the idea of putting something like this
remsignal = 0.05*newsignal + .95*remsignal
As the real acceleration would, I believe, be swamped out by the damping of the noise.
I'm the head programmer of team 701, and i have spend almost all hours for a week on the KOP '09 Accelerometer. Now after all the effort I am getting position from it, now accumulator, no DMA, no filtering, no averaging. A side from some drift, that i believe i can fix as soon as i find a better method for zeroing. IT WORKS
I'm the head programmer of team 701, and i have spend almost all hours for a week on the KOP '09 Accelerometer. Now after all the effort I am getting position from it, now accumulator, no DMA, no filtering, no averaging. A side from some drift, that i believe i can fix as soon as i find a better method for zeroing. IT WORKS
Do you think you could lend the rest of us a hand? I'd be interested in knowing what all you went through to get it working.
But, congrats! That's more than a lot of us can say right now about our accelerometers :-)
Just an update. Took the accelerometer into work, and had an EE take a look at it. Bottom line is that on the bench, it works just fine. So it's probably noise coming from the bot. Not exactly sure what to do to identify the source of the noise, but will try some things.
Just an update. Took the accelerometer into work, and had an EE take a look at it. Bottom line is that on the bench, it works just fine. So it's probably noise coming from the bot. Not exactly sure what to do to identify the source of the noise, but will try some things.
Someone else suggested taking this out of the equation and using a chip with a digital interface - I think they were right.
Here's a relatively good priced 3-axis accelerometer from Sparkfun:
http://www.sparkfun.com/commerce/product_info.php?products_id=8791
It has an I2C interface, and here's the best part - a 192 sample ring buffer. It can sample on its own at a fixed speed, and has a line you can connect to a digital I/O port to act as an interrupt when the buffer is 1/2 or 3/4 full. You then can read all the acceleration data, pre-filtered, into your own code and run integration and analysis. It even gives 11-bit data, and is temperature calibrated.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.