ROS 2 Lyrical Luth · Lesson 67 of 86

Multi-floor navigation

One map per floor, switching maps, elevators and floor-aware goals.

Estimated time · 60–90 min

Learning goals

What you will understand

Explain multi-floor navigation in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

Nav2 navigates within one 2D map. For several floors keep one map per floor and switch the active one when the robot changes floor, using the map_server's load_map service, then re-set the initial pose in the new map. A floor-aware layer in your own code decides which floor a goal belongs to.

The robot rides an elevator using an integration node (a door or elevator API): navigate to the elevator, request the floor, wait, drive out, load the new map, and re-localize. Treat each step as a separate action so a failure can be handled.

Guided lesson

Work through these steps

1.
Source the ROS 2 Lyrical environment in a fresh terminal.
2.
Read the multi-floor navigation example and identify what each line does.
3.
Build only the affected package, source the workspace overlay, and run the example.
4.
Inspect the result from a second terminal with the ros2 CLI or RViz2 and compare it with the expected result.

Worked example

Read it before you run it

ros2 service call /map_server/load_map nav2_msgs/srv/LoadMap "{map_url: /maps/floor2.yaml}"
# Switch the active map to floor 2.
ros2 topic pub --once /initialpose geometry_msgs/msg/PoseWithCovarianceStamped "{header: {frame_id: map}, pose: {pose: {position: {x: 1.0, y: 2.0}, orientation: {w: 1.0}}}}"
# Tell AMCL where the robot is after leaving the elevator.
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {header: {frame_id: map}, pose: {position: {x: 5.0, y: 3.0}, orientation: {w: 1.0}}}}"
# Navigate on the new floor.

What the example is doing

1.The ros2 commands query the running graph; they do not prove that a node's internal behavior is correct.
2.Build from the workspace root, then source install/setup.bash so the shell can discover the new package.
3.Use a second sourced terminal to inspect nodes and interfaces while the example runs.

Watch it run · Mobile robot

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into your ROS 2 package, replace every TODO, then build with colcon build and run it from a sourced terminal.

# TODO: load /maps/floor2.yaml through the map_server load_map service (nav2_msgs/srv/LoadMap)

Expected output

result: true

Stuck? Show the full solution (try it yourself first)

ros2 service call /map_server/load_map nav2_msgs/srv/LoadMap "{map_url: /maps/floor2.yaml}"

Expected result

How you know it worked

ROS_DISTRO is lyrical in every terminal used for the exercise.
The complete package from the exercise builds and the expected graph entity appears in a second terminal.

Practical exercise

Apply the lesson

Prepare two maps (floor1, floor2) and simulate an elevator as a location where the map is switched. Write a small node that switches the map, sets the initial pose and sends the next goal.

Before you continue

ROS_DISTRO reports lyrical in every terminal you used
The example builds and runs without errors
You checked the result with a ros2 command, RViz2 or a test, not just by reading the code

If something goes wrong

ros2 cannot find a package or executable.

Source /opt/ros/lyrical/setup.bash, build from the workspace root, then source install/setup.bash in that terminal.

Nodes run but cannot discover each other.

Confirm both terminals use Lyrical, the same ROS_DOMAIN_ID, and compatible network/discovery settings.