Accelerometers and speed

[mickztlin]

So we have had a few accelerometers laying around and I was thinking about what can we use them for. I was thinking about using them to do speed and distance readout for testing our drive train. Im currently in physics c so I understand it does not read off velocity but acceleration, but couldn't I use the kinematic: (at+v_i)=vf and as long as i know we are starting with no velocity find speed and distance final. Would this work and what are some challenges with doing this

[magnets]

You are correct, you can take the integral of acceleration to get your changes in velocity, but the sensor is not really accurate enough to get a reliable velocity. The accuracy of your current velocity depends on how accurate you were a second ago, which depends on how accurate you were before that....

Just like when you integrate the angular rate given by a gyro, and drift is present over long periods of time, your velocity will drift, but a lot more. Getting an encoder on the shaft is one way to measure velocity, but they can be hard to work in if you've already started designing.

You can use an optical sensor and paint half a shaft white and the other half black, and measure velocity based of the frequency of the change from white to black.

[Joe Ross]

While this is theoretically possible, in the real world, with cheap accelerometers, it isn't practical. Small errors in acceleration add up over time and produce poor velocities and even worse distances.

A similar process is used for the gyro (which gives angular rate) and to get angle. The cRIO FPGA does the calculation at a very high rate (1000s of samples per second), which wouldn't be possible in software. Even so, the gyro angle drifts by many degrees by the end of a match.

It's possible that you might get decent velocity results for a short period. If you wanted to experiment with this, I would look at how the gyro software was implemented and copy that.

[mickztlin]

Thanks for the advice, the idea was just something we were playing around with so we may try just for fun (if we have time)

[faust1706]

You should expect cheap hardware to not work perfectly, and a gyro and accelerometer is no exception to this rule. Some hardware you can get away with not being perfect, but not these two.

As someone else has mentioned, the gyro measures degrees/sec, so you must integrate it to get degrees. In a perfect world, the integration would be correct, but there is a delay in points on the graph, aka the "function" of degrees/sec is not continuous but rather just a collection of points.

We are still using a gyro this year. It runs through ardiuno and apparently is better than the KOP one. A clever method to combat this would be to calculate yaw from vision (yaw is heading on the field), then every once in awhile (once a second or so) replace the gyro reading with the solution vision gets. This is the method we are using.

[Michael Hill]

Originally Posted by Joe Ross

While this is theoretically possible, in the real world, with cheap accelerometers, it isn't practical. Small errors in acceleration add up over time and produce poor velocities and even worse distances.

A similar process is used for the gyro (which gives angular rate) and to get angle. The cRIO FPGA does the calculation at a very high rate (1000s of samples per second), which wouldn't be possible in software. Even so, the gyro angle drifts by many degrees by the end of a match.

It's possible that you might get decent velocity results for a short period. If you wanted to experiment with this, I would look at how the gyro software was implemented and copy that.

I always thought the drift of a gyro was predictable and you could correct the drift in code.

[JohnGilb]

Some drift may be predictable - you might notice that your gyro has a pretty constant 0.05 degree/second drift in one direction. You could compensate for that in software (and probably should!).

However, as you look closer and closer at the drift, trying to compensate more and more accurately (hmm, looks like it was 0.051, or maybe 0.05102...), you'll eventually hit a point where the drift is no longer predictable - the drift is essentially small and random in both directions.

Essentially, the more expensive / higher quality a gyro you have, the smaller that "noise" value is. Also, operating in ideal conditions (temperature-controlled, constant voltages) will reduce that noise further.

But it won't be totally eliminated, and these errors accumulate.

[yash101]

If you have vision tracking, you could use processing to automatically recalibrate the gyro/accelerometer. For speed, as already mentioned before, encoders are your friends, not accelerometers!

[mickztlin]

My intention was something we could simply strap onto the robot instead of an encoder (what we used in previous years) but that ended up to be easier.

[otherguy]

You could look at using an IMU.

FRC 2465 is selling one they built: www.kauailabs.com/store

Some more info here: http://www.chiefdelphi.com/forums/sh...d.php?t=124379

[John]

Originally Posted by otherguy

You could look at using an IMU.

An IMU is a set of accelerometers and gyroscopes (in this three accelerometers and three gyros to detect all 6 degrees of freedom). The nav6 includes a magnetometer, which may help mitigate gyro drift, but won't do anything for linear acceleration.

In general, you may have success with an accelerometer (or an IMU containing one) if your margin for error is large enough (say, if you just want to drive forward ~8-12 feet in auto to pick up the 5 points, and want a sensor instead of timing). But if you want really accurate positioning you will probably need a different sensor (probably encoders).

[slibert]

Originally Posted by John

An IMU is a set of accelerometers and gyroscopes (in this three accelerometers and three gyros to detect all 6 degrees of freedom). The nav6 includes a magnetometer, which may help mitigate gyro drift, but won't do anything for linear acceleration.

In general, you may have success with an accelerometer (or an IMU containing one) if your margin for error is large enough (say, if you just want to drive forward ~8-12 feet in auto to pick up the 5 points, and want a sensor instead of timing). But if you want really accurate positioning you will probably need a different sensor (probably encoders).

As we developed the nav6, we developed code to calculate linear acceleration. Given the digital motion processing that fuses the gyro/accellerometer and the sensor calibration that's automatically performed, a reasonably accurate estimate of the gravity vector is developed. This gravity vector, when adjusted to be relative to the world reference frame and then removed from the raw accelerometer data, yields linear acceleration, which in the X and Y axes is reasonably accurate.

As you've indicated, it really depends the level of accuracy that is required. I don't have nav6 linear acceleration accuracy measures yet, but will try to post them when we've measured them. The linear acceleration measures certainly won't be perfect, since an IMU uses estimation techniques during the gyro/accelerometer fusion.

Of course, wheel slip and encoder decode tracking error can also be introduce inaccuracies in certain cases, so encoders pose challenges, too.

One of the nice ideas I've seen discussed on Chief Delphi is fusing the encoder data from the drive wheels w/the linear acceleration (like that calculated by the nav6). These two data streams would be fused by a Kalman Filter (or perhaps more simply by a complementary filter approach) which would be tuned to use the encoder data - unless wheel slip was detected in which case the IMU-generated linear acceleration measures would be used until the slippage had subsided.

I'm curious as to others thoughts on this idea, as I'm thinking this would be a nice research and development project that we could work on during the off-season and make available to the community if there was interest.....

[efoote868]

As others have mentioned, you will get small errors in your measurements which can accumulate when you add them together for a long period of time.

There are things you can do to try and mitigate these errors. For an accelerometer, try to keep the vibrations hitting it as minimal as possible. This means mount it to a most rigid part of your robot (towards the center) with a damper material (such as a soft foam) in between. Also, handle the sensor with care. Every accelerometer I know of has a G tolerance, which will be on the order of 100s -1000s of Gs. Any jerk (think collision or bounce) more than this will ruin your sensor, and you won't be able to tell just by looking at it.

The last thing I'd suggest you do would be to thoroughly test your code and your setup to understand it's limitations - if the error becomes too large after 10 seconds then you probably won't want to use it for more than autonomous mode.