I would like to use the diff_drive_controller package for my real robot. This robot doesn't have any wheel encoders so I configured the controller as open loop. Because I'm in an open loop, I can't use a PID controller and consequently can't correct commands based on feedback from wheels.

Depending on the kind of ground or even the linear velocity of the robot, the angular velocity is not often accurate (due to friction mainly).

For example :

  • if I send 1 rad/s to the controller in my house, it is pretty accurate
  • if I send 1 rad/s to the controller on the grass, it is way slower

Consequence : using NAV 2 with this controller becomes a nightmare

How can I fine tune the controller to get a nicer behavior ? Should I implement something in my hardware interface (maybe based on the odometry coming from my ekf filter) ? Should I fine tune the wheel_separation_multiplier ? Something I'm not aware of ?


1 Answer 1


Maybe I'm wrong, but can't you use the EKF as described here? Open_loop only means that the odometry is calculated from the commands instead of reading back sensor values. You anyways will need some sensor fusion on top of it, using GNSS or IMU data, and I wouldn't do that inside the hardware component.

  • $\begingroup$ I use an EKF as described in this tutorial but I don't have something saying "hold on, I asked 3m/s but in fact I see that it is actually 2m/s because of the ground so let met send 4m/s to be more accurate". Is there something magic like this ? $\endgroup$ Nov 16, 2023 at 8:58
  • $\begingroup$ sorry, I don't have experience with the Nav2 stack, if it is possible to "close the loop" then. $\endgroup$ Nov 17, 2023 at 9:35

Your Answer

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

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