[Feature request]: Replace slotcar plugin with DriveToPoseController

[sauk2]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

The slotcar plugin has been the default controller for robots in RMF demos and testing. While it simulates forces and velocities realistically, it often becomes a bottleneck in larger scenarios because of the high number of computations running under the hood.

The DriveToPoseController system plugin (gazebosim/gz-sim#2679) has recently been introduced as a lighter alternative and is already available in Jetty and Ionic releases, with an open PR for backporting to Harmonic (gazebosim/gz-sim#2939).

Would like to know if the PMC is interested in moving forward with this effort - @luca-della-vedova, @aaronchongth

Open questions

• Are there specific slotcar plugin features that DriveToPoseController must replicate before full replacement?
• If we decide to go forward with the migration then do we wait for the next ROS 2 release cycle or should we fast-track the Harmonic backport and begin updating RMF demos sooner?

Implementation Considerations

• Update RMF demo worlds to use DriveToPoseController along with DiffDrive and OdometryPublisher plugins
• Update RMF demo fleet manager to communicate with the Gazebo model over the topics provided by DriveToPoseController

Alternatives

No response

Additional information

This plugin was presented in the recent Gazebo Community Meeting (September 2025) - https://vimeo.com/1123639071#t=31m7s

[Yadunund]

I like the idea of relying on DriveToPoseController but i'm not sure if it can be a replacement for slotcar. We would still need a "service" like slotcar to subscribe to PathRequest messages from RMF over ROS but we can offload the responsibility of computing headings, velocities, etc to DriveToPoseController. The slotcar "service" would then become a filter for PathRequests messages for a specific robot and translate ROS-based requests to Gz transport ones (/cmd_pose).
This slotcar service could be downstreamed to rmf_demos_fleet_adapter

[mxgrey]

I think Yadu has the right idea. At first I wondered if we should use gz-transport or zenoh inside of rmf_demos_fleet_adapter to talk directly to the DriveToPoseController, but there are other factors considered by slotcar:

• Responding to stop commands
• Responding to pause/resume commands from the traffic-light adapter
• Stopping in the presence of obstacles

But it's worth considering using DriveToPoseController to calculate the heading and velocities like Yadu said. I think to make it work we'll need to add a service to the DriveToPoseController to pause and resume.

[luca-della-vedova]

I had a look at the DriveToPose plugin and here are my findings, pardon for the verbosity but there is a lot to go through.

As others mentioned, there additional features that slotcar implements. Apart from the ones Grey mentioned we also have:

• Battery state estimation, while in principle we could use the Gazebo BatteryPlugin, our battery model is a lot simpler and is designed to match in behavior the model in rmf_battery, having this different system could make it tricky to map BatteryPlugin properties to an rmf_battery model and make sure the simulated battery and its model behave similarly.
• Fairly minor and probably not so used nowadays but we do have support for Ackermann vehicles in slotcar, where we implement a pure pursuit controller that goes over the whole path request. I don't believe DriveToPose can support Ackermann vehicles (although I haven't tried it out).

So I agree in general with Yadu and Grey that we can't replace the whole slotcar but we can perhaps replace the pure navigation / heading calculation, with the addition that some updates will be needed to make this feasible.

Now, we moved a away from full physics simulation with differential drive robots some time ago into a more kinematic approach of just applying velocity commands to models. Applying torques to wheels to move robots was sometimes more trouble than worth, when for example wheels would slip , models had wrong inertias, we had to tune mass to avoid models sliding, or even robot wheels would get stuck in the gap between lift and floor. It really doesn't matter when all we really care about is high level behavior for robots (coordination of large fleets) and not necessarily how wheels in a differential drive robot interact with the floor.

Although the description of your PR says that the DriveToPose system requires DiffDrive there is no reason for this requirement since at the end of the day all it does is publish cmd_vel messages and it could in principle work with the much simpler VelocityControl system that just subscribes to velocity commands and applies them to the robot. Again since we don't really care about differential drive itself we would probably go this route.
This is not just hypothetical, I actually tried out your new DriveToPose system with a VelocityControl robot and it indeed does navigate correctly, now the caveats that should be addressed for it to be able to be used for waypoint following:

• DriveToPose implements a simple P controller that applies a velocity command of P * error, it leaves the job of handling speed limits to the downstream system (in your case DifferentialDrive). Since VelocityControl doesn't have any speed limit parameter, robots can move extremely fast for far away waypoints. This could be fixed by adding a speed limit for linear / angular velocity to the DriveToPose controller, then I believe it would indeed have the correct navigation behavior that we would expect.
• In addition to the robot's speed limit, we also have lane specific speed limits. These are actually a lot trickier since they are received through the PathRequest message. I am not too sure how to handle this without creating a new message for DriveToPose, unless we have two separate services, one to request the path and one to set the speed limit and we call both of them (but this feels quite hacky).
• As mentioned by Grey we would need an interface (most likely through gz-transport) to allow for the pausing and resuming, for both traffic light adapters and e-stop for obstacle avoidance.
• There seem to be no concept of reversibility in DriveToPose, we would need it to make sure that reversible robots make the shortest possible turn to reach their goal, while non reversible robots always turn to face forward as is done here.