SparkFun Forums

[mpthompson]

I was getting frustrated with my Kalman filter so in the updated version of the project below I have added the working Kalman filter from the Autopilot project to compare it's output with mine. The new modules are in tilt.c/h.

http://home.comcast.net/~michael.p.thom ... _IMU_3.zip

The original code can be found here:

http://www.rotomotion.com/downloads/tilt.c
http://www.rotomotion.com/downloads/tilt.h

In looking at their code I couldn't figure out why their Kalman equations seemed different from mine. It turns out they are actually implementing an Extended Kalman Filter and computing a Jacobian matrix. I haven't tuned the co-variance matrices, but their code seems to work very well with the IMU. It seems very resistant to horizontal accelerations. I'll be looking into more detail about this and probably follow their lead and create an independent implementation of an Extended Kalman Filter. I should then be able to do an apples-for-apples comparison to work out the kinks in my implementation.

I agree with you regarding the need to use captured data. I may revert back to that path while I dive into this deeper.

-Mike

[emf]

I was getting frustrated with my Kalman filter so in the updated version of the project below I have added the working Kalman filter from the Autopilot project to compare it's output with mine. The new modules are in tilt.c/h.

Nice work. I just made a few ugly hacks and got it up & running on my dsPIC. I only played around with the tilt.c code for a few minutes, but it seemed to work reasonably well. The main thing I noticed was that bumps (+/- Z axis) caused some pretty big changes in the estimated roll pitch angles -- it was easy to get it to give a reading of 20-30 degrees roll/pitch when it was still level. I'm not sure I have all of my ADC calibration values set correctly, so this could be a false alarm...

In looking at their code I couldn't figure out why their Kalman equations seemed different from mine. It turns out they are actually implementing an Extended Kalman Filter and computing a Jacobian matrix.

Almost every paper on Kalman filtering for attitude uses the extended filter. There are so many variations, it's hard to keep track of them all. Ghint's is supposedly a continuous-discrete EKF, but I haven't figured out what that really means (the few bits of info on continuous filters I have found say they're usually not used).

It was very encouraging to see the angles scrolling across my screen though.

[icecube]

Have you guys seen this?

http://www.recherche.enac.fr/~poine/video/ahrs2fg.mpeg

The source code is located here:
http://cvs.savannah.gnu.org/viewcvs/pap ... /airborne/

... or see the news item from December 7th:
http://www.recherche.enac.fr/paparazzi/ ... /Main_Page

[modles]

This stuff is great guys, looking to start work on my mess around uav and this stuff is a god send

im just trying to spec out my hardware at the moment and im struggling with all the options.

for IMU:-
do i go for the 5DOF sparkfun (only 2grams which is a big bonus in my project, and i could use a second breakout board for yaw gyro?)

or the full out 6DOF? if so which version 2 or 3? i dont need bluetooth so is there any benefit to v3?

or maybe even the memsense nIMU, looks like a good balance of weight and function, but will it work with this kalman code?

for controller:-
im guessing it has to run C so my options are:
Gumstix, how do i connect the IMU to this, can i connect other I2C sensors onto this, or do i need some expansion board?
also, which gumstix board, there are about a million of them?

Robostix, will this provide everything to collect RC receiver data, collect sensor data (including IMU) and control servos and electronic speed controllers?

sorry for the newbie questions!

Many thanks in advance

Ben

[emf]

Have you guys seen this?

I ran into that a week or so ago when I was looking for other filters. Looks like a neat project -- I'd love to see one of those little guys in action. The source for their filter looks a good bit more readable than most I've come across. I've hacked their code into the AVR_IMU framework, but I've been too busy to test it this week. Hopefully I can do some tests this weekend.

for IMU:-
do i go for the 5DOF sparkfun (only 2grams which is a big bonus in my project, and i could use a second breakout board for yaw gyro?)

I'm guess it depends a bit on your application. I know people have had success with only two gyros. I'm thinking you could get away with it if you're using a fixed-wing aircraft where yaw is going to be minimal. with a helicopter the third axis is probably a lot more important. There's certainly nothing stopping you from having the third gyro on a second breakout board if you need it.

As an aside, I was just looking at a few datasheets last night, and I noticed that the ADXRS gyros measure an axis orthogonal to the ones measured by the IDG. If you didn't mind dealing with two different types of gyros and having both 3V and 5V sensors, you could make a killer IMU with no risers. An IDG300 for pitch & roll rates, ADXRS300 for yaw rate, ADXL330 for all three accelerometer axes. And as long as I'm dreaming, slap on a HMC1053 for a three-axis magnetometer. Throw on a couple voltage regulators and a little bit of signal conditioning for good measure. Hmm...

or maybe even the memsense nIMU, looks like a good balance of weight and function, but will it work with this kalman code?

It looks like a great product... It's not cheap, but it has all of the filtering and a/d stuff bundled up in one small package which would save a lot of work. Maybe if I win the lottery...

The Kalman filters (this one and ghint's) can easily be modified to connect with pretty much any set of gyros/accelerometers. The project in this thread reads the sensors directly with the AVR's a/d converter, but you could easily replace the few lines in the main loop that acquire the next set of readings to read it from a UART for the 6dof IMUs, or I2C, or a text file for debugging.

[modles]

Thanks for the info

the memsence nIMU works out at £1300. It does not do any kalman filtering but it is calibrated and temperature compensated.

I came accross this today
http://www.xsens.com/index.php?mainmenu ... nu=MTi_OEM

complete AHRS system in 11grams, and looks like its rought the same price, maybe cheaper, waiting for a price back.

apears to be this sensor head
http://cloudcaptech.com/crista_sensor_head.htm
but with the orientation processing done onboard

Difficult to know what to do when there are $300 ish sparkfun units, im worried they will not be calibrated very well and the results rather sketchy.

My UAV is a small indoor quad rotor so i need pretty fast and accurate data.

[emf]

I came accross this today
http://www.xsens.com/index.php?mainmenu ... nu=MTi_OEM

That's a nice little unit too. If you're looking for a way to get up & running quickly, that's probably the type of thing to look for.

I haven't seen a lot of reports from people on these forums who have working flying contraptions based on the sparkfun units. I think it should be quite possible to make one, though. The sensor hardware for the old autopilot (helicopter) project and the paparazzi project looks fairly similar, and they seem to have had success in real world flights. It just looks like the folks here are in the earlier stages of development (or are using them for stuff that doesn't fly). I think there's someone else here working on making a quad rotor controller. I think you can count on spending a number of days testing & tweaking your hardware if you go this route.

apears to be this sensor head
http://cloudcaptech.com/crista_sensor_head.htm

This one actually gives you some details in the datasheet. It looks like all of them are using the ADXRS gyros, like the 6DOFv2. Different accelerometers, but probably not a big deal. The big difference I see is they have a 16-bit ADC instead of using the microcontroller's 10-bit one, and they probably have slightly better filtering. I don't know how much difference the extra 6 bits make.

One day, after I get the filtering working to my satisfaction, I'll try hooking it up to a 16 or 22 bit ADC and see if it looks any better. For now, I'm sticking to the 12-bit ADC in my PIC and I'm pretty sure that'll be fine for my purposes.

The analog devices gyros have temperature outputs which allow you to do temperature compensation. The IDG gyro used in the 6DOFv3 doesn't. The kalman filter is supposed to track gyro drift, so I'm hoping this won't be a problem, but time will tell.

[SOI_Sentinel]

Hmmm... they may be fibbing a bit. I'm not an analog signal chain specialist or know too much about digital noise filtering, but the gyros are rated at 0.1 deg/s/sqrt(Hz). So, given the normal 40Hz bandwidth, we're looking at 0.7 deg/s/Hz, which matches their claimed numbers. Now, this is the thermal noise of the just the gyro, too. So, it's 0.23% error, or an equivalent best noise ratio of about 429 levels for 0 to 300 deg/s, so about 9 bits. Add one bit for sign, and we're looking at 10 bits.

Now, they may be using a higher bit depth so they can get at least 10 effective number of bits out of their ADC without oversampling. An external ADC would allow them to isolate their analog and digital power planes and lower signal noise.

[emf]

Hmmm... they may be fibbing a bit.

Thanks for the analysis. I get the feeling I'm going to be spending the rest of my weekend trying to figure out what the heck you just said

[modles]

me too

[emf]

Hmmm... they may be fibbing a bit. I'm not an analog signal chain specialist or know too much about digital noise filtering, but the gyros are rated at 0.1 deg/s/sqrt(Hz). So, given the normal 40Hz bandwidth, we're looking at 0.7 deg/s/Hz, which matches their claimed numbers. Now, this is the thermal noise of the just the gyro, too. So, it's 0.23% error, or an equivalent best noise ratio of about 429 levels for 0 to 300 deg/s, so about 9 bits. Add one bit for sign, and we're looking at 10 bits.

I looked at the numbers again and it doesn't look so scary in the light of day. Let me see if I have this right. Here's what I got when I run the numbers for the 5DOF IMU:

The IDG300 is rated at 0.014 deg/s/sqrt(Hz) if you believe the numbers in the datasheet. Its bandwidth is internally limited to 140Hz, so that gives us 0.166 deg/s/Hz of noise. The gyro puts out 2mV/deg/s, so this noise would equate to 0.322mV.

How many bits do I need? Assuming I have an ADC with a range of 0 - 3.3V, it will need to resolve 3.3/0.000322 = 10249 levels. log_base2(10249) is 13.3, so I'd need at least a 14-bit ADC to ensure that I'm not throwing away any real data.

Did I get that right?

[ghint]

Almost every paper on Kalman filtering for attitude uses the extended filter. There are so many variations, it's hard to keep track of them all. Ghint's is supposedly a continuous-discrete EKF, but I haven't figured out what that really means (the few bits of info on continuous filters I have found say they're usually not used).

It was very encouraging to see the angles scrolling across my screen though.

Actually my code is heavily based upon rotomotion's implementation. This is stated all over the code

[ghint]

Almost every paper on Kalman filtering for attitude uses the extended filter. There are so many variations, it's hard to keep track of them all. Ghint's is supposedly a continuous-discrete EKF, but I haven't figured out what that really means (the few bits of info on continuous filters I have found say they're usually not used).

It was very encouraging to see the angles scrolling across my screen though.

Actually my code is heavily based upon rotomotion's implementation. This is stated all over the code

Actually, now that i've read your filter (the one based on tilt.c) i can say that they're exactly the same (i based mine on that same piece of code, except my constants are the same because the gyro models are the same). The main difference is you beat me at code readability. Congrats, man. Your code is as clean and neat as it gets.

Now, as for your own code, i can't see why it shouldn't to as good as tilt.c I'm guessing it's just a matter of constant tuning.

BTW, if anyone gets quaternion rotations working with this code, much of the cross axis interference gets smoothed out. When that happens, if this code is still GPL-like, i'll hapily move my own aside and replace the ahrs in the flightdirector with this.

Can't wait for some news. Keep us posted, pls!

[Bergamot]

This stuff is going to be hard to test since it'll always have to be done on the hardware. It would be *really* nice to have sets of test data that also included physical measurements of the angles so we could analyze how much error we're getting. Something tells me I'm going to spend a few hours driving figure eights in empty parking lots trying to get some tricky data...

I was thinking of building a rig where my circuit board was hinge mounted on a potentiometer, letting me compare real angular values with the estimated ones.

Haven't tried it, though.

[ghint]

This stuff is going to be hard to test since it'll always have to be done on the hardware. It would be *really* nice to have sets of test data that also included physical measurements of the angles so we could analyze how much error we're getting. Something tells me I'm going to spend a few hours driving figure eights in empty parking lots trying to get some tricky data...

I was thinking of building a rig where my circuit board was hinge mounted on a potentiometer, letting me compare real angular values with the estimated ones.

Haven't tried it, though.

Hi

I've done that (two axes). All you need is a sphere mouse and a weight attached to the ball (or smaller ball with weight).

To be accurate, that setup is really an accelerometer. It basically measures the effect of gravity's force with is basically g (gravity acceleration) times the object's mass. So by measuring its weight (force), you're measuring a product of an acceleration, hence the accelerometer.

All in all, it's just cheaper, less bulky and a lot more elegant to use a mems accelerometer...

Mind those linear accelerations though. That's why you need gyros.