Any sucess using a accelerometer to measure distance

[dwodrich]

I understand they noise and will drift over time. We would like to just use one for measuring short distances in auto mode. So we are fine with reseting the accumulators and measuring 3 feet.

What we are having trouble with is getting any usable infromation out of the device. We have tried sampling the readings at the start and applying the average to get the reading "centered". But event then we seem to get alot of drift.

We have been struggling with this for some time. We are currently using the I2C and this years accelerometer, but are now thinking we may need to got with one of the analog ones to more effectivly filter the signal.

I have search high and low for soem example code and have not found much, any ideas of samples from this group?

[Doug Norman]

In general I'd take a look at the examples - there are several for accelerometers. But if I were measuring distance, I'm not sure I'd pick an accelerometer. Once you get good acceleration readings, you would then have to integrate once over time to get velocity, and then integrate velocity over time to get distance. That works great in physics class, but is a bit tricky in the real world. Have you considered using an encoder for measuring distance?

Early on we did some testing with accelerometers - it was difficult to simply measure velocity, let alone distance.

[dwodrich]

Originally Posted by Doug Norman

In general I'd take a look at the examples - there are several for accelerometers. But if I were measuring distance, I'm not sure I'd pick an accelerometer. Once you get good acceleration readings, you would then have to integrate once over time to get velocity, and then integrate velocity over time to get distance. That works great in physics class, but is a bit tricky in the real world. Have you considered using an encoder for measuring distance?

Early on we did some testing with accelerometers - it was difficult to simply measure velocity, let alone distance.

Yes, considered encoders, but with mecanums and traveling any direction, I'm not sure they would be very accurate ether. The any direction part makes an idler hard and the mecanum slip make encoders on the transmission hard.

[Kennersoft]

If you only want your robot's forward velocity, mount your accelerometer with the sensitive axis pointing forward, then you can do an average of a number of them to give you average acceleration over a time, then integrate based on that. For 15 seconds of autonomous, it should be stable enough.

We're using the kit 3-axis accel over I2C and set that up to measure at 200Hz (200 samples/sec), which we then accumulate 10 samples to integrate. The output is velocity at 20Hz. I added a little "distance traveled" item for our autonomous that integrates this 20Hz velocity to distance, with a reset flag that sets it back to 0. This allows for "drive forward 3 feet, turn 90*, drive forward 10 feet" style autonomous as you can reset the distance traveled after the turn.

[dwodrich]

Originally Posted by Kennersoft

If you only want your robot's forward velocity, mount your accelerometer with the sensitive axis pointing forward, then you can do an average of a number of them to give you average acceleration over a time, then integrate based on that. For 15 seconds of autonomous, it should be stable enough.

We're using the kit 3-axis accel over I2C and set that up to measure at 200Hz (200 samples/sec), which we then accumulate 10 samples to integrate. The output is velocity at 20Hz. I added a little "distance traveled" item for our autonomous that integrates this 20Hz velocity to distance, with a reset flag that sets it back to 0. This allows for "drive forward 3 feet, turn 90*, drive forward 10 feet" style autonomous as you can reset the distance traveled after the turn.

Thanks, this helps. Are you using a timed loop or just delays in the code to get the timing you want.

So sounds like you are capturing acceleration 200 times per second. Then you are averaging every ten of them and multiplying by .05 to get velocity at 20Hz. I am guessing you are multiplying again to get distance traveled in the .05 of a second. Then you are accumulating that distance to get total traveled.

Do you have any sample code I could let the team look at?

[billbo911]

If you truly want to measure distance with an accelerometer you need to be aware of one major obstacle, gravity sucks!

I know, that is a bit obtuse, but my point is, gravity will play a huge factor in getting accurate measurements. You see, if the accelerometer is even the slightest bit unlevel, gravity will be adding or subtracting from the values collected from the accelerometer. On top of that, if the mounting mechanism is not completely stable, with respect to the ground, then gravity's effect on the values will not be constant. So, as you might imagine, gravity will not be your friend if you try to take this approach.

Please do not let me discourage you with this posting, it is only meant to make you aware that while measuring distance with an accelerometer is theoretically possible, it's accurate implementation is far from simple.

[Kennersoft]

Originally Posted by billbo911

If you truly want to measure distance with an accelerometer you need to be aware of one major obstacle, gravity sucks!

I know, that is a bit obtuse, but my point is, gravity will play a huge factor in getting accurate measurements. You see, if the accelerometer is even the slightest bit unlevel, gravity will be adding or subtracting from the values collected from the accelerometer. On top of that, if the mounting mechanism is not completely stable, with respect to the ground, then gravity's effect on the values will not be constant. So, as you might imagine, gravity will not be your friend if you try to take this approach.

Please do not let me discourage you with this posting, it is only meant to make you aware that while measuring distance with an accelerometer is theoretically possible, it's accurate implementation is far from simple.

This is true, but if you're tracking your robot's attitude (heading, pitch, and roll) you can compensate for that. We have that in our code, and it even "calibrates" itself on startup by reading the current gravity.

dwodrich, I do have sample code for you, except it's a mess right now since we're having to rewrite it a tad to reduce complexity. When some of the students can't follow what's going on I know I've got a problem.

[dwodrich]

Originally Posted by Kennersoft

This is true, but if you're tracking your robot's attitude (heading, pitch, and roll) you can compensate for that. We have that in our code, and it even "calibrates" itself on startup by reading the current gravity.

dwodrich, I do have sample code for you, except it's a mess right now since we're having to rewrite it a tad to reduce complexity. When some of the students can't follow what's going on I know I've got a problem.

I'd love to take a look at it maybe I can help clean it up?

[pasini]

It is perfectly possible and simple to use an accelerometer to measure distance, with proper calculation.
CayennE-k has the technology. See it at CayennE-k Tecnologia www.cayenne.com.br
Cheers
Pasini