Hey everyone, I’m integrating a differential drive AGV (tugboat-style, ~82kg) with Open-RMF using VDA5050 over MQTT. Got the fleet adapter running, nav graph working, robot shows up on the dashboard. Now hitting some questions I couldn’t find clear answers for:
1. Traffic editor — how do you handle curves for a DIFF robot?
Since RMF passes waypoints one by one to the fleet adapter, I understand that placing intermediate waypoints before curves gives the Nav2 planner room to maneuver. But is there a recommended way to draw this in traffic editor? Do people place extra vertices before corners, or is there a smarter approach for robots that can’t make tight turns?
2. Is there any standard or convention for mapping in traffic editor?
Things like: how many waypoints per corridor, how far apart they should be, whether unnamed intermediate vertices are fine or if everything should be named. Couldn’t find anything beyond the basic docs. What does your nav graph look like in practice?
3. AMCL integration — what problems did you run into?
We’re using AMCL for localization. Curious what issues others hit when integrating with Open-RMF — coordinate frame mismatches, map origin issues, anything with the transform between the robot map and the RMF nav graph. What bit you and how did you fix it?
4. Anyone running Open-RMF with VDA5050?
Most examples I found use REST API between the fleet adapter and the robot. We went with VDA5050 over MQTT directly. Wondering if anyone else did this and what the experience was — particularly around is_command_completed logic, order sequencing, and keeping the RMF schedule in sync with what the robot is actually doing.
More to your question, we do have a plan to support curves for lanes and robot trajectories in the next generation traffic system. We don’t have any plans to introduce support for curved lanes in the “current generation” since it would require substantial work spread across the traffic editor and rmf_traffic. We’d be open to PRs to introduce these capabilities into the “current generation”, but the core Open-RMF development team is focusing our day-to-day efforts on getting the next generation across the finish line since that will come with far-reaching improvements that are not feasible in the current generation.
2. Is there any standard or convention for mapping in traffic editor?
In case you didn’t see it, there’s a guide on how to build navigation graphs to handle certain recurring needs.
how many waypoints per corridor
You generally shouldn’t insert waypoints that aren’t serving a specific function. Waypoints should be inserted in locations where a robot may need to wait (e.g. wait at a waypoint for traffic to pass before crossing an intersection), or where one traffic lane connects to another traffic lane, or at a position that might be a task destination.
whether unnamed intermediate vertices are fine or if everything should be named
Unnamed vertices are totally fine, especially intermediate vertices. The only downside to not naming a vertex is you won’t be able to use it as a task destination.
coordinate frame mismatches, map origin issues, anything with the transform between the robot map and the RMF nav graph
The traffic editor (and these days the site editor) are meant to help with this. For the traffic editor there’s a guide that explains how to align a robot map with your floor plan and then extract the coordinate transform.
One issue that’s not resolved yet is the fact that maps generated by SLAM can have regional distortions that are not accounted for by a simple linear transformation. There’s an open issue ticket to address this for the site editor, but we don’t currently have any resources committed to it.
4. Anyone running Open-RMF with VDA5050?
I believe @sauk2 has done some extensive work related to this.
Thanks for the detailed response! This clarifies a lot.
On the DIFF question: Yes, our robot is a differential drive robot —
so turning in place is mechanically possible. The challenge we’re facing
is not about minimum turning radius per se, but about path quality and predictability when RMF delivers waypoints one at a time to Nav2.
In practice, the robot follows Dubins path geometry. Even though it can
rotate in place, our operational preference is to avoid stop-rotate-proceed
maneuvers in the middle of corridors — both for efficiency and because the
tugboat carries load. We want smooth, continuous curvature paths between
waypoints where possible, with in-place rotation reserved for tight corners
where there’s no alternative.
The issue with the current waypoint-by-waypoint delivery
(easy_full_control) is that Nav2 replans from scratch at each waypoint
with no awareness of the next segment. A Dubins path planner can produce
a smooth arc between two poses if it knows both the current and the next
heading — but it can’t do that if it only receives one destination at a time.
This is exactly why we are migrating to RobotCommandHandle::follow_new_path()
— receiving the full path at once allows us to:
Pre-process the waypoint sequence with Dubins geometry before sending
to the robot
Pass the complete path as a single multi-node VDA5050 order (we’re
integrating directly via VDA5050 over MQTT, no REST layer)
Let the robot’s internal planner (Nav2 + MPPI) execute with full
trajectory context
On the next-gen traffic system: Very glad to hear curves are planned.
Our Dubins preprocessing is essentially a workaround for what the next-gen
should handle natively. We’d be happy to share our implementation as input
for that work when the time comes.
On SLAM distortions: This matches what we observed. We’re using 4-point nudged transforms which work well near the reference points but show drift
toward the edges of the map. We’ll follow the open issue on the site editor.
On VDA5050: Looking forward to connecting with @sauk2 — direct VDA5050
integration without a REST intermediary has some specific challenges around orderUpdateId sequencing, is_command_completed detection via nodeStates/edgeStates, and factsheet-based auto-discovery that would be
great to compare notes on.
Are you still integrating rmf? Just wanted to ask about fleet management system, like task sheduling and such, just wanted to think, can I offer any solution or maybe something, maybe with math-logic at this distributed system
Sorry if its offtopic, will not bother more, if its not suitable, just let me know if so