Isolate before you integrate, and isolate again when things break
The single most valuable debugging habit in this whole project is one you should have used before final assembly and should return to the moment something goes wrong: test subsystems independently. Before wiring the sensor and motors into one loop, verify each piece alone, motors spin the right direction at the right speed when driven directly by a test sketch, the sensor returns sane distance readings printed to a serial monitor, the battery holds voltage under load. When the integrated robot misbehaves later, the fastest path to a fix is re-isolating: disconnect the sensor and drive the motors with hardcoded values, does the motion look right? Reconnect the sensor alone and print its readings without touching the motors, are they sane? Whichever half breaks in isolation is where your bug lives, and you've cut the search space in half with one test.
This is where the previous three courses pay off directly. A robot that drifts to one side might be a mechanical issue (uneven wheel friction) or a code issue (unequal PWM values) or, from the actuator course, simply two 'identical' motors with normal manufacturing variance in speed, which is common enough that many designs add a per-side trim value in software rather than assuming both motors behave identically. A robot that resets when motors start is almost always the power course's territory, insufficient battery capacity or a shared, undecoupled supply rail. A robot with an unresponsive or laggy control loop points back to the embedded systems course, a blocking call or a busy-wait eating the time your loop needs to react.