Copper Bridge
The fastest way to integrate a robot that already runs copper-rs.
copper-rs robots integrate through the public
rovernexus-cu-components
crates. The cu-rover-nexus crate provides a Copper bridge component
(NexusBridge) that you include in your graph. It translates Copper pins
(pose, twist, status, pause, teleop) to and from the same Cap'n Proto
messages the agent consumes over local Zenoh. From the agent's
perspective a bridged copper-rs robot looks identical to a native one.
Unlike the ROS 2 Bridge, which is a separate process on
the Unix domain socket hop, the Copper bridge is
compiled into your Copper application and speaks the agent's primary Zenoh
contract. Autonomy tasks do not depend on rover_nexus_core or open Zenoh.
The bridge owns the session.
How it fits
Copper graph <──► NexusBridge (same binary) <──► local Zenoh (Cap'n Proto) <──► rover-agent <──► cloud
- Uplink: your tasks publish pose, twist, and status onto Copper pins.
The bridge converts them to Cap'n Proto and publishes on the local Zenoh
robot/**key space. - Downlink: the bridge subscribes to the agent's
commandtopic, converts commands into Copper payloads, and emits them on pins your drivetrain or interlock consumes.
See Architecture for the end-to-end flow and Zenoh for the hop the bridge uses.
What you do
- Install the agent on the robot's Linux host by running its bootstrap command, which installs and enrolls the robot in one step.
- Keep the local Zenoh hop. Leave
[local_transport]at the defaultzenoh(or omit it). Do not switch the agent to the Unix domain socket; the Copper bridge connects as a Zenoh client to the agent's local session. See Zenoh. - Depend on the crates. Clone
rovernexus-cu-componentsnext to your Copper application and depend oncu-rover-nexus. Follow that repository's README for the current copper-rs (cu29) pin. Then bringNexusBridgeinto the#[copper_runtime]binary crate:
rust
use cu_rover_nexus::NexusBridge;
- Include the facade and wire pins. Include
nexus_facade.ronin yourcopperconfig.ronand connect your pose / twist / status / pause / teleop pins. Unwired channels stay idle. The default facade maps CopperPose2,Twist,StatusBundle,Pause, andModeNamepins; optional raw pins cover the full messaging catalog. See Telemetry Mappings. - Declare capabilities so the cloud can match missions to the robot.
The repository also ships optional Copper tasks you can include the same way: a mode arbiter (pause / teleop / auto twist interlock), a mission adapter (assign / pause / resume / cancel onto a pursuit path), and a camera sink that feeds the agent's teleop video path.
Requirements
- copper-rs (cu29) 1.1.x on a Linux host (the same host as the agent)
- The agent's
[local_transport]left at the defaultzenoh - The
stdfeature ofcu-rover-nexus(on by default) for the host bridge
The repository documents the pin map, RON includes, optional tasks, camera sink, and bridge config keys.
Next steps
- Set Up the Copper Bridge
- Telemetry Mappings
- Messaging reference
- Coordinate Frames
- Capabilities
- Client Libraries: the Cap'n Proto message definitions the bridge translates to and from, plus Rust/Python/C++ bindings.