Robot integration notes that preserve the failure boundary
These notes turn public logs and source code into reproducible checks for real-hardware integration. Every page separates what the source proves, what is an engineering inference and what still requires hardware validation.
Current technical notes
Unitree fleet reliability: one failure class, one release gate
Connection generations, command freshness, confirmed STOP, immutable sensor time, fault injection and release regression for G1 / Go2 / Go2-W field systems.
OPEN SERVICE →Go2 edition checklist: model name is not an API contract
Official Air/Pro/X/EDU/Go2-W evidence, eight pre-purchase questions and five hardware gates for SDK access, sensor provenance, mapping, control ownership and stop behavior.
OPEN NOTE →G1 arm control while walking: ownership before gains
A source-bounded matrix for locomotion, waist and arm-SDK ownership, followed by five hardware gates for fixed arm poses, payloads, interlocks and recovery.
OPEN NOTE →Fail-closed action freshness for networked robot control
Why a half-open action stream can replay the last command, and the minimum timestamp, sequence, hold and re-arm contract needed before reconnection.
OPEN NOTE →Go2 autocharge: separate plate detection from power contact
A diagnostic order for TIMEOUT_DETECT, point-cloud instability, final-pose error and plate-distance tuning without confusing visual markers with LiDAR geometry.
OPEN NOTE →TinyNav Unitree bridge: stop when the cmd_vel stream becomes stale
Upstream PR #235 adds a configurable steady-clock watchdog, an independent short-timeout safety-stop client and focused pure-logic tests. The patch is mergeable and awaiting maintainer review; its 0.5 second default and robot behavior have not been validated on hardware.
VIEW PULL REQUESTEvidence labels used here
| LABEL | WHAT IT MEANS | WHAT IT DOES NOT MEAN |
|---|---|---|
| CODE TRACE | A behavior is directly visible in a linked public revision. | It has not necessarily been reproduced on this integrator's hardware. |
| ENGINEERING INFERENCE | The explanation follows from code plus an observed state trace. | It is not a confirmed root cause until the requested measurement is captured. |
| HIL PENDING | A bounded hardware-in-the-loop test is specified and still needs agreement or execution. | No pass result, performance figure or deployment claim is implied. |
| FIELD VERIFIED | A result may use this label only after the exact hardware, configuration, route and acceptance record are preserved. | A vendor video, simulation or adjacent robot model is not enough. |
Have a G1 or Go2-W failure trace?
Send the exact hardware edition, firmware, compute, network, last known-good state and the shortest reproducible workflow. A useful first engagement is one failure boundary and one recorded acceptance result.