# Choosing the state vector for an EKF

Could someone help me understand the logic behind choosing a particular state space vector for an EKF?

Context: Say there is a 4 wheeled robot that operates only in 2D. It is equipped with an inertial unit (a/g/m) and wheel encoders (I understand that these alone might not satisfy accuracy constraints, but consider this as a hypothetical case).

Now, some literature has the state as [q, x, y, vx, vy]' while a few others as [q, q_dot, x, y, vx, vy]'. My question is, what is the advantage with having certain 'rate terms' as opposed to only the normal parameters? Also, what about including bias terms in there?

How do I go about selecting an appropriate state space vector for any use-case (in general)? Is there a set of intuitive/mathematical steps to consider/follow?

Thanks!

In general, I try to obey the following two rules when selecting states:

1. Only use the states necessary for control, and
2. Choose states to be measurable properties, whenever possible.

For example, on my car's dashboard I could include: suspension displacement, brake pad wear, tire wear, etc. - these are all measurable properties that are critical to operation but, provided they are within spec, they are not critical to control. The more indicators (states) I attempt to include, the more "costly" it is to monitor them. For a person, it takes time to read the gauges; for a computer, every additional matrix dimension increases the computation time for state prediction, gain calculations, etc.

Similarly, I could try to estimate fuel consumption by using a function of engine power (torque and RPM), or I could do it by monitoring fuel pump flow. In the former, fuel consumption is a function of two states, where the latter is a function of one state.

By choosing your states to be directly measurable parameters, you can use them as direct feedback, bypassing the need for observer design for that state. This in turn allows you to use reduced-order observers, which reduces both the controller design complexity for you and again the computational complexity for the controller.