How to Use This Course

How to Use This Course: Videos, Repository, Labs and Checkpoints

Goal

Learn the operating manual of the course itself, so you never wonder "where am I supposed to look?"

What You Will Build

Your personal workflow for the next weeks.

Why This Matters

This product is a lab, not a playlist. The repository is the primary material; videos walk you through it; lessons tell you exactly where to put your hands. Students who treat it as "watch first, maybe code later" lose most of the value.

Two Things About the Videos and the Editor

The written lesson is the source of truth, not the video. Some videos were recorded earlier, on a plain ROS2 setup, so on screen you may see a different workspace path (for example ~/ros2_ws) instead of this lab's containerized workspace (/lab_ws/training_ws). The concepts and the commands are identical — just follow the paths and commands written in each lesson's .md / commands.md, which are adapted to this lab. When the screen and the lesson differ on a path, the lesson wins.

VS Code is the standard editor. You create and edit files (a .cpp, a CMakeLists.txt, a YAML config) in VS Code. Because the lab workspace /lab_ws is bind-mounted, you can edit its files with VS Code on your host (or via Dev Containers: Reopen in Container, Module 2) and your changes are instantly live inside the container — no need to edit with vim in the container terminal. Rule of thumb: edit in VS Code, run in the container (./scripts/lab shell / exec).

Architecture Layer

None — course mechanics.

Files You Will Touch

  • labs/module_XX_*/ — each module folder contains:
    • README.md — what the module builds and why
    • module_objective.md — the one-paragraph goal
    • commands.md — every command, copy-pasteable
    • lessons/NN_*.md — the lessons (this file is one of them)
    • checkpoints/module_XX_checklist.md — how you verify yourself

Files You Should Not Touch Yet

Commands

The whole course runs through one CLI:

./scripts/lab doctor            # is my environment healthy?
./scripts/lab build             # build image + workspace
./scripts/lab start demo        # the Module 0 demo
./scripts/lab start module_03   # each runnable module has a start target
./scripts/lab check module_00   # automated module verification

Step-by-Step Instructions

For every lesson, follow the same loop:

  1. Read Goal / What You Will Build / Why This Matters (2 minutes).
  2. Locate — open the files listed under Files You Will Touch.
  3. Run the commands.
  4. Observe — compare with What You Should See.
  5. Modify the small parameter the lesson suggests, re-run, observe the difference.
  6. Adapt — read How to Modify This for Your Own Application and add one line to your personal adaptation notes.
  7. Check — the lesson checkpoint, then the module checklist at the end of the module.

What You Should See

A rhythm: every lesson ends with something you ran or changed, not just something you read.

How to Modify This for Your Own Application

Two habits that transfer directly to professional work: (1) keep an engineering log (what you changed, what happened); (2) never skip a checkpoint — in industry this is called commissioning discipline.

Common Mistakes

  • Copy-pasting commands from the video instead of commands.md (videos may abbreviate; the repo is the source of truth).
  • Editing files under src/ "to see what happens" before Module 3. You will get your chance — with guidance on what is safe to touch.

Checkpoint

You know the 7-step lesson loop and where commands.md lives for each module.

Expected Output

None.

Next Step

Windows user → 05_setup_windows_11_wsl2_docker_vscode.md Ubuntu user → 06_setup_ubuntu_2204_docker_vscode.md

Complete and Continue