Inquiry about inter-floor movement

[psi0000]

Hello, I am currently setting up an open-rmf environment.
I would like to ask if there is any feature that allows robots to move between floors without using a lift.

It seems that the system automatically relies on the lift mechanism for inter-floor movement.
However, in my case, I would like to enable floor transitions using something else — for example, an escalator, or even a direct change in the robot’s z-axis position (instant movement).

If such functionality exists, could you please let me know how it can be controlled or implemented?

[mxgrey]

Within the rmf_traffic library, there's nothing to prevent you from connecting waypoints that are on separate levels. Theoretically you could create a waypoint at the bottom of the stairs/escalator (stairs_L1) and then a waypoint at the top of the stairs (stars_L2) and connect them together, like in this diagram:

The only blocker is that the traffic-editor UI doesn't provide a UI for making connections between anchors on different levels. The only reason we don't provide that UI is the core team has never had a use case where it was needed, and we haven't had a community contribution for it.

I would be open to a PR to the traffic-editor or site editor that adds the ability to connect waypoints that are on different floors. I think the hardest part is deciding what the UX should be like. For lifts it's pretty straightforward: We make the lift vertices available to connect to from every floor. For stairs/escalators it's not obvious to me... Should the user have to create a vertex on each level in the right position and then use a special UI tool to connect them? Should there be a tool specifically for drawing stairs/escalators as a special kind of lane?

Alternatively you could choose to do some post-processing on the nav graph that gets generated. You could use a naming convention for your stair-related waypoints, e.g. stair_<name>_bottom / stair_<name>_top , and then you could run a script on the 0.yaml nav graph file that gets generated by the building map generator where you add items to the lanes: array to connect matching endpoints of stair_<name>_bottom / stair_<name>_top. You could also add "docking" events to those lanes if you need the robot to perform a special behavior when going up or down.

[TheoFCruz]

Hello, I am having a similar problem and came across this issue. If I understand correctly, the nav graphs separate vertices and lanes by levels, and the lanes: array references the vertices by their index within that specific level. Wouldn’t that make the connections you suggest infeasible?

I was thinking about other solutions and considered that having a “docking” event on a lane within a single level could allow commanding the robot to change levels. However, if those vertices are not connected in the graph, they wouldn’t be considered by the path planner, which is a major problem.

In my case, the movement would be strictly vertical, so maybe “virtual” lifts would suffice—that is, no actual lift structure would exist, but the robot would listen to lift requests and change its height level accordingly. Would this option be considered during path planning? For example, if a robot had to go up and then down to reach its goal while avoiding another agent?