Flagship 01 · ROS 2 · GO2 + Jetson

HELIX: the layer that notices before the robot does

A ROS 2 reliability layer that detects runtime faults, turns raw symptoms into structured FaultEvents, diagnoses the likely cause, and audits every zero-velocity recovery command before it is trusted.

Repository Evidence ledger Demo video
8 GO2 + Jetson sessions audited
1.16 ms mean ROS 2 callback-path latency
96.5% near-threshold anomaly TPR at 0% FPR
81K/s offline detector throughput
−56% C++ RSS vs Python, promotion still gated

01 The problem

Learned robot policies fail in ways that look normal from the outside. Sensors go stale while still publishing. Recurrent state freezes. Topic rates degrade without dropping to zero. Policy outputs stay numerically plausible long after they stopped meaning anything.

A deployment stack needs a layer that notices the system is becoming untrustworthy before a user or a robot is exposed to the consequence, and that can prove afterwards what it noticed and when.

02 Why existing approaches fall short

Plenty of robotics work ships a trained policy or a navigation stack. Far less ships the operational layer around it: the thing that detects silent failure, separates confirmed behavior from inferred behavior, and refuses to overclaim when the physical intervention path is not wired.

Simulation validation does not establish hardware safety. For an edge robot the reliability layer has to run inside ROS 2, fit a companion computer's budget, survive real topic timing, and leave an audit trail. Most monitoring tooling assumes a datacenter, not a Jetson on a robot.

03 Core insight

Separate sensing from acting, and make the split explicit in the evidence. That decision is what lets HELIX prove faults were detected and recovery commands published, without claiming the robot physically executed a safe hold. When the actuation path turned out to be unsubscribed, the architecture surfaced it as a finding instead of hiding it behind a green dashboard.

04 Architecture

Heartbeat monitoring, topic-rate anomaly detection, and log-pattern parsing feed a diagnosis stage that emits structured FaultEvents. Diagnosis produces recovery hints; a cooldown-aware auditor decides whether an action is permitted, records it, and publishes the zero-velocity command on a dedicated topic.

HELIX architecture: sensing feeds diagnosis, which feeds a cooldown-aware recovery auditor
Architecture diagram from the HELIX repository evidence docs.

05 What I built

ArchitectureDesigned the reliability-layer split and the verified / inferred / not-validated evidence ledger that governs every claim in the repo.
Detection pathsAnomaly detector, heartbeat monitor, log parser, diagnosis rules, and the recovery-audit path.
Live integrationFound and fixed the R1 schema mismatch that silently blocked live diagnosis across earlier sessions.
C++ portPorted the anomaly detector to C++ for the Jetson budget, then reported the failed promotion gate rather than shipping it on.

06 Validation method

Live GO2 graphObserved from both companion and development machines across eight sessions.
Jetson sessionsMeasured persistent runtime, resource use, and thermal behavior on the Orin NX.
Topic adapterBridged real robot topics into HELIX metrics rather than replaying synthetic traces.
Separated benchmarksPure algorithm speed, ROS 2 callback latency, and hardware-session behavior measured independently, so no single number does double duty.

07 Results

Live graph attachabilityHELIX nodes observed and processed live GO2 topic-rate streams through an adapter.
Closed-loop control plane30 ANOMALY faults produced 14 recovery hints, 14 audited actions, and 3,064 zero-twist /helix/cmd_vel messages in one GO2 session.
Latency1.16 ms mean, 1.24 ms p95 through the actual rclpy callback path in a single-process benchmark.
Detector realism96.5% TPR at 0.0% FPR on near-threshold synthetic anomalies. Heavy-tailed noise and slow drift remain known weak cases.
C++ portMean RSS 45.0 MB to 19.81 MB, CPU about 2.0% to 0.80%. It still missed the 30% RSS target I set, so the port stays launch-gated.

08 Verified vs pending

Verified on hardware

VerifiedGO2 and Jetson sessions captured live ROS 2 topic landscapes, latency, resource, and HELIX runtime behavior.
VerifiedHELIX emitted structured FaultEvents from bridged GO2 rate metrics and log-pattern injection.
VerifiedDiagnosis and recovery-audit messages flowed after the R1 schema fix.
VerifiedThe C++ anomaly detector produced a lower-resource live fault stream.

Not yet proven

PendingThe published /helix/cmd_vel stream had zero downstream subscribers in Session 8, so it never physically held the robot.
PendingNatural idle jitter produced STOP_AND_HOLD actions before threshold tuning and stale-topic handling were complete.
PendingPhysical recovery actuation, long-duration service operation, and confirmed real fault classification each still need separate validation.

09 Limitations

HELIX is strongest as a runtime evidence and control-plane layer. It is not yet proof that the GO2 physically executes a recovery stop. The anomaly detector still needs threshold tuning for natural idle jitter and a dedicated stale-topic path for silent dropouts, and the headline detector numbers come from synthetic anomalies rather than a corpus of confirmed real faults.

10 Next step

Wire a real subscriber to /helix/cmd_vel in a controlled lab session and demonstrate that an injected fault physically holds the robot, with the motion path instrumented on both ends. That single session converts the largest pending row in the ledger into a verified one.