CodeTheRobot

Ubuntu Linux for Robotics · Lesson 95 of 96

Building full AMR robots

Project: a differential-drive AMR from packages to a deployed, self-starting robot.

Estimated time · 120–180 min

Learning goals

What you will understand

  • Explain building full amr robots in your own words
  • Use it in a small workstation example
  • Verify the result instead of assuming it worked

Understand the idea first

The mental model

A complete autonomous mobile robot on Ubuntu combines everything: an Ubuntu robot computer, a description package (URDF), sensor drivers (lidar, IMU, camera), a base controller, state estimation (EKF), Nav2 with a saved map, a bringup package and a systemd service that starts it all. Build each layer, test it alone, then combine.

Write acceptance checks before you begin: starts by itself in under 60 seconds from power on, drives to five goals without collision, recovers from a blocked path, stops within half a second if commands stop, logs to disk without filling it. Record the results so that a second robot can be verified the same way.

Guided lesson

Work through these steps

  1. 1.

    Open a terminal and record the current state before changing anything.

  2. 2.

    Read the building full amr robots commands and predict what each one does.

  3. 3.

    Run the commands one at a time and compare each output with your prediction.

  4. 4.

    Write the commands that worked in a setup note you can repeat later.

Worked example

Read it before you run it

sudo systemctl enable --now robot-bringup.service
# The robot software starts at boot.
ros2 launch amr_bringup bringup.launch.py map:=$HOME/maps/warehouse.yaml
# One command starts drivers, EKF, Nav2 and RViz2 (for testing).
ros2 lifecycle get /bt_navigator
# Confirm Nav2 is active.
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {header: {frame_id: map}, pose: {position: {x: 4.0, y: 1.0}, orientation: {w: 1.0}}}}"
# Send a test goal.
journalctl -u robot-bringup.service -b --no-pager | tail
# Read the service log after the run.

What the example is doing

  1. 1.Lines without sudo only inspect or change files you own; sudo authorizes a system-wide change.
  2. 2.Read command output before moving to the next line. Stop if names, versions, disks, or paths differ from the lesson.
  3. 3.Comments beginning with # explain safety checks and are not executed by the shell.

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.

goalMOBILE ROBOT

Demo for Building full AMR robots. Expected result: The AMR starts and reaches the goal

Practice code

Now type it yourself

Open a terminal, run the starter line by line (or save it as practice.sh and run bash practice.sh), and replace every TODO with your own command.

# TODO: start the AMR bringup launch file with the map argument set to $HOME/maps/warehouse.yaml

Expected output

The AMR starts and reaches the goal
Stuck? Show the full solution (try it yourself first)
ros2 launch amr_bringup bringup.launch.py map:=$HOME/maps/warehouse.yaml

Expected result

How you know it worked

  • Each command completes without an unexplained error.
  • Your notes contain the command, the important output, and what it proves.

Practical exercise

Apply the lesson

Assemble the AMR (simulation first), run the five acceptance checks, write a one-page report with results and limitations, and list five things to test on the real robot first.

Before you continue

  • You recorded the starting state
  • Every command and output is understood
  • The change can be repeated from your notes

If something goes wrong

A command says permission denied.

Check ownership and permissions first. Do not add sudo unless the command changes a documented system location.

A command or package is not found.

Check spelling, Ubuntu version, enabled repositories, and whether the previous installation command succeeded.