Robot rotates in place despite having valid global path observed in Open RMF demos

[Armstrongdematic]

Hi everyone,

I’m encountering an issue while running the Open RMF (Robotics Middleware Framework)
Problem Description

The robot often rotates in place (on its own axis) even when it has already received a valid global path from the planner. This unnecessary rotation occurs in several scenarios:

While navigating to a goal/task – the robot sometimes stops mid-path and rotates in place before continuing.

After completing a task – before heading to the next goal, it rotates in place.

In between the path – even when already moving toward the goal, it may pause and rotate without any visible obstacle.

In multi-robot scenarios – if one robot is behind another and receives a global path that simply moves straight ahead, it still rotates in place before starting to follow the path, instead of proceeding directly.

Context

This behavior is observed when running the standard Open RMF demos using the default configurations. There are no obvious obstacles or dynamic entities that would require reorientation.
Question

Is this expected behavior due to the local planner or RMF navigation settings?

Could it be related to how initial orientation or path heading alignment is handled?

Are there recommended parameters to tune in order to prevent these unnecessary in-place rotations?

Any insights or suggestions for further debugging would be greatly appreciated. If helpful, I can provide logs, configurations, or specific demo scenarios where this is reproducible.

Thanks in advance!

[mxgrey]

What versions of the repos are you using? The latest main branches of rmf_traffic, rmf_ros2, and rmf_simulation have a series of fixes to known bugs that were causing unnecessary rotations.

[Armstrongdematic]

Hi @mxgrey,

Thanks for the reply! I’m currently using version 2.0.3 of the repos (rmf_traffic, rmf_ros2, and rmf_simulation).

Is this version considered up-to-date with the fixes you mentioned for the unnecessary rotations? If not, could you point me to the recommended version or branch to upgrade to?

Also, if there are any specific parameters I should tune in 2.0.3 to mitigate the in-place rotations, I’d appreciate your guidance.

Thanks again!

[mxgrey]

For rmf_traffic, rmf_ros2, and all of their dependencies I always recommend using the latest main branch. Those main branches are compatible with humble, jazzy, kilted, and rolling ROS distros.

For rmf_simulation, you'll need to use the branch that corresponds to the distro of ROS that you're using. If you're using the jazzy distro of ROS, then you'll need to use the jazzy distro of rmf_simulation. For kilted use the kilted branch. The only exception is that you should use the main branch if you're using the rolling distro of ROS.

The rotation fixes should be in rmf_simulation for the jazzy, kilted, and main branches. Jazzy has the lowest version number at 2.3.3, so the version you're using may be too old to have the fixes.

[Armstrongdematic]

Hi @mxgrey,

Thanks again for the clarification and support!

I’m currently using ROS 2 Humble, and the simulation is also running on this system. As a result, I'm not able to switch to the jazzy branch of rmf_simulation at the moment.

If there are any workarounds or parameter tuning suggestions that can help mitigate the unnecessary in-place rotations while staying on the Humble branch, I’d greatly appreciate any guidance.

Also, I have a follow-up question:
Does Open RMF currently have full support for ROS 2 Jazzy?
The last time I tested on Jazzy, I encountered build issues with the Open RMF demos, so I had to revert back to Humble. If Jazzy is now fully supported, I’d be open to upgrading in the future.

Thanks again for your help!

[mxgrey]

Sorry for the late reply, this fell deep into my backlog this month.

As a result, I'm not able to switch to the jazzy branch of rmf_simulation at the moment.

What we've done in the past when we have a deployment frozen on humble is to do our simulation-based testing in jazzy (or later) and then port our fleet adapter logic over to humble for the final testing on the hardware and then subsequently to be deployed. In principle there's a risk that there could be substantial differences in some underlying dependencies between jazzy and humble which could lead to inconsistent test results, but we never noticed any issues with that in our own testing.

Does Open RMF currently have full support for ROS 2 Jazzy?

Yes, we have stable support for jazzy and kilted. Rolling is currently broken for simulation because Gazebo migrated to Qt6 and we haven't resolved that on our end yet. If you run into build problems on jazzy or kilted, I recommend making absolutely sure that your system and its packages are clean. These days using a docker image or some other kind of container is very useful for this.