Filtering out Vibration while using a KOP Accelerometer
 

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)

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

The data sheet 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?

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

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.

What bandwidth would you suggest?

Re: Filtering out Vibration while using a KOP Accelerometer
 

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 :)

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

Re: Filtering out Vibration while using a KOP Accelerometer
 

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

Re: Filtering out Vibration while using a KOP Accelerometer
 

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.