SparkFun Forums

[emf]

Thanks - so I take it that the code is not quite up to speed yet in that there is some work to be done on the accelerometer side of things.

Yeah, don't expect to download this and have a working artificial horizon. It's not that there's a problem with reading either of the sensors, it just doesn't give them the right weights when combining them into an attitude estimate. It's also missing some other stuff you'd need in a real project. For example, there's no calibration routine (manual or automatic) for the accelerometer; its zeros are hard-coded. It's a nice starting point, but expect to have to do a bit of tweaking to get it to work.

On an earlier issue, the additional benefit of slapping on some active filtering (op-amps) is that you automatically buffer the sensor output (which is pretty high impedance as I understand it). This should, in theory, result in more accuracy.

Right... you're going to need the op-amps in there anyway, if you can use them to do some filtering while you're at it, sounds like a good idea to me. I've just stuck with RC filters and simply buffering the outputs because analog scares me. I think I stand a better chance of getting the digital filtering right.

I wonder if Ghint's project does any better under acceleration. I guess I'll have to give it a try myself once my module comes in. Again, thanks for your inputs - let's keep this thread alive.

I'd definitely give his a look. I don't know if his has flown yet or not, but I get the impression he's put a quite a few hours into getting it working and testing it.

I'm going to stay out of the code for a while and just play with the simulator. I'm also working on a simple logger so I can get a few real-world data sets to play with (maybe next month), but I don't think there's much hope for it working in the real world until it can handle the noise-free data from the simulator.

[mpthompson]

It's been a while since I posted to this thread, but I've made some progress with the Kalman filter code I posted in the early messages on my balancing robot. The result of the early work can be seen in the following video:

http://www.youtube.com/watch?v=qTGolngNves

This robot is using my Rotomotion derived code running on a 20MHz ATmega168 taking 10 bit analog samples from the Spark Fun IMU 5 DOF board. Only three of the five channels are used as this robot is only balancing in the pitch plane. What's impressive to me is that I was able to get the robot balancing with the Rotomotion derived code without changing any of the turning parameters such as the various covariance values even though I'm presumably using much different sensor hardware.

I'm currently making my way through the book "Probabilistic Robotics" which has a fair amount of information on the Extended Kalman Filter. Hopefully I'll be able to learn enough to begin intelligently tuning the filter to better balance the robot. There is currently some lag in the position/rate values that take a few seconds to settle down that I really need to eliminate before the robot will balance in a rock steady manner.

BTW, does anyone know what specific Kalman Filter paper that Trammell Hudson refers to in his original tilt.c file here? Knowing which paper he's referring to would help in dissecting the implementation a bit.

-Mike

[emf]

The result of the early work can be seen in the following video:

Very nice work! Looks nice and stable. Carpet can't be the easiest surface to balance on either...

What's impressive to me is that I was able to get the robot balancing with the Rotomotion derived code without changing any of the turning parameters such as the various covariance values even though I'm presumably using much different sensor hardware.

You got me wondering how we could be running essentially the same code and getting such different results. I pulled up a few old spreadsheets and I'm starting to see what the problem is. The way it's set up, the filter adjusts the gyro bias very quickly, so when the gyro output increases to indicate that you're rotating, the filter just thinks the bias has changed and quickly adjusts to ignore that. In my test data, the bias changes around 1 degree per second per second, varying by at least 10 degrees per second in either direction during a simulated climb/descent. Since you don't have any rotations that last more than a fraction of a second, the filter probably works well maintaining the bias at the right value for you. If I can figure out how to slow this response a lot, the filter will probably start working very well for me.

Edit: I started blindly tweaking constants last night. If you divide the Q values by 100000, it starts to act a lot more like it should. The pitch estimate tracks pretty well with the the true pitch -- sometimes varying by up to five degrees, but it gives you hope that you could get a usable estimate with a little more tweaking. The bank estimate looks like it would be usable for staying level, but still nowhere close on extended turns. It might be fixable by decreasing those constants a few more orders of magnitude, or perhaps I need to be altering the ratio between the two Q values. Anyway, finally some promising results.

[Wulffy]

...BTW, does anyone know what specific Kalman Filter paper that Trammell Hudson refers to in his original tilt.c file here? Knowing which paper he's referring to would help in dissecting the implementation a bit.

-Mike

Hey Mike! Been lurking a while herein. Glad to see some real positive activity with regards to KF implementation.

I haven't taken the time to review what source you are referencing, however, I have found a wonderful source for papers that will most likely have what you are looking for, here: http://CiteSeer.ist.psu.edu.

I'd recommend taking a peek there...

Just in case there is interest, I have found a couple filters that I feel offer the most opportunity for desirable results. Take a peek at these:

File 1 and File 2

Also be sure to check this and this out.

[darinm]

Could this hardware (IMU 5) be used to output of pitch and roll for a period of 6 hrs in an aircraft?

[jaymarallag]

I noticed that the code has a little delay in response. Does anyone have any idea what variable/s must be manipulated to improve the response? tnx...

[e5kjetil]

I noticed that the code has a little delay in response. Does anyone have any idea what variable/s must be manipulated to improve the response? tnx...

Well, It's a recursive filter... You can update at a higher rate, by means a faster microprocessor. Adjusting the variances/sd will also allow you to tune the response.

[Slot4]

Hi everyone,
my apologies if I missed it, but did anybody try to use thermal compensation for the IDG-300 gyros? The temperature related bias looks huge. Or probably the variable bias can be handled on-the-fly by a proper Kalman filter alone?

[YankeeGeek]

Hi everyone,
my apologies if I missed it, but did anybody try to use thermal compensation for the IDG-300 gyros? The temperature related bias looks huge. Or probably the variable bias can be handled on-the-fly by a proper Kalman filter alone?

I used temperature data from an SCP1000 to negate IDG300 temperature drift.

[Slot4]

Hi everyone,
my apologies if I missed it, but did anybody try to use thermal compensation for the IDG-300 gyros? The temperature related bias looks huge. Or probably the variable bias can be handled on-the-fly by a proper Kalman filter alone?

I used temperature data from an SCP1000 to negate IDG300 temperature drift.

Did it make a big difference?
I guess you had to place the SCP1000 very close to IDG300 in order to measure the chip temperature.

[Tobias]

Hi

I currently have 3 accelerometers and 2 gyros attached to a development board. The data from the gyros is smooth and I can get a reasonable value for pitch and roll angles from them, but as you would expect it drifts with time. So I want to take my accel. data and 'adjust' the pitch / roll angles to remove any drift when I have little or no real roll or pitch, so I thought the kalman filter / tilt code from the forum would help. However the filter appears to rely more on the accel. data than the gyro data. Changing the SW_00 and SW_10 figures in the kalman init code does not appear to change the behaviour of the filter.

I cannot rely on pitch and roll figures derived from the accelerometers as the air frame is capable of producing high dynamic turns which introduces lots a centripetal forces causing huge errors.

Am I asking too much from this kalman filter? or how do I force the filter to bias its result more towards the gyro data.

thanks for any input you can provide

[gabossy]

Is there any open-source photo gallery that lets users download multiple images? I've looked at some of the well-known open source gallery scripts, like Gallery, Plogger and ZenPhoto. While they all have great features, none seems to have a "multiple download" feature.

[rp181]

Time to bump up the thread.

I have been trying to get the tilt.c to work, but the output values are very bad, they hover around 0, and jump when I accelerate. Once I rotate it, the value falls back to zero after holding it for a second or two.

What types of values does this take? I tried degrees/sec for the gyro and G's for the accelerometer, as well as the raw ADC value (14 bit ADC, gyros 5V, accelerometer 3v3).

What values are people changing to get proper output results?

[Hami]

Hey people,
I am not an expert but i already read a few papers and threads.
I have read a paper, in which a Kalman based filter and a "new" filter is campared. The Kalman based filters was not better, is complicated and need a much more powerfull micro.
Try to google for: "An Efficient Orientation Filter for Inertial Measurement Units (IMUs) and Magnetic Angular Rate and Gravity (MARG) Sensor Arrays" (Sebastian O.H Madgwick et al.; 2010). I also recognized, that the autor of this paper is active in this threads.... .
Perhaps the papers of Mahony and the DCM-Filter would also be interasting for you.

Hami

[rp181]

I have implemented a DCM filter, but I would also like to try a kalman filter. I am running a XMOS MCU, so I have lots of power available.