# Should acceleration be included in state vector of a Kalman filter?

I'm developing (actually adopting existing solution) a Kalman filter to model motion of a vehicle (UAV or automobile). The state vector will include position, velocity, and, possibly, acceleration.

In that existing solution acceleration is included; state transition is something like $(\vec x,\vec v, \vec a) \to (\vec x+\Delta t\cdot \vec v,\vec v+\Delta t \cdot \vec a,\vec a+\xi)$, where $\xi$ is a process noise.

I think that such model is good when acceleration is changing somewhat smoothly, but when there are bursts of acceleration, removing $\vec a$ from state and adding noise to velocity should be more suitable: $(\vec x,\vec v)\to(\vec x+\Delta t\cdot\vec v,\vec v+\xi)$.

Tests show that there is almost no difference in precision of solution between both models (turns out that the observation data provides more effect on position than the velocity).

So the question is, when should I include acceleration in state, and when should not? What things should I consider?

• My general impressions: (1) Kalman filters are black magic, and people just tinker with them to make them work. (2) Kalman filters don't have particularly good or special properties. They're just enshrined in tradition. – Ben Crowell Aug 12 '11 at 13:12
• @Ben: Black magic for sure, but they do have a special property or two. You can change the projection (i.e. the physics of you detector say by adding a magnetic field to a previously field free machine) without having to change any part of the fit and still get optimal answer. The fitter only talks to the propagator when it asks "where is the track so far pointing?". (Assuming the representation space you selected is general enough, but that is usually true). Of course, relatively few people really understand them and I am not one of them. – dmckee Aug 12 '11 at 15:05

I feel like the question is equivalent to "when does acceleration have memory?". Because that's what the state variables are, the system's memory from frame to frame.

So the spin up time for a jet engine, or the motion of the air-break, might be a good example of the physical meaning of state/memory for an axial acceleration in a UAV.

Similarly a model of the hydraulics system and how it moves the control surfaces might be a good physical interpretation of the state variables for non-axial/rotational accelerations in a UAV.

I'm sure you can imagine similar sorts of state/memory for the accelerations in a car.

You say, right in your description that you probably don't need them. ("Tests show that there is almost no difference in precision of solution between both models")

You'll only be able to reasonably model these effects is if your time deltas are on the same order of magnitude (or smaller) than the time scales that these effects occur on.

And modeling them will only help if the errors introduced by them are of a similar magnitude (or larger) than the errors you're typically seeing from other sources (noise/measurement uncertainty). Otherwise they'll by hard to detect because error magnitudes add (at least in simple cases) like perpendicular vectors: E^2 = e1^2 + e2^2

Kalman filters are not black magic but the standard way of predicting how a system known only through measurements will behave.

The physics of a car is to a good approximation that of a system of second-order differential equation, except for the source term that comes from the driver's actions and from the slope of the road. The states of the car when the driver is inactive are just position and velocity, the driver's states are the angles of the wheels and the acceleration in wheel direction, the road's state is its slope.

The Kalman filter should probably have the same states, unless these are mostly predictable from the knowledge of the road, and then made part of the dynamical equation rather than independent states. The noise term then just covers the discretization errors of the differential equation for the motion and any change in driver and road states.

On the other hand, in the end only the actual performance counts, and if you have enough data to test the model under realistic conditions, you can simplify the model as long as performance does not degrade.