Kalman Filter questions for odometry

As an experienced programmer looking into improving my odometry consistency while being interested in higher-level math, I found a Vexforum post on Kalman filters for odometry. I have studied them and am confident of implementing them on my team’s robot. However, since I have limited time, I do not want to implement them on my robot unless it makes a significant improvement in a VRC setting. Here are some questions I would like to pose to the advanced programmers and mentors on the forum to help me understand more:

1. How much does a good Kalman Filter improve odometry errors?

2. Is it better to use one multivariate filter (harder to program) to filter position, velocity, and direction from my odometry task or use multiple one-dimensional filters (easier to program) to filter the individual encoder values?

3. How much time does it take to fully implement a Kalman Filter?

1 Like

Although a short article at the moment (we hope to improve it in the near future) we have an overview of Kalman Filters here that may answer the first bulletpoint at the very least. #2 and #3 should be up to your personal discretion.



It sounds like you have already done research, but for others, WPI has a nice article on Kalman Filters:

To risk-reduce #3 (time to implement), I would suggest considering that you use WPI’s implementation as a reference point


Thank you for all the responses so far. Here is one more question I can think of. Would there be any advantage of making my own Kalman Filter over using the one in okapilib? (my team is considering switching to PROS)

Comes back to a typical deciding point in industry - “Buy Versus Build”. If you leverage the Okapilib one, you won’t have to write it yourself. You will need to ensure that you know how to use it, and there are chances that it has a bug. Whichever way you decide, I would also suggest documenting the reasoning in your Engineering Notebook.


Just to expand on this, if there is a bug in Okapilib’s implementation that you discover, this can be another good opportunity to document it in your EN. You can document how it was resolved which may include:

  • Shifting away from their implementation to your own
  • Reporting the bug to the Okapilib project
  • In addition to reporting the bug, fixing the bug and submitting a PR back to the project so that others may benefit.