LEGO Boost 17101 driven by ZCode / Codex in plain language

The project started with a BLE connection check using pylgbst, where the maker learned that the Move Hub's LED color does not indicate connection status and that only one process can own the Bluetooth connection. These hardware lessons shaped later design rules, such as using a file lock to enforce a single BLE owner. The arm design went through versions, with the final v4 using the 17101 set's own parts and a counterweight made from tires to keep gears meshed. A key limitation the maker found is that AI agents could not reliably derive weight balance from 3D models, so a human had to adjust the physical build.

The conversion from LDraw to URDF used two constants: 1 LDU equals 0.4 mm, and the Y-up display coordinate was flipped to ROS's Z-up. For the parallel linkage, the maker used mimic joints to represent the motion relationship since URDF only supports tree structures. The planning layer, which the maker calls the best-value investment, runs in a fake mode without ROS or BLE, and collision avoidance uses 2D A* with OBB checks and AABB early rejection. Hardware calibration revealed that the toy gearbox struggles to hit specified angles, with about ±3 degrees of variability, which led the maker to relax tolerance from 1.0 to 2.5 degrees based on measurements.

The AI integration deliberately avoids giving the agent any direct path to the motors. The skill document enforces five rules, including always checking state before moving and reporting only actual measured angles as fact. In a fake-mode test, asking ZCode to rotate the base 10 degrees right triggered a sequence of state check, plan preview, match confirmation, and execution. The maker notes that this no-bypass design works well when the agent is an LLM that interprets rules, and lists remaining tasks such as calibrating the physical arm's speed settings and validating its range and collision shapes.