Crate arora_hal 

The Arora Hardware Abstraction Layer.

Hal is the boundary to a real (or fake) device — the thing studio-bridge called a Controller. A HAL reads sensors and reported state, accepts actuator/state writes, and pushes a feed of changes the hardware makes.

The Arora runtime mirrors a HAL against a DataStore: HAL updates flow into the store, store writes flow to the HAL. The HAL trait depends only on arora-types, so any execution engine can drive it without pulling in the bridge.

The I/O seam

Consistent with the bridge, the HAL’s data plane is an owned inbound stream and a non-blocking outbound push: updates hands out the sensor feed as a Stream (each call an independent subscription, owned by its consumer — the runtime’s loop is its one poller), and try_send pushes actuator writes immediately, called directly from the synchronous step. Any real async work is the implementation’s own responsibility (its own task/queue), the same way a bridge owns its socket; this crate depends on no async runtime.

The device owns its HAL (Box<dyn Hal> at the builder). An implementation that also serves an observer (a simulator UI, a test double) shares its internals and hands sibling handles out itself — FakeHal clones onto the same state.

Pick an implementation per robot: FakeHal here (also the test double), and the real ones (ros2, restful, nao) in their own sibling crates.

Structs

FakeHal

An in-memory fake Hal for tests and simulators.

HalDescription

What device a HAL drives.

Enums

HalError

Something went wrong talking to the hardware.

Traits

Hal

The Hardware Abstraction Layer: the boundary to a device.

HalAssets

Optional extension: HALs that can supply a 3D model (GLB) of the device.

Type Aliases

HalResult

UpdatesStream

The sensor feed of a Hal: an owned stream of the changes the hardware reports. The stream ending means the hardware feed is gone.