PayloadActuatorDriver controls a non-imaging mission payload:
sprayer, dropper, claw, sampler, winch, or any other actuator the
operator triggers from a panel or a mission action.
The interface
A Rust trait of the same shape ships in the
ados-sdk crate at
ados_sdk::drivers::PayloadActuatorDriver. It mirrors the Python
contract (discover, open, close, capabilities, actuate,
get_state) with an associated Session type and returns
DriverResult. actuate returns DriverError::InvalidParam when
command.action_id is not in PayloadCapabilities::actions, so the
host can reject the request before it reaches hardware.
PayloadCandidate, PayloadCapabilities, PayloadCommand, and
PayloadState carry the same fields (args and metadata are
msgpack value maps on the Rust side). Pick the language that matches
your plugin’s agent.runtime (python or rust).Capabilities
actions is the tuple of action_id strings the driver accepts in
PayloadCommand. The GCS panel discovers these and renders one
button per action. metadata is the open-ended bag for
driver-specific knobs (max payload mass, refill volume, vendor
firmware version).
Commands
action_id is mandatory. args is a free-form dict that the
driver validates. Unknown keys should raise ValueError.
State
busy=True while an action is in flight; the host serialises
actuate calls per session to keep the contract simple. Drivers
that report sustained errors should propagate them via
metadata["error"] and raise DriverError on the next actuate
call so the GCS sees the failure on the user-action path.
Manifest permissions
sensor.payload.register, which the operator
approves when they install the plugin. Once registered, actuation
flows through the driver’s actuate(...) method, and the host
serialises those calls per session.
See also
- Driver layer for the contract.
- Permissions for the capability model and risk bands.