Hardware
Open-source ESP8266 robot arm with Rust firmware
The open-source firmware runs on a five-servo ESP8266 arm and provides the joint model used by the simulator. The simulator itself has no serial, Bluetooth, or network dependency on that arm, so a school can teach the full course without buying one.
Design
Rust owns the policy; C++ is a hardware library
The dependency runs in one direction. Only one crate declares imported hardware functions, and the boundary carries bytes rather than Arduino strings, C++ objects, routes, JSON, or application state.
Rust owns
- Startup policy and the cooperative executor
- Hotaru routing and the protocol
- HTTP parsing and responses
- Servo validation and state
C++ owns
Only operations that require Arduino or ESP8266 symbols:
- Clocks, interrupt masking, watchdog, restart, heap, random, serial
- Wi-Fi access-point and station modes, raw TCP and UDP handles
- Captive DNS and SPIFFS handles
- GPIO, PWM, servo pulse writes, raw OTA writes
Native WiFiClient, File, and Servo objects remain behind integer handles on the C++ side. Embedded Arduino firmware has no ordinary Rust fn main(), so the gateway exports one non-returning C entry that setup() calls once.
Workspace
The crates
- hcr-gateway
- The application. Startup policy, routing, and the single C entry point Arduino calls once.
- hcr-http
- no_std HTTP parsing and responses, plus the Hotaru protocol.
- hcr-io-esp8266
- Hotaru transport over the platform’s TCP.
- hcr-rt-esp8266
- Runtime, time, and critical sections.
- hcr-platform
- Platform traits and values shared across the workspace.
- ffi/hcr-ffi
- The only crate that declares imported hardware functions, plus safe adapters over them.
Protocol
The current device API and the hcr.v1 service contract
The Rust service uses the additive hcr.v1 envelope with JSON and CBOR bindings. The current ESP8266 Rust gateway exposes a bounded HTTP/JSON servo API; MQTT is not implemented in the gateway yet.
| Client | Transport | Encoding |
|---|---|---|
| Browser app (today) | HTTPS request–response | JSON |
| Rust service contract | hcr.v1 HTTP binding | JSON and CBOR |
| ESP8266 Rust gateway (today) | HTTP on the device access point | JSON |
| MQTT device path (planned) | MQTT over TCP/TLS | CBOR |
Correlation in the envelope
Not in MQTT 5 properties. Devices may negotiate 3.1.1, and the HTTP binding has no properties at all. One mechanism that works everywhere is more reliable than two partial mechanisms.
Timestamps are not ordering
Device clocks are unreliable; the ESP8266 only reaches NTP when the router is up. Ordering comes from per-topic FIFO, never from the sender’s clock.
Additive minor versions
New optional fields, new kinds, new topics. A receiver that meets something it does not know logs and drops it rather than failing.