Accelerometer success?

[gvarndell]

Is anyone having success with the accelerometer?
It seems every thread I read about it people are having no luck getting useful data from it.
If your team is making good use of it, please share your success story?

[Bongle]

Originally Posted by gvarndell

Is anyone having success with the accelerometer?
It seems every thread I read about it people are having no luck getting useful data from it.
If your team is making good use of it, please share your success story?

We adjusted our WindRiver accelerometer class so that it implemented an averaging filter. It takes the last 20 samples and averages them. It delays its responsiveness somewhat, but it also removes much of the noise that the accelerometer displays.

We know that there is a GetAverageVoltage function, but it didn't seem to be doing any actual averaging, so we averaged GetVoltage instead.

[gvarndell]

Originally Posted by Bongle

We adjusted our WindRiver accelerometer class so that it implemented an averaging filter. It takes the last 20 samples and averages them. It delays its responsiveness somewhat, but it also removes much of the noise that the accelerometer displays.

We know that there is a GetAverageVoltage function, but it didn't seem to be doing any actual averaging, so we averaged GetVoltage instead.

How often are you sampling?
Are you able to translate your average acceleration to a reasonable approximation of current velocity?

[Bongle]

Originally Posted by gvarndell

How often are you sampling?
Are you able to translate your average acceleration to a reasonable approximation of current velocity?

I doubt we would be able to, the thing is still very noisy. We're sampling at about 100hz (the rate that our wheel-control PID loop is currently running). The spec sheet says that accelerometer runs up to 225hz, so we might bump it up later as a test.

The good news is that we don't want to get our velocity. We're comparing the accelerometer-reported acceleration with the acceleration reported from our encoders. If the encoders report an acceleration substantially higher than the chip, we know we've got wheelspin and should probably do something about it.

[EricVanWyk]

Originally Posted by Bongle

We adjusted our WindRiver accelerometer class so that it implemented an averaging filter. It takes the last 20 samples and averages them. It delays its responsiveness somewhat, but it also removes much of the noise that the accelerometer displays.

We know that there is a GetAverageVoltage function, but it didn't seem to be doing any actual averaging, so we averaged GetVoltage instead.

Don't forget to turn on the oversampling / averaging.

A good start for how many bits of oversampling you want is:

log2 { ( 500,000 Samples / Second from the 9201 ) / (8 channels) / (X Samples per second that the PPC wants to process )}

If your code executes 1000 times per second, 6 bits is about right.

If your code executes 50 times per second (with the Driver Station updates), 10 bits is about right.

[manderson5192]

What about a Fast Fourier Transform? Couldn't you theoretically FFT the signal, implement a low-pass filter, and then inverse FFT it into a (relatively at least) very clean signal?

I'm thinking of fiddling around with this idea, as I have some code laying around that does FFTs very efficiently. I'm still a little concerned about the processing power involved, but if I get this working then I will go ahead and post it up somewhere online.

On the simpler side, though, the moving average is nearly unbeatable. Our signals-processing mentor strongly encourages going after that idea before getting into steadily more complex ideas.

-Matt

[Jared Russell]

Why would you bother?

The Fourier transform is generally a more useful tool for designing filters rather than implementing them. There is no frequency domain filter that cannot be implemented in the time domain.

[MrForbes]

Originally Posted by Bongle

We're comparing the accelerometer-reported acceleration with the acceleration reported from our encoders. If the encoders report an acceleration substantially higher than the chip, we know we've got wheelspin and should probably do something about it.

I was thinking about this, and realized that it's probably unnecessary...if the encoders report an acceleration substantially higher than the robot can accelerate (which is a pretty low number, at the rate the encoders report things happening) then you have wheel spin.

[manderson5192]

Originally Posted by Abwehr

Why would you bother?

The Fourier transform is generally a more useful tool for designing filters rather than implementing them. There is no frequency domain filter that cannot be implemented in the time domain.

I think I remember reading a little about how to design time-domain filters based on a Fourier Transform, but I couldn't glean much from the website's brief description.

I'm assuming that taking a Fourier Transform of the signal could reveal the frequencies of the high-frequency signals of vibrations and electronic noise. Using this information, one could then design a time-domain filter to extract the "real" acceleration signal. If this assumption is wrong, would you so enlighten me .

Also, I would like to know what the name of such a time-domain filter would be. I'd like to do some research on it...

Thanks!
-Matt

[EricVanWyk]

Originally Posted by manderson5192

...

Matt -

It sounds like you have a strong enough background to start looking into time domain filters. Please look into FIR and IIR filters - they are much cheaper to compute and can do everything you were asking about. Please share your results.

I've done the "FFT -> throw away stuff I don't want -> IFFT" method before. It is waaaaay too draconian, and has really nasty artifacts. I'm not saying it is impossible, but it can have some really wonky side effects.

[Bongle]

Originally Posted by squirrel

I was thinking about this, and realized that it's probably unnecessary...if the encoders report an acceleration substantially higher than the robot can accelerate (which is a pretty low number, at the rate the encoders report things happening) then you have wheel spin.

There are a couple reasons I like the dynamic approach:
1. It covers more cases. Our robot could get involved in a pushing match and have the TCS still work (in theory)
2. It covers the case where the trailer starts filling up, and the ratio of the robot-trailer system's mass tilts more towards the trailer
3. It works as the field and wheels degrade and their CoFs increase or decrease
4. It works on the carpet.

The static approach will our fall-back if we can't get the dynamic setup working properly.

[MrForbes]

I don't see any cases there that would not be handled by the static approach...the robot mass is pretty large compared to the inertia of the wheels, even in a situation where you get bumped by another robot, or drive on the carpet, or the load on the robot changes. In a pushing match you'll be accelerating much less than when you're out in the open.

(really, I'm not trying to dissuade you from making the accelerometer work, I just think that it's not necessary for TCS)

[Bongle]

Originally Posted by squirrel

I don't see any cases there that would not be handled by the static approach...the robot mass is pretty large compared to the inertia of the wheels, even in a situation where you get bumped by another robot, or drive on the carpet, or the load on the robot changes. In a pushing match you'll be accelerating much less than when you're out in the open.

(really, I'm not trying to dissuade you from making the accelerometer work, I just think that it's not necessary for TCS)

One big issue is your on-carpet acceleration: On a carpet, your robot's potential acceleration will be higher than on regolith. So if you artificially cap wheel acceleration to your on-regolith acceleration, you're hurting your peak performance.

Another issue is your ability to push trailers or pull a loaded-up trailer: Your in-code maximum acceleration will be higher than what your robot can physically achieve, and so your wheels will be able to speed up and start spinning despite the code being there.

However, these arguments from me are mostly based on our system's theoretical performance. It may turn out to be not reliable enough for a full-time implementation, at which point a static setup makes sense.

[Jared Russell]

Originally Posted by manderson5192

I think I remember reading a little about how to design time-domain filters based on a Fourier Transform, but I couldn't glean much from the website's brief description.

I'm assuming that taking a Fourier Transform of the signal could reveal the frequencies of the high-frequency signals of vibrations and electronic noise. Using this information, one could then design a time-domain filter to extract the "real" acceleration signal. If this assumption is wrong, would you so enlighten me .

Also, I would like to know what the name of such a time-domain filter would be. I'd like to do some research on it...

Thanks!
-Matt

Matt -

Do you have access to MATLAB? There is a nice digital filter design tool that you can use to accomplish the goals you are putting forward.

To design a filter, there are generally a few steps that you will want to follow. Basically, you capture some representative sample data, take its FFT, and examine its Bode plot. From this you should be able to surmise what frequencies are useful, and what are noise. You can then pick a "cutoff frequency" above which your filter will reject the signal as noise (for a low-pass filter, which is what you want here). Finally, you pick your filter type and size (number of poles) and you can compute all of the necessary coefficients from the selections you've made. Voila!

So from the above you will see you need three things to design a (low-pass) filter:

1. A characterization of the noise (Which is what the FFT can help you with)
2. A filter architecture
3. A filter size

For #2, there are hundreds of well-known filters out there. All linear filters are either FIR (finite impulse response) or IIR (infinite impulse response). A moving average is an FIR filter, since there is no feedback from prior filter outputs into the next filter output. A filter like "x_filtered = 0.1*x + 0.9*x_filtered" would be IIR, since there is feedback from the last value of "x_filtered" to the next. Generally, FIR filters are easiest to implement and are always stable. IIR filters can achieve better noise rejection performance, but you have to worry about stability and other tradeoffs.

Once you have your filter type, it's time to address #3. Clearly, a moving average of the last 100 readings will reject higher frequency noise than a moving average of the last 3 (since in the 100 "tap" case, a single spike would only be 1/100th of the output, whereas in the 3 tap case, a single spike would be 1/3rd of the output). This applies to all types of linear filters. Unfortunately, with increased smoothing comes increased phase (time) delay. To go back to our moving average example, if the input stepped from 0 to 1 at time T, it would take 50 readings before our 100 tap moving average registered even half of the change.

I hope this helps (and isn't too confusing). For more information, Wikipedia has some great filtering articles. Try:

http://en.wikipedia.org/wiki/Digital_filter
http://en.wikipedia.org/wiki/Low_pass_filter
http://en.wikipedia.org/wiki/Filter_design

For particular types of filters that tend to work well in practice, try:

http://en.wikipedia.org/wiki/Chebyshev_filter
http://en.wikipedia.org/wiki/Butterworth_filter
http://en.wikipedia.org/wiki/Elliptic_filter

Good luck!

[Jared Russell]

Originally Posted by Bongle

One big issue is your on-carpet acceleration: On a carpet, your robot's potential acceleration will be higher than on regolith. So if you artificially cap wheel acceleration to your on-regolith acceleration, you're hurting your peak performance.

Another issue is your ability to push trailers or pull a loaded-up trailer: Your in-code maximum acceleration will be higher than what your robot can physically achieve, and so your wheels will be able to speed up and start spinning despite the code being there.

However, these arguments from me are mostly based on our system's theoretical performance. It may turn out to be not reliable enough for a full-time implementation, at which point a static setup makes sense.

Well put.

In short, static acceleration limiting will prevent slip as long as (1) no external forces are manifest and (2) you know your CoF with high confidence. Once these assumptions are broken, however, you can lose traction and - with the static approach - you will have no automatic way to detect that this has occurred and, by extension, will have no automatic way to regain traction.