Re: Kalman Filter Code
5dof board from sparkfun).
Anyone sucessfully got this working using ADC gyros and
accellerometers rather that PWM? fancy sharing your code? :)
Also, it seems it only calculated angle for 1 axis, would it be
possible to extend this to both pitch and roll attitude estimation?
board from Sparkfun..
What are you trying to do? If you are building a balancer, the original
application of that code, I believe, perhaps that's not the best
sensor. It produces ~3g/volt centered on 1.5volt, and
~500degrees/second/volt centered on 1.5volt - pretty large ranges for a
balancer. Since the outputs are centered on 1.5v, you'll lose almost
another full bit of that resolution, too, directly interfaced to a 5vADC
input, which is centered on 2.5v.
What do you see?
Im just trying to get a basic IMU sorted to use for a camera stabilization unit. Im currently
using a atmega168 chip but would rather try and use the basicx.
I understand your point with regards the voltage and ranges, perhaps this will be a problem
with my applicatiion, pehaps not.
When i make the changes that i think are correct, i.e changing pwm inputs to adc, and
adjusting the center and delta values....
the output just seem to be a looping value of 184.108.40.206.5.6.8....70.
As im not using pwm sensor, what should i set the Period variable too?
Well, that might actually be a good sign. If the gyro filter code is
working but you haven't determined (and removed) the gyro bias, the
output _will_ climb in one direction as the bias error is repeatedly
added to the gyro rate integration. If that's the case, you're actually
pretty far along and just need to solve a bias problem.
> ... what should i set the Period variable too?
In the original code, Period is determined by measuring the repetition rate of his accelerometer's PWM output which, in turn, determines the accelerometer task's loop rate which the author says is about 30Hz. That suggests his PWM rate was about 60Hz since he does some processing between samples and must miss alternate cycles. The gyro is read as fast as it's task can loop, apparently, which in his message he says is about 150Hz; in the code, though, it says 180Hz and uses a constant of 0.00555 second.
Your sample rates are not determined by a PWM output, so you must either
establish a determined rate- or measure an undetermined one. For the
former, you can trigger an external interrupt at a regular rate using a
timer, or for more casual measurements you can use a software delay in a
task loop to approximate a rate, like sleeping for 100mS to approximate
10Hz; the rate will be less and varying in a task-switching environment
like this, remember, but in this case a Period of 0.100 will be close to
You can also, though, have the loops measure their own loop times, the
smartest approach, I think. Depending on the rate, you might either
count the number of loops over a certain period of time, or subtract the
loop event time (time now) from the previous event (then) to determine
the last elapsed Period.