The method
You learn a robot by watching it fail.
Most robotics courses show you a system that already works and ask you to admire it. On the job, nothing works and nobody knows why. Botopsy inverts the tutorial: every lab hands you a running system with a real fault planted in it, and you restore it.
Why failure-first
A working demo teaches you the happy path. But the skill that actually pays is the one nobody drills: standing in front of a robot that should move and does not, with a hundred plausible causes and no idea which one is real. That is diagnosis, and you only get better at it by doing it under conditions that resemble the real thing.
So the labs are not fill-in-the-blank. The system compiles, launches, and runs. It is broken in one specific, load-bearing way, and the break is in a file you can open and edit. There are no toy stubs and no reference answer to diff against.
The loop: reproduce, bound, fix, verify
Every case, from a reversed encoder to a Nav2 planner that refuses to plan, runs on the same four steps. Internalize the loop and the subsystem barely matters.
1. Reproduce
See the failure with your own eyes before you touch anything. Launch the system, watch the robot spin the wrong way or the map come up empty, and confirm the symptom is real and repeatable. A bug you cannot reproduce is a bug you cannot verify you fixed.
2. Bound
Narrow the fault from “something is wrong” to a specific subsystem, node, or message. This is where the tooling earns its keep: read the graph, echo the topic, check the transform tree, inspect the node’s state. Diagnosis comes before editing.
# What is actually running and talking to what?
ros2 node list
ros2 topic list -t
# Is the message even arriving, and does it look sane?
ros2 topic echo /odom --once
ros2 topic hz /scan
# Is the transform tree connected?
ros2 run tf2_ros tf2_echo odom base_link3. Fix
Change the smallest thing that addresses the root cause, not the symptom. Flipping a sign until the robot happens to go the right way is not a fix; understanding that the encoder was wired to count backwards is. The editable files are real source, launch, URDF, or config, and your edit changes real behavior.
4. Verify
Prove it. The grader relaunches your current files and reads the system’s observed behavior, so a pass means the robot now actually does the right thing, not that your text matched a key.
Transfer, not memorization
Many cases close with a second scenario shaped differently that depends on the same underlying lesson. The point is to make sure you took away a concept you can carry, not a keystroke sequence for one specific robot. When you can fix the same class of fault in a system you have never seen, the lesson stuck.
The reference pages in this section are organized the same way, by fault class rather than by feature. Read the one that matches the subsystem you are fighting, then go open a lab and fight it for real.