ROS 2 for Mobile Robots

From never having used ROS 2 to driving a real robot with it.

Note

11 topics are written — all 10 of Part 1, plus topic 11 of Part 2. Click a title to read it. Topics 12–18 are still an outline.

Who this is for

People who already have the hardware and want it moving under ROS 2 — engineers building their own AGV/AMR, or teams migrating from an older system.

No ROS experience needed, but you should be comfortable with basic Linux (open a terminal, cd, ls, edit a file).

Part 1 — Foundations

The goal here is to be able to read what the system is doing. No hardware required — one computer is enough.

#	Topic	Covers
1	What ROS 2 is, and when not to use it	The problem it solves · what it costs you · jobs where plain code is simpler
2	Installing Ubuntu and ROS 2	Matching versions · installing Humble · proving it works before moving on
3	Nodes, topics, messages	Start with `turtlesim` to see it · who publishes, who subscribes, where data flows
4	Command-line tools	`ros2 node` · `ros2 topic` · `ros2 param` · `rqt_graph` — how you inspect a running system
5	Workspaces and your first package	`colcon build` · folder layout · the `source` step everyone forgets
6	Writing a publisher and subscriber	Your first node (Python) · consuming data from another node
7	Launch files and parameters	Starting many nodes at once · moving settings into YAML · changing values without touching code
8	tf2 — coordinate frames	`map` → `odom` → `base_link` → sensors · why a mobile robot cannot skip this
9	RViz	What it can show · configuring it for what you need · using it to find faults
10	QoS — the most common trap	Why “looks fine but no data” happens · sensor data vs reliable profiles

Part 1 — Foundations

Part 2 — Real hardware

11. Make the wheels turn first

Tip

Topic 10 sits at the end of the foundations on purpose — it is a leading cause of beginners losing a whole day with perfectly correct code. ros2 topic list shows the topic, but ros2 topic echo prints nothing.

Part 2 — Connecting real hardware

Important

🔒 This section is for customers who bought the hardware from us — it needs a password. Ask us for one. Part 1 above is free and needs nothing.

The content here refers directly to the specifications and settings of the equipment we supply.

Ordered the way a robot actually gets built — make the wheels turn first, then teach it where it is.

#	Topic	Covers
11	Make the wheels turn first	Drive/motor over RS485 · sending velocity from ROS 2 · confirming direction
12	Odometry from encoders	Reading encoders · publishing `/odom` · the `odom → base_link` transform · matching measured distance
13	Robot model (URDF)	Placing wheels and sensors · `robot_state_publisher` · checking it against the real robot in RViz
14	LiDAR and SLAM	Connecting a LiDAR · choosing one for your area size · mapping with `slam_toolbox`
15	Navigation with Nav2	Costmap setup · tuning speed and stopping distance · sending goals
16	Safety sensors	Safety laser scanner · wiring it to the emergency stop · warning vs stop zones
17	Magnetic tape guidance	The non-SLAM alternative · when to prefer it over LiDAR · reading tape sensors into ROS 2
18	Power and charging	Sizing the battery for a shift · automatic docking · battery state in ROS 2

Why this order

Part 1 before Part 2, because when real hardware refuses to work the first question is “how far did the data get?” — and that is unanswerable if you cannot read ros2 topic and tf. Without it you are guessing between a bad cable, a bad drive, and bad code.

Within Part 2, do not skip 11–13. Many people start at SLAM because it looks the most impressive, then get stuck on a distorted map. The cause is usually not the LiDAR — it is inaccurate odometry. The map will be wrong no matter how good the LiDAR is.