We should make a Reed shrine. He's the one who got us, & later everyone else on DIYDrones, using 200Hz update rates on the old quad rotors to get them stabilized. He also got us looking at pure gyro autopilots.
Accelerometers & magnetometers add lots of stability but have lots of problems in high vibration helicopters, so if you can master pure gyro navigation you'll really be on the inside of the inside. Forget 10 seconds. Those ADXRS gyros go 10 minutes without significant heading drift.
I'll also humbly admit I understand BARELY any matrix algebra. You DO NOT need this. I am sure it can provide some structure to the equations, but I assure you my setup is both rigorous and I use some techniques to renormalize some things in each iteration of the process.
It is sort of funny though: I spent weeks thinking through how the 3D rotation rates concisely and correctly equate to predictive updates to the attitude vectors in each axis. When I was done I had a group of 3 equations... lo and behold they are partial differentials and could be arranged in a matrix. What I had done is (without understanding matrix algebra conventions) developed the essence of what is behind the matrix of predictive update equations... nuts and bolts fundamental motion equations WITHOUT singularities (places where math infinities creep in and cause the system to have bad spots). Hell, my update equations don't even use any trig... they use the fundamental underlying notions underpinning triangle trigonometry (how X and Y relatate to the hypotenuse).
So while I won't publish code - I know from experience my comments will indeed be very helpful to many people that struggled with what I used to struggle with.
So the reason I say all this is to encourage people to not get stuck in fear like I had been for too long. If you look at a Kalman filter paper and don't understand matrix algebra then it is frightening to see all the symbols. However I do have a VERY solid understanding of statistics basics in an applied sense from my years of statistical work at Intel, so that is one strength I have that I might be under-estimating.
@Dean: Wow, that is great stuff. Reading this thread yesterday let me on a multi-hour crash course in IMU and coming back and reading your comments today Dean was just a treat. I think the driving around in the car concept is gold. Thank you!
I can see bcr's point of view though... it is worhtless from his point of view, or for his needs.
Chris is 100% correct that my work is closed source, but I do talk high level stuff often. So how about some peace offerings:
1) There is no Kalman anything in my IMU. You don't need it, so don't get hung up on it. Besides, it is not a black box or magic bullet... it is just a way to use statistics to optimally blend the prediction and estimate portions of the IMU. You can totally get by with a fixed weighting factor ratio between the gyro-driven updates to the model and the accel-driven measurements.
2) Taking into account centripetal forces is key. Don't just let the filter de-weight accelerometer updates when the accel starts showing things that don't agree with the current model, such as in a banking turn or when pulling up. Ignoring real affects and measureable forces is sloppy, and doing so hurts the IMU function.
3) You also need to be mindful of what happens in a continual banking turn. For example, normally you can look at pitch rate from the pitch gyro, and also look at a noisy estimate of pitch rate by differentiating pitch which was calculated by Atan2 of the X and Z accel axes. If you sum the error between the two methods over a huge number of samples, you can in fact determine if the gyro bias has drifted, by how much, and iteratively trim that axis gyro bias. You can even do something slightly fancier and check to see if the gyro scale factor needs trimming too. BUT - what happens in a constant banking turn of indefinate duration??? I'll tell you what happens: there is a NON-ZERO pitch rate (it is physically real) sensed by the pitch axis gyro (because the plane is pulling through a continual turn) HOWEVER the X and Z accel vectors aren't changing because in an ideal sense the nose is at a specific level and so is the Z axis vector. What does this mean for the differentiation of Atan2 of X/Z to determine wether or not the pitch axis gyro is in need of a bias update? Well, the X and Z aren't moving so they report a zero pitch rate which is in disagreement with the pitch gyro. This discrepency (if ignored) will make your pitch gyro bias get pushed away from true bias to the point where if somehow magically the plane could continue loitering like this, the pitch rate would apperently be zero according to gyro with now messed up and wrong bias. The loiter would go to crap. If on the other hand you know the Earth-centric yaw rate (heading change rate) and the IMU roll angle, then you can calculate EXACTLY how much of the pitch gyro is directly comparable to the atan2(X/Z) method, and your IMU code won't do wrong things to the pitch gyro bias.
Now that I'm on the "inside" with proven and robust IMU code that I 100% developed from scratch (and therefore understand on the deepest level), I know exactly why on the U-Nav website they made a point to show a video of long duration loiter of the U3500 with a plane... to demonstrate that their IMU code handles this very effect I just described. This effect not only applies to pitch axis, but the yaw axis as well.
The last "gem" I leave is one I got from Reed Christiansen, and I disclaim that in no way did he divulge any IP on the Kestrel autopilots... just some general advice on a couple high level questions I had for him. He asked me hypothetically: if my model was forced to use only gyro prediction to propagate the model (with accel measurements not added in at all) then how long does my IMU stay converged on reality? My answer at the time was "a couple seconds". His reply was "It needs to be at least 5 or 10 seconds... you need to have really low drift in the gyros". So I went off and analyzed my code. It turns out the numeric resolution I was using (integer math!!) was causing integer errors, or stated another way my number divisions were too coarse to keep track of the really fine gyro rates for really accurate prediction updates. I went off and increased numeric resolution by a factor of 256X, and this caused my gyro drift to go from 1 deg/s, to 0.4 deg/minute!
One more: all the centripetal effects in code can be safely tested by driving your car around. I did this with a laptop on the passenger seat showing virtual horizon of the AttoPilot GCS with the IMU on the floor. I got the code working so that in any turn or hitting the brakes the pitch and roll stayed true to the attitude of my car... not distrubed by the centripetal or acceleration forces. I leave to whoever is reading to go off and look in their high school physics books how to relate centripetal force to angular rates and forward speed.
@bcr: that's harsh. Dean's done some of the best work in this field and is an inspiration to all of us. Not everyone has to be open source to make a useful contribution. Even the high-level explanations he gives for his technique are helpful in steering our own course.
Bryan - I have been at home all week. If the caller ID looks like it is from a telemarketer or a business I don't generally answer. Maybe you called from work? I am still selling Atto v1.8!
Paul - my IMU code is not based on Mahony's estimator or any other code, papers, etc.. It is a 100% written from scratch method. The estimator is of course recursive, and blends prediction with accel measurements, heavily weighting towards prediction with just enough accel measurement blended in to keep the IMU model converged. There are oodles of special corrections and complications I take into account. The end result is my extimator cannot be confused by any type of motion that will be encountered in a fixed wing aircraft. Examples are inverted flight, spiralling dives, hairpin turns, etc. I have done all these motions in RC mode then immediately passed control to Auto mode and watched the plane immediately right itself and rejoin the loiter circle. I have also passed control to Auto while the plane (flying wing) is in the middle of a crazy maneuver, and same nice recovery.
Chris - True, thermopiles are so expensive that the MEMS IMU chips actually don't cost any more! The extra cost is in development and testing of the very complex code to pull it all off in a robust manner.
Jack - I started on the IMU route in January 2006 when I began this adventure. I had no concrete idea how to make an IMU work, but did understand crude basics of data filtering and how to integrate gyro rate to estimate position changes. As you would know, this is only about 2% of the way to a working IMU. I then shifted to themropiles so I could focus on all the other complex aspects of autopilot flight such as navigation, all the special trig involved, data logging, how flight plans work, airspeed control, power sensing, etc... IMU is just one tiny piece of the puzzle of an autopilot, so going to themropiles allowed me to keep the development pace very brisk. Over the last 2 years I slowly learned enough to write my own scratch-made IMU methods that totally suit my goals: something that can't get confused and quietly does its job so you don't have to worry or think about it.
Comments
Accelerometers & magnetometers add lots of stability but have lots of problems in high vibration helicopters, so if you can master pure gyro navigation you'll really be on the inside of the inside. Forget 10 seconds. Those ADXRS gyros go 10 minutes without significant heading drift.
It is sort of funny though: I spent weeks thinking through how the 3D rotation rates concisely and correctly equate to predictive updates to the attitude vectors in each axis. When I was done I had a group of 3 equations... lo and behold they are partial differentials and could be arranged in a matrix. What I had done is (without understanding matrix algebra conventions) developed the essence of what is behind the matrix of predictive update equations... nuts and bolts fundamental motion equations WITHOUT singularities (places where math infinities creep in and cause the system to have bad spots). Hell, my update equations don't even use any trig... they use the fundamental underlying notions underpinning triangle trigonometry (how X and Y relatate to the hypotenuse).
So while I won't publish code - I know from experience my comments will indeed be very helpful to many people that struggled with what I used to struggle with.
So the reason I say all this is to encourage people to not get stuck in fear like I had been for too long. If you look at a Kalman filter paper and don't understand matrix algebra then it is frightening to see all the symbols. However I do have a VERY solid understanding of statistics basics in an applied sense from my years of statistical work at Intel, so that is one strength I have that I might be under-estimating.
Chris is 100% correct that my work is closed source, but I do talk high level stuff often. So how about some peace offerings:
1) There is no Kalman anything in my IMU. You don't need it, so don't get hung up on it. Besides, it is not a black box or magic bullet... it is just a way to use statistics to optimally blend the prediction and estimate portions of the IMU. You can totally get by with a fixed weighting factor ratio between the gyro-driven updates to the model and the accel-driven measurements.
2) Taking into account centripetal forces is key. Don't just let the filter de-weight accelerometer updates when the accel starts showing things that don't agree with the current model, such as in a banking turn or when pulling up. Ignoring real affects and measureable forces is sloppy, and doing so hurts the IMU function.
3) You also need to be mindful of what happens in a continual banking turn. For example, normally you can look at pitch rate from the pitch gyro, and also look at a noisy estimate of pitch rate by differentiating pitch which was calculated by Atan2 of the X and Z accel axes. If you sum the error between the two methods over a huge number of samples, you can in fact determine if the gyro bias has drifted, by how much, and iteratively trim that axis gyro bias. You can even do something slightly fancier and check to see if the gyro scale factor needs trimming too. BUT - what happens in a constant banking turn of indefinate duration??? I'll tell you what happens: there is a NON-ZERO pitch rate (it is physically real) sensed by the pitch axis gyro (because the plane is pulling through a continual turn) HOWEVER the X and Z accel vectors aren't changing because in an ideal sense the nose is at a specific level and so is the Z axis vector. What does this mean for the differentiation of Atan2 of X/Z to determine wether or not the pitch axis gyro is in need of a bias update? Well, the X and Z aren't moving so they report a zero pitch rate which is in disagreement with the pitch gyro. This discrepency (if ignored) will make your pitch gyro bias get pushed away from true bias to the point where if somehow magically the plane could continue loitering like this, the pitch rate would apperently be zero according to gyro with now messed up and wrong bias. The loiter would go to crap. If on the other hand you know the Earth-centric yaw rate (heading change rate) and the IMU roll angle, then you can calculate EXACTLY how much of the pitch gyro is directly comparable to the atan2(X/Z) method, and your IMU code won't do wrong things to the pitch gyro bias.
Now that I'm on the "inside" with proven and robust IMU code that I 100% developed from scratch (and therefore understand on the deepest level), I know exactly why on the U-Nav website they made a point to show a video of long duration loiter of the U3500 with a plane... to demonstrate that their IMU code handles this very effect I just described. This effect not only applies to pitch axis, but the yaw axis as well.
The last "gem" I leave is one I got from Reed Christiansen, and I disclaim that in no way did he divulge any IP on the Kestrel autopilots... just some general advice on a couple high level questions I had for him. He asked me hypothetically: if my model was forced to use only gyro prediction to propagate the model (with accel measurements not added in at all) then how long does my IMU stay converged on reality? My answer at the time was "a couple seconds". His reply was "It needs to be at least 5 or 10 seconds... you need to have really low drift in the gyros". So I went off and analyzed my code. It turns out the numeric resolution I was using (integer math!!) was causing integer errors, or stated another way my number divisions were too coarse to keep track of the really fine gyro rates for really accurate prediction updates. I went off and increased numeric resolution by a factor of 256X, and this caused my gyro drift to go from 1 deg/s, to 0.4 deg/minute!
One more: all the centripetal effects in code can be safely tested by driving your car around. I did this with a laptop on the passenger seat showing virtual horizon of the AttoPilot GCS with the IMU on the floor. I got the code working so that in any turn or hitting the brakes the pitch and roll stayed true to the attitude of my car... not distrubed by the centripetal or acceleration forces. I leave to whoever is reading to go off and look in their high school physics books how to relate centripetal force to angular rates and forward speed.
Paul - my IMU code is not based on Mahony's estimator or any other code, papers, etc.. It is a 100% written from scratch method. The estimator is of course recursive, and blends prediction with accel measurements, heavily weighting towards prediction with just enough accel measurement blended in to keep the IMU model converged. There are oodles of special corrections and complications I take into account. The end result is my extimator cannot be confused by any type of motion that will be encountered in a fixed wing aircraft. Examples are inverted flight, spiralling dives, hairpin turns, etc. I have done all these motions in RC mode then immediately passed control to Auto mode and watched the plane immediately right itself and rejoin the loiter circle. I have also passed control to Auto while the plane (flying wing) is in the middle of a crazy maneuver, and same nice recovery.
Chris - True, thermopiles are so expensive that the MEMS IMU chips actually don't cost any more! The extra cost is in development and testing of the very complex code to pull it all off in a robust manner.
Jack - I started on the IMU route in January 2006 when I began this adventure. I had no concrete idea how to make an IMU work, but did understand crude basics of data filtering and how to integrate gyro rate to estimate position changes. As you would know, this is only about 2% of the way to a working IMU. I then shifted to themropiles so I could focus on all the other complex aspects of autopilot flight such as navigation, all the special trig involved, data logging, how flight plans work, airspeed control, power sensing, etc... IMU is just one tiny piece of the puzzle of an autopilot, so going to themropiles allowed me to keep the development pace very brisk. Over the last 2 years I slowly learned enough to write my own scratch-made IMU methods that totally suit my goals: something that can't get confused and quietly does its job so you don't have to worry or think about it.
Has Dean stopped selling Attopilots? We've been trying to reach him by e-mail and phone for the past week with no response.
Bryan
-
1
-
2
-
3
of 3 Next