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.

Synchronous I/O seam

Consistent with the bridge, the runtime drives the HAL synchronously: the inbound sensor drain is updates (a sync-pollable Subscription the step loop try_recvs), and the outbound actuator push is try_send — non-blocking, 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.

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