Little Boy'z NeXus

NeXus Hardware Graph - Replay Telemetry & Wiring Explorer
NeXus AI Doctor - Safe Simulation & Diagnosis Workflow
ESP32-S3 Signal Wiring - INA219, PS2 and Motor Drivers
Power and Safety Wiring - 3S Supply, Relay and INA219
Motor and Hall Encoder Wiring - Three Wheels
System Design - Observe, Diagnose and Verify
System Architecture - Edge, Local App and Nebius

Inspiration

When a robot or small machine fails, the symptom is obvious but the cause is not. A loose signal wire, mismatched sensor, disabled driver, or unsafe power path can waste hours and produce misleading numbers. We built NeXus so a physical prototype can explain its own wiring, telemetry, faults, and recovery steps.

What it does

NeXus is an AI hardware doctor for an ESP32-S3 three-wheel motor rig. It follows three paths: Prevent unsafe configurations before actuation; Manual Diagnose faults using live measurements, signal health, the wiring graph, and an evidence-linked Nemotron hypothesis; and Auto Heal only bounded software-controllable faults after deterministic safety checks and fresh Before/After verification. The React interface shows a live dashboard, searchable hardware graph, exact pin and wire guide, ESP32 log, wheel RPM, AI Doctor, treatment steps, audit timeline, and downloadable session evidence.

How we built it

A versioned JSON Hardware-as-Code profile defines the board, current sensor, L298N drivers, three JGB37-520 encoder motors, PS2 receiver, power path, pins, connections, and limits. PlatformIO firmware emits strict telemetry and starts with motor drive disabled. A FastAPI backend validates and stores samples, monitors serial health, streams updates over WebSockets, builds grounded model context, and runs the diagnosis and verification state machine. We call NVIDIA Nemotron-3-Ultra-550B-A55B through Nebius Token Factory using its OpenAI-compatible API. Nemotron ranks hypotheses and proposes an allowlisted next read; local safety policy decides whether any tool may run. React and TypeScript use the same versioned contracts as the backend and firmware.

Challenges

Sensor identity matters: an INA219/INA226 mismatch can create plausible but incorrect readings. We added profile, firmware, and sensor compatibility checks. An I2C failure can resemble a valid zero, so signal loss, stale readings, and powered-off rails are distinguished. Current alone cannot prove motor motion, so encoder RPM and newer samples are part of verification. Physical commands are supervised and bounded; model output never sets safety limits or directly controls a motor.

Accomplishments and learning

One machine-readable profile connects firmware generation, backend validation, and wiring UX. On the earlier INA226 reference rig, we completed a physical telemetry-to-Nemotron-to-read-only-tool vertical slice with three passing live runs. A separate 10/10 structured diagnosis acceptance set used authored cases. The current INA219 three-wheel revision has passed software tests and firmware build checks; those earlier physical runs do not certify this revision. The system records model metadata, policy decisions, tool evidence, and verification under a trace ID while keeping secrets and private reasoning out of the public record. We learned that AI is most useful for grounded hypotheses when the physical system already has explicit limits and evidence.

What's next

We plan to add calibrated hardware adapters, richer sensors, operator approval for bounded write actions, and fleet-level trends. This is a hackathon prototype on one rig, not a claim of autonomous or production-certified motor control. See the repository README for setup and the exact hardware profile.