Teaching ROS 2 With One Robot: An 8-Week Course Outline for Universities

TL;DR: This guide gives you a ready-to-run outline for a teaching ROS 2 university course built around a single mobile robot shared by up to 20 students. It combines simulation-first exercises, paired hands-on rotations, and a field project. Each of the eight weeks includes objectives, exercises, and grading criteria. The approach assumes one Leo Rover (or a similar UGV), Gazebo for parallel simulation work, and Git-based team workflows. You will find a final project brief and recommended course-pack materials at the end.

Why teaching ROS 2 at university level needs a different structure

ROS 2 is widely used in research and industrial mobile robotics. Yet most departments face the same constraint: budgets allow one, maybe two, physical robots per cohort. A teaching ROS 2 university course that ignores this reality either turns into a lecture series with slides, or a queue in the lab. Neither produces engineers who can debug a real DDS transport issue or tune a Nav2 behavior tree.

The outline below solves the scarcity problem by treating simulation as the primary development environment and the physical robot as a validation station. Students work in pairs, rotate through hardware slots, and submit reproducible packages. The teaching ROS 2 university course structure assumes 8 weeks, 4 contact hours per week, hardware slots scheduled separately from regular contact time, and prior exposure to Linux and Python or C++.

What you need before week 1

The prerequisites keep setup friction low and let students focus on ROS 2 concepts:

• One mobile robot with a ROS 2 stack, wheel odometry, a camera, and a suitable ranging sensor for mapping and navigation. A Leo Rover can be configured with ROS 2 Humble support, a Raspberry Pi 4 compute unit, and documented robot-description resources, which removes a week of bring-up work.
• Ubuntu 22.04 workstations with ROS 2 Humble and Gazebo Fortress installed. One workstation per student pair.
• A shared Git server (GitLab or Gitea self-hosted works well).
• A robotics lab area of at least 4 by 4 meters with obstacles and printable ArUco markers.
• Wi-Fi on a dedicated SSID or a router isolated from campus networks to avoid DDS discovery noise.

How to run the course with one robot and twenty students

The rotation model is the backbone of this teaching ROS 2 university course. Students work in pairs (10 pairs from 20 students). Each pair gets one 30-minute hardware slot per week for validation, scheduled outside regular contact time. Everything else happens in Gazebo, configured to mirror the real robot’s URDF, sensors, and topic namespaces as closely as practical.

The hardware booking discipline is what keeps this workable:

1. Simulation gate: a pair cannot book the robot until their code passes a simulation checklist (topics publishing, no runtime errors, target behavior visible in RViz).
2. Time-boxed slots: 30 minutes on hardware, logged with a rosbag2 recording that becomes part of the submission.
3. Handover protocol: each pair leaves the robot charged at its charging station, with a clean workspace and the last working commit tagged in Git.

This mirrors how field robotics teams actually operate: most iteration happens in simulation, and hardware time is treated as a scarce, scheduled resource.

What each of the 8 weeks covers

Week 1: ROS 2 fundamentals and the DDS graph

Objectives: understand nodes, topics, services, actions, and how DDS discovery works. Students install ROS 2 Humble, run turtlesim, and inspect the graph with ros2 topic, ros2 node, and rqt_graph.

Exercise: write a publisher and subscriber pair in Python (rclpy) that exchanges std_msgs/String, then rewrite the subscriber in C++ (rclcpp). Grading: both nodes build with colcon, run without warnings, and pass a provided launch_testing integration test.

Week 2: URDF, TF2, and simulation setup

Objectives: read a URDF, understand the TF tree, and launch the robot in Gazebo. Students clone the Leo Rover simulation packages, spawn the robot, and visualize its TF frames in RViz.

Exercise: add a virtual sensor (a downward-facing camera) to the URDF and confirm its camera link appears in /tf and that it publishes an image topic. Grading: correct joint hierarchy, no TF warnings, image topic at the configured simulation update rate.

Week 3: Teleoperation and rosbag2

Objectives: drive the robot with teleop_twist_keyboard and a joystick, then record and replay data. This is the first week pairs book hardware slots.

Exercise: record a 2-minute rosbag2 of /cmd_vel, /odom, and /camera/image_raw on the physical robot, then replay and inspect the recorded trajectory in RViz. Grading: bag playback contains the required topics and timestamps, and the recorded odometry trajectory is visible and consistent in RViz.

Week 4: Sensor processing and computer vision

Objectives: process camera streams with OpenCV inside a ROS 2 node. Students use cv_bridge and detect ArUco markers.

Exercise: publish the marker pose as a geometry_msgs/PoseStamped in the camera optical frame, then transform it to the base_link frame using TF2. Grading: after camera calibration, position error is within 5 cm at 1 meter distance in simulation; validated on hardware during the pair’s slot.

Week 5: Nav2 basics and the behavior tree

Objectives: launch the Nav2 stack, set a goal in RViz, and understand the default behavior tree. Students tune costmap parameters and inflation radius.

Exercise: create and save a 2D occupancy-grid map with slam_toolbox in simulation, localize on that map, then navigate between three waypoints. Grading: robot reaches all three within 30 seconds each without collisions; any recovery behaviors must be explained in the submission.

Week 6: SLAM on real hardware

Objectives: run slam_toolbox or Cartographer on the physical robot with its actual sensors. This week doubles the hardware slot to 60 minutes per pair, scheduled outside regular contact time.

Exercise: map the lab area, save the map, then relocalize and navigate. Grading: submitted map file, a rosbag2 of the mapping run, and a launch file that reproduces the navigation demo.

Week 7: Custom behavior and the ROS 2 lifecycle

Objectives: write a managed (lifecycle) node and integrate it with a custom behavior tree node in Nav2. Students learn why lifecycle nodes matter for deterministic startup in field robotics.

Exercise: implement a “patrol” behavior that cycles between waypoints and pauses when an ArUco marker is detected in front of the robot. Grading: correct lifecycle transitions logged, patrol resumes after marker is removed.

Week 8: Final project presentations

Objectives: integrate everything into a field task. Each pair demos their project on the physical robot in a 15-minute slot, with the rest of the class watching.

What the final project should require

The final project brief in this teaching ROS 2 university course asks each pair to solve one of three tasks, all inspired by common research robotics use cases:

• Inspection patrol: autonomously visit four map-frame waypoints marked with ArUco markers, log a timestamped image at each, and return to start.
• Object localization: detect a colored object, approach it, and report its map-frame coordinates.
• Follow-me mode: track and follow an ArUco marker held by a person, keeping a 1-meter distance.

Grading weights that have worked in similar courses: 30% simulation reproducibility (fresh clone builds and runs), 30% hardware demo, 20% code quality and documentation, 20% written report explaining architecture choices and failure modes observed.

What materials to distribute to students

A downloadable course pack removes friction. The recommended contents:

• A course_ws colcon workspace template with starter packages for each week.
• The robot URDF and Gazebo launch files, obtained from the robot manufacturer’s GitHub repositories.
• A Dockerfile pinning ROS 2 Humble and Gazebo Fortress, so students on different machines get identical behavior.
• A grading rubric per week, published in advance.
• A hardware booking spreadsheet with charging status and last-known-good commit hash.

Publishing rubrics in advance changes student behavior. They stop guessing what “good” means and start reading the launch_testing assertions.

How to adapt the course when constraints change

The 8-week outline assumes one robot and 20 students. Two common variations:

• Two robots, 20 students: shorten week 3 hardware slots to 20 minutes but run them in parallel, and add a swarm-coordination exercise in week 7 using ROS 2 namespaces.
• One robot, 30+ students: switch to triads instead of pairs, and require every hardware slot to be video-recorded so absent teammates can review it.

For departments that already run a robotics track, this course can slot in as a second-semester module after an introductory Python and Linux course. For details on educational deployments and lesson formats, see Fictionlab’s education applications page.

Frequently asked questions

Can this course run entirely in simulation if no robot is available?

Yes, weeks 1, 2, 4, 5, and 7 work fully in Gazebo. You lose the field validation in weeks 3, 6, and 8, which is where students learn that real sensors are noisier and TF timing matters. Simulation-only versions still teach ROS 2 concepts, but graduates will need bring-up experience elsewhere.

Why ROS 2 Humble and not Jazzy or Rolling?

Humble is an LTS release supported until May 2027 (per ROS 2 release documentation). For an 8-week course repeated across semesters, LTS stability and compatibility with an existing teaching platform can outweigh the newer features in Jazzy. Jazzy is also an LTS release, so it is a suitable choice for new deployments where the robot drivers, simulation packages, Nav2, and slam_toolbox have been tested on it. Rolling is intended for development and is not recommended for a repeatable course environment.

How much prior programming experience do students need?

Working knowledge of Python and basic Linux command line. C++ is used in week 1 and optionally later, so a one-week C++ primer helps if students have never seen it. Object-oriented concepts are helpful but not required for the core exercises.

What if a pair’s code breaks the robot during their slot?

Enforce two rules: no direct pushes to the robot’s main branch, and every hardware run starts by checking out a Git tag. If a run corrupts the filesystem, reflash from a known image. Budget 2 hours of instructor time per week for exactly this.

How do you prevent students from copying each other’s code?

The rubrics reward reproducibility and written explanation of design choices, not just working demos. Two pairs can submit similar code, but the reports will differ. Instructors familiar with pair-based grading catch shared code quickly.

Is Gazebo Fortress mandatory, or can students use Gazebo Classic?

Gazebo Fortress is a supported LTS release and is commonly used with ROS 2 Humble. Gazebo Classic reached end of life in January 2025 per the Open Robotics deprecation notice. New Humble-based courses can use Fortress; courses based on newer ROS 2 releases should evaluate the corresponding supported Gazebo release, such as Harmonic.

Can this outline scale to a full semester (15 weeks)?

Yes. Add weeks on multi-robot systems (ROS 2 namespaces and DDS domain IDs), MoveIt 2 for a manipulator arm, ros2_control internals, and a longer field-deployment project. The 8-week version is the minimum viable teaching ROS 2 university course.

Get the Leo Rover into your teaching lab

If you are planning a ROS 2 course and want a platform with documented URDFs and ROS 2 support, review the education deployment options on the Fictionlab education page and request a quote for your department.