Skip to main content
The Peripheral trait defines the interface for hardware peripherals in ZeroClaw. Implement this trait to integrate physical devices like microcontrollers (STM32, Arduino), GPIO boards (Raspberry Pi), sensors, and actuators as agent-controllable capabilities.

Overview

Peripherals are the agent’s “arms and legs” - remote devices that run minimal firmware and expose hardware capabilities as tools. The agent connects to peripherals, retrieves their tool definitions, and can invoke hardware functions just like software tools.

Trait Definition

Required Methods

name

Return the human-readable instance name of this peripheral.
&str
Unique instance identifier including index or serial (e.g., “nucleo-f401re-0”, “rpi-gpio-hat-1”)
Note: Must uniquely identify the specific device instance when multiple boards of the same type are connected.

board_type

Return the board type identifier.
&str
Stable lowercase identifier (e.g., “nucleo-f401re”, “rpi-gpio”)
Note: Must match the key used in config schema’s peripheral section.

connect

Establish a connection to the peripheral hardware.
anyhow::Result<()>
Success or error
Responsibilities:
  • Open underlying transport (serial port, GPIO bus, I²C, etc.)
  • Perform initialization handshake with firmware
  • Verify device is ready for commands
Example actions:
  • Open /dev/ttyACM0 at 115200 baud for STM32
  • Export GPIO pins via sysfs for Raspberry Pi
  • Perform version check handshake with firmware

disconnect

Disconnect from the peripheral and release all resources.
anyhow::Result<()>
Success or error
Responsibilities:
  • Close serial ports
  • Unexport GPIO pins
  • Perform safe shutdown sequence
  • Release any held locks or file descriptors
Note: After this call, health_check() should return false until connect() is called again.

health_check

Check whether the peripheral is reachable and responsive.
bool
true if device responds within timeout
Implementation: Perform lightweight probe without altering device state (e.g., ping command, read status register).

tools

Return the tools this peripheral exposes to the agent.
Vec<Box<dyn Tool>>
Array of tool implementations that delegate to hardware
Each tool:
  • Implements the Tool trait
  • Delegates execution to underlying hardware (GPIO, sensors, actuators)
  • Handles communication protocol with firmware
  • Returns structured results to the agent
Example tools:
  • gpio_read - Read digital pin state
  • gpio_write - Set digital pin state
  • adc_read - Read analog sensor value
  • pwm_set - Control PWM output
  • sensor_read - Read temperature/humidity/etc.

Implementation Example

Here’s a simplified STM32 Nucleo peripheral:

Communication Protocol

Typical firmware communication pattern:
See docs/hardware-peripherals-design.md for complete protocol specification.

Factory Registration

Register your peripheral in the factory:

Configuration Example

Lifecycle Flow

  1. Startup: Agent reads peripheral config
  2. Factory: Creates peripheral instances via factory
  3. Connect: Agent calls connect() on each peripheral
  4. Tool Registration: Agent calls tools() and merges into tool registry
  5. Runtime: LLM can invoke peripheral tools like any other tool
  6. Health Monitoring: Periodic health_check() calls
  7. Shutdown: Agent calls disconnect() on cleanup

Best Practices

Hardware Safety: Validate all parameters before sending to firmware. Invalid GPIO operations can damage hardware.
Timeouts: Use reasonable timeouts for serial/I²C operations (typically 100-1000ms). Hardware can be slow.
Error Recovery: Implement reconnection logic for transient failures (cable disconnects, USB resets).
Thread Safety: Use Arc<Mutex<>> for shared resources like serial ports since tools may be called concurrently.
Firmware Protocol: Keep protocol simple and text-based for debugging. Binary protocols are harder to troubleshoot.

Supported Board Types

Current implementations:
  • nucleo-f401re - STM32 Nucleo F401RE over USB serial
  • rpi-gpio - Raspberry Pi GPIO via sysfs

Firmware Development

See docs/hardware-peripherals-design.md for:
  • Communication protocol specification
  • Firmware implementation guide
  • Example firmware for STM32 (C/C++)
  • Testing and debugging procedures

Testing