Most of building a robot is debugging it.
Botopsy Lab drops you into a broken ROS 2 system, gives you the real tools, and makes you find the fault. Then tests check your fix.
How a lab actually goes
Every case runs the same way I ran it on a real robot: see the symptom, gather evidence, change one thing, prove it.
You get a symptom, not a checklist
The robot does something wrong. Obstacle shows up on the wrong side, a topic goes quiet, the map never loads. That is all you start with.
You look before you touch
Real ROS tools. tf2_echo, ros2 topic echo, the node graph, the logs. You find the actual fault instead of guessing and restarting things.
You change the smallest thing
One line in a URDF, one QoS setting, one namespace. The fix is usually tiny. Finding it is the hard part, and that is the point.
Tests decide, not you
Automated checks run against the repaired system. They pass or they do not. No completion buttons, no vibes.
The main track
ROS 2 Systems Debugging
Learn ROS 2 by diagnosing and repairing robot systems that fail the way real ones do.
- ROS graph diagnosis
- QoS reasoning
- TF timing
- Launch configuration
- Executor analysis
- Incident reconstruction
- Modules
- 8
- Repair incidents
- 16
- Transfer challenges
- 8
- Capstone
- 1
- Level
- Beginner to intermediate
- Runs on
- ROS 2 Jazzy
It runs in the browser. You do not install ROS.
The whole thing is a real workspace: editor, terminal, and a Gazebo sim of the broken robot. Guided cases open with one file and one check so you are not lost. Once you are past those, you get the full workspace.
obstacle alignment restored
- Visible tests8 / 8
- Hidden regression tests3 / 3
- Fault foundTF rotation
ROS 2 Jazzy / Ubuntu 24.04 / reproducible image
One person built this from a year of broken robots.
These labs are the notes I kept while building an AMR, turned into cases you can break and fix yourself. The first one is free. The beta is open if you want in early.