I have setup a sensor fusion problem to estimate a classical 2d position + orientation of a wheeled mobile robot in an embedded environment.

Sensor measurements include:

  • IMU (6axis accl+gyro) @ 40Hz
  • GPS (2d position) @1Hz
  • Wheel odometry (linear v_x, angular omega_z) @ 10Hz

I do not know what is the best way to setup an EKF estimate loop when such samples are not updating synchronously.

These are the possibilities that come to my mind:

  1. Consider the filter (and thus model dynamics) timestep constant (arbitrarily fixed, let's say the fastest sensor's sampling rate, i.e. IMU @ 40Hz) and each loop do 1 predict + 3 model measurement updates with the current sensor sample stored (1 update for each sensor sample). This considers constant sensor samples between subsequent loops, effectively assuming constant ans synchronous sampling.
  2. Consider the filter (and thus model dynamics) timestep variable (maybe adding such timestep as control variable) and do 1 prediction + 1 update for each sensor sample update. Such timestep should be computed from subsequent sample timestamp difference from a sample measurement queue.

The second approach sounds more complex as it requires a prediction step for each incoming sample (besides dealing with all the timestamps computation witchcraft) but may be the most accurate as the filter updates only when we are triggered by sensor updates.

Thanks you so much for your support :)


1 Answer 1


The correct way of integrating multi-rate observations in a Kalman framework when the measurements are unavailable is to let the system evolve resorting merely to the prediction steps.

Therefore, set up the overall system rate to be equal to the fastest one and then manipulate the $\mathbf{H}$ matrix as described in https://dsp.stackexchange.com/a/60513.

  • 1
    $\begingroup$ You are basically suggesting approach 1 with correction step performed at sample update time, correct? $\endgroup$ Jan 24 at 12:30
  • 1
    $\begingroup$ Yes, right this. $\endgroup$ Jan 24 at 12:33
  • $\begingroup$ Thanks for the suggestion! Btw, my control input is varying at the same rate of wheel odometry.. I guess I should keep my control constant during the faster prediction step, right? $\endgroup$ Jan 24 at 12:44
  • $\begingroup$ If the controller runs at 10 Hz, it won't see anything faster than this. Just downsample the output of your estimator from 40 Hz to 10 Hz and integrate the result into your controller's block. $\endgroup$ Jan 24 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.