Source lower host releasedControl/data 20 FPSEvaluation 5 x 50Optional data +100 OOD demosMechanics parameters released; CAD review pending

Physical benchmark

Build and reproduce DIYRobot

DIYRobot is the single physical platform used by KinRT. This page connects the released lower-host source, hardware contract, zeroing, three-camera alignment, LeRobot data, KinRT training, and guarded evaluation in one workflow.

14 follower jointsThree RGB views14-D state/actionQualified operator required
01

Know what is reproducible today

The public release now includes the reviewed lower-host implementation under hardware/diyrobot/lower_host, source hashes, calibration procedures, camera-reference data, a parameter register, a core BOM, and explicit mechanical provenance. The source host was read only: no remote file or hardware state was changed during this audit.

Parameters are public; final manufacturing CAD remains under review.

The release identifies every source-verified actuator, address, control parameter, camera role, base dimension, and safety threshold. The verified RobStride-adapted arm CAD, original chassis and lift drawings, complete fastener BOM, camera-mount geometry, and printable task mat will follow after assembly and redistribution checks. Do not claim a mechanically identical reconstruction before those artifacts are available.

DIYRobot is the only public platform and runtime name. The earlier internal name appears only in immutable source-provenance and historical-checkpoint records; it does not identify a second robot or a public code path.

Open the DIYRobot source and full operator documentation.

02

Separate the derived arm from the original base

Follower arm · Derived design

The follower-arm mechanism is derived from the Apache-2.0-licensed TRLC-DK1 Follower v0.2.0 working design and adapted for RobStride O3 actuators. Modified adapter, shaft, bearing, link, cable-cover, and mount parts require final assembly verification before CAD release.

Mobile base and lift · Original DIYRobot design

The three-omni-wheel chassis and lift-system mechanical integration are original DIYRobot engineering. This claim does not extend to purchased actuators, cameras, vendor interfaces, or third-party software.

The current TRLC-DK1 repository publishes v0.3.0; it is an upstream reference, not the exact geometry of the local v0.2.0-derived assembly. Apache-2.0 attribution and modification notices will accompany every released derivative CAD file.

03

Assemble from verified parameters

DIYRobot hardware and control topology
The lower host owns cameras and actuator buses; the GPU host owns KinRT inference.
SubsystemVerified hardwareAddressing
Leader arms14 Feetech STS3215Left 1-7; right 8-14
Follower arms14 RobStride O3Left 1-7; right 11-17
Mobile baseThree Damiao DM43100x21, 0x22, 0x23
LiftDamiao DM4310 + ESP32 optical limits0x24
VisionC930e, C920, ARKMICRORight wrist, left wrist, overhead
ParameterReleased valueScope
Wheel radius0.05 mSoftware kinematics
Base radius0.125 mCenter-to-wheel
Wheel layout240 / 0 / 120 degLeft / back / right azimuth in the released kinematic model
Wheel speed cap100 RPMCommand safety cap
Base controlkp=0, kd=3, feed-forward 3Classic CAN at 1 Mbit/s
Lift homing-1, step 2 deg, kp=8, kd=0.3Automatic homing disabled by default
Lift thresholds30 / 90 degBase/lift coordination
Fast base threshold0.2 m/sBlocks upward lift target
Physical authority comes first.

One qualified operator must own a tested emergency stop or power disconnect. Clear and support the swept volume before any tool that can enable follower torque.

04

Install the lower-host package

Use the LeRobot revision validated for the platform. The release does not claim compatibility with every upstream revision.

Lower-host installation
cd /path/to/lerobot
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -e .
python -m pip install pyserial opencv-python scservo-sdk

cp -a /path/to/KinRT/hardware/diyrobot/lower_host \
  src/lerobot/robots/diyrobot

python -m pip install -e \
  /path/to/KinRT/policy/pi05/packages/openpi-client

python -c "from lerobot.robots.diyrobot import DIYRobot; print(DIYRobot.name)"
Software-only gate

Run OFFLINE_SELF_TEST=1 ./start_diyrobot_pi05_policy_client.sh. It must report 14 motors and action shape (1, 14) without opening cameras or actuator buses.

05

Map devices by identity

The release omits the original serial numbers and USB topology. Create target-specific udev rules that map verified devices to these semantic paths:

PathPhysical role
/dev/diyrobot/leaderFeetech leader bus
/dev/diyrobot/follower-leftLeft RobStride bus
/dev/diyrobot/follower-rightRight RobStride bus
/dev/diyrobot/chassisDamiao chassis/lift bus
/dev/diyrobot/lift-limitsESP32 optical-limit reader
/dev/diyrobot/camera-*Right wrist, left wrist, overhead
Read-only discovery
ls -l /dev/serial/by-id /dev/serial/by-path
ls -l /dev/v4l/by-id /dev/v4l/by-path
lsusb
udevadm info --query=property --name=/dev/ttyUSB0
udevadm info --query=property --name=/dev/video0

Confirm each physical role without trial motion. The active strict path uses separate left and right follower buses; the generic class also retains a single-bus compatibility mode. Do not mix their calibration or port model.

06

Calibrate and zero one joint at a time

Generate all calibration files on the target robot. The tools do not issue pose targets, but follower sampling may briefly enable and disable the selected RobStride motor.

One-side rest and range
cd /path/to/lerobot/src/lerobot/robots/diyrobot

python diyrobot_rest_range_calibrate.py rest \
  --device both --side left
python diyrobot_rest_range_calibrate.py range \
  --device follower --side left --duration 20
python diyrobot_rest_range_calibrate.py show \
  --device both --side left

Move joints by hand only through a conservative working range; do not use mechanical stops as limits. Repeat for the right side, record direction/scale evidence, and physically validate each joint before marking it validated.

Required evidence per jointAcceptance rule
Leader/follower identityName, side, ID, and bus agree
Rest and rangeRest lies inside a conservative absolute range
Direction and scaleBase, positive, and negative samples agree
Physical validationTiny supervised test completed without drift or mismatch
RecordRobot ID, operator, time, and file digests stored

The complete commands, file schemas, lift-zero procedure, and recalibration triggers are in the calibration guide.

07

Align all three cameras to the checkpoint contract

ViewCollection keyPolicy keyFormat
Overheadoverheadcam_high640 x 480 @ 30
Left wristleft_grippercam_left_wrist640 x 480 @ 30
Right wristright_grippercam_right_wrist640 x 480 @ 30

The current code does not rectify images or apply a homography. Its browser overlay uses the overhead rectangle (128,151) to (458,416) at 640 x 480. The saved overlay JSON is not consumed by recording or policy inference.

Camera height is not enough.

Checkpoint-compatible reproduction also depends on pitch, roll, yaw, field of view, task-mat pose, exposure, and semantic camera mapping. Physically align the task mat to all four pixel corners.

Preview only
./start_diyrobot_three_camera_webui.sh
# Stop the preview before collection or policy inference.

Exact per-camera mounting geometry, task-mat dimensions, and the printable reference are coming soon. See the camera-alignment guide for normalized corners, acceptance checks, and the future homography release contract.

08

Collect and inspect a smoke episode

One bounded episode
TASK="Put the pill box into the center of the notebook." \
REPO_ID="local/diyrobot_smoke" ROOT="/data/diyrobot/smoke" \
EPISODES=1 EPISODE_TIME=20 RESET_TIME=0 FPS=20 \
./start_diyrobot_pi05_record.sh

Each frame must contain finite 14-D observation.state, the 14-D target actually sent as action, three RGB views, and exact task text. Strict-teleop JSONL is diagnostic data, not training data.

Metadata

Episode, task, frame, parquet, and video counts agree.

Images

Three streams are current, correctly named, upright, and synchronized.

Motion

State/action order and degree units match the 14-D contract.

Outcome

Failed demonstrations remain outside a success-only training set.

09

Prepare method labels and train

Freeze the dataset digest, then create and verify K=4 supervision using the KinRT method procedure with the DIYRobot dataset path. FULL and LoRA are optimization regimes of the same method.

Normalization and training
cd /path/to/KinRT/policy/pi05
uv run python scripts/compute_norm_stats.py \
  --config-name kinrt_full_diyrobot
uv run python scripts/train.py kinrt_full_diyrobot \
  --exp-name diyrobot_kinrt_full

Use kinrt_lora_diyrobot for LoRA. Keep the selected name identical across normalization, training, checkpoint serving, and reporting. The reported DIYRobot runs use 8,000 steps and effective batch size 32.

10

Deploy through guarded stages

GATE AOffline self-test

No cameras or actuator buses.

GATE BDry policy

Cameras and feedback, no target commands.

GATE CBounded motion

One chunk step and short duration.

GATE DBenchmark

Fixed checkpoint and physical protocol.

Dry then bounded
POLICY_SERVER="<gpu-host>:<port>" TASK_ID=0 \
  ./start_diyrobot_pi05_policy_client.sh

POLICY_SERVER="<gpu-host>:<port>" TASK_ID=0 \
ALLOW_MOTION=1 DURATION=30 ACTION_CHUNK_STEPS=1 \
  ./start_diyrobot_pi05_policy_client.sh

Stop immediately on startup mismatch, unexpected direction, drift, stale feedback, camera failure, policy timeout, invalid action shape, or collision risk. Software cleanup is not a substitute for the physical stop.

11

Keep evaluation fixed when using optional OOD data

Evaluate the five prompt-v3 tasks with 50 trials each in the original environment. Record task, prompt variant, checkpoint, calibration digests, camera reference, operator, outcome, and stop reason for every trial.

DIYRobot training example under altered illumination
The additional 100-episode dataset contains altered-lighting demonstrations for optional training. It is not a 100-trial test set.
Optional robustness setting

Add the 100 OOD-lighting demonstrations only as a separately reported training condition. Test the resulting checkpoint with the same 50-trial-per-task protocol in the original environment so the comparison remains controlled.

Publication boundary

The source and protocol are released; physical execution was not rerun during this audit. Numeric equivalence still depends on checkpoints, target-specific calibration, and the pending mechanical/camera geometry release.