Crate cu29_runtime

Source

Expand description

Copper Runtime & SDK

GitHub last commit

§Why Copper

Rust-first – ergonomic & safe

Sub-microsecond latency – zero-alloc, data-oriented runtime

Deterministic replay – every run, bit-for-bit identical

Interoperable with ROS2 – bridges via Zenoh opening the path for a progressive migration.

Runs anywhere – from Linux servers, workstations, SBC to bare-metal MPUs

Built to ship – one stack from simulation to production

Already showing up in: ✈️ Flying | 🚗 Driving | 🌊 Swimming | 🚀 Spacefaring | 🤖 Humanoids

§Try Copper In 30 Seconds

No setup required. Open one of the live demos in your browser: the simulator runs on the left and the live Copper monitor runs on the right.

These are not mockups: BalanceBot is the exact same application that runs on a Raspberry Pi physical robot, and Flight Controller is the same control stack we run on a microcontroller (STM32H7) on real drones. Copper lets that same graph be recompiled for embedded hardware, a local workstation, or the browser.

BalanceBot
Self-balancing robot sim with a live Copper DAG and latency monitor.

Flight Controller
Quadcopter flight sim with the same live Copper monitor.

Prefer a native app instead of the browser? Install the published demo crates from crates.io:

cargo install cu-rp-balancebot
balancebot-sim

cargo install cu-flight-controller
quad-sim

The source for the published demo crates above lives in copper-project/extra-examples. Cross-framework comparison benchmarks live in copper-project/benchmarks.

Want to see more Copper in action? Watch the community showcase video.

§Get Started

Requires Rust 1.95 or newer. The latest stable Rust toolchain is recommended.
Start a new project from templates: Project Templates
Browse the live component catalog: Copper Component Catalog Community components are welcome there too; if you build a reusable Copper component, prefer publishing it as its own crate and adding it to the catalog.
See a full task graph + runtime walkthrough: Copper Application Overview
Build and deploy an application: Build and Deploy a Copper Application
RON configuration reference: Copper RON Configuration Reference

§Documentation

Link to the full documentation

Runtime concepts and SDK features: Copper Runtime Overview
Task lifecycle: Task Lifecycle
Modular configuration: Modular Configuration
Task automation: Task Automation with just
Supported platforms: Supported Platforms
Bare-metal development: Baremetal Development
Component catalog: Copper Component Catalog
FAQ: FAQ
Release notes: Copper Release Notes
Roadmap: Roadmap

§Python Support

Copper has two very different Python stories:

Offline Python log analysis: use cu29-export and app-specific PyO3 modules in the application crates that expose them. This is a reasonable workflow because Python stays off the runtime hot path.
Runtime Python task prototyping: use components/tasks/cu_python_task and examples/cu_python_task_demo. This is for experimentation only and is strongly not recommended for production or realtime robots.

Putting Python inside a Copper task defeats the performance model Copper is built for: it adds allocations, latency, jitter, and middleware overhead, and it ruins the realtime characteristics of the stack. The intended use is to sketch one task in Python, get the behavior right, then rewrite it in Rust.

§Citation

If you use Copper-rs in your research, please cite it as:

@misc{copperrs2026,
  author       = {Guillaume Binet and Copper Project contributors},
  title        = {Copper-rs: A deterministic runtime and SDK for robotics},
  year         = {2026},
  howpublished = {GitHub repository},
  url          = {https://github.com/copper-project/copper-rs},
  note         = {Version v1.0.0-rc1 or latest}
}

§Project

[!NOTE] We are looking for contributors to help us build the best robotics framework possible. If you are interested, please join us on Discord or open an issue.

Modules§

app
config: This module defines the configuration of the copper runtime. The configuration is a directed graph where nodes are tasks and edges are connections between tasks. The configuration is serialized in the RON format. The configuration is used to generate the runtime code at compile time.
context: User-facing execution context passed to task and bridge process callbacks.
copperlist: CopperList is the main data structure used by Copper to communicate between tasks. It is a queue that can be used to store preallocated messages between tasks in memory order.
cuasynctask
cubridge: Typed bridge traits and helpers used to connect Copper to external components both as a sink and a source.
curuntime: CuRuntime is the heart of what copper is running on the robot. It is exposed to the user via the copper_runtime macro injecting it as a field in their application struct.
cutask: This module contains all the main definition of the traits you need to implement or interact with to create a Copper task.
debug: CuDebug: lightweight time-travel debugger helpers on top of Copper logs.
distributed_replay: Discovery, validation, planning, and causal execution helpers for distributed deterministic replay.
logcodec
monitoring: Some basic internal monitoring tooling Copper uses to monitor itself and the components it runs.
payload: Copper-friendly payload helpers used in task messages and task-local caches.
pool
reflect: Runtime reflection helpers built on top of bevy_reflect.
replay: Shared Clap-backed helpers for replay and resimulation binaries.
resource: Resource descriptors and utilities to hand resources to tasks and bridges. User view: in copperconfig.ron, map the binding names your tasks/bridges expect to the resources exported by your board bundle. Exclusive things (like a serial port) should be bound once; shared things (like a telemetry bus Arc) can be bound to multiple consumers.
simulation: cu29::simulation Module

Macros§

input_msg
output_msg
rx_channels: Declares the receive channels of a CuBridge implementation.
tx_channels: Declares the transmit channels of a CuBridge implementation.