Filtering out Vibration while using a KOP Accelerometer [Archive]

View Full Version : Filtering out Vibration while using a KOP Accelerometer

joshyboy9987

13-01-2008, 19:07

So, this year, as the only programmer with experience, I figured I'd work on using an accelerometer to calculate distance for the autonomous mode. The Calculus behind this isn't hard, and the programming isn't either (in theory).

When I wrote the program, it compiled fine and the accelerometer seemed to give us pretty accurate data. We mounted the RC onto a cart and started walking with it through the halls, while using HyperTerm to take some data. We then took this data and plopped it into an excel graph, and to our surprise, got some messed up data! The accelerometer (both x and y) seemed to be super sensitive to shocks & vibrations. This was before the double integration too! We tried mounting the accelerometer in a piece of foam to help the shocks a bit, and that worked, but it didn't work well enough. We still can't get good data. I thought about doing a rolling average type of thing, but it seems that the data is averaged around 0 milliG's (512 on an analog input).

So does anyone have any ideas on how to make the data better? I want to use an accelerometer, because it gives the robots position based only on acceleration, rather than basing it on wheels, or other, more unreliable things...

(The loop is short enough to get a enough data points, and I did the integration right)

Alan Anderson

13-01-2008, 19:37

As you've found, what you want to do is not easy. The KOP accelerometers do a great job of detecting vibrations. Maybe you could mechanically filter the shocks by mounting the accelerometer to a heavy chunk of metal, which is then connected by foam or springs to the robot chassis. But I haven't heard of any teams successfully using only the accelerometer to do position tracking.

jleibs

13-01-2008, 19:52

First of all, there's the obvious "search for accelerometer" and read a bunch of other threads. I'll let someone with more FIRST experience than I point you to the ones that are actually useful.

Second, make sure you are using timer interrupts, so that the change in time between measurements is reliable. (Once more, someone else can provide better advice than I as to how to make this happen).

Mounting the accelerometer in a piece of foam is a pretty good idea as a form of a mechanical low-pass filter.

I believe, there are some tricks that can be done with a capacitor to act as an electrical low-pass filter.

If that's not enough, you're going to have to add a software low-pass filter as well. An average of the past N samples is a suboptimal version of this, but at least a decent place to start. However, the problem with a software lowpass filter is that it can only operate at your processor frequency and I suspect the noise you are trying to filter out is at a higher frequency than your processor is running.

Out of curiosity could you post a plot showing one of the shocks that you believe to be throwing off your data?

Could anyone tell me a little bit more about the actual physical mechanism of the KOP accelerometers? Are these returning a continuous voltage that is proportional to acceleration, or are they clocked at some particular frequency?

Most accelerometers I have worked with return a digital delta-v, which is the integration of the acceleration over the time-step of their frequency of operation. This is clearly preferable to returning an instantaneous sample of acceleration. I'm a software guy and not an EE, so I don't tend to ask what's going on under the hood in so far as the amount of processing the accelerometer is actually doing.

In any case, believe it or not, basing your navigation on wheels tends to be a lot more robust than accelerometers. Though, in an ideal world, you would combine the two of them. I expect most teams have had pretty decent success combining encoder-based wheel odometry with using gyros to estimate rotation changes.

jleibs

13-01-2008, 20:18

Ok... curiosity inspired me to do a little more digging...

The data sheet (http://www.analog.com/UploadedFiles/Data_Sheets/ADXL204.pdf) seemed like a good place to start.

The user selects the bandwidth of the accelerometer using Capacitor CX and Capacitor CY at the XOUT and YOUT pins. Bandwidths of 0.5 Hz to 2.5 kHz can be selected to suit the application.

My suspicions of the usefulness of a capacitor were further confirmed by their explicit instructions to use one. What capacitor size have you chosen and what bandwidth are you trying to achieve?

joshyboy9987

13-01-2008, 20:27

jleibs

13-01-2008, 20:56

Thanks for the advice. What do you guys think about taking the derivative of the acceleration and if it's too high just throwing the data over again. (I guess that's kind of a filter too, in a way)
I don't use a timer-based interrupt as I first planned, but am instead using the timer function in easy C to measure the time difference between calls... The timer is then reset to 0 to start the next time period.

I'll post our data a little later, I don't have it on my computer, it's on the robotics

I've read the spec sheet, but if I end up using a filter as they suggest, won't it take out things like the robot crashing into the wall and stuff like that. That would change the acceleration really fast. I mean, I can't assume I'm not going to hit anything in autonomous (hybrid) mode.

Throwing out accelerations that have changed too much from the previous measurement is indeed a form of filter. I think this would generally be referred to as statistical filtering. The statistics govern how you define "too high", etc. There are some questions raised here though of what you use in place of this data, etc.

Since you are not forcing the time via a timer interrupt (which I suspect it is recommended that you figure out how to do), do you have an idea of what frequency your code is actually polling the accelerometer?

As far as filtering out things like robot crashes, there is always a trade off. However, there is a fundamental difference between what the accelerometer does in the presence of noise, and what it does when you hit a wall.

When you have the kind of shock noise you're seeing there should be a positive acceleration followed by a negative acceleration. Your robot, has, after all not actually changed its velocity. The problem is that I believe this is happening faster than the sampling time of your robot, and you are only catching one half of it since you can't sample that fast.

If your robot hits a wall, it ACTUALLY decelerates. There is a deceleration, and there is not an immediately following positive acceleration that would zero it out.

The capacitor is supposed to be chosen based on the frequency at which you are polling the accelerometer. It smooths things out such that they are at a rate you can sample them.

Now, when you smooth out a positive acceleration immediately followed by a negative acceleration, you get something close to 0.

However, when you smooth out just a negative acceleration by itself, you simply get a smaller negative acceleration. The fact that the acceleration is smaller reflects the fact that your sample time is longer and the fact that your total change in velocity is the same.

This SOUNDS right to me... but I havn't dealt with circuits at this level in a while. Someone with more experience at this level please correct me if I'm wrong :)

joshyboy9987

13-01-2008, 22:08

Yeah, I think everything you've said sounds right... I have a timer in Easy C that gives me the time every time I use GetTime so I use that to determine the time between polls. (You can't integrate w/o time!). I think we are polling it fast enough too, because we see both the positive and negative amplitudes when we graph our data. I was talking with one of our mentors and he said that I should use a lowpass filter on the signal (with a capacitor) and then take that and sample it as fast as possible. I guess the frequency of the sample should be 5-20 times what the filter bandwith is...

I'll see how it works tomorrow and let you know.. Thanks for the help. I'll see if I can post some graphs too...

Chris Hibner

13-01-2008, 22:19

I've done a lot of navigation systems for FIRST robots. I would highly recommend NOT using accelerometers for determinings distances. Double integrations are thrown off easily by small offset shifts (which are inevitable). We always used a non-driven wheel with an encoder located as close to the center of the robot as possible. We always had good results with that.

joshyboy9987

13-01-2008, 22:25

Hmmm... The design team is gonna have a fit if I tell them to put an extra wheel on the robot, maybe I'll just make 'em deal with it.

But if I was to use an accelerometer, any ideas on how to make it work? The spec sheet says to use filters, so I guess I'll try that, but otherwise I might have to add some extra hardware..

TubaMorg

13-01-2008, 22:53

Ok... curiosity inspired me to do a little more digging...

The data sheet (http://www.analog.com/UploadedFiles/Data_Sheets/ADXL204.pdf) seemed like a good place to start.

My suspicions of the usefulness of a capacitor were further confirmed by their explicit instructions to use one. What capacitor size have you chosen and what bandwidth are you trying to achieve?

I believe the accelerometers in the FIRST KoP come built into a board, which includes the recommended components. I don't know the size, though. All of the included sensors are assembled onto boards for FIRST.

comphappy

13-01-2008, 23:18

joshyboy9987

13-01-2008, 23:27

Yeah, we thought about just putting another micro on the robot so that it could handle the sensors and just output values to the RC to save some processor time, but there's not too much going on during hybrid mode...

You think they'd care if I just added two capacitors! I hope not, because you're right, the accelerometer comes with filters on board, but the signal needs to be filtered further.. (Data to follow...)

joshyboy9987

13-01-2008, 23:37

Ok, here's the data... ax, ay are the accelerations after Easy C's getacceleration function. anx and any are the analog input values for x and y...

dx and dy are the distance traveled in the x and y directions. (They aren't right, which is the problem!) Every data point is about 25 ms apart. (I'm not positive about that one, but it's close to that...

It's in an excel workbook that's in a .zip file..

ay2b

14-01-2008, 00:55

My impression from the FIRST rules is that I can not make my own electronics, unless it is on the OI, correct me if I am wrong, because i will just create an integrator circuit, and off load it all from the RC.

Yes, you are wrong. You are allowed to have additional electronics on the robot. However, they are only allowed to connect to the RC's I/O ports (and to power) -- you cannot connect additional electronics to the spikes or victors.

See sections 8.3.6 & 8.3.8, especially <R53>, <R68> and <R81> through <R84>.

jleibs

14-01-2008, 01:02

TubaMorg, I can't verify for sure whether there are already capacitors in place as I don't have a KOP. The data sheet made it sound like the user choses the capacitor, so I figured it would have to be added by the user after the fact. But, if FIRST has mounted it on another board already, I guess there's a chance they did this for you. It would be nice if someone could verify this for sure (and what size capacitors FIRST decided to use).

With regards to an extra wheel for odometry. While adding an extra wheel can be useful things can definitely work by monitoring actual drive shafts. Your team probably just needs to add an encoder and not a whole extra wheel if most of your design is already being implemented.

I don't know about the legality adding your own custom circuits... I'd like to hear someone else chime in on where that falls within the rules.

I'll take a peek at the data when I get a chance.

comphappy

14-01-2008, 01:18

ay2b

14-01-2008, 01:36

Your calculations look very wrong, i would check them first.

<R68> is what i was referring to, the beginning makes it sound like they are not allowed, because they are not COTS. But if all of the components are COTS and you put them on the PCB is that OK?

Let's look at R68:

Additional electronic components for use on the ROBOT must be either COTS items or assembled from COTS items. Additional electronic components include any object that intentionally conducts electricity, other than Innovation First Inc. relays and speed controllers, wires, connectors, solder, and fabricated printed circuit boards.

So as long as your custom electronics is either COTS (such as an encoder) or assembled from COTS items, it's allowed. A separate PIC, resistors, capacitors, PCBs, etc, are all examples of COTS items which can be assembled to your own circuit.

jleibs

14-01-2008, 01:41

As for data. I guess one question I have is: what motion (if any) was occuring while this data was recorded.

The next question is how to interpret your accelerometer values, which are in the range of 475 to 569 or so. How does this relate to millivolts coming out of the accelerometer? Sorry, I havn't played with the controller in a while... and when I did, back in 2002... well... everything was different :)

Anyways, according to the Sensor Manual (http://www.usfirst.org/uploadedFiles/Community/FRC/FRC_Documents_and_Updates/2008_Assets/Manual/2008_Sensor_Manual.pdf), it would appear that horizontal orientation under no acceleration should be outputting 2.5 volts.

According to the Data Sheet (http://www.analog.com/UploadedFiles/Data_Sheets/ADXL204.pdf), it would appear that the 0g corresponds to 1.65V given a 3.3V input. I think first is driving it with a 5V input. So a 0g output of half of Vs seems to be self consistent here.

So the first thing we want to verify: is the meaning of your numbers there somehow consistent with the ~2.5V +/- 1.7V that we expect to see from the output of the device?

comphappy

14-01-2008, 01:45

Let's look at R68:

So as long as your custom electronics is either COTS (such as an encoder) or assembled from COTS items, it's allowed. A separate PIC, resistors, capacitors, PCBs, etc, are all examples of COTS items which can be assembled to your own circuit.

my concern stems from the fact that I cannot come up with something that would be in violation of this rule if it is not a drive circuit which are explicitly prohibited. So if I fully design my own integrator and PCB, then I am ok?

Alan Anderson

14-01-2008, 08:05

The next question is how to interpret your accelerometer values, which are in the range of 475 to 569 or so. How does this relate to millivolts coming out of the accelerometer?...So the first thing we want to verify: is the meaning of your numbers there somehow consistent with the ~2.5V +/- 1.7V that we expect to see from the output of the device?

The RC's analog inputs have ten bits of precision. That gives results from 0-1023 for a voltage from 0-5 volts. A value of 475 translates to about 2.32 volts, and 569 represents about 2.78 volts.

Tom Bottiglieri

14-01-2008, 08:12

Qbranch

14-01-2008, 08:22

won't it take out things like the robot crashing into the wall and stuff like that. That would change the acceleration really fast. I mean, I can't assume I'm not going to hit anything in autonomous (hybrid) mode.

Hey, that's a safety feature we're having in hybrid mode! We're using one of the programmable comparators to detect (and generate and interrupt) if we get a G-spike indicating a crash (a lot like a car with airbags) and in the event of a crash will kill all the motors to protect the robot. Now if we can just get it to call OnStar... :D

-q

Qbranch

14-01-2008, 08:24

Hmmm... The design team is gonna have a fit if I tell them to put an extra wheel on the robot, maybe I'll just make 'em deal with it.

uhhhhh..... just put an encoder on one of the wheels you already have? I realize this can slip, but its probably a better probability of it working than an accelerometer with error squaring... eh... i mean double integration. :rolleyes:

-q

jleibs

14-01-2008, 11:34

Try a Kalman filter. There is source code to some optimized versions floating around on the internet. (The full filter is a bit labor intensive.) This filter was designed to read noisy signals and make estimates of true value based on it.

http://en.wikipedia.org/wiki/Kalman_filter

First of all, Kalman Filters are great :)

Second of all, the rest of this post will likely sound like non-sense unless you've read a couple articles in Kalman Filters. If you think you're interested in Kalman Filtering, this (http://www.cs.unc.edu/~welch/kalman/) is a good place to start.

Now onto what I was going to say: I've never had a Kalman treat the accelerometers as direct measurements in a nav system before. There are a couple reasons for this. Keep in mind, I use a full 6DOF system where all of this is more complicated. For one, it requires running the Kalman faster than we want to (at the full 400Hz IMU rate). Additionally, doing so requires the linearization of a fairly gnarly prediction function (since the prediction function is doing an implicit double-integration).

Finally, and I think this is the most important one: if your state vector includes acceleration and you are Kalman filtering your acceleration. You need a MODEL of how you expect your acceleration to change from one time-sample to the next. It's comparing this prediction to what you actually measure that allows a Kalman to function well. You have no means of acquiring such a prediction, especially when you want to measure things like crashes and bumps (outside the scope of your controlled values). So basically, to tune your Kalman to reflect the unpredictable nature of your accelerations, the process noise will have to be high enough that very little smoothing will actually happen.

What we tend to do is leave acceleration out of our state vector. We track position, orientation, and velocity inside the Kalman. We then integrate the accels/gyros using the inertial nav equations essentially as part of the prediction phase, and use this to update our predicted position/orientation/velocity values. Then, we use the Kalman measurement update to incorporate additional sensors such as GPS/IMU and correct these terms.

Calibrating and working out bugs in this kind of system is the kind of nightmare that can take an experienced engineer months (or years) to get right. At work, the Kalman Filter we use for our nav system has a state vector with 150 elements in it. Needless to say, it is still being debugged.

But you guys are working in 3DOF and I expect the problem is likely more tractable in that case. Maybe I'll review the equations when I get a chance this afternoon.

Where a Kalman would really shine is fusing measurements from your accelerometers with measurements from your shaft encoder or other sensors.

Anyone, please feel free to contact me if you would like to discuss Kalman filtering in more details.

comphappy

14-01-2008, 23:20

Some people might find this article of interest.
http://www.freescale.com/files/sensors/doc/app_note/AN3397.pdf

jleibs

14-01-2008, 23:36

Some people might find this article of interest.
http://www.freescale.com/files/sensors/doc/app_note/AN3397.pdf

Definitely a great starting point for anyone looking at doing this. Thanks for the great find, comphappy!

joshyboy9987

17-01-2008, 23:15

Yeah, my calculations were off a bit... I forgot to keep track of the stupid velocity constant when I did the first integration... Now the data is better, but still bad... I think we might go with the encoders... We even shock mounted the accelerometer, and that didn't help all that much. (Magnetic shock)

comphappy

17-01-2008, 23:17

you may consider low pass filtering out the freq range from the motors and/or compressor.

gnormhurst

18-01-2008, 07:42

I looked at the data in the spreadsheet. I plotted the dx values and the dy values (I assume these were the result of double integration and represented position). Each seems to have a recognizable trend. If this roughly corresponds to the movements you were applying to the robot (you didn't say), I'd be encouraged that the data could be useful. Sure, it's a little fuzzy. The trick is to filter out the fuzzyness without delaying the data so much that it's no longer useful.

If you need instantaneous location to within an inch, it's probably not going to be useable. But if you just need to know if you are probably past the wall and should turn left, it might work.

windell747

21-01-2008, 02:55

Hi, I'm currently trying to decide between using wheel odometry and a double integration of accelerometer data. So this is a very interesting conversation!

One thing that I've failed to see is any mention of the gyroscope data used in conjunction with the accelerometer data. I see this as important because the robot's frame of reference translates and rotates with respect to the absolute coordinate frame of the field. Pretty much what I am saying is that the x and y coordinates of the accelerometer won't always remain parallel to the x y axes of the field therefore the orientation of the robot must also be monitored. Has anyone considered this as a probably source of error? I might've missed something, but there is my two cents!

windell
#2477

jleibs

22-01-2008, 01:16

I believe this has been discussed in other threads, but if not, here's a short answer.

Yes, rotation has to be considered as well. However, gyro's are in general much, much more accurate that accelerometers.

Among the reasons is the fact that gyro gives you change in angle so only a single integration is necessary as compared to the double integration of accelerometers. Also, in general, vibrations and other forms of noise will cause small accelerations more so than they will cause torques and rotations. In the 3D case you also have to worry about subtracting out the gravity vector (gravity is identical to an acceleration), whereas the earth's rotation can more justifiably be ignored.

I'm sure the physical mechanism plays a role in the difference of reliability as well, but I don't know off the top of my head what the exact mechanisms are.

So yes, this is a source of error. If you're using accelerometers though, they will almost surely dominate your error.

As for wheel odometry vs. accelerometers, I would strongly suggest wheel odometry. Once more, in wheel odometry (like a gyro), you only have a single integration, which bounds the error growth more reasonably. It is again largely an issue of single vs. double integration.

However, even with wheel odometry, gyro is still going to be very useful in keeping track of your orientation since most forms of rotation involve wheel-slip, making an odometry-based rotation estimate hard to do accurately.

Kingofl337

22-01-2008, 08:20

You may want to try the gear tooth sensors that came in the kit. You mount them in your gear box, then you can sense FWD/REV direction with accelerometer and pwm outputs to the motor.