UnderStanding IMU Physics

[fatal1ty89]

Hi Folks;
I'm a RC helicopter pilot and electronic engineer student.
I'm trying to do my UAV.
I need to understand the Inertial measurement unit physics and kalman filter. I have 3axis acceloremeter and xyz gyro.

Have you got any basic to pro document?

Thans in advance...

[jetblackaircra]

There are several posts on here already about this stuff. search for kalman filter.

[Nimski]

It takes a while to work through it, but this is all you need to know:

http://openuav.astroplanes.com/library/docs/attitudeKF_dev.pdf

For more goodies:

http://openuav.astroplanes.com/index.php?pageid=1

[jglenn]

Those are some very interesting links, but I ran into a weird problem when attempting to print out some pdfs. I have the program to do that, but it calls
up another site trying to sell me a $29.95 conversion program, and refuses to
let it print out. I rechecked my pdf printer, it works as long as I don't use that site. Hackers???

The math and computer resources to implement an IMU are rather staggering.
There has to be simpler ways to at least control a stable motor plane, not a flying wing or stealth fighter. Why use a sledgehammer, when a feather might work? :cool:

[rbeall]

hey man, I'm about a year a head of you and unfortunately there really is no simple answer. In short.... Yes you can simplify the calculations to run on 8bit uProcessors, No the math can't really be simplified. If anything it has to be all there or the filter will depart in all most anything other than steady level flight. I just finished flight testing an over simplified kalman and that's exactly what happed. On the bench it worked fine but once the Centripetal acceleration kicked in the excess acc kicked the filters a**! That pdf that was attached isn't all the information you need either. I sugest getting a prof to help you wiggle the math down to every last variable. A big part of it is simplifying the lines of matrix code in column form and only calcing the ones you use. The pdf kinda explains that. Honestly they do a lot of the math for you which is nice you just have to implement it in traditional Kalman form. Good luck man

[jglenn]

Thanks, I am not sure I want to try to make an IMU, just studying it.

What CPU are you using? Clock speed? Language? Have you considered
16 or 32 bit chips?

[dmgoedde]

On the bench it worked fine but once the Centripetal acceleration kicked in the excess acc kicked the filters a**!Ignore centripetal effects, then all you get is a table top demo.

If you want to use it in flight, have to subtract centripetal effects from left/right and up/down axes, and linear acceleration from the fore/aft axis. I heard someone erroneously state "my IMU's Kalman filter autmatically takes care of centripetal effects" when their OSD (a real product made by a real company) clearly shows it does NOT by the virtual horizon. What I think he meant was his filter de-weights the accel data when centripetal forces. I call this IMU-abuse... throwing in crappy data and assuming the filter will sort it all out. NO!! Stop IMU abuse. Take the accel data and subtract out centripetal effects! This leaves the attitude-only components of them. NOW you can play ball.

[jglenn]

Dean: is it practical to do this with an 8 bit cpu?

What about a magnetometer substituting for an IMU? I have stabilized the pitch axis with one, at first in just one direction (damn compass effect dogging my solution). The motor and mag field from the wires throw it off, but compensation can cancel. Everyone is trying to eliminate the thermopyle..

[eddymoore]

Yes, there are some IMU libraries floating around that run fine on, say, an AVR. Check out DIY Drones too, for some alternative methods.

Ed

[dmgoedde]

Dean: is it practical to do this with an 8 bit cpu?Some of the commercial ~$5k IMU autopilots use 8 bit CPUs, So yeah, it is doable. I myself got tired of 8-bit CPUs about 3 years ago, and left them for good.

[jglenn]

Thanks eddie and dean. An 8 bitter I'd guess would have to run pretty fast,
40MHz or more. Up goes the power consumption. Will look at all refs, but
the math already is pretty complex for an algebra and basic calc guy.

I am just trying to make a mild autostabilizer for a motor glider, no aerobatics.
Decided to try a mag sensor, one I have used for rocket tiltover sensing, but in the horizontal mode. The data is interesting and fragile, can give pitch data but also heading, which I don't need right now.

Question: the top line units have 6 DOF sensors plus the 3 axis magnetometer,
what do they do with the extra data? Is it fused or overlapped with the IMU?

[jetblackaircra]

The power consumption and equipment required for a badass processor is not that big of a deal. Get an ARM or some other awesome processor and don't worry about having to deal with 8 bit math again.

Dean,

I want to talk about the centripetal forces... In the example of a Kalman filter than Nimski posted they make the assumption that the vehicle is not climbing or decending, they assume angle of attack is equal to pitch angle (almost never a good assumption) and that sideslip angle is 0. Most full sized aircraft try to fly with zero side slip, but to assume it is always 0 is a dumb assumption. Is this kind of what you're getting at? The example does take into account, however, the centripetal forces on the vehicle from turning.

[rbeall]

Do you subtract them out with GPS and assume SOG is all in u (v & w ~=0) or do you use simplifications with airpseed and pitch angle?

[dmgoedde]

Dean,

I want to talk about the centripetal forces... In the example of a Kalman filter than Nimski posted they make the assumption that the vehicle is not climbing or decending, they assume angle of attack is equal to pitch angle (almost never a good assumption) and that sideslip angle is 0. Most full sized aircraft try to fly with zero side slip, but to assume it is always 0 is a dumb assumption. Is this kind of what you're getting at? The example does take into account, however, the centripetal forces on the vehicle from turning.I don't see any problems with climbing or descending, per se. You allude to the complications of angle of attack (aircraft attitude) being different than what I call the "climb attitude", which in my code is the angle the center of mass is moving through space relative to level flight, specifically solved by taking ArcSin(ClimbRate/Airspeed). You could also do ArcTan(ClimbRate/GroundSpeed) if there is no wind, but that is not a good assumption.
In my system, the IMU tracks raw attitude of the aircraft body, however this might be different than the climb angle. I believe this is called alpha? Anyway, there might be an error between the body attitude from IMU and flight level (from the ArcSin method above), thus my 5Hz nav code accumulates this error and computes a pitch bias. This pitch bias corrects for things like mis-alignment of the IMU in the aircraft (from installation or mechanical shift during flight) or rising/falling air columns.

Regarding centripetal effects, I assume perfect alignment between 3axis accel and 3-axis gyros, and therefore direct coupling between certain rate and corresponding accel axes. Thus, forward speed and angular rate on a specific gyro axis translates directly to an added centripetal force sensed by the accel axis normal to the rotation axis. Following simlifications of forward flight, I assume Z gyro rate (yaw) gives Y accel (left/right) centrip effects and Y rate (pitch) affects z accel axis (up/down) however rate on the X axis (roll) has no centripetal affect on Y or Z accel axes, because of the forward motion. To actually calculate how much centripetal force is present based on forward speed and angular rate, you need to recall the simple V^2/r relationship from simple calculus based physics in your B.S. program (or maybe high school), however V^2/r defines the problem in terms of a turn radius, not simply a forward speed and angular rate. I leave it to the reader to rearrange the equation for that.

Then in the fore/aft accel axis (X) there is no centripetal force, however there is a non-attitude component cause by changes in forward speed (linear acceleration). To get this accel value, you need to differentiate the forward speed. Airspeed is the way to go, not GPS. Airspeed data can be noisy, so a good math filter to clean it up helps.

So you take raw XYZ accel data, subtract the centripetal and accel effects that should be present (expected I should say) based on speed and angular rates, then viola you have an attitude-only components of the accel data, albeit VERY noisy as accelerometers tend to be noisy. NOW you can take this corrected accel data and inject it into your Kalman filter or whatever you are using to take gyro data and run the prediction cycles.

BTW - I wrote this over at DIY Drones but will state it again... I personally DON'T use a Kalman filter, nor do I know crap about matrix algebra. These things are NOT required to make a robust working IMU. However the required things you must understand are far from trivial, and there are not really any shortcuts in my opinion. For example, I just don't see a way to make a simple IMU for gliders... "Oh no, I just want to stabilize a glider but not flying wings!". I think that either all the important physics aspect are handled, or not. If not, then the system won't work properly even for a glider. It has nothing to do with how stable the plane is. The IMU must NOT lose its solution on attitude... it has to stay "converged".

You need:
1) 'matrix' (or set) of equations that can take the system state (XYZ attitude components, each can range from -1 to 1 g, but are orthogonal to each other and must "sum" to 1g total) and based on the 3-axis angular rates, predict forward in time (by a discrete step in time size) what the new state must be. I stated I don't know crap about matrix algebra formally, however when I derived a concise set of equations for this last year, it looks very much like a matrix. So, in practice I'd conclude that an understanding of matrix algebra just provides structure to it all. Maybe soomeday I'll learn it.

2) How to filter data to enhance signal/noise ratio

3) How to model a system as a series of discrete changes in discrete time steps.

4) How to code in serious constraints and general reality checks. This just has to do with keeping everything robust across all reasonable process space.

5) subtracting non attitude effects from accel data... generally you must have a physical model for what affects are dominant in your aircraft. for now, I am staying away from VTOL because I'm not sure yet how I would handle non-attitude affects.

6) Picking good sensors. There is no way I would ever pick the inexpensive LISYAL300 for instance. It would be fine for pitch and roll as these axes gyro drift can be tracked by the atan2 method using accel data, but not for yaw. It has lots of noise and drift compared to the Analog Devices gyros, and it lacks a temperature output. Temp output not required for pitch and roll, but for yaw unless there's a magnetometer on board, you don't have a good way to trim the yaw gyro bias with complementary data... can't use GPS because body heading and ground track heading don't agree unless there is no wind. The only good way I know for a 6 DOF IMU is to have a very clean yaw gyro (like ADXRS610) with onboard temp data, and have a multi-point bias table for the yaw gyro. If you go the 9 DOF route, then I suppose you could save $40 and use the LISYAL300 then.

7) How to track and correct for disturbances like gyro drift.

The reason I wrote I don't think a decent IMU could be made just for gliders is based on my personal experience. Back in 2006 I made a 5 DOF PCB similar to Sparkfun's (same chips, but mine had a ADC on the backside). This lacked a yaw gyro. Yaw data is required if you want to properly estimate forward in time what the latest state is. My crude IMU also lacked corrections for centripetal effects. What it did in flight was if already flying straight and constant speed, then it kept the plane going straight. If in a turn, it stayed in a turn even if I commanded a return to level (I had a Co-Pilot type code running). If I hit the thrust to accel forward more, then the thing would dive becase it though it was going into a positive incidence. What a mess. Totally NOT usable for stabilizing a UAV.

In contrast - skip forward to April 2009... here I am with a prototype full 6DOF IMU, and accurate temp-based bias curves for the gyros (I used dry ice and a hair dryer... captured cal data from -40 to +85C). I got centripetal and accel force corrections handled in my code, and fully verified by countless driving tests where attitude is displayed on my laptop as I drive. Taking sharp coners and the roll attitude stays 100% level. This is NOT a "Kalman Filter" weighting scheme whereby the filter somehow magically determines it needs to de-weight the accel. No, I am specifically subtracting out the non-attitude effect. Hit the gas or the brakes and pitch stays relatively constant as well. I go to do the first ever flight test (in a Spectra flying wing by RP Flight Systems), and what do you know - it worked perfect for a 30 minute flight, much of which was in a continual loiter. I repeated the flight for AltitudeAP the next morning, and he piloted the plane for several minutes in assisted-RC mode (like CoPilot type flight) where the IMU is in full control, or I should say the autopilot code is in full control of stability and 100% relying on the IMU to give an accurate attitude solution at all times.

[dmgoedde]

Do you subtract them out with GPS and assume SOG is all in u (v & w ~=0) or do you use simplifications with airpseed and pitch angle?I use airspeed. After all, the aircraft's reference frame and what it is pushing off of is the body of air. GPS is a weak way to go, because it only is correct if wind is 0, in other words it is still the aircraft airspeed that matters. This is one way my method differs from Premerlani's. I would assume he uses GPS just because his develoment board lacks an airspeed sensor.

If you look at the papers by the BYU guys, one of them discusses this and they used airspeed, NOT GPS speed. Besides, if you use GPS speed you'd also have to divide that by Cosine(Pitch) to convert flat ground-centric speed to body-centric speed (forward direction of the aircraft). It is not a good way to go, or not the best way to use GPS.

Also, GPS speed has some unspecified time lag. How much??? I don't know!

One drawback of using airspeed is if Pitot gets clogged... oops. I can guess that my IMU would freak out if nonsense airspeed data were injected into my IMU model.

[jetblackaircra]

Regarding centripetal effects, I assume perfect alignment between 3axis accel and 3-axis gyros, and therefore direct coupling between certain rate and corresponding accel axes. Thus, forward speed and angular rate on a specific gyro axis translates directly to an added centripetal force sensed by the accel axis normal to the rotation axis. Following simlifications of forward flight, I assume Z gyro rate (yaw) gives Y accel (left/right) centrip effects and Y rate (pitch) affects z accel axis (up/down) however rate on the X axis (roll) has no centripetal affect on Y or Z accel axes, because of the forward motion. To actually calculate how much centripetal force is present based on forward speed and angular rate, you need to recall the simple V^2/r relationship from simple calculus based physics in your B.S. program (or maybe high school), however V^2/r defines the problem in terms of a turn radius, not simply a forward speed and angular rate. I leave it to the reader to rearrange the equation for that.

Dean,

The problem I see with this is that the aircraft does not always move in a circular path when an angular rotation is present. For instance, if the aircraft encountered a headwind gust and pitched nose down to maintain level flight. There would be a momentary nose down rotation rate, but no accompanying acceleration in the Z axis like there would be if the airplane began to dive.

By the way,

Alpha is angle of attack, the angle between the relative wind and the chord line of the wing, and is totally seperate from pitch angle which is what the IMU should be measuring. For example, the aircraft could be in a steady climb with 0 angle of attack and a pitch angle of 10 degrees nose up. If you are using the angle given by ClimbRate/Airspeed as your pitch angle, then you are not measuring pitch angle. An extreme example of the difference would be when the airplane is in a tail slide. The nose is pointed straight up and the angle given by ClimbRate/Airspeed is straight down.

In truth, a true IMU should not need airspeed input. The Kalman filter, however, adds a bit of redundancy and robustness by using both GPS groundspeed (and ground track) and vehicle airspeed to reduce error in the IMU vehicle speed which is calculated using the accelerometers. A side effect of using the Kalman to do this is that you end up being able to easily calculate wind speed and direction. These two variables become vehicle states which are used to estimate the movement of the vehicle.

[dmgoedde]

Dean,

The problem I see with this is that the aircraft does not always move in a circular path when an angular rotation is present. For instance, if the aircraft encountered a headwind gust and pitched nose down to maintain level flight. There would be a momentary nose down rotation rate, but no accompanying acceleration in the Z axis like there would be if the airplane began to dive.

By the way,

Alpha is angle of attack, the angle between the relative wind and the chord line of the wing, and is totally seperate from pitch angle which is what the IMU should be measuring. For example, the aircraft could be in a steady climb with 0 angle of attack and a pitch angle of 10 degrees nose up. If you are using the angle given by ClimbRate/Airspeed as your pitch angle, then you are not measuring pitch angle. An extreme example of the difference would be when the airplane is in a tail slide. The nose is pointed straight up and the angle given by ClimbRate/Airspeed is straight down.

In truth, a true IMU should not need airspeed input. The Kalman filter, however, adds a bit of redundancy and robustness by using both GPS groundspeed (and ground track) and vehicle airspeed to reduce error in the IMU vehicle speed which is calculated using the accelerometers. A side effect of using the Kalman to do this is that you end up being able to easily calculate wind speed and direction. These two variables become vehicle states which are used to estimate the movement of the vehicle.I'm saying all this stuff with confidence because my IMU is proven is many many flights now with 2 small and astable airframes... I'm not manufacturing facts, or too stuck on how it 'should' be with 2nd order effects slowing me down. I think maybe you are developing a larger IMU autopilot, based on a single board computer, intended for larger UAVs? I'm focusing on the spirit of very small autopilots built using limited RAM and small microcontrollers... like the now-current sub-$10k systems.

I'm also not revealing complete detail on how my IMU works. There are corrections and things that were hard-won by lots of cursing and trial and error, are critical for real success, and I am not going to divulge publicly.

You are correct, though I think being too much of a purist here (for what my goals are). When rotation happens on an axis, the aircraft will NOT cut through the air like it is on rails. It will "slosh" through the local air, a type of high-alpha manuever. There is also the effect of simple translational motion, say in the Z or Y axis caused by turbulence (buffeting), and these cannot be accounted for as centripetal effects. There are ways to compare the centrip-corrected attitude-only portion of accel data, and if it is more than "X" amount away from 1g, then there must be some non-centrip and non-attitude effect happening, so then the code can de-weight accel input into the filter, so as to not inject in nonsense.

Sure - you can point out that what I wrote is not the complete story, or simply too simple to be 100% accurate. Yes, there are times when body rotations don't cause centrip effects. >>> On the other hand, a very common mistake would be to ignore centrip effects, and say "hey, the glorious Kalman filter will magically handle the complications"<<<


In truth, a true IMU should not need airspeed input.I couldn't disagree more. Sure, for a table top demo. In a real flight, why would you inject accel data into the IMU model if the accel data is a mixture of attitude and other forces? Maybe your filter is providing airspeed estimate based on ground track heading and GPS speed. I can do this easily offline in Excel with Atto data, but have yet to put the effort into real-time computation of it.

The reason I brought up the pitch bias thing - my 130/520 Hz IMU models pitch WITHOUT the alpha corrections at that level of code. But the 5Hz Nav loop handles alpha corrections using barometric and airspeed data. This is done for solid altitude control under varying conditions. When I said "pitch" I meant IMU attitude pitch, distinct from Alpha. The Nav loop calc's a pitch bias to account for alpha, so that the UAV can achieve well-trimmed level flight centered on altitude target, not persisting at some error offset. This is very much like I of PID: integrating error over a time period, then calc'ing a trim offset.

[jetblackaircra]

Our IMU is based on an ARM 7 processor, our single board computer is only to handle our streaming video and wireless telemetry.

With enough trial and error you could make an "IMU" that gets close to the desired result of making an airplane fly without being anywhere close to an actual IMU. A perfect example of this is your thermopile autopilot. If it weren't for the problem of thermopiles needing a heat signature from the horizon to give you an idea of where down is, you've got a great autopilot there. Like I said before, the trick is knowing where down is. And with the right sensors and a lot of trial and error you can know where down is.

What I meant by a true IMU doesn't need airspeed as an input is that an IMU by definition is a system that using only inertial sensors gives orientation and position. So, you should be able, using only inertial sensors like accelerometers and angular rate gyros, know position and orientation (heading, elevation angle, and bank angle) without knowing any other input like airspeed (which is really arbitrary for the purposes of vehicle navigation). Imagine taking your IMU, not installed in an airplane, and allowing several people to play catch with it. So it will tumble and travel all over the place, most of the time not experiencing the gravity vector (due to being in a ballistic trajectory) and still know where it is relative to it's starting point and how it is oriented relative to it's starting orientation. That is a true IMU. You add a GPS to it and you get an INU. Inertial navigation unit.

If you had perfect accelerometers and perfect angular rate gyros, with no drift and no error, you wouldn't need any other sensors to know where you are and how you are oriented. The trick is figuring out a way to use the gravity vector to correct for drift and error in the gyros (orientation) and to use GPS to correct for drift and error in the accelerometers (position). Or, to use a combination of those signals to minimize error and determine where the vehicle is and how it is oriented.

We have been concentrating on making sure that no matter what type of aircraft (or vehicle, or whatever the thing is installed in) the IMU is able to robustly maintain a fix on it's position and orientation, and the Kalman filter, when properly implemented can do this.

By the way, you mentioned you are running your sensor loop at 130Hz and your calculation loop at 520Hz. How do you gain anything by running your computations faster than your sensor updates? When the sensor values don't change, neither does the math. It'd be like saying every five seconds my bank account gets an extra dollar, but I'm going to add 20 cents every second instead. If you can, I'd try using that extra processor time to increase your sensor loop frequency and make your calc loop the same speed as your sensor loop. Although, I must say, 130Hz sensor loop is plenty fast.

What kind of processor are you using?

Oh, and I feel compelled to say this... when properly implemented the Kalman filter does handle centripetal forces when not subtracted from sensor input. Think of it this way... you have an IMU where you are subtracting the centripetal forces from the accel data, and you make it move at 100 mi/hr in a straight line while it spins at 100 rev/min but not turning. Since you are subtracting centripetal accelerations which are not actually being applied to the IMU, you are causing a false signal which the software will have to account for. The same is true if you have an IMU which does not subtract centripetal accelerations and you make it move in an arc similar to an aircraft turning. There are accelerations which are not being accounted for. The idea with a Kalman filter is that you have a system model which is not always accurate, but it is accurate most of the time. It uses that system model to determine which sensors are most likely to be accurate. So, when the system is steady state the accelerometers are going to be able to tell you which way is down. When the system is turning, climbing, decending, rotating, tumbling, whatever, the rate gyros have the best idea of how the vehicle is oriented because there are disturbances in the other sensor data. You don't have to use a Kalman filter to determine which sensors to trust, but the Kalman filter statistically finds the solution with minimal error. That is what it's designed to do.

[jglenn]

Question on this:

**The trick is figuring out a way to use the gravity vector to correct for drift and error in the gyros (orientation) and to use GPS to correct for drift and error in the accelerometers (position). Or, to use a combination of those signals to minimize error and determine where the vehicle is and how it is oriented.**

Could you use the Z axis accel sensor to detect when you are flying close to
level, and null out the gyros?

Dean is using the Parallax Propeller, has eight 32 bit CPU's.

Another viewpoint of the Kalman filter, I am not a math or physics whiz, but
have seen an app in the amateur rocketry field. It is a puzzle to use baro
or accel data to properly fire the apogee recovery system, on a high speed,
heavy rocket, this is critical, as too early or late can tear things up.

Every company has their own method, but a guy won the National Meet R&D
event a few years ago by feeding data from altimeters into a PC based Kalman filter, which no altimeter had been using at that point. He found that
everyones threshold software was not optimum, the Kalman could "predict" the optimum point better. I see it as a kind of artificial intelligence, a brain. ;)

Jetblack: why can't one use just a magnetometer for a casual glider control?
If you don't need to get radical on manouvers, you may not need all the fancy realtime inertial data. I have a plane I can launch at any angle including straight up, and a field sensor moves the stabilizer to put it into a glide, everytime. Well at least in just one direction so far. I have no accel or gyros, and just a crummy pic chip running assembler.

[dmgoedde]

ARM7 - is that 130 MIPS and 32 bit? As I stated before, I'm using the 32 bit 160 MIPS 8-core Prop chip by Parallax Inc.

I'm not sure what authority you think you have stating what is and is not an IMU. How is your IMU autopilot flying these days? Have you proven it with several hours of flight, including 30 minute continual loiters and recovery from 3-D aerobatics? If it uses at least 6 DOF accel/gyro sensors (and maybe 3 axis magnetometer) then it is sensing intertial effects to keep track of "down", and it is an IMU.

IMU <> Kalman Filter. Ask Reed Christiansen of Procerus. He and I had a 2 hour phone chat sans NDA, but still talked lots of shop. Of course I didn't tell him my secret stuff, nor did he. Last I heard, Procerus makes money, and everyone respects the Kestrel.

I was very very complete chatting with Jack Crossfire on my thread regarding the 130Hz/520Hz of how my system works. You can go read my thread.

YES - my IMU code:
1) uses differentiated accel attitude data to track and trim pitch and roll bias

2) uses 20-points temp curve to track yaw bias (because my current unit lacks megnetometer and I don't trust GPS for yaw bias correction)

3) main loop at 130 Hz where the measurement updates (accel input) go into the model, however the prediciton cycle is broken into 4 sub steps because the 3-D roations are partial differentials in which individual axis rotations are not commutative (different order of operations gives different final states) plus the equations modify the states but also rely on the states, so it is like a circular reference... an iterative process. Breaking it into 4 sub steps at 520 Hz keeps nonlinearity on the process under control

4) Normalizations are applied at each time step to keep the 3-axis attitude vectors of the model at 1.0g total.


My IMU development status is NOT focused on code or approach to the problem, I am scrambling to make more prototypes because Sparkfun sent me the IDG-1215 (67 deg/sec) instead of what I orderded (IDG-500, 500 deg/sec, dual rate in fact). Funny thing: the pinouts are close enough so that my proto circuit worked! However in my snap roll mauevers of the little Funtana X, the roll axis gyro maxed out and coming out the plane recovered to correct pitch but roll about 20 deg behind. The IDG-500 would have tracked rotations through the maneuver.

[Nimski]

In truth, a true IMU should not need airspeed input.


I couldn't disagree more.

Can you elaborate on that please? We currently use an industry standard IMU with exceptional performance, and it has no idea it is on a plane, let alone inputs of airspeed, etc.

I think understand what you're saying, that if you have 3 axes of acceleration sensing, you need to know the centripetal acceleration vector so that you can extract the gravity vector, so you compute the acceleration using the airspeed and angular rate (and calculating the radius from those two), but airspeed is also relative to the wind, so your centripetal acceleration is a guess at best?

However what you could do, is say:

a is proportional to w^2 (assuming r is constant)

so if you have 3 axis of acceleration, and their |length| is not exactly (9.81) you can create a vector that when added to your acceleration vector, will correct it to 9.81. But there are infinite permutations, so how do you know the components of this "correction vector"? You assume the components are proportional to their respective angular rates (w^2, to be more precise), and then you have as good a guess as if you fed airspeed into the IMU directly.

[clolson]

Hi Dean,

If I gave you a sequence of gyro/accelerometer readings and a matching sequence of gps readings, would you be willing to run it through your IMU and send back the matching sequence of roll/pitch/yaw and lon/lat/elev estimates? We are starting to work on some IMU algorithm benchmarking tools. :-) Anyone else? The more the merrier. :-)

Here's a couple random IMU related comments ...

1. The gold standard for mems sensor based IMU's seems to be the Microbotics MIDG-II ($6750 last time I got a quote.) That is what the following movie was generated from. You can see how the yaw estimate converges pretty well with the aircraft's true yaw after a minute or two of flight ... despite some arbitrary cross winds. (This is a manually flown flight with the IMU just acting as a passenger collecting data.) The biggest challenge in IMU algorithm development is knowing the true attitude and location versus your IMU's estimate. A camera is a poor truth reference in the sense of not being able to compute actual error values, but it's a great tool for a basic sanity check. If the IMU estimate wiggles when the camera wiggles and the IMU estimate can be used to generate a pure synthetic view that matches the camera view pretty well, then you know you are at least in the right ball park

http://www.youtube.com/watch?v=SAMGnK9ztdA&feature=channel_page

Just for fun, here's a 2nd varient of the same raw footage (the two video streams were edited together later.)

http://www.youtube.com/watch?v=RgK1019Bjno&feature=channel_page

2. I've flown many hours of autonomous flight (some of that entirely over ocean) with an ARHS/Navigation algorithm developed for use with the Xbow MNAV by an engineer at Xbow. This is open-source code and pretty simplistic, but it actually does a nice job at getting an aircraft around the sky with the exception of some pitch error through turns (so we've used some other tricks to make sure we can maintain our set altitude through turns.) It is a very light weight algorithm in terms of computational power so despite it's limitations, it might be attractive for someone with less compute power at their disposal. (My entire autopilot application doing everything including the ahrs/nav consumes about 2% of a 400mhz ARM7 based gumstix.)

3. It's my understanding that the procerus kestrel autopilot uses inertial sensors, but isn't a full kalman filter implementation and is more of an adhoc collection of things. It's well respected in the sense that it's an effective autopilot and does a fine job at getting an aircraft around the sky. I don't intend to say or imply anything critical here, but I don't think it benchmarks all that well against something like a MIDG-II.

4. Just to throw in a me-too ... here at the U of MN Aerospace Engineering dept we are adapting a full INS/GNS algorithm (developed in matlab by one of our professors), then hand ported to C to run in real time on an embedded CPU. It's a bit heavier weight than the MNAV ahrs/nav algorithm. Right now when the algorithm runs at 50hz it is burning about 30% of a 400mhz ARM7 (gumstix) cpu, but that still leaves a lot of CPU for everything else. This will be released as open-source and our implementation will be integrated with my MicroGear autopilot application. We have the basics working, but need to do a bit of clean up and a tiny bit of rework before we are ready to try using it for autonomous flight.

Sorry Dean, you aren't the only one that gets to have all the fun. :-)

Curt.

[dmgoedde]

Can you elaborate on that please? We currently use an industry standard IMU with exceptional performance, and it has no idea it is on a plane, let alone inputs of airspeed, etc.My comment about using airspeed was aimed at an attitude by Mike. I really want people to realize that if they add a $15 diff P sensor and calc airspeed, then centrip forces are trivial to subtract from the accel data, and limit injecting too much crud into the IMU filter. If you go the GPS route, then it take a big hairy model to tease out the data. There are excellent papers on IMUs in small MCUs by the BYU guys.

How big is your "industry standard" IMU that does not require airspeed? Can the code be run on just 20 MIPs in a small MCU, run at a fast update rate, and still stay well converged?


I think understand what you're saying, that if you have 3 axes of acceleration sensing, you need to know the centripetal acceleration vector so that you can extract the gravity vector, so you compute the acceleration using the airspeed and angular rate (and calculating the radius from those two), but airspeed is also relative to the wind, so your centripetal acceleration is a guess at best?You can rearrange the V^2/r so that the two inputs are simply V and rotation rate. This is trivial: speed in m/s * rate in radians/sec, and if you want the acceleration in g's then divide by 9.81m/s^2.

Relative not to wind... relative to the reference frame that the aircraft is moving in, namely the air. Airspeed of the aircraft. If we assume that more or less the aircraft tracks with the air and rotation rates with forward speed give centrip effects, it is the air that the plane banks off of afterall. whe nI did my initial centrip testing I drove around in my car, happily using GPS ground speed because THAT is the reference frame my vehicle was moving in.


But there are infinite permutations, so how do you know the components of this "correction vector"? You assume the components are proportional to their respective angular rates (w^2, to be more precise), and then you have as good a guess as if you fed airspeed into the IMU directly.It is very simple and practical for several reasons:

1) assume forward speed, in the "X" axis.

some symmetry and orthogonalness of the axes of gyro and accel helps out:
2) Z rate (yaw) causes centripetal force in the Y axis (left/right)
3) Y rate (pitch) causes centripetal force in the Z axis (up/down)

Need to also correct for non-attitude effects on X axis:
4) differentiate the airspeed to get linear acceleration rate in X axis

5) In the end, all the rigamarole to clean up accel data is only a tiny part of it. The filter is very heavily weighted towards gyro data to continually estimate forward in time the new attitude states.

When I stated that I don't use a Kalman filter, what I meant is I have a fixed ratio for the amount of accel data (measurement update) that is injected into the model at each iteration. At 100:1 gyro predict:accel measure I get excellent convergence and error is kept very low while rejecting injecting in Accel noise into the model. I have also flown with 500:1, and done table top demos at even 5000:1 fixed ratio.

Of course I am using accel data to keep error at bay and model converged on reality. Of course I use accel data to track and trim gyro bias. And of course I have a robust estimator with complete matrix of strapdown equations that I developed from scratch. The only thing I decided NOT to use is a Kalman filter to dynamically weight the predict and measure cycles based on statistics... so in reality I am not using a fully optimal blending, however at 100:1 it stays really well converged and relatively noise-free at the same time.


Mike
1) I simply take issue with the mistaken idea that some people have that Kalman filter is magic, or that it is required for a "real" IMU. Sorry if you don't agree.
2) Sounds like you are building a full INS. I'm just shooting for a robust AHRS with the initial 6 DOF IMU. If I really wanted to do an INS and do dead reckoning for extended time periods, I would add a magnetometer and have a 9 DOF IMU/INS.

All this talk from my side is 'after the fact' of many many hours of flawless IMU flight in flying wings and relatively astable 3D aerobat plane. I'm just recanting why my system works, not getting caught up on what 'should' work. If I sound cocky, I don't mean it that way. I am by no means an IMU ultra-guru, but I do know more than enough to develop this sort of stuff from scratch, and keep the system well constrained, runable in just a few MIPS

[jetblackaircra]

Dean,

Do you not understand what I'm saying about calculating centripetal acceleration? If you need to do that to make your IMU work, you're cutting a corner that might make your IMU not as robust as some. I realize you've had some flight tests that have shown good results. I'm not saying there is only one way to make an airplane fly with accelerometers and rate gyros.

Like I said before, there are ways of using intertial sensors to find the orientation of a vehicle without using a Kalman filter, but using a Kalman filter correctly will do it better. This has been mathematically proven.

Nimsky is correct. An IMU does NOT need airspeed as an input. It should calculate it's own speed relative to it's initial or start up speed by integrating the acceleration signal over time. If you wish, you can use airspeed to correct for drift in inertial speed due to sensor error.

Once again, with perfect sensors, this would all be a moot point. You would simply integrate a bunch of sensor values until you get the state variables you want to use. But sensors have defects which cause error in the signal. That is why we must filter the data. The kalman filter uses a system model which dictates how the state variables (position, speed, acceleration, pitch, roll, and yaw) are related to sensor inputs. These are pure physics relationships and have nothing to do with the IMU being in an airplane traveling through air.

I'm not saying a Kalman filter is magic, obviously it is a tool just like any other piece of code, made to do a specific task. All I am saying is that it has been mathematically proven to provide a more accurate estimation of a system than any other type of filter. You might be able to create an algorithm that gives a good idea of the vehicles attitude for most operating conditions without a Kalman filter, but there will be circumstances in which the algorithm shows a significant error.

I give you this challenge, toss your IMU up and down and allow it to rotate during freefall. This will require the IMU to use only gyro input for rotation during freefall since gravity is no longer being sensed. See if your IMU handles that situation.

[dmgoedde]

Hi Dean,
If I gave you a sequence of gyro/accelerometer readings and a matching sequence of gps readings, would you be willing to run it through your IMU and send back the matching sequence of roll/pitch/yaw and lon/lat/elev estimates?Right now, in my multi-core approach, the AHRS runs in one core and tracks 3-axis attitude, and Earth-centric heading and yaw rate, in addition to the body-centric 3-axis gyro rates. The full INS type stuff is not part of the model; I don't (yet) inlcude estimates of Lat and Lon. That just comes from the GPS. If I was currently tracking lat and lon as a more complete INS, then I could run your data. Oh yeah, and if I had time also. I wish I had more time.

2. I've flown many hours of autonomous flight (some of that entirely over ocean) with an ARHS/Navigation algorithm developed for use with the Xbow MNAV by an engineer at Xbow. This is open-source code and pretty simplistic, but it actually does a nice job at getting an aircraft around the sky with the exception of some pitch error through turns (so we've used some other tricks to make sure we can maintain our set altitude through turns.) It is a very light weight algorithm in terms of computational power so despite it's limitations, it might be attractive for someone with less compute power at their disposal. (My entire autopilot application doing everything including the ahrs/nav consumes about 2% of a 400mhz ARM7 based gumstix.)My method specifically handles a few complications that arise in continual turns, so the pitch and everything else tracks right there spot-on 100% no matter what is going on. I stumbled across some subtle effects, and devised an elegant vector-based method to ignore certain components of motion, or I should say subtract them out.

I am very interested in benchmarking my IMU results against any data you have.

[wadiprawita]

Thank's Dean

learn many things from your post

regards

-doni-

[danidanko]

here is something I made with some code I found on kalman filter

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

[rbeall]

Dean, the assumption that "air is the frame" i'm flying in so i use airspeed, is inacurate. The IMU is always measuring accelerations in EFEC inertial frame. u-dot,v-dot,w-dot. Using airspeed as an approximation works so well because wind is not a large factor and the airspeed sensor has a whole lot higher bandwidth. It is nothing more of an aproximation which uses a better sensor. You can also use h-dot (vertical speed) to clear up some of the u-dot under estimations. But this is still just an estimation that uses a better sensor than GPS.

If you are subtracting out centripetal what needs to be subtracted out? "elegant vector-based method to ignore certain components of motion"? unless the airspeed estimation isn't quite estimating the acceleration in the turn accurately....errr feed forward theta from phi...or is that too much

[dmgoedde]

I give you this challenge, toss your IMU up and down and allow it to rotate during freefall. This will require the IMU to use only gyro input for rotation during freefall since gravity is no longer being sensed. See if your IMU handles that situation.Yes - no problem. Tested, works fine.

This is why:
1) My code is already heavily weighted towards gyro predictions in each iteration cycle. 100:1
2) My code de-weights the accel input depending on how far the centrip-corrected accel total force vector falls away from 1.0000 g. If the total Accel component is 1g, then the gyro/accel weighting ratio is 100:1. This is the max amount of accel input into the model. I happened to chose it such that over a +/- 0.5 g range around 1g (from 0.5 to 1.5) the weigting proportionally fall off to nothing. For example, if accel force works out to 0.75g, then my IMU 'knows' that some non-attitude and non-centrip effects are present (could be translational buffeting in the Z or Y axis... like you brough up before: not always does rotation and forward speed = centrip effetcs), so in this case the gyro predict : accel measurement inputs to the model for that iteration step would be 200:1. If total accel force is 0.6g (or 1.4g) then weighting is 500:1.

In the case of a free fall, accel measures 0 g, and my model would be 100% only gyro predictions in the updates. On the other extreme a violent jolt of 3 or 4 or 5 g that can't be accounted for by centrip effects would also cause the IMU to rely 100% on gyros.

Because my yaw gyro drift is temp-compensated to better than 0.04 deg/sec, and the pitch and roll are auto-trimmed for bias using accel data, all 3 axes gyro are always well trimmed. My IMU can tolerate prolonged durations of free fall or other situations where accel data is mostly nonsense or no help with attitude.

But why trust what I say??? It is time for another video demo.

[dmgoedde]

Dean, the assumption that "air is the frame" i'm flying in so i use airspeed, is inacurate.It has error, but by and large is better than ignoring a non-attitude component of the accel data, AND the errors over long times integrate close to zero. Besides - let be clear here... accel data is just for long-term constraining of error. The main driver of IMU iterations is the gyro-based predict portion.

If you are subtracting out centripetal what needs to be subtracted out? Why isn't this clear? The start of your sentence answers the question. Accelerometers measure just raw accel forces. This means it is a combination of attitude and non attitude forces. Non attitude forces are things like centripetal force, and changes in translational speed along an axis (aka linear acceleration). Attitude component is simply 1g * Cos(theta), where theta is the angle between the axis in questions and a line from center of the IMU and center of the Earth.

BTW - NOWHERE in my block of strapdown equations is there anything as simple as a naive "Cos(theta)".

"elegant vector-based method to ignore certain components of motion"? unless the airspeed estimation isn't quite estimating the acceleration in the turn accurately....errr feed forward theta from phi...or is that too muchNope - there is a component of rotational motion in the body-frame (observable to the 3-axis gyro sensors) while the UAV is in a banking turn, BUT does not equate with a change in sensed attitude components. In a coordinated turn, there is some balance between continuous pitch rate and yaw rate, yet neither X, Y, nor Z attitude components are changing.

My set of 3 strapdown equations that calc dX/dt, dY/dt, and dZ/dt aren't the thing that needs this subtle correction I am alluding to and called "elegant". The elegant thing I found has to do with knowing how much of the actual gyro rates can be tracked (compared against) the rate found by differentiating angles found by atan2(X/Z) and (Y/Z) for purpose of trimming pitch and roll gyros. If a person were to blindy integrate error between gyro rate and rate via atan2(X/Z) for pitch while in a turn, certain problems arise. Pitch rate is actually non-zero (depending on bank angle and other things) BUT neither X nor Z are changing. This leads to the problem that atan2(X/Z) method to get pitch rate from accel data comes up as 0 rate, however pitch gyro senses a real rate. There is now falsely calculated an error, and then the pitch gyro bias will be trimmed based on wrong data.

I am guessing THIS is why Curt Olsen mentioned he has seen some IMU have pitch estimation problem through turns. OF course... if you jack with the pitch bias and make it wrong, then the IMU model will pull away from reality as the incorrect pitch rate injects error into the prediction cycle.

I say if a factor is observable, then subtract it out. Clean things up as much as you can. My IMU is NOT based on Kalman filters, but I do rely heavily on gyro-based predictions, trim biases, use accel to constrain error as a very low pass filter, etc... I also handle all possible motion complications with some simplifications for fixed wing aircraft, and have provision for variable de-weighting of the accel data based on how 'trustable' it is.

What more is there to do?

Mike - how accurate do you know the relative variances of your data sources? Is your Kalman truly optimal? When I use words like 'elegant' I generally mean that there is stuff going on that 1) far as I know I discovered from scratch - or at least I never heard of it before, 2) it cleanly solves a problem, or 3) I'm not going to give explicit details.

[jetblackaircra]

Dean,

You seem to get defensive when people ask you questions about your products. I mean no harm, just discussing....

Oh just FYI, rate gyros and accelerometers I'm using are all temperature compensated from the factory from -40C to +85C. How are you calibrating yours? From the factory or testing and a calibration table? The testing required to calibrate rate gyros is pretty intensive.

[Nimski]

Accelerometers measure just raw accel forces. This means it is a combination of attitude and non attitude forces. Non attitude forces are things like centripetal force, and changes in translational speed along an axis (aka linear acceleration). Attitude component is simply 1g * Cos(theta), where theta is the angle between the axis in questions and a line from center of the IMU and center of the Earth.

BTW - NOWHERE in my block of strapdown equations is there anything as simple as a naive "Cos(theta)".

I don't think the question is ignoring non-attitude components at all, that is necessary for a properly functioning IMU, the question is the way you determine these non-attitude components, and whether or not airspeed is necessarily the best way to do it.

[rbeall]

Thanks Dean, I completely get what you are driving at. Did you use the equations for q and r subtractions or just get a general feel for the numbers vs phi? I guess both approaches should present the same solution. I'm interested to see now. Can't believe I missed this! I am basically running the same type of filter but just now starting to add in all the frills. Thanks!

[fireisborn]

Dean,


In truth, a true IMU should not need airspeed input. The Kalman filter, however, adds a bit of redundancy and robustness by using both GPS groundspeed (and ground track) and vehicle airspeed to reduce error in the IMU vehicle speed which is calculated using the accelerometers. A side effect of using the Kalman to do this is that you end up being able to easily calculate wind speed and direction. These two variables become vehicle states which are used to estimate the movement of the vehicle.


This is True - An IMU + GPS = attitude and position in a dynamic situation. Throw in a compass and you get a full attitude solution in a static situation as well.

The compass is needed in non-accelerating flight because psi, or vehicle heading is not observable without body accelerations.

Using airspeed and some gyros is an easy way to observe bank angle without coupling to a gps, however it relies on airplane coordinated turn kinematics - hence it is not vehicle independent.

By coupling the IMU to a GPS, you get a true vehicle independent attitude solution - including true vehicle heading (not just ground track). The filter will basically align the GPS acceleration vector with the body accelerations sensed by the IMU. The quaternion at which they align is the attitude solution.


If you are only going to be flying on airplanes and you are CPU/memory limited , the airspeed trick is a great way to get the job done without allot of hassle.

[reedchristiansen]

3. It's my understanding that the procerus kestrel autopilot uses inertial sensors, but isn't a full kalman filter implementation and is more of an adhoc collection of things. It's well respected in the sense that it's an effective autopilot and does a fine job at getting an aircraft around the sky. I don't intend to say or imply anything critical here, but I don't think it benchmarks all that well against something like a MIDG-II.


Curt.


Curt,
Glad to hear the flying and simulating is going well. Give us a call sometime to catch up, or we'll see you at AUVSI this year.

You need to get your hands on one of the new Kestrels. 500 Mhz 32 bit DSP, running the full integrated attitude/position solution. I think it will give the MIDG-II attitude/position estimate a run for it's money and then some - And it will fly your airplane or helicopter to :)


In the spirit of this thread, I guess I should use the prase "Kalman Filter". The Kestrel 3 has a 17 state loosely coupled GPS-INS Extended Kalman filter.

Reed

[airmcn_3]

Curt,
Glad to hear the flying and simulating is going well. Give us a call sometime to catch up, or we'll see you at AUVSI this year.

You need to get your hands on one of the new Kestrels. 500 Mhz 32 bit DSP, running the full integrated attitude/position solution. I think it will give the MIDG-II attitude/position estimate a run for it's money and then some - And it will fly your airplane or helicopter to :)


In the spirit of this thread, I guess I should use the prase "Kalman Filter". The Kestrel 3 has a 17 state loosely coupled GPS-INS Extended Kalman filter.

Reed



Reed,

Very nice!

[mlbco]

Dean,

I'll accept your invitation to show IMU performance data. I'm not an amateur since I have a business that sells products, but I did develop all IMU and flight control code for my UAVs, mostly out of my own pocket before anyone ever bought a product from me.

My latest flight computer (see attached photo) has several boards stacked together. The CPU is based on a Texas Instruments DSP chip which is very fast for floating point operations. The other boards contain 3 axis gyros, 3-axis accel, 3-axis magnetometer, 4Hz GPs, baro, airspeed, temperature, RPM, fuel,etc.. sensor stuff, servo interface, and there is also a DC-DC power distribution board and 1 watt telemetry modem in the stack. The size is similar to a Cloud Cap Piccolo 2. The code is written in C++ and I'm running all loops at 100HZ.

The attitude estimator is a linear filter, which is like a complementary Kalman filter with fixed gains. Attitude values are extracted from an estimate of the complete direction cosine (DC) matrix. In other words, I estimate all 9 terms of the DC matrix using a linear filter and then extract Euler angles or quaternions, or whatever I want from the DC matrix. This avoids any singularity problems in the transforms.

The complementary filter adjusts the attitude estimate from direct gyro integration using an estimate of gravity that comes from the accel's (minus the centrifugal terms) and an estimate of heading from the magnetometer. I won't go into the math, but you can use the raw sensor values to build up a DC matrix to compare with the direct gyro integration results. I do not use any linear accelerometer corrections. All centrifugal effects are estimated using airspeed and gyro readings. I don't use GPS for any attitude estimation because I want an IMU solution unaffected when GPS is lost. I retain all of the accelerometer tilt effects so that the system estimates correct roll, pitch, and yaw when rotated without any velocity.

The linear filter is adjusted to weight the gyros more than the accel's and therefore shows little sensitivity to linear accelerations unless they last for relatively long periods of time. I do not use an Extended Kalman Filter (EKF) because I'm not smart enough to write a robust EKF that I trust and I haven't found the need for it yet.

My autopilot has successfully flown many fixed wing UAVs and hovering aircraft, including a tail-sitter UAV.

The figures below show the variation of theta (pitch) when the IMU is accelerated back and forth +-0.5 g at 1/2 HZ. The theta error is +- 1.5 deg in this case. Also shown is the theta errors (negligible) during an 8-g catapult launch. The error during the launch is small because the duration of the 'g' is short, where as the bench test case was purposely chosen to have longer duration of 'g'.

Steve

[dmgoedde]

Dean,

The attitude estimator is a linear filter, which is like a complementary Kalman filter with fixed gains. Attitude values are extracted from an estimate of the complete direction cosine (DC) matrix. In other words, I estimate all 9 terms of the DC matrix using a linear filter and then extract Euler angles or quaternions, or whatever I want from the DC matrix. This avoids any singularity problems in the transforms.I'm tracking raw XYZ attitude components in my model. Gyro rates integrate into that directly, then there is a normalization to re-scale and keep the total at 1g. The integration of gyro into model updates is where the partial diffs come into play, because for example dX/dt depends on two things: Y and Z rate, and Z and Y rate. Similar equations go for Y and Z predictions. There are no singularities the way I do it. Maybe my method is akin to tracking "DCM", but I just don't know what the 9 components would be. I have 3 attitude for XYZ, 2 for Earth-centric Yaw position and rate that I track, and 3 XYZ rates so that is 8. When I want to extract actual roll or pitch from the model it's as simple as taking X or Y attitude and doing an ArcSine of that into 1g. I'm also not using floating point at the moment, however I am tracking angular rates and attitude to 6 significant figures.

The complementary filter adjusts the attitude estimate from direct gyro integration using an estimate of gravity that comes from the accel's (minus the centrifugal terms) and an estimate of heading from the magnetometer. I won't go into the math, but you can use the raw sensor values to build up a DC matrix to compare with the direct gyro integration results. I do not use any linear accelerometer corrections. All centrifugal effects are estimated using airspeed and gyro readings. I don't use GPS for any attitude estimation because I want an IMU solution unaffected when GPS is lost. I retain all of the accelerometer tilt effects so that the system estimates correct roll, pitch, and yaw when rotated without any velocity.That sounds remarkably similar to what I am doing. When I write "centripetal" maybe I should have used "centrifugal". No magnetometer in my case, so in the current implementation I have a very loosely coupled approach with the GPS being relied on for position and ground track heading for navigation.

The linear filter is adjusted to weight the gyros more than the accel's and therefore shows little sensitivity to linear accelerations unless they last for relatively long periods of time. I do not use an Extended Kalman Filter (EKF) because I'm not smart enough to write a robust EKF that I trust and I haven't found the need for it yet.My mind came natively wired to think in iterative processes and I do know enough matrix algebra to see my update equations fall into a form amenable to being in a matrix. I also understand general statistics and how a Kalman filter uses variance of data inputs and the model to decide how to blend the data streams together optimally.

For now, I am starting at the "Kestrel2" level (pardon me Reed!) sans KF, but with a 32 bit processor. I can't complain about the performance of my IMU as it tracks attitude fully through 3D maneuvers, and all the other important bits and pieces of an IMU are working well. My computation load is very small and fits my performance bill: I only wanted to take up one of the 8 cores and spend 20 MIPS on the IMU.

The figures below show the variation of theta (pitch) when the IMU is accelerated back and forth +-0.5 g at 1/2 HZ. The theta error is +- 1.5 deg in this case. Also shown is the theta errors (negligible) during an 8-g catapult launch. The error during the launch is small because the duration of the 'g' is short, where as the bench test case was purposely chosen to have longer duration of 'g'.

SteveI am getting similar results with informal 'hand shake' bench test of about +/- 0.5 to 1 degree distrurbance.

[dmgoedde]

I don't think the question is ignoring non-attitude components at all, that is necessary for a properly functioning IMU, the question is the way you determine these non-attitude components, and whether or not airspeed is necessarily the best way to do it.I like airspeed because it doesn't depend on having GPS lock. That's reason 1.

I do realize there are 2nd order effects and complications in my assumption that centrifugal force can be completely calc'd using forward speed and gyro rates. One complicating effect is aircraft don't ride the air like they are locked in on rails. There is sideslip, and what I call 'sloshing' when a pitch change happens and aircraft is starting to grab and bite the air to affect an attitude change. This was poigniantly clear to me in 2008 when I was flying my small 14 ounce 26" span MAV at 80 km/h on a triangular waypoint circuit, and the air was relatively thin at 120 F (almost 50 C!). The plane would snap roll to the proper roll target of 30 deg after hitting a waypoint and needing to bank turn to the next waypoint, but the plane onyl veeerrrry slowing grabbed the air and actully started turning. It was bizarre to watch.

Reason #2: Aircraft fly in air and push off of it while affecting changes in attitude. Airspeed = relative speed difference between aircraft and the air it is moving in. Wind speed does not matter one iota, it is just the aircraft and the air, not the wind. Simple. To me, using GPS data is a far more bizarre and alien way of doing things. It is not direct and has the complicating effect of being related to the aircraft motion via Wind (magnitude and direction), which CANNOT be measured at all, it has to be purely worked out and estimated in a model as some error between other things. In the case of an IMU model for attitude there is the gyro-driven predict updates, but a "real" measurement of attitude direct from the accelerometers. No voodoo involved. And back to Wind... what a mess.

BTW - I think estimating wind is still important and I don't scoff at it. Knowing wind magnitude and heading helps navigation by allowing a scheduling of how much roll response is used to deal with a heading error for purpose of navigation.


I have heard only protests... but nobody explain physically why it would be fundamentally wrong to calc centrifugal forces using rates and airspeed. I myself can tell you all of the reasons why complicating 2nd or 3rd order complicating crud messes up the assumption, but as of now it is working really well for me, and I firmly believe airspeed is the 1st order thing and fundamentally the way to go.

[dmgoedde]

Dean,
You seem to get defensive when people ask you questions about your products. I mean no harm, just discussing....
Mike - If I seem to get defensive it's because my mind doesn't work like normal people. I simply cannot and do not think in the same structure, and am stuck on the other side of the wall people call "outside the box". I end up having to work 4x harder and keep re-inventing the wheel. If I could sit down and keep a clear mind for a few hours, then I would have digested fully this great little paperback here I got titled "Matrices and Transformations" by Anthony J. Pettofrezzo. Someday I'll be fully equiped to put a solid framework of matrix algebra around what I know, digest in my mind all the great KF and EKF papers, then everyone had better look out, because people don't realize how competitive I am and that I do indeed have chips on my shoulders and something to prove. If a robust 3-axis IMU can be made without a KF, I will make it happen (oops, I already have done that). Me a nice guy? No. Would I try to put other autopilot companies out of business if I could make the be-all end-all best ever autopilot? YES, just because that would be FUNNY. I quit a nice $100k + benefits Engineering job to do full time work on a measly THERMOPILE autopilot. Does that tell you anything? I'm mostly a nut with emotional maturity of a 15 yo. That's embarassing, but on the other hand this social networking on RCGRoups is abstract and sort of a veil where we just type text back and forth on cyberspace... not face-to-face talk like our minds are evolved to do. So, no real embarassment involved. I could continue typing all sorts of dumb things here.

Back to reality a minute - Mike I detected a serious tone from you I didn't like. I wrote heresy that I'm not using a KF, not using floating point math, and claims that my IMU is robust and fully handles 3D flight. It must have seemed a HUGE contradiction on so many levels for you. You jumped in with all sorts of assumptions that my IMU probably can't handle free fall or the IMU would freak out if a non-centrifugal and non-attitude force hit the accelerometers. There was also inflamatory accusations of what is and is not a "real" IMU. Nope! In reality, every single thing is being handled in my IMU model and is well constrained and self-trimming. To boot the whole darn thing could be understood by anyone with solid understanding of intro calculus and intro physics. If I weren't trying to be a competitive force and keep paying my mortgage, I would VERY happily write a nice little .pdf tutorial on the "Dean" method for IMU and I think instantly several hundred hobbysist with great interest in this but scared of matrix algebra or symbols and concepts they don't understand in the KF papers would immediately go "Holy CRAP!!! I undertsand it now!!" like I did about 7 months ago when I independently figured it all out. I am trying to debunk myths and help people not be afraid of this topic though. I'm really tired of ivory tower attitudes, so sure this is a chip on my shoulder. Its sort of like now that I crossed a hurdle and can use my IMU in a flying wing even at 3' altitude (assisted flight mode) for indefinate duration flights I know I'm on the 'inside' of this rich topic

After all this thread was started by a person trying to get started with IMU, asking for help to understand the physics of how it all works. The last thing they need is a bunch of people (experts) jumping in using the same lingo that they already found (and didn't understand) in all the KF IMU papers.

What I REALLY liked about working at Intel Corp as an engineer was all the endorphins... hard core pressure and how Intel was founded. Andy Grove is my prime example. He refers to "yelling meetings" where people have their own ideas at stake and believe in them passionately and argue FIERCELY. They are not enemies though. Highly spirited debates are AWESOME. Who wants to live and work on stuff that they don't have fierce passion for?!? Not me.

So Mike - I'm not mad at you or all that defensive really. My 5.5 years at Illinois (UIUC) in the PhD Chem program put me through much more in-your-face challenges from PhD advisors at a top end hard-core school (I'm talking about YOU Ralph Nuzzo, Andy Gewirth, and Greg Girolami) having to defend ideas vigorously, think objectively, and put up with diva attitudes. Same thing at Intel for 7.5 years... thank goodness for Illinois, because when I got to Intel my manager, dept managers, and factory managers couldn't phase me. I never felt like they were my superiors. Technically they were above me in the management chain but that was a formalism. Hard life experiences... get some (I'm not saying you lack them mike, this is a general statement).

Oh just FYI, rate gyros and accelerometers I'm using are all temperature compensated from the factory from -40C to +85C. How are you calibrating yours? From the factory or testing and a calibration table? The testing required to calibrate rate gyros is pretty intensive.What ones are you using? The $600 IMU cube thingy from Analog Devices? I'm only doing my own cal on the yaw gyro. Pitch and roll gyro bias is easily tracked using accel data. Yaw could be done with GPS data in a simple 6DOF IMU system, but I don't trust that at all because ground track heading <> body heading... complications on how to integrate gyro error against GPS heading info. I don't like that. A 9 DOF IMU would be pretty easy using magnetometer data to trim yaw bias, but as I said I'm doing a simpler and loosely integrated 6 DOF with GPS IMU right now.

So - for max accuracy I rely on a multi-point fit of bias with temp, and linear interpolation between nearest 2 data points.
Dry Ice is -78C and only $1/Lb at your local grocer, and an easy way to cool things to -40C. My yaw gyro rate response is already internally temp-compensated and stays within about 1% of itself across across -40 to +85, but that leaves bias value. -40 to +85 using dry ice and a heat gun, keeping ramp rate to about 0.25 deg/sec, and doing the cycle up/down several times to ensure hysterysis is not rearing its ugly head (the aDXRS610 appears to have very very little hysterysis).

[rbeall]

Centripetal = Earth centered earth fixed inertial frame.

This is a never gonna happen case but think of it this way. Say you trimmed up a 20 deg bank turn. The windspeed = trim airspeed. And the wind direction = heading of the airplane (constantly changing at the same rate as the turn rate of the aircraft).

The scenario depicts an aircraft hovering in a turn no doubt (speed over ground = zero). Would the airplane "feel" any centripetal accelearton? No it would not yet all of the simplification equations that include angles and airspeed would still produce false accelerations. The accelerometers would indeed measure a table top 20deg roll (ax+ay+az = 1)

Thats the way I think about it. Could be wrong here or there but it is a true statement that the accelerometers measure acceleration relative to inertial frame which is the earth.

If you look at BYU's paper they give you the acutal equations before they simplify them. If you look at the centrip terms they are body velocities and body rates. These velocities are with respect to the inertial frame being ECEF. I emailed Randy Beard and asked him about it and he basically said "it works well in this application but it is a simplication that breaks down in acceleration (turns)." If you really want to wrap your mind around it....We are accelerating around the sun so how does that get subtracted out in the kalman...ahh just kidding I know the sun revolves arond us....thought I was stupid there for a sec huh?

[clolson]

Curt,
Glad to hear the flying and simulating is going well. Give us a call sometime to catch up, or we'll see you at AUVSI this year.

You need to get your hands on one of the new Kestrels. 500 Mhz 32 bit DSP, running the full integrated attitude/position solution. I think it will give the MIDG-II attitude/position estimate a run for it's money and then some - And it will fly your airplane or helicopter to :)


In the spirit of this thread, I guess I should use the prase "Kalman Filter". The Kestrel 3 has a 17 state loosely coupled GPS-INS Extended Kalman filter.

Reed

Hi Reed, that's exciting to hear. We've heard rumors, but haven't had a chance to see this first hand. :-) Sounds like several new INS/GNS algorithms are coming on line (or have come online) this year. We are in the process of migrating from the theoretical (matlab) to the real world (C + embedded systems + real live sensor data) and still have some issues to address, but our basic system is up and running.

As part of my university connections we are working on a FlightGear based system where we can fly a trajectory, then either collect simulated sensor data from the flight dynamics engine, or we also have a sophisticated algorithm that will generate pseudo sensor data from the original flight path. So that gives us raw sensor data + a real truth reference and provides a neat way to bench mark specific algorithms, or be used as a tool when tuning your filter. I supposed that's cheaper than going out and trial and erroring to see how many times in a row you can successfully fly a senior telemaster through a hula hoop in 20kt cross winds. :-)

[mlbco]

Dean,

Here is a reference for direction cosines (Mechanics of flight
By Warren F. Phillips):

http://books.google.com/books?id=6-_iGbJHM-8C&pg=PA870&lpg=PA870&dq=direction+cosine+matrix+from+angular+rates&source=bl&ots=uD7idZWenN&sig=jN7zsvLN3mDDJ5dcLkhxMVG2Yyg&hl=en&ei=XpgUSqK_HYKjtgff56WWBA&sa=X&oi=book_result&ct=result&resnum=2

Look at equation 11.3.4, that is how the gyros relate to the terms of the transform matrix (i.e. direction cosine matrix). Sounds like your method is similar or same as this.

Based on what you said and shown I think your work is very good. It's not simple to make flight hardware/software that is robust and accurate. Anyone who can demonstrate successful, robust autonomous control has made a great accomplishment. If it were easy everyone would be doing it and this forum would be irrelevant.


Steve

[mlbco]

Centripetal = Earth centered earth fixed inertial frame.

This is a never gonna happen case but think of it this way. Say you trimmed up a 20 deg bank turn. The windspeed = trim airspeed. And the wind direction = heading of the airplane (constantly changing at the same rate as the turn rate of the aircraft).

The scenario depicts an aircraft hovering in a turn no doubt (speed over ground = zero). Would the airplane "feel" any centripetal accelearton? No it would not yet all of the simplification equations that include angles and airspeed would still produce false accelerations. The accelerometers would indeed measure a table top 20deg roll (ax+ay+az = 1)

Thats the way I think about it. Could be wrong here or there but it is a true statement that the accelerometers measure acceleration relative to inertial frame which is the earth.

rbeall,

Congratulations, you've entered into the realm of the downwind turn argument! I'm not going to dredge that up in this forum, but there is an explanation to your claim.

The aircraft feels the same acceleration in the inertial frame as is felt in the body axes coordinate frame and this acceleration is sensed by the on-board accelerometers. Even though the velocity over the ground is instantaneously zero, it is still changing (i.e acceleration) and the direction and magnitude of this acceleration equals the value calculated from the (w x v) terms of the acceleration in vehicle body axes. I have been referring to the (wxv) terms as centrifugal, but in reality it is part of the math for calculating the derivative of a vector as observed from another coordinate system (which may be rotating). In the inertial reference frame these terms don't exist because the inertial frame (by definition) doesn't rotate w.r.t "the fixed stars". The only acceleration terms that remain are the direct component derivatives of the inertial velocity vector. Differentiating these gives the same answer as the acceleration calculated in body axes, but the bookkeeping looks different because you're in a different coordinate system.

I guess the answer to your claim is that the centripetal acceleration terms only exist in certain frames of reference, but the actual value of acceleration relative to an inertial frame is always the same.

Steve

[rbeall]

I think you agree with me on the reference frame argument but not the (w x v) terms. Just to over explain and maybe you can point out my faulty assumptions but here goes....

The scenario I set up above sets up the body velocities = 0 all the time. The center of gravity of the aircraft is not moving with respect to the earth. It is only rotating. For all intents and purposes the airplane thinks it is flying and it is just in a constant airspeed rotating one.

The (w x v) terms you are talking about are the body velocities (all = 0) times body rates (which are some non-zero value).

body velocities = u,v,w = 0; anything times zero is zero therefore there is zero "(w x v)" centripetal acceleration. Reference the BYU paper for the (w x v) break down on each axis.

I could be totally wrong but just because the fan is running in the background when i do my table top demo it doesn't mean the imu is accelerating.....oh my fan spins air counter clockwise in my circular room at a constant velocity which just so happens to be trim airspeed. I guess if I put it in my uav it will accelerate? Ha just messing around but yeah anything times zero is zero for most mathematics.

[mlbco]

The scenario I set up above sets up the body velocities = 0 all the time. The center of gravity of the aircraft is not moving with respect to the earth. It is only rotating. For all intents and purposes the airplane thinks it is flying and it is just in a constant airspeed rotating one.

In this case there truly is no acceleration and none will be sensed. The term (wxv) will equal zero (there is no 'v') and so will all the other acceleration terms, regardless of reference frame. You've described a purely rotational system which will have rotational momentum and possible gyroscopic effects, but the CG will never move and the accelerations are zero.

Steve

[jetblackaircra]

What ones are you using? The $600 IMU cube thingy from Analog Devices?


No, much less expensive, but I'm not saying more than that....

Pitch and roll gyro bias is easily tracked using accel data.

Not in an extended period of freefall (no gravity reference on the accelerometers to correct the bias), or an extended period of coordinated turn (acceleration in the vehicle is aligned with the Z axis even though the aircraft is banked, this is why you feel upright in an airliner while turning, go fly with a pilot friend and ask him to do uncoordinated turns, feels weird) , or an extended period of steady state sideslip (vehicle is level, but side slip causes lateral acceleration with no turn rate).

Don't have time to respond to the giant email about how you only do things you're passionate about. Good for you.

[rbeall]

Right....this overkill of an example which would never happen points out how using airspeed is only an approximation of the elements of groundspeed (u,v,w)

So the airspeed simplification equations would however estimate that the vehicle is accelerating even though its not.

[reedchristiansen]

Hi Reed, that's exciting to hear. We've heard rumors, but haven't had a chance to see this first hand. :-) Sounds like several new INS/GNS algorithms are coming on line (or have come online) this year. We are in the process of migrating from the theoretical (matlab) to the real world (C + embedded systems + real live sensor data) and still have some issues to address, but our basic system is up and running.

As part of my university connections we are working on a FlightGear based system where we can fly a trajectory, then either collect simulated sensor data from the flight dynamics engine, or we also have a sophisticated algorithm that will generate pseudo sensor data from the original flight path. So that gives us raw sensor data + a real truth reference and provides a neat way to bench mark specific algorithms, or be used as a tool when tuning your filter. I supposed that's cheaper than going out and trial and erroring to see how many times in a row you can successfully fly a senior telemaster through a hula hoop in 20kt cross winds. :-)




I assume you are still using the xbow mnav and gumstix? (I still have that mnav if your supplies are running low - I can just put a new fedex label over the old one and drop it back in the mail :) ) Anyhow, sounds like things are progressing nicely on your end.

I am becoming more and more a believer in a good sim environment. Airspace is just too darn expensive these days and the more complex the vehicle the harder it is to work out the control through trial and error. Some vehicles you only get one shot at flight.

When you get your telemaster to fly through a hula hoop on command, let me know and we will go make some money. Especially if it is a senior telemaster and the wings are still on :)

Reed

Reed

[Nimski]

The $600 IMU cube thingy

I'm very excited about this one. Hopefully will get mine soon.

[dmgoedde]

Not in an extended period of freefall (no gravity reference on the accelerometers to correct the bias), or an extended period of coordinated turn (acceleration in the vehicle is aligned with the Z axis even though the aircraft is banked, this is why you feel upright in an airliner while turning, go fly with a pilot friend and ask him to do uncoordinated turns, feels weird) , or an extended period of steady state sideslip (vehicle is level, but side slip causes lateral acceleration with no turn rate).Oh yes you can! This is one of the KEY 'elegant' things I was referring to in my code. There are two rotation components. One is trackable via differentiated atan2(X/Z) and the 2nd component is not trackable, but is knowable depending on a calculation of Earth-centric yaw rate which can be found if you know all 3 gyro axis rates and the 3 attitude vecotrs. Not "how it should be" or "theory" on my part - proven in many flights.

[dmgoedde]

What I meant to write was this:

No turn is necessarily perfectly coordinated; there can be some component of the rotations in 3 axis that bring the nose out of Earth-plane. The non-Earth portion of the rotations can be tracked against atan2(x/z) method, so if you know how much of the rotation in pitch is not attributable to the part in the Earth-parallel plane, then that can be used to track pitch bias.

[jetblackaircra]

First of all, pitch/elevation angle is not the issue in a turn. In a climbing turn or decending turn, the fact that you are turning doesn't cause problems estimating elevation angle.

The issue in a coordinated turn is that you have no accelerometer reference for bank angle. The accelerometer tells the IMU it is level because a yaw rate is causing the acceleration vector to be aligned with the vehicle Z axis.

This is why the Kalman filter system model is very helpful. It can use the relationship between all sensor information available (magnetic heading, GPS, etc.) to determine a best estimate of the state variables when any one, two, or more sensors are not giving data which corresponds to the system model. In other words, you tell the Kalman filter the physics of how the sensors should correlate, and it determines which ones are giving valid data, and weights their affect on the state variables accordingly.

It's kind of like an instrument rated pilot who has partial panel loss (some instruments not working). The pilot is trained to watch things like pitch angle, vertical speed, and altitude to make sure that they correlate. For instance, if your artificial horizon says you are pitching 15 degrees nose down, but your vertical speed says you are climbing and your altitude is increasing, and your airspeed is approximately what it should be and has not changed, it probably means your pitot static is correct and you may have lost electrical or vacuum to your gyros (depending on what kind of system you have) and your artificial horizon should not be trusted.

[rbeall]

Is the atan2(X/Z) differentiated before or after the estimated centripetal (from airspeed) approximations are taken out?

Basically I'm looking for a more specific definition of atan2(X/Z)

differntiated atan2(X/Z) = measured approx theta_dot?

I'm pretty sure I understand exactly what you are accomplishing I'm just trying to match nomenclauture with the convential theory.

[jab]

While the topic is IMU physics, the practical goal in regard to UAV is controlled flight. To my knowledge the best and simplest solution would be "perfect" gyros with no drift. So it seems logical to focus on finding ways to remove drift, and thus IMU becomes relevant. But I was wondering. If you have a GPS heading, would it not then be possible to calculate roll & pitch angles by measuring the earth magnetic field using magnetometers? Possible problems I can for see would be local magnetic field variations and solar flares.

[jglenn]

I have done some work in that area, a GMR sensor for the earth field, coupled
with a PIC cpu and servo. It is tricky, to sense the weak field, about 10 oersted. Mag fields from ESC wires are significant, with a motor, the motor itself has a lot less effect.

Initially, I just flew a hand launch glider with elevator stabilization.
It works pretty well, in one heading, when you change direction the a/d value
changes. But dynamically, I don't see why, for mild close to level flying, you need an IMU. They cost too much anyway! :p

[jetblackaircra]

Just to clarify, an IMU is anything that measures vehicle attitude/position with inertial instruments. So, an IMU does not become relavent when you try to remove gyro drift... if you have gyros, you have an IMU. Without removing gyro drift you just have a bad IMU.

The IMU is not necessary to fly a UAV. But nothing is necessary. With a stable airframe you can steer with just GPS. I'm sure there are people on here who have done it. I know of a company who made Glidersonde (http://www.nssl.noaa.gov/projects/glidersonde/glider.php) and I know they fly in this way.

The question is not whether you need an IMU for all UAVs, the question is whether your particular mission requires an IMU.

If you have a stable airframe, you can get away with just GPS.

If you don't need to fly in fog or rain, the Attopilot I'm sure is great for you.

If you want to be able to fly anywhere, any time, any airframe, an IMU is probably what you want.

[jglenn]

GPS is too slow for a wind gust hitting your bird. You have to correct within
0.1 seconds. Just curious, do you work on UAV's as a real job? Several of the
people here have pretty current knowledge, it is hard to judge sometimes.

[jetblackaircra]

GPS is too slow for a wind gust hitting your bird. You have to correct within
0.1 seconds. Just curious, do you work on UAV's as a real job? Several of the
people here have pretty current knowledge, it is hard to judge sometimes.

Hence the term "stable airframe". Go talk to the group on here for hand launch aircraft. An airframe can be made to be so stable that wind gusts (within reasonable limits) are compensated for by airframe stability.

1Hz is plenty fast to steer the vehicle. The only issue comes from drift due to wind which can be accounted for with a simple pitot probe. I know for a fact that there are several people/companies flying UAVs on this principle alone.

And since you asked, I have designed a UAV airframe and control system for my own business and I have a degree in Aerospace Engineering from an ABET accredited school as well as several years industry experience with a large aerospace company.

..... 0.1 seconds? Did you just pick that number out of thin air? Ask any R/C pilot and they'll tell you that some aircraft can fly through gusty air with hands off the controls for many seconds.

[jglenn]

Interesting. The level of experience here is impressive, just trying to learn and absorb info, not at the level of you guys. Surviving on the hobby UAV market sounds difficult. I've been flying model planes (yes, starting with HLG), and amateur rockets for decades, dabble in esoteric control systems and products.

You folks could learn from the rocket people, the gov slammed the hobby after 911, clamping down on motor sales, shipping, storage, etc, calling ammonium perchlorate propellant "high explosive". 2 rocket organizations sued the ATF 9 years ago, and a Federal judge recently ruled in their favor. Perhaps a UAV org is needed to prevent the same thing happening. I am hearing about having to fly under 400', keeping the plane in site. So how can you legally test long range autonomous flight? Go to mexico or the ocean?

In the many planes I have flown, only one flying wing (they scare me), many many times I have seen disruptions due to wind affect the attitude, and if I only responded in one sec it would already be in a dive or stall. Yes I know there are various levels of stability built into different planes. My goal is not stabilizing an unstable plane, but augmenting a stable one and doing basic navigation. Yes, the 10 HZ rate is arbitrary, but I am not running Spin code or C, just Basic at this time.

You may never have heard of it, but another novel way to sense attitude is electrostatic. A guy decades ago put foil squares on the wingtips, and had a small radioactive source at the nose (source from StaticMaster antistatic brush, maybe radium, little bit). This ionized the airstream. An opamp circuit detected if the wings were not level, because the atmosphere has a gradient of voltage change with altitude. Perhaps not practical, but it worked. I just think that accel and gyro's, and thermopiles are not the only way to sense attitude.

[jetblackaircra]

You're absolutely right. There are lots of ways to do it. It all depends on what conditions you want to be able to fly in.

[jglenn]

Rain and fog of course. Near lakes, mountains, and forest fires! :D

Actually I mostly fly when calm, morning after sunrise. Do have some planes
that can handle 20-30 mph winds, Axi-Gold in one, vertical climb if I want to.
The wind makes things tough, I admire the autopilots that can handle that.

But I am shooting for not so hard conditions, a hobby controller that does not
require a pHd to operate and modify. That university batlike plane that comes
out of the tube, they said it used some kind of "visual navigation". I have been
thinking about this, say a CMUcam, programming to recognize landmarks and
features. One test mission I want to do is to just launch the plane in a certain direction, have it autonomously go out a certain distance, then flyback over the
same path and then circle. Without a gps. Wind drift will be a problem, as well
navigation. If the system could declare certain landmarks, and find them again, it might work. I am just an electronic hobbyist type, but do have a physics/C prog friend, as well as an aero prof pal that might help.

Any thoughts on organizing the hobby to enable representation for the inevitable government oversight? 400 feet? Gimme a break. :mad:

[airmcn_3]

Any thoughts on organizing the hobby to enable representation for the inevitable government oversight? 400 feet? Gimme a break. :mad:


We are trying very hard.

Sounds like an AttoPilot V1.8 would do the job for you.

[Buzz_Lightyear]

One test mission I want to do is to just launch the plane in a certain direction, have it autonomously go out a certain distance, then flyback over the same path and then circle. Without a gps.

Without a GPS? I'm pretty sure attopilot 1.8 is not suited for his requirements. In fact, I don't know of any hobby autopilot that is.

[noether]

I'm very excited about this one. Hopefully will get mine soon.

We have here two versions of this cube, the 16405, and the 16350. Both are amazing for our UAVs. Also for 2D, i recommend the 16300 version.

I'm new in this forum, and i'm very excited seeing that there are many hobby projects (like ours) in UAVs.

www.spacefishproject.com

[airmcn_3]

Without a GPS? I'm pretty sure attopilot 1.8 is not suited for his requirements. In fact, I don't know of any hobby autopilot that is.


I missed the without a GPS part........ I strike what I said as Buzz is correct.

[jglenn]

airmcn3: Is the AMA sympathetic to experimental UAV's? Something tells me
they won't like them, not up on the latest regs, other than staying under 400'
and keeping autonomous flights in sight at all times (ha, get a telescope).

I hope to get an Atto someday, it is impressive. I am just toying around with
out of the box experiments, have nothing against GPS, but want to see what
nav is possible without it. My flux sensor has been used to stabilize one axis,
and gives heading data too. I don't plan on flying miles away, if I could use
dead reckoning with speed and time, it will provide rough distance. You know
that if war breaks out, they will mess up the gps sig to wreck the accuracy.

Average wind speed and direction could be uploaded to the processor to try
to compensate for drift. Yes it may be nuts, and I'll wind up with an Atto or
Arduino, but I enjoy making circuits and programs, sometimes they work.. :p

[dmgoedde]

The issue in a coordinated turn is that you have no accelerometer reference for bank angle. The accelerometer tells the IMU it is level because a yaw rate is causing the acceleration vector to be aligned with the vehicle Z axis..Correct - IF you feel "ok" ignoring centripetal effects corrections. If you take raw (uncorrected) Y accel axis data and take out centrifugal term (forward speed multiplied by yaw rate), then Y accel will indeed show the roll angle in the turn. If you do same for raw Z accel data (subtract forward speed x pitch rate) then Z is attitude component as well. This is really very very simple stuff. I suppose this aligns somewhat with what you wrote regarding how a proper IMU filter combines many data sources to an overall solution.

What I trying to get through here is that a simple 6 DOF IMU can indeed work perfectly well (and in fact I have demonstrated it on many long flights) if very simple corrections are applied. There is no hocus pocus to what I am claiming - the corrections are based on completely observable data (did I use 'observable' correctly Reed?)

rbeall - based on our 3 hour phone conversation yesterday, and your real-world experience with the Kestrel, your own IMU autopilots, and your apparently deep knowledge of the BYU papers... can you tell me if you think I know what I am talking about here?!?!?

[rbeall]

Dean is accurate in his statements and he is properly implementing a fixed gain (variable gain observer) state update prediction filter. The extended kalman filter has been mathematically proven to be the optimal choice for correcting the sensor data. However, if you are anyone who actually has an imu flying in an airplane then I think you would know that the easiest answer is always the best answer....fixed-gain -deweighting filter. Implementation is fairly straight forward and easy to tune. I don't think any one disagrees that EKF is better so there is no need to really convince anyone of that. Both methods work very adequately and that's that. I always love the guy who talks about how much faster the corvette is over your mustang...oh but he doesn't have a corvette to race your mustang. He only has seen the stats on google.

[kbosak]

The scenario depicts an aircraft hovering in a turn no doubt (speed over ground = zero). Would the airplane "feel" any centripetal accelearton? No it would not yet all of the simplification equations that include angles and airspeed would still produce false accelerations.
Overestimating the speed of the motion is not dangerous in centrifugal kill algorithm, since the sensor would simply overestimate the actual roll.
Underestimating the airspeed (GPS when diving etc) is dangerous and invitation for algorithm-induced spin.

What I don't understand is how do you integrate Y-accelero in order to get rid of airspeed sensor and create a driftless IMU with it.
Consider the following loop:
You take yawrate and airspeed and apply horisontal centrifugal kill.
You take pitchrate and airspeed and apply vertical centrifugal kill.
Then you compute the global length of the remaining G vector and what is left is probably linear acceleration along the Y axis. You can integrate it naively, producing new airspeed.
What stinks is that you are reintroducing the same airspeed into the centrifugal kill algorithm. Whatever Kalman you put to cover the mess, it is very likely that the airspeed will drift away into singularity. Unless I am missing something.

[rbeall]

airspeed is simply a state you read. You don't need to Kalman it. Complete convergence of these filters is impractical. If you keep the dynamics of the vehicle low and apply some adhoc failsafes you can keep the plane in the air. However limiting the bank angle to around 35 degrees is a great start.

I don't think I completely follow your airspeed proposal, however you simply use airspeed to resolve your body speeds on each axis to subtract out the appropriate centripetal.