Set up Arduino UNO Q and verify the network
Connect UNO Q with a USB-C data cable and finish the first-run wizard in Arduino App Lab. Give the board a recognizable name, set its Linux login password and join the same local network as your computer.
Run the Color your LEDs example. Open its web view and verify that a change actually reaches the board. Stop the example and note the board IP in Network Info. If the example works over USB but the browser cannot reach the board over Wi-Fi, check the network before changing the robot app.
For the standard runtime, download the board libraries in App Lab, stop the app, and open a terminal in its actual project directory on UNO Q. Run python3 tools/prepare-bridge.py, then sudo bash tools/router-2m.sh for its 2 Mbps Bridge. Return to App Lab, select Run, and open the board IP on port 9527. Use the scripts from the installed revision.
Prepare the parts and assign servo IDs
Match the BOM, print files, actuator model and expansion-board revision before assembly. Test a printed bearing seat and servo mount before committing to a full print. Confirm the supply limits, polarity and connector pinout against your exact revision before connecting power.
In Servo setup, connect one servo at a time and power down before swapping connections. Scan its current ID, set the new one, scan again and label the physical unit. Use 10–14 for the left leg, 20–24 for the right leg, 30–33 for the head and neck and 34 for the mouth. Left and right are the robot’s own sides.
Check the assembly sequence and cable clearances
Lay out the mirrored leg parts separately. Seat the bearings and test the joint fit before fastening the covers. The illustrated assembly sequence identifies 10 × 15 × 3 mm bearings and M2.5 × 6 screws around the feet, and M3 × 16 screws at the documented mounts for IDs 30 and 31. Match each fastener to its own location.
Route leg cables before closing their joints and connect the lower leads in the head and neck mechanism before closing that assembly. With power off, check for pinched cables and leave enough slack for movement. Compare part orientation and fastener placement against the drawings for your revision.
Inspect the robot before its first powered movement
Keep the robot supported with the feet clear and the joints unobstructed. The control page should report 15/15 servos and an online IMU. Check that readings continue to update before loading the motors.
If the console opens but servo or IMU readings stop updating, check the Bridge and board feedback. If one ID is missing, stop motion, power down and check that servo’s connector and label. Record the failing stage, the action that reproduces it and the status or error text before changing several settings.
Calibrate and test the standard motion runtime
The documented standard build starts in Inference only with motor torque off. Support the robot, open Calibration, line up one joint with its mechanical center and select Set center & hold for that joint. Keep hands clear as it begins to hold. Repeat the alignment for each joint, then select Unload all or Exit with the robot supported.
Back up your own data/zero_pos.json if your installed build creates it. Check Default pose with support, then test a small motion command on a clear, level floor. Zero motion stops travel while preserving the current control mode. Torque off releases the joints, so support the robot before using it.
Install the AI runtime and test each peripheral
Check the branch-specific App Lab ZIP against its published SHA-256. Import the verified ZIP through Import App. Stop running apps, back up the previous app and its data when upgrading, and confirm Wi-Fi SSH access before configuring USB Host. USB setup can interrupt the computer’s USB or ADB connection.
On the documented AI branch, work in the actual AI app directory on UNO Q. Run bash tools/install-ai-support.sh, then sudo bash tools/router-2m.sh. Run the app via App Lab’s Network connection. Open the board’s root web address for the AI cockpit and port 9527 for motion.
Test the microphone, speaker and camera separately before binding the voice account. The documented optional ToF uses VL53L5CX. Confirm the exact carrier, connector and driver for other modules such as VL53L8CX. On builds exposing /api/tof/status, check for state=ranging, fresh=true, an advancing seq and valid_zones greater than zero before testing obstacle response.
Train and validate a matching policy in simulation
Luwu Dynamics’ downstream training project uses mjlab with MuJoCo Warp. The documented setup uses a separate CUDA machine, Python 3.12 and uv. In the training project, use uv sync to install its pinned dependencies and uv run list-envs to identify the task that matches your robot.
Replay the exact checkpoint in simulation before exporting it. The documented scripts/export.py exports ONNX from that checkpoint and embeds observation normalization. Check the runtime’s joint order, observation fields and normalization conventions before loading the result. Record both software revisions, the checkpoint and the exported file’s checksum.
Identify the original Microduck and the UNO Q adaptation
Pollen Robotics’ Microduck and microduck_rl are the upstream mechanical and learning projects. Luwu Dynamics adapted the design for Arduino UNO Q with different actuator and mechanical assumptions. For example, the downstream simulator models 1910-family actuation, while the original uses XL330.
Identify which design you are assembling before choosing a BOM, print files, calibration profile or ONNX model. Keep a record of the hardware, actuator model, runtime branch and policy checkpoint so later repairs can match the working configuration.
