Accelerometer use

[artdutra04]

I've been contemplating this for a while too, as I used the difference between the two values coming back from the encoders on the drive train for detecting and preventing drift. However, in threory*, the acceleration measured from the accelerometer can be used as a internal GPS system. With a known starting speed (0 m/s) when the robot initializes, and with a known acceleration each time through the loop, you should be able to ascertain the exact speed and direction of your robot at any time.

With the initial velocity, acceleration, and time, you can use simple physics to determine the final velocity. If you keep a running counter in your code to track time between executions of the loop, as well as the output speed from the previous time through the loop, you can keep running this code to find the current velocity of the robot, as well as the distance covered from the previous location.

If you include the gyro, it gets a lot more complicated, as now you have to deal with trigonometry and more vectors, but you still should be able to run your current data through physics equations to get the current location, orientation, and position of the robot relative to the origin.

* I've never actually tried this; this is just an educated guestimate from what "should" be feasible on paper. Whether the controller is powerful enough to handle that many floating-point math problems (co-processor anyone?) is another story. I apologize if what I wrote here is really off-base.

[EricVanWyk]

What exactly are you trying to do?

Combining a singly gyro and a single accelerometer is fantastic for giving position and direction on a non-holonomic (aka KitBot) robot. Unfortunately, it doesn't sound like that is what you want.

Canceling noise is hard. Canceling drift is harder. Noise assumes that the data we are getting back is essentially Gaussian, which means we can do fun filtering . Drift is inherently more evil, as it implies that the sensor tends to one side. I don't know of a good way to handle drift without using some side-band information. In other words, if your sensor has drift, something else better compensate for it.

One thing you might consider doing is finding out when you KNOW your gyro better be reading 0s. If you ain't moving, you ain't spinning. Perhaps you should keep a note of how your gyro handles sitting still, convert that to a DC offset, and subtracting it out.

Another method (less good) is to make your accelerometer into a craptacular gyro. Place it as far forward or backward as you can, in the middle of the bot, and rotate it to point side to side. Now when you spin, the accelerometer picks it up. However, it also picks up when you get slammed into, and it totally bombs for accuracy because it in no way compensates for your turning radius.

More info = more answers.

[Alan Anderson]

Originally Posted by artdutra04

...in threory*, the acceleration measured from the accelerometer can be used as a internal GPS system...
* I've never actually tried this; this is just an educated guestimate from what "should" be feasible on paper...

You're talking about an Inertial Navigation System. GPS relies on external references; INS is fully self-contained.

Other people have tried it on FIRST robots. There's too much noise (mechanical, mostly) for anyone to have made it work reliably...yet.

[Salik Syed]

Here is some info on a Filter you can use to help cancel out noise if you are interested:
http://en.wikipedia.org/wiki/Kalman_filter

It is kind of dense and hard to understand, but I think it would be possible to implment if you got some outside help.

You may also be interested in page 668 of this article:
http://robots.stanford.edu/papers/thrun.stanley05.pdf

I think it might be better to get creative and come up with your own way of filtering out noise, you can use multiple sources (Gyro, Encoders, accelerometer) and based on correlations figure out which ones are accurate and which ones aren't

[EricVanWyk]

Originally Posted by Salik Syed

I think it might be better to get creative and come up with your own way of filtering out noise, you can use multiple sources (Gyro, Encoders, accelerometer) and based on correlations figure out which ones are accurate and which ones aren't

I am reasonably sure that that is exactly what a Kalman Filter does: Take a whole bunch of noisy measurements and boil them down into one less noisy measurement. Unfortunately, I think that using an accelerometer as a noisy gyro is weak at best. I do like the use of encoders though.

Please take what I say with a hefty grain of salt, as my education for Kalman filters is hilariously spotty. I was helping to interview candidates for a position at Olin, and as a result I heard 4 or 5 introductions to SLAM (Simultaneous Localization and Mapping). Each professor would then gloss over Kalman Filtering with varying degrees of success.

I think it would be a great project to do a white paper on Kalman Filtering as applied to an IMU for FIRST. Take a kit bot, add a gyro, accelerometer and a pair of encoders. This gives you some degree of redundancy, as either the gyro/accelerometer pair or the encoder pair could do all of the work. Then you can combine their data for a more robust system.

Enjoy