In the first article I told the story of building the robot, from printing the parts and making the motors move to teleoperating with a PS4 controller, collecting demonstrations, and training a model that picks bottles off a table. At the end I mentioned an idea I've been calling a physical API, a layer that exposes what the robot does in the physical world as data, meaning telemetry, history, and the feedback that guides future training. This article is about the first big piece of that layer, observability.
While a model or the teleop runs, my view of the hardware is whatever the terminal prints. For a quick test that's enough, but the failures I want to avoid don't announce themselves there, like a motor slowly overheating across twenty minutes of episodes, the power supply voltage dropping when all six joints pull at once, or the control loop quietly running below the rate the whole design assumes. Observability is how I get to see these things coming, instead of discovering them after a burned motor or a session of bad data, and it's also how I learn what normal looks like, so the abnormal stands out. What made it possible to build without much effort is that the raw material was already available. Every one of those answers travels on the CAN bus the whole time, and I just had to listen.
