Crate cu29_runtime

Source

Expand description

Copper Runtime & SDK

GitHub last commit

🤖 Copper is to robots what a game engine is to games - build, run, and replay your entire robot deterministically.

§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 demos directly:

$ cargo install cu-rp-balancebot
$ balancebot-sim

$ cargo install cu-flight-controller
$ quad-sim

The source code for these demos lives in examples/cu_rp_balancebot and examples/cu_flight_controller.

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

§Get Started

Start a new project from templates: Project Templates
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
Available components: Available Components
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 such as examples/cu_flight_controller. 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 v0.13 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.
monitoring: Some basic internal monitoring tooling Copper uses to monitor itself and the components it runs.
payload
pool
reflect: Runtime reflection helpers built on top of bevy_reflect.
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.