Kalman Filter - Acceleration Measurements

[jstluise]

I am using a extended Kalman filter for the state estimation of a nonlinear system. The real system has accelerometers, so I need to include the acceleration of the system as part of my measurements with noise added (position and angular rates are other measurements).

All of the Kalman filter design I've done in the past only had measurements based on state variables. Obviously the acceleration is not a state variable, so I am unsure about how to get my simulated acceleration measurement.

I can get acceleration since I know what my inputs are, but all of my EKF references don't have inputs as part of the measurement function:

That's the only way I can think of getting my acceleration measurements...what am I missing?

 

[D H]

Obviously the acceleration is not a state variable ...

Rhetorical question: Why not?

If you make acceleration part of your state vector, then you should have some means of predicting what acceleration should be. If the control system commanded the object in question (e.g., a vehicle) to accelerate in a certain way, then that commanded acceleration should be incorporated into the predict side of the Kalman filter. Plus some plant noise. When you do have acceleration as part of your state vector, the accelerometer readings are a "measurement". Those measurements, like any other measurement, go on the state update side of the Kalman filter. The uncertainties in the accelerometer readings are measurement noise for those updates.

If you don't make acceleration part of your state vector, then the fact that the object is undergoing acceleration is a bit of a surprise. The accelerometer readings are not a measurement in the sense of a Kalman update. They instead need to be used in the predict side of your filter. The noise is a bit trickier. You have plant noise plus sensor noise, and the sensor noise is now a random walk (integrated white noise), or integrated random walk if velocity also is not part of your state. You can remove some of the surprise (and hence some of the noise) by accounting for commanded accelerations, but it's still a bit of a surprise.

One final point on accelerometers: They don't measure acceleration due to gravity. They measure acceleration due to non-gravitational forces only. You need to account for acceleration due to gravity, typically on the predict side of your filter.

 

[jstluise]

Rhetorical question: Why not?

If you make acceleration part of your state vector, then you should have some means of predicting what acceleration should be. If the control system commanded the object in question (e.g., a vehicle) to accelerate in a certain way, then that commanded acceleration should be incorporated into the predict side of the Kalman filter. Plus some plant noise. When you do have acceleration as part of your state vector, the accelerometer readings are a "measurement". Those measurements, like any other measurement, go on the state update side of the Kalman filter. The uncertainties in the accelerometer readings are measurement noise for those updates.

If you don't make acceleration part of your state vector, then the fact that the object is undergoing acceleration is a bit of a surprise. The accelerometer readings are not a measurement in the sense of a Kalman update. They instead need to be used in the predict side of your filter. The noise is a bit trickier. You have plant noise plus sensor noise, and the sensor noise is now a random walk (integrated white noise), or integrated random walk if velocity also is not part of your state. You can remove some of the surprise (and hence some of the noise) by accounting for commanded accelerations, but it's still a bit of a surprise.

One final point on accelerometers: They don't measure acceleration due to gravity. They measure acceleration due to non-gravitational forces only. You need to account for acceleration due to gravity, typically on the predict side of your filter.

Thanks for the in depth response! The reason I said that acceleration is not a state variable is because by definition, it is not needed to describe the state of the system. But, it would make things much easier if it was included in the state variables for the reasons you mentioned. I thought about this, but I am unsure about how to include it (never had to before). Don't I need to know the behavior of the acceleration derivative is to include it in my state vector? Do I just differentiate the equation I have for acceleration? Or is it simpler than that?

Your comment about accelerometers...is that true for all accelerometers? If the few that I've worked with they measure absolute acceleration. For example, the single axis accelerometer will measure +/- 1g if it is sitting on the table (depending on if it is upside down or not). Or maybe I misunderstood your comment?

Thanks again!

 

[D H]

Have you done a literature search on this? This is the reason Kalman filters were invented, to get man to the Moon in the 1960s. There's fifty years of literature on this very topic. Whether to include acceleration in the state -- so do, some don't. It depends in part on what the filter is for (e.g. a black box inertial navigation system that doesn't know a thing about commanded accelerations versus a control system that intimately knows (or thinks it knows) what acceleration is supposed to be), in part on personal preference, in part on trying different approaches and seeing which one works best.With regard to my comment on accelerometers not sensing gravity: No local experiment can sense gravitation per Einstein's equivalence principle. An accelerometer is the quintessential local experiment. The only way to sense gravitation is with a non-local experiment. Measure position vector to the planet of interest and numerically differentiate twice, for example.

So if accelerometers don't measure gravitation, why does an accelerometer sitting on a table sense an acceleration of 1g?

Draw a free body diagram. What forces act on the accelerometer, and what is the net force? Ignoring acceleration toward external bodies such as the Moon and Sun, the forces acting on the accelerometer are the downward gravitational force exerted by the Earth on the accelerometer and the upward normal force exerted by the table on the accelerometer. The net force: The accelerometer is at rest with respect to the rotating Earth. The net force is that needed to make the accelerometer undergo uniform circular motion about the Earth's rotation axis, one revolution per sidereal day. The distance to the rotation axis is approximately r=R_e*cos(latitude). For a latitude of 45 degrees, the accelerometer is accelerating at about 0.024 m/s². If your accelerometer did sense gravitation, this is the value that it would report rather than 9.8 m/s².

So why does an accelerometer sitting on a table sense an acceleration of 1g? Simple: It's senses everything *but* gravitation. In this case, it senses the upward normal force exerted by the table on the accelerometer that is not quite equal to but opposite the downward gravitational force.

 

[jstluise]

Excellent! Thanks! The bit on the accelerometer makes sense now...kind of mind boggling but I think I have it. So let's say an airplane at steady flight, the accelerometer in the down direction (earth normal) will be reading +1g. But my model is only accelerating due to the uniform circular motion because it is in the absolute frame. This is the difference I must account for.

I'll search around for info on the Kalman filter issue. I was not aware of this issue until I started revisiting EKF and more complicated models...never came up before with the simple academic problems I've been through. Also, when I've worked with accelerometer measurements before, they were just integrated and compared to the model velocity (this was in a simple PID control case, no state estimation).

Because I know (ie think I know) what the commanded accelerations are from the model, I will try to get it working first without including acceleration as a state.

Thanks, you've been very helpful!

 

[D H]

Excellent! Thanks! The bit on the accelerometer makes sense now...kind of mind boggling but I think I have it. So let's say an airplane at steady flight, the accelerometer in the down direction (earth normal) will be reading +1g. But my model is only accelerating due to the uniform circular motion because it is in the absolute frame. This is the difference I must account for.

That is *one* of the differences you must account for.

Here's another: Your velocity vector is expressed in some frame of reference. To predict the velocity at the next time step you need to know the derivatives of the components of your velocity vector. That is not what your accelerometer reports. Suppose your airplane pitches up, or yaws left. Your accelerometer doesn't know that the orientation with respect to inertial has changed. It doesn't know anything about the way it is oriented. Your accelerometer outputs are expressed in the "accelerometer case frame". You need to transform the accelerometer outputs to the velocity vector frame and account for the unsensed gravitational acceleration.

And yet another: If you are working with an airplane, you may well want position and velocity expressed in a frame that is rotating with the Earth. This is a rotating frame. This means the dynamics include accelerations from fictitious forces such as the centrifugal and coriolis accelerations. Your accelerometer doesn't measure these, either. There's a reason they're called fictitious forces: They aren't real. They are fictions. Extremely convenient fictions, but fictions nonetheless. Accelerometers don't sense fictitious forces.

And yet another: Your accelerometer has lots of goofy errors. If you have a 3 axis accelerometer, it would be real nice if those measurements represented accelerations in three orthogonal axes. They aren't. The individual single-axis accelerometers are not aligned perfectly. There's always some non-orthogonality error that poisons the accelerometer outputs a bit. It would be real nice if the accelerometer was oriented internally exactly the way the spec says it is, and oriented to your aircraft frame exactly the way you wanted it. It's not. There are instead misalignment errors. It would also be real nice if a reported acceleration of (say) 10 meters/second² really meant 10 meters/second², 1 meters/second² really meant 1 meters/second². Accelerometers have biases and scale factor errors. Some people make the sources of these errors a part of the state so that they can be estimated.

 

[jstluise]

Good points, thanks.

My model is a simple 3DoF model (can be used for any aircraft/ spacecraft ) which accounts for the Earth rotating frame. So I have my inertial frame (e.g. ECI), my rotating frame (e.g. ECEF), and my body frame. The additional frame that I didn't include would be a frame that is always normal to Earth (e.g. NED), but I will save that one for a future 6DoF model. So, my position and velocity state variables are expressed in my rotating ECEF frame.

My initial thought before you brought up these important points was that my acceleration measurement would just be the acceleration in the rotating ECEF frame, but transformed to the BODY coordinate system. This was because I was thinking the accelerometer was taking 'absolute' measurements. But, looks like I'll have to rethink some of this, especially dealing with the centrifugal and coriolis accelerations.

I can see how a local normal place (e.g. NED) would be useful in accounting for the gravity bias in the accelerometer measurements.

 

[AlephZero]

So if accelerometers don't measure gravitation, why does an accelerometer sitting on a table sense an acceleration of 1g?

Another way to look at that: accelerometers don't measure acceleration. They measure force (or some proxy for force, like strain in an elastic material), and the force is often the weight of some internal component of the accelerometer.

The internal dynamics of the accelerometer explains why the output is only accurate (i.e. within the data sheet definition of "accurate") over a restricted frequency range, for example.

 

[jstluise]

Another way to look at that: accelerometers don't measure acceleration. They measure force (or some proxy for force, like strain in an elastic material), and the force is often the weight of some internal component of the accelerometer.

The internal dynamics of the accelerometer explains why the output is only accurate (i.e. within the data sheet definition of "accurate") over a restricted frequency range, for example.

This is how I was thinking about it and it made the concept easier to grasp, at least as far as dealing with the gravity bias.

Still thinking about the coriolis and centrifugal force and accounting for them. Is it just a matter of subtracting them out, essentially transforming the motion to the inertial frame? Since the accelerometer can't measure them because they are fictitious.

 

[D H]

Another way to look at that: accelerometers don't measure acceleration. They measure force (or some proxy for force, like strain in an elastic material), and the force is often the weight of some internal component of the accelerometer.

That explanation fails to describe how an accelerometer in free fall such as on an orbiting spacecraft reports no acceleration.

The most accurate model of large scale (non-quantum) phenomena is general relativity, not Newtonian mechanics. In GR, an ideal accelerometer measures proper acceleration, acceleration relative to a (local) co-moving inertial frame. Inertial frames in GR are not the same as inertial frames in Newtonian mechanics. Accelerometers don't measure what we call "weight", gravitational acceleration times mass, because that force is a fictitious force that results from looking at things from the perspective of a non-inertial frame.

 

[jstluise]

I think I'm pretty close to understanding what an accelerometer is capable of sensing (everything but gravity & fictitious forces), but I just wanted to make sure.

For gravity (ignoring centrifugal and coriolis for now), considering the FBDs of the two cases of an accelerometer sitting on a table and an accelerometer in an orbiting (falling) satellite makes it easy to convey the idea. For example, the only force on the orbiting satellite is gravity and this is the acceleration that the model reports; however, in real life the accelerometer reports 0 m/s^2, so the model must be biased to remove the acceleration due to gravity (leaving a net force of zero).

For the fictitious force (centrifugal/coriolis), it is a bit more confusing. If we remove all external forces in the inertial frame (e.g. gravity), a scenario that helps me understand is a mass being ejected into space, away from earth. Remember, no gravity so in the inertial frame the mass just goes in a straight line away from the origin (center of Earth). But, in the rotating frame, due to centrifugal and coriolis accelerations, the mass appears to spiral out around Earth. Of course, in real life, the onboard accelerometer is reading zero. Looking at the model in the rotating frame, we see an acceleration from the centrifugal and coriolis effects. Thus, they need to be removed to make the correct measurement in the model.What I am still a little iffy on is the correct transformation from the body frame to the rotating frame. In real life, if I make an acceleration measurement in the body frame, these measurements must be transformed to the rotating frame. This is equivalent to the acceleration in the rotating frame, minus the centrifugal and coriolis effects that are in the model.

Going the other way, if I take the acceleration in the rotating frame of the model and subtract the centrifugal and coriolis effects, then transform it to the body frame, this is the acceleration that an accelerometer will read (ignoring gravity at the moment). I think that is all correct.

Is it correct to say that an accelerometer only measures accelerations in the inertial frame (after accounting for the gravity bias)? I mean, once you remove the centrifugal and coriolis forces, that's saying that your acceleration in the rotating frame is equal to the acceleration in the inertial frame.

 

[D H]

Emphasis mine:

For example, the only force on the orbiting satellite is gravity and this is the acceleration that the model reports; however, in real life the accelerometer reports 0 m/s^2, so the model must be biased to remove the acceleration due to gravity (leaving a net force of zero).

What model are you writing about? A simulation engine that let's one test the filter in a simulated environment? Some onboard software model that processes the accelerometer data? Something else?

Why do accelerometers report zero acceleration for an object in free fall? I'll look at this from two different perspectives.

• General relativity.
  General relativity is the most accurate explanation of large scale phenomenon, so it's good to look at this as the premier explanation. An ideal accelerometer is a device that measures "proper acceleration", acceleration relative to a co-located, co-moving, and free-falling test object. That test object defines an inertial frame in general relativity. Note that this general relativistic inertial frame is quite different from a Newtonian inertial frame. In Newtonian mechanics, that free falling frame is an accelerating frame: Not inertial.
  
  Einstein imagined how a person in an windowless elevator car could make sense of what was experienced locally inside that elevator car. Suppose you are standing on the floor of that elevator car. Everything feels normal. How can you tell whether the elevator car is at rest on the surface of the Earth or have you been kidnapped by bug-eyed monsters and the car is in a spaceship in deep space, accelerating at 1g? Now suppose you feel weightless. How can you tell whether the elevator car is orbiting the Earth or is in deep space and not accelerating at all? The answer in both cases is that there is no way to distinguish between the alternatives. Newtonian mechanics says something rather different. It says the car at rest on the surface of the Earth is close to inertial, the accelerating car in deep space and the orbiting car are non-inertial. The only situation in which general relativity and Newtonian mechanics agree is the non-accelerating car in deep space. Another big difference is that inertial frames are global (span the universe) in Newtonian mechanics but are local in general relativity.
  
  An accelerometer is very much akin to that person in a windowless elevator car. The accelerometer doesn't know anything about the external environment. It reports acceleration relative to a locally free-falling object, the test mass inside the accelerometer.
  
  
• Newtonian mechanics.
  An accelerometer comprises a test mass that is somewhat free to move with respect to the accelerometer housing. Because the test mass is somewhat free to move, the accelerometer must apply a force on the test mass to keep the test mass stationary with respect to the housing. It is this force that the accelerometer senses and reports (scaled via F=ma) as acceleration. As the accelerometer is small, there is essentially no variation in gravitational acceleration across the tiny expanse of the accelerometer. Acceleration due to gravity affects the accelerometer housing and the test mass equally. No force is needed to keep the test mass stationary with respect to the housing if the accelerometer is in free fall.

Note very well: I am not advocating that one should use general relativity to solve a robotic car moving along a road problem. That's ridiculous. Use Newtonian mechanics. The reason I invoked general relativity at all is because the equivalence principle and Einstein's elevator car thought experiment helped me gain a solid understanding of why accelerometers behave the way they do. If it doesn't help you, just use the Newtonian explanation.

For the fictitious force (centrifugal/coriolis), it is a bit more confusing.

Suppose Jim wants to describe behavior from the perspective of a frame rotating with the Earth, John wants to describe behavior from the perspective of a frame rotating at 1000 Hz about the x axis, and Susan wants to describe things from the perspective of an inertial frame (Newtonian inertial frame). How does the accelerometer know who is observing the behavior? The answer is, it doesn't. From Susan's perspective, those fictitious forces do not exist. This is the perspective from which accelerometers measure acceleration.

What I am still a little iffy on is the correct transformation from the body frame to the rotating frame. ... Is it correct to say that an accelerometer only measures accelerations in the inertial frame (after accounting for the gravity bias)?

Correct. Or, almost correct. Accelerometers measure acceleration with respect to inertial (specifically, with respect to a general relativistic inertial frame, so no correction for gravity bias is needed). The results however are in terms of a frame fixed with respect to the accelerometer (the accelerometer case frame). Velocity is typically expressed in terms of some external frame, so those case frame accelerations need to be transformed to the position/velocity frame to make sense of those reported accelerations.

 

[jstluise]

What model are you writing about? A simulation engine that let's one test the filter in a simulated environment? Some onboard software model that processes the accelerometer data? Something else?

The model is simulation engine like you say. It is the 3DoF model that I discussed earlier that describes the motion of the body in a rotating frame. My state variables are the position and velocity in the rotating frame as well as the angular position and velocity of the body in the inertial frame.

When I make my accelerometer measurements within the model (to simulate my filter), this is where I have to take the acceleration of the body wrt to the rotating frame, remove the centrifugal/coriolis effects, account for gravity, then express the resulting acceleration in the body frame. THIS is what my accelerometer will read in the real world.

Thanks for taking the time to help me out!

 

[jstluise]

You can remove some of the surprise (and hence some of the noise) by accounting for commanded accelerations, but it's still a bit of a surprise.

Conceptually this makes sense, but I am unsure about the implementation. Right now I am not accounting for the commanded accelerations, but I wanted to see if any improvements can be made by doing so. Do you have any recommendations? I haven't been able to come up with any sources that discuss this.

Thanks!

 

[D H]

You won't find many sources nowadays that discuss this. Unfortunately, that information has become rather restricted since September 11, 2001.

 

[jstluise]

I think I have discovered the difficulty in dealing with the accelerometer noise when the acceleration is not made part of the state vector. Since the accelerometer measurements are used in the predict side of the filter, I get the random walk like you were talking about. I end up with state errors that drift.

Top to bottom: Position X, Position Y, Velocity X, Velocity Y

In the above image, my process noise covariance matrix is set to zero because I was assuming my process was perfect for the moment. But then I got to thinking, and added the accelerometer noise to the the process noise, and I came up with better results:

I'm not sure if what I did is correct or not, though. It seems like I should not have the accelerometer noise in the process noise of the model, but I should include it in the process noise covariance matrix only when I am propagating/predicting my error covariance matrix, P...

Can you shed some light on this?

I am going to try to add my acceleration to my state vector, but it seems like in that case I need to know the derivative of the input...is this right?

 

[D H]

You have to have process noise (aka plant noise). If you don't, the covariance matrix will collapse and the filter will reject measurements. Think about it: If the state is known perfectly, why bother with those stupid noisy measurements?

How much process noise? That's the black art of Kalman filters. It's called filter tuning, and it's usually done empirically. Basically, you want more than enough noise to keep the covariance from collapsing, but too much noise will make the filter outputs become noisy. Your state is staying within the 3 sigma bounds, which is a good start. Fiddle around with your process noise. Scale it up and down (maybe by quite a bit) to see what it does to behavior, repeat these coarse adjustments and then later fine tune until you get the behavior you want.

Note also that you need to account for behavior when you take your device off the test stand and start driving it with a (noisy) motor (or whatever). This is true plant noise; you'll need to add some of that plant noise to your empirically-based process noise that's needed just to make the filter behave nicely.

 

[jstluise]

You have to have process noise (aka plant noise). If you don't, the covariance matrix will collapse and the filter will reject measurements. Think about it: If the state is known perfectly, why bother with those stupid noisy measurements?

How much process noise? That's the black art of Kalman filters. It's called filter tuning, and it's usually done empirically. Basically, you want more than enough noise to keep the covariance from collapsing, but too much noise will make the filter outputs become noisy. Your state is staying within the 3 sigma bounds, which is a good start. Fiddle around with your process noise. Scale it up and down (maybe by quite a bit) to see what it does to behavior, repeat these coarse adjustments and then later fine tune until you get the behavior you want.

Note also that you need to account for behavior when you take your device off the test stand and start driving it with a (noisy) motor (or whatever). This is true plant noise; you'll need to add some of that plant noise to your empirically-based process noise that's needed just to make the filter behave nicely.

Thanks, that makes sense. I'll just have to experiment with the process noise to see the effect it has on the filter. So really you aren't ever accounting for the accelerometer noise...you just tune the process noise until it works?

I think adding the acceleration to the state vector would be worth doing, since I have an idea what the commanded acceleration is. But differentiating the acceleration to get jerk means I have to know the derivative of my input, right?

 

[D H]

With regard to that random walk: The only way to get rid of that is to take other measurements. Cameras. Star trackers. Magnetometers. Lidar measurements. GPS. Radar range/range rate. All kinds of other sensors are used. If you don't, your position will degrade rather quickly. Adding these sensors will of course make your Kalman filter get bigger and bigger.

 

[D H]

Thanks, that makes sense. I'll just have to experiment with the process noise to see the effect it has on the filter. So really you aren't ever accounting for the accelerometer noise...you just tune the process noise until it works?

You account for the accelerometer noise in the measurement noise side of the filter. That's the easy part. It's in the spec. Well, not quite. The filter specialists I've worked with always add fudge factors to make the filter work. Tuning is a black art.

 

[jstluise]

With regard to that random walk: The only way to get rid of that is to take other measurements. Cameras. Star trackers. Magnetometers. Lidar measurements. GPS. Radar range/range rate. All kinds of other sensors are used. If you don't, your position will degrade rather quickly. Adding these sensors will of course make your Kalman filter get bigger and bigger.

I forgot to mention that I am using GPS position measurements in this simulation, with a standard deviation of +/- 2m. The standard deviation on the accelerometer measurements is +/- 0.05 m/s^2.

You account for the accelerometer noise in the measurement noise side of the filter. That's the easy part. It's in the spec. Well, not quite. The filter specialists I've worked with always add fudge factors to make the filter work. Tuning is a black art.

Yes, of course. I didn't word my question very well. I should have said specifically in the predict side of the filter. The noise is added to the accelerometer measurement like you said, given the spec. In the predict side, we just tune the process noise covariance matrix until we get desired results.

 

[D H]

The standard deviation on the accelerometer measurements is +/- 0.05 m/s^2.

That sounds a bit weird, or rather it sounds unweird. Accelerometers usually have rather weird error specs. The units inevitably have a square root of time (or square root of frequency) in them.

A typical approach is to update with the accelerometers much more frequently than the GPS measurements. The GPS measurement is there just to keep the integrated random walk from walking all over the place. You don't need to do that update nearly as often as the accelerometer update. If you follow this approach, you should see your covariance matrix grow while you're only using the accelerometer data, then shrink with the GPS update, then grow again, etc.

I should have said specifically in the predict side of the filter. The noise is added to the accelerometer measurement like you said, given the spec. In the predict side, we just tune the process noise covariance matrix until we get desired results.

Exactly.

 

[jstluise]

That sounds a bit weird, or rather it sounds unweird. Accelerometers usually have rather weird error specs. The units inevitably have a square root of time (or square root of frequency) in them.

Yeah I wasn't completely sure about what to use. The data sheet for the IMU (ADIS16448) I am using just for some initial numbers gives a Output Noise = 5.1 mg rms ~= 0.05 m/s^2 rms. There is also a noise density number given in units of mg/sqrt(Hz), which is what you mentioned...but I didn't know how to use it.

A typical approach is to update with the accelerometers much more frequently than the GPS measurements. The GPS measurement is there just to keep the integrated random walk from walking all over the place. You don't need to do that update nearly as often as the accelerometer update. If you follow this approach, you should see your covariance matrix grow while you're only using the accelerometer data, then shrink with the GPS update, then grow again, etc.

This is exactly where I was going with this. As you might have guessed, I'm developing an integrated GPS/INS system for the GN&C system of a vehicle. So simulating GPS dropouts is part of that.

At times in between GPS measurements (only using accelerometers), do I just set my gain to zero since I don't have any measurements to update my estimates? As a result, this makes my a priori state estimate and state error covariance matrix equal to my posteriori state estimate and state error covariance matrix. I couldn't think of another way to do it...

Here's an example with the GPS updating every 10 seconds (accelerometer every 0.01 sec) with the method I just described:

 

[D H]

Regarding the noise density: Google the term "accelerometer allan variance".

Regarding the GPS updates (or lack thereof): Google the term "sensor fusion" (maybe with Kalman filter mixed in).

Many people process measurements one at a time: Propagate, update with measurement #1, update with measurement #2, propagate, ... Each update has its own H matrix, which is now much smaller. Key advantages include not having to worry about how to handle missing measurements (it's built into the process) and a much smaller innovation matrix (so much easier to invert). The key disadvantage is that this misses correlations between measurements.

 

[jstluise]

Many people process measurements one at a time: Propagate, update with measurement #1, update with measurement #2, propagate, ... Each update has its own H matrix, which is now much smaller. Key advantages include not having to worry about how to handle missing measurements (it's built into the process) and a much smaller innovation matrix (so much easier to invert). The key disadvantage is that this misses correlations between measurements.

That's a clever way of doing it, I like it. Like you say, you don't have to worry which measurements are available or not, which makes it nice. So I wonder, are the two methods equivalent if there are no correlations between measurements?

While we are on the subject of the sensor fusion idea, I'll see if you know anything about this since I haven't found a good answer. From what I've seen, commercial GPS/INS systems have a GPS and IMU (accelerometer, gyros, and sometimes magnetometers). That alone, apparently, can provide a full state estimation for position and attitude. The position I understand, but not attitude. A 6DoF system is not fully observable with only gyros. A triaxial magnetometer would help, but there is still a degree of freedom missing.

I've read about estimating attitude with GPS and multiple antennas, but I don't believe that is used on these GPS/INS units. There must be some trickery involved that I am missing. Maybe some constraints put on the system based on what type of vehicle it is? For example, in addition to the magnetometer, an orientation of a rocket can be estimated with two gps position measurements if you assume the angle of attack is low/zero.