Has anyone gotten useful data from the accelerometer?

[Chriszuma]

I was playing around with the accelerometer the other day, trying to use its sum to determine velocity. However, I fiddled with my algorithm for a couple of hours and couldn't get it to give me anything close to an accurate reading. Has anyone actually gotten this to work? I think they're just way too sensitive to use for tracking. I'll probably end up just using the gear tooth sensor to measure distance, which makes more sense anyway.
Maybe I need to upgrade to kevin watson's oversampling uart?

[Mike]

Originally Posted by Chriszuma

I was playing around with the accelerometer the other day, trying to use its sum to determine velocity. However, I fiddled with my algorithm for a couple of hours and couldn't get it to give me anything close to an accurate reading. Has anyone actually gotten this to work? I think they're just way too sensitive to use for tracking. I'll probably end up just using the gear tooth sensor to measure distance, which makes more sense anyway.
Maybe I need to upgrade to kevin watson's oversampling uart?

I've played with an accelerometer, but from what I've heard they can be very tricky. I would go with the encoder/gear tooth sensors to calculate position. How is yours connected? Could you show us the code?

[Chriszuma]

Originally Posted by Mike

I've played with an accelerometer, but from what I've heard they can be very tricky. I would go with the encoder/gear tooth sensors to calculate position. How is yours connected? Could you show us the code?

I just took in the data from it and summed it into a static variable. I tried bitshifting it, putting on a deadband, everything i could think of, but it looks like the data is just not accurate enough, or maybe it can't read from it quickly enough. I'll post the code later tonight, since it's currently saved on a computer half an hour from here.

[Matt Krass]

Originally Posted by Chriszuma

I just took in the data from it and summed it into a static variable. I tried bitshifting it, putting on a deadband, everything i could think of, but it looks like the data is just not accurate enough, or maybe it can't read from it quickly enough. I'll post the code later tonight, since it's currently saved on a computer half an hour from here.

Are you accounting for ALL acceleration? Fun fact: That chip will provide you with a deluge of information all lumped in to one signal. You need to filter out gravity, acceleration from getting hit, deceleration and probably more I'm not thinking of.

Also, it measure acceleration, not velocity, so if you're cruising at a constant speed, it'll read back 0 acceleration...plus the above mentioned factors. Gravity is tough, it varies based on orientation, on the upside that makes it great for sensing absolute angle when you're not moving, maybe use it for that and use encoders for velocity?

Hope that helped..

[Kevin Watson]

Originally Posted by Chriszuma

I was playing around with the accelerometer the other day, trying to use its sum to determine velocity. However, I fiddled with my algorithm for a couple of hours and couldn't get it to give me anything close to an accurate reading. Has anyone actually gotten this to work? I think they're just way too sensitive to use for tracking. I'll probably end up just using the gear tooth sensor to measure distance, which makes more sense anyway.
Maybe I need to upgrade to kevin watson's oversampling uart?

Using an accelerometer to determine your position is very, very hard. I'd start out by integrating once to determine your velocity and once you're happy with your results, try to integrate if again for position. I haven't tried it, but perhaps someone could try it out with the gyro code and report back. If you do, make sure that it is still and lying flat on a table while the bias is being calculated.

-Kevin

[Chriszuma]

Yeah, I was trying to simply integrate the acceleration to get velocity. I couldn't even pull that off. I came to the conclusion that gear tooth sensors make way more sense and it was slightly retarded to even consider using the acceleros in my navigation code.

[doubleslash]

I'd have to chip my two cents in and agree that using the accelerometer to measure speed is exorbitantly difficult. Our omniwheels provide a bit of slippage and encoders are therefore somewhat inaccurate, but in terms of being able to determine our location in autonomous, they are still our number one choice (versus the unreliability of the accelerometer).

[KenWittlief]

using the accelerometer to measure speed is exorbitantly difficult?!

velocity is the integration of acceleration. If you have the sensor horizontal pointing fore and aft, then all you need to do is add the output of the sensor to a variable (16 bits is best) each time you pass through the main loop of your code, and subtract out the zero reading (offset)

the register will then contain your velocity, all the time.

[Joel J]

Yea, but the velocity reported is, simply put, crappy. Velocity calculation from accelerometers is very hard in the sense that the results are noisy, and the noise readily amplifies with each integration. I'm sure you understand this.

The accelerometer isn't useless though. It can be fused with the gyro, to eliminate most of the bias. Saying this can be done is one thing, but actually doing it is an altogether different thing.

The accelerometer shares the same weakness with the encoders--they are both sensitive to BUMPs, and other "high frequency" changes--and also the same strengths: they are both pretty consistent over the long term. Therefore, fusing the accelerometer with the encoders might not be as fruitful.

[KenWittlief]

you need to step back a bit and look at the big picture. If there is noise and bumps they will be random and will average themselves out over time.

You could also filter the analog signal in HW or in the code. At any given instant the velocity integration may be a little off, but if you are reading it on every loop through your code, and using it for some purpose (like a PID closed loop speed control) the inertia of the motors and the robot will also help smooth out any random noise on the signals.

[Joel J]

Have you tried using accelerometers for this purpose? Do you have any specific experiences to share? I'm eager to hear of your results.

[Chriszuma]

Yes Ken, we all understand that it works perfectly in theory. I, however, have actually tried to implement this and failed miserably. The accelerometers simply are not reliable enough, coupled with the fact that a lot of the acceleration can occur in short spurts, which might not even be picked up by a given program loop.
Also: If you have a little bit of offset in your velocity calculation, then when you calculate position from that, it will be offset twice as bad.

If you have successfuly overcome these obstacles, please enlighten us.

[KenWittlief]

In the past the teams I have mentored used the ADXRSxxx family of yaw rate sensors for two functions: to close the loop on steering with a PID feedback control system, and we integrated the turn rate to get a relative compass heading.

For both applications the yaw rate sensor works very well. We could spin the robot 360 degrees left, then 360 right and it came back to 0 degrees so well that we could not measure any error.

The two axis accelerometer in the KOP this year is also made by Analog Devices, its the same family of products. I looked into the part used, the ADXL311. This is an excellent device. Analog Devices literally sells them by the millions.

Maybe my last post gave the impression that all you have to do is hook up the wires and add some numbers together. OK, I admit that was over simplifying the entire design - that was only the starting point.

Ive read the data sheet for the ADXL311. Looks like this would be a good topic for a white paper. The device has a user selectable bandwidth, controlled by parts that are soldered on the board. I dont know the default bandwidth as the board is shipped in the KOP, but it would not be hard to set this device up to get a 10 or 20Hz bandwidth.

Bandwidth is the indication of what the device will let through to its outputs, and its also related to the noise-floor of the output signal. The lower the bandwidth you use, the less noise the sensor will have.

Im afraid I cannot give all the details of everything you would need to do to use these devices on your robot in the character limit of this post. Even if I could, that is part of what this program is all about - students and mentors on a team looking at the data sheet for the part, and the application notes that Analog Devices has on their website, and refining the response of the sensor, and the code that integrates it to get the results you want. I cant do that for you over the CD forum.

One key to success with these devices is getting the bandwidth set so that it integrates the acceleration for you between the times the uC reads the output signal. Keep in mind that your robot has a lot of mass, its not possible for your robot to be jerking around on the floor jumping from +2g to -2g to +2 gs at 5mS intervals. The force required to do that would be off the scale. (BTW: Jerk is accelerated acceleration). If you have the sensor solidly attached to a heavy part of your robot frame, the signal you get from it will be fairly smooth and noise (vibration) free.

These devices are excellent for measuring tilt and acceleration. They are also very good for calculating velocity. As Watson pointed out, going one integration further to get distance is pushing it somewhat, but all things considered, having more sensors on your robot is better than having no sensors.

[cbolin]

Hi,
We are using the accelerometer to indicate that we are on the ramp sitting still and not rotating from side to side.

Consider mounting the accelerometer at a less than perfect horizontal orientation. We noticed that resolution (sensitivity) is much better if the acc. is tilted between 30 to 60 degrees. This has proved somewhat consistent for us.

Another use for the acc. is in autonomous mode. You are for example driving from point a to b. You are cruising at a nice speed when suddenly there is an unexpected spike (up or down) in accel. We are using this (in conjunction with wheel gear teeth data) to indicate a possible collision so we can execute a reversing action, and then put the bot back on the right path.


Regards,
ChuckB

[6600gt]

[quote=
These devices are excellent for measuring tilt and acceleration. They are also very good for calculating velocity. As Watson pointed out, going one integration further to get distance is pushing it somewhat, but all things considered, having more sensors on your robot is better than having no sensors.[/QUOTE]

I have heard poeple do floating point trig calculations, then why can't you do floating point integration calculations?

Wouldn't it be accurate enough?