What is a compatible driver?
A compatible driver connects your hardware’s native API to a Cyberwave asset and twin: it translates the device’s protocol into MQTT topics, command envelopes, and (optionally) edge data channels that the UI, workflows, and SDK understand. This guide is for integrators building a driver from scratch for a custom or third-party asset in your workspace. Cyberwave-maintained drivers use the same rules; theircw-driver.yml files are linked later as examples only.
Drivers can run on edge hardware, on the robot, in the cloud, or on a developer laptop. In production they usually run beside the device under Edge Core.
Each driver ships as a Docker image. Edge Core pulls and runs it with the environment variables below, so local development matches production deployment.
Quickstart: scaffold with the Claude skill
The fastest way to get started is the Cyberwave Driver skill for Claude Code. It asks you a few questions about your hardware and scaffolds a complete, production-ready driver project — including the Dockerfile, local dev setup, and a working twin connection. Install the skill:Quickstart: use the SDK
The fastest way to write a compatible driver is to use one of the official SDKs:- Python SDK —
cyberwave-sdk - C++ SDK — see the C++ SDK docs
Environment variables
When Edge Core starts a driver container it injects the following environment variables. You can develop your driver assuming these are always set to valid values — no need to handle the case where they are absent.CYBERWAVE_CHILD_TWIN_UUIDS is set when child twins are attached to the driver twin. Drivers can use this to coordinate child devices (for example, multiple cameras) without additional configuration.
Restart behavior tuning
The following optional variables let you override Edge Core’s restart defaults:Driver failure handling
Drivers must exit with a non-zero code when they cannot access required hardware (for example, a missing/dev/video* device or a disconnected peripheral). This allows Edge Core to detect startup failures and trigger restart logic.
Edge Core raises the following alerts:
driver_start_failure— raised when a driver container cannot reach a stable running state.driver_restart_loop— raised when a driver exceeds the restart threshold within the window. The container is stopped and marked as flapping.
Twin JSON file
CYBERWAVE_TWIN_JSON_FILE points to a JSON file on disk that contains the digital twin instance (including its metadata) and the associated catalog twin data, matching the TwinSchema and AssetSchema API schemas.
Drivers may read and modify this file. Edge Core syncs any changes back to the backend when connectivity is available.
Runtime configuration
Drivers should treatmetadata["edge_configs"] as the source of truth for per-device runtime configuration, and metadata["edge_fingerprint"] as the edge identity (not duplicated inside edge_configs).
Read edge_configs from CYBERWAVE_TWIN_JSON_FILE at startup to obtain per-device settings without hardcoding them in the image.
Declare your driver interface (cw-driver.yml)
To make a custom asset work with Cyberwave, your driver project should include a cw-driver.yml at the repository root (next to your Dockerfile). The file is the contract between your hardware bridge, the platform APIs, the web UI, and the SDK: it lists which MQTT topics you use and which command strings you accept.
Cyberwave’s own edge drivers (Go2, SO-101, DJI Mini, and others) use the same format — treat them as reference implementations, not as something you must fork. Copy the patterns that match your robot (locomotion, joint bus, camera stream, etc.) and trim what you do not implement.
Compliance checklist
If the manifest and the running driver disagree (undeclared command, wrong topic), teleop, agents, and SDK helpers will not line up with what the hardware actually does.
Why you need it
Without a declared interface catalog, the platform cannot know which MQTT topics your driver uses, which command strings are valid oncyberwave/twin/{uuid}/command, or whether a command is continuous (stick-held) vs discrete (one-shot). That metadata drives:
Planned — topic entries will also reference dedicated payload schemas (protobuf / robot-native layouts) for typed robot data on the wire. Today,
payload_schema_ref names the logical schema; strict validation against those refs is not enforced yet.What cw-driver.yml contains
Top-level fields:
YAML path → MQTT topic
Topic entries are nested asmqtt.<namespace>.<leaf>. The leaf key is the MQTT path segment (use hyphens in YAML, e.g. webrtc-offer). Each entry becomes a flat key in metadata["mqtt"]["topics"] by joining a namespace prefix with the leaf:
Namespace prefixes:
Each leaf entry sets
direction, payload_schema_ref, description, and optional source_types.
WebRTC signaling is always on the twin prefix (cyberwave/twin/{uuid}/webrtc-offer, webrtc-answer, webrtc-candidate, and webrtc-command for media-service commands). Declare them under mqtt.twin with hyphenated leaf names — not as a separate top-level namespace:
In some first-party Cyberwave profiles you may see a legacy
mqtt.webrtc.offer shorthand (offer → webrtc-offer under the twin prefix). For new drivers, use mqtt.twin.webrtc-* only.Compiled catalog shape
On the platform, your asset (and twins created from it) store a JSON bundle atmetadata["mqtt"]:
topics— map of canonical slug →{ direction, payload_schema_ref, description, … }commands.supported— list of command name stringscommands.specs— per-command flags such ascontinuousandrate_hzschema_version,driver_family— format and implementation hints
metadata["mqtt"] when you call set_schema on a twin.
Reference implementations (Cyberwave drivers)
Use these open-source manifests as templates — copy the namespaces and command style that match your hardware, then delete what you do not implement:Apply the manifest to your twin
After you authorcw-driver.yml, register it on a twin you own with the Python SDK. You do not need to hand-build JSON or call low-level asset APIs — point set_schema at your manifest file and the platform updates that twin’s metadata["mqtt"], refreshes the catalog cache, and binds catalog-derived command methods on twin.commands (for example twin.commands.stop(), twin.commands.move_forward(...) when those names appear in commands.supported).
registry_ids in the YAML to match the asset your twin was created from. Re-run set_schema whenever you change the manifest so teleop, agents, and SDK callers stay aligned with your driver.
set_schema — REST and SDK
Full OpenAPI entry: Update Twin.
merge=True (default) deep-merges the new metadata.mqtt into existing twin metadata. merge=False replaces the entire mqtt block.
Invoke catalog commands after set_schema — they publish over MQTT, not REST:
Platform API reference
Use the Python SDK for day-to-day driver work; use REST when integrating from another language or CI. All REST paths are under/api/v1 and require a bearer token unless noted otherwise. See the REST API reference for request/response schemas.
Bring-up (workspace)
Runtime state (REST alternatives to MQTT)
Drivers normally stream state over MQTT (see below). These REST endpoints are available for tools, simulators, or HTTP-only bridges:Runtime messaging (MQTT)
Declared incw-driver.yml → compiled into metadata.mqtt.topics. At runtime the driver (or SDK teleop) uses the MQTT broker (WebSocket URL in NEXT_PUBLIC_MQTT_URL for frontends; port 1883 / 9001 locally for edge). Topic prefix may include an environment segment in deployed stacks; slugs below are canonical.
Payload shapes: MQTT API Reference.
Edge data bus (local, not REST)
See Data Wire Format for encoding rules.
Assets, twins, and public catalog entries
First-party Cyberwave drivers ship a
cw-driver.yml in their repositories for reference — you follow the same file format, then apply it to your twin with set_schema during bring-up.
Sensor data output
If your driver produces sensor data (video frames, depth maps, audio, joint states, etc.), publish it to the edge data bus so worker containers and ML models can consume it locally with zero network overhead. There are two options: the Zenoh data bus (recommended) and the filesystem convention (fallback for constrained environments). Both use the same channel names — a driver can switch between them by changing one env var.Option A: Zenoh data bus (recommended)
The Zenoh data bus provides zero-copy shared memory between driver and worker containers. Data is consumed directly by worker hooks andcw.data.latest().
Key expression convention
The
DataBus handles key composition automatically via CYBERWAVE_TWIN_UUID.
Canonical channels
You can define custom channels by picking any channel name.
Python SDK example
CYBERWAVE_TWIN_UUID is read automatically from the environment. CYBERWAVE_DATA_BACKEND selects the transport (zenoh or filesystem).
Wire format reference (for native language publishers)
For C++, Rust, or any language that needs to publish without the Python SDK:content_type:"numpy/ndarray"|"application/json"|"application/octet-stream"shape:[H, W, C](for ndarray; omit for JSON/bytes)dtype:"uint8"|"uint16"|"float32"etc. (for ndarray; omit for JSON/bytes)
C++ native publish example
Minimalzenoh-cpp snippet that publishes frames with the correct header:
DataBus.subscribe() automatically decodes this payload — no adapter code needed.
Option B: Filesystem convention (fallback)
The filesystem convention is the fallback for environments where
eclipse-zenoh cannot be installed. For most drivers, use cw.data.publish()
(Zenoh data bus) instead — it provides zero-copy shared memory and is consumed
directly by worker hooks. Both conventions use the same channel names.CYBERWAVE_EDGE_CONFIG_DIR is always set by Edge Core (defaults to /app/.cyberwave).
Ring buffer (for stream data)
- Write
.npyfiles to numbered slots:{slot:06d}.npy - Slot index =
write_count % buffer_size(default: 120) - Atomic writes: write to
{slot}.npy.tmp, thenrename()to{slot}.npy - Update
meta.jsonafter each write
Latest value (for state data)
- Write a single JSON file:
latest.json - Atomic writes: write to
latest.json.tmp, thenrename() - Include a
timestampfield
.npy files and JSON to the same paths.
MQTT topics and payloads
If you publish data over MQTT directly (rather than through the SDK’scw.data.publish), see the MQTT API Reference for the complete list of topics and payload schemas supported by the platform. That page covers:
- Twin transform: position, rotation, scale
- Joint state updates (single-joint, flat multi-joint, and aggregated formats)
- Navigation commands and status reporting
- Locomotion commands (
move_forward,turn_left, etc.) - Telemetry lifecycle events (
connected,telemetry_start,telemetry_end) - Sensor data: depth frames, point clouds, metrics
- Edge health reporting
- WebRTC signalling
- Health check ping/pong
Migrating from MQTT-only drivers
If your driver currently publishes sensor data over MQTT, you can add Zenoh publishing without removing the MQTT path. The two paths serve different consumers:- MQTT → cloud backend (telemetry, frontend, workflows)
- Zenoh → local worker containers (zero-copy inference, fusion)
Step 1: Set CYBERWAVE_DATA_BACKEND
EnsureCYBERWAVE_DATA_BACKEND=zenoh is set in the driver container. Edge Core sets this automatically for managed drivers. For manual testing:
Step 2: Add cw.data.publish alongside the MQTT call
Step 3: Verify with a subscriber
Controlling which paths are active
SetCYBERWAVE_PUBLISH_MODE to choose:
Licensing your driver
You own your driver code. There are two common paths:- Open source — publish your driver as a public repository on GitHub under the Apache 2.0 license. This is our recommended default and makes it easier for the community to contribute and reuse your work.
- Closed source — keep your driver proprietary. In this case, we recommend obfuscating your code before distributing the image and including a clear license file that reflects your distribution terms. Interested in writing a closed-source driver? Reach out to us.
Example driver repositories
Fork or read these repositories when building your own compliant driver — each includes aDockerfile, Edge Core env contract, and (where applicable) a cw-driver.yml:
- Camera — cyberwave-edge-camera-driver: USB/RTSP camera as a twin (child of a parent robot twin).
- SO-101 arm — cyberwave-edge-so101: joint bus + command topic pattern for a manipulator.
- ROS UGV — cyberwave-edge-ros-ugv: locomotion and onboard camera profiles under
cw-driver-profiles/.
Advanced topics
Once you have a working driver, these guides cover the platform features your driver can leverage:Edge Workers
Hook-based worker modules for on-device ML inference and event-driven
processing.
Data Wire Format
SDK header encoding, key expressions, and the on-wire contract for edge data
channels.
Data Fusion Primitives
Time-aware sensor fusion: interpolated point reads and time-window queries.
Synchronized Multi-Channel Hooks
Approximate time synchronizer that fires when samples from all listed
channels arrive within tolerance.
Record & Replay
Capture live edge data to disk and replay it for deterministic debugging.
MQTT API Reference
Complete list of MQTT topics and payload schemas: telemetry, commands,
navigation, joint states, and more.