3

Let's say I would like to use an EKF to track the position of a moving robot. The EKF would not only estimate the position itself but also variables affecting the position estimate, for example IMU biases, wheel radius, wheel slip and so on.

My question is, is it better to use one big EKF (state vector containing all estimated variables) or multiple smaller EKFs (each one responsible for tracking a subset of all variables to be estimated)? Or is there no difference?

As for the example above, the EKF could be split into one for tracking position, one for estimating wheel radius and slip and one for estimating IMU biases. The position EKF would of course use the estimations output from the other concurrent EKFs and vice versa.

To me it seems it would be easier to tune and test multiple smaller EKFs rather than just one big. Are there any other advantages/disadvantages (execution time, ease of debugging etc.) assuming the resulting estimates are equal in the two approaches (or close enough at least)?

Thanks, Michael

Isak T.
  • 131
  • 1

1 Answers1

1

Unless there is some cross-channel noise, like a motor power line causing noise on some sensor signal line, then it won't matter if you do one large filter or a series of small filters because the noise covariance matrix and other matrices should all be block diagonal matrices.

As mentioned in this post over at the DSP stack exchange:

In general though your Q matrix will be full, not a diagonal, because there is correlation between the state variables. For example, suppose you are tracking position and velocity in x-axis for a car. Process noise (which Q is modelling) might be things like wind, bumps in the road, and so on. If there is a change in velocity due to this noise, there will also be a change in position. They are correlated, and so the off-diagonal elements will be non-zero for those terms.

So, while there may be correlation between position and velocity for one motor, there should be no correlation between feedback noise on one motor and feedback noise on the other motor, just like there shouldn't be correlation between motor feedback noise and IMU output, etc.

Given this, the fact that noise should not be correlated across various sensed elements, you are free to break the filter down into sub-sections. There shouldn't be any change in computational speed unless you're working with software highly optimized for matrices (read: Matlab), but even then there shouldn't be a noticeable difference in speed unless you're working with a huge (thousands of elements) matrix.

I would break the filter down into subsections just for clarity - you're going to have a bigger issue if you fat-finger or misinterpret a section and you don't notice because you're working with some ridiculous 15x15 matrix or similar.

Community
  • 1
Chuck
  • 16,061
  • 2
  • 18
  • 47
  • After thinking a bit more about this, is it really enough that the "sensed elements" are uncorrelated? In the "one big EKF" approach, the G matrix (jacobian of prediction) will cause certain off-diagonal elements in the state covariance to be non-zero. As all the state variables being estimated are there to improve the position estimate, will I not lose information by splitting into many smaller EKFs? I could see there would be no difference if the states being estimated are independent. – Isak T. Aug 26 '15 at 06:36
  • Yes, you are correct. I think I misunderstood your scenario; I read "IMU" and "EKF to track the position" and thought you were after more than just horizontal position. There are a lot of quadcopter IMU questions asked here so I just assumed you'd be moving in some up/down or roll direction too. Anyways, I would say my advice still stands - evaluate your matrices to see if they are arranged in block diagonals, which would indicate independent sub systems. If so, you can split it and I would recommend you do for clarity. If you cannot split them you're stuck with what you have. – Chuck Aug 26 '15 at 11:35
  • 1
    Thank you for teaching me "fat-finger", gonna start peppering that into technical discussions! XD – Brian Lynch Oct 24 '15 at 20:53