copper-rs v0.14: a smoother path from prototyping to production
One of the persistent frictions in robotics is the gap between exploration and deployment.
You prototype quickly in one environment, then rebuild everything to make it deterministic, observable, and safe. The system you experiment with is not the system you ship.
Copper-rs v0.14 is all about closing that gap.
Prototype directly inside a real system
Copper now supports running tasks in Python as a first class citizen. One obvious advantage is to leverage any large python code base you might have with a smooth porting pathway towards Rust but also to temporarily open up a python task to quickly iterate on an algorithm before committing.
That task (or tasks) sit inside a normal Copper graph, alongside Rust tasks, with the same execution model, the same logs, and the same monitoring and determinism.
This makes it possible to:
validate an algorithm against real logs or simulation
inspect it through the Copper monitor
iterate quickly without changing the surrounding system, and without recompiling.
Once the behavior is correct, the task can be rewritten in Rust without touching the rest of the graph and LLMs excel at this!
The system stays the same from first experiment to final deployment.
Monitoring that matches how systems are structured
Monitoring is now explicit and composable.
Instead of combining everything into a single implementation, you can separate:
a safety monitor responsible for decisions
a UI monitor for visualization
a lightweight monitor for logging and debugging
This allows safety policies to be defined independently from how the system is observed.
A new cu_safetymon component is a base example, it provides configurable handling for:
panics
lock failures
shutdown conditions
Webassembly is now a supported target: run a copper application directly in a browser!
A Copper application, including its live monitor, can run directly in a browser. The task graph, execution flow, and monitoring behavior are identical to what runs on desktop or even embedded targets.
This gives a direct way to demo your robots to potential customers in one click!
You can try it right away on our 2 examples:
Click here for to run the balancebot demo (this code runs on linux on a raspberry pi natively with no change)
Click here for a full flight controller demo (this code runs baremetal on an STM32 and we fly real drones with it)
Better integration with existing ROS2 systems
The ROS2 bridge is now bidirectional and supports liveliness tracking and ring-buffered data paths.
This makes it easier to introduce Copper into an existing ROS2 system as you migrate from ROS2 bit by bit.
A unified execution context
Tasks and bridges now receive a CuContext instead of a just a robotic clock.
This context includes:
runtime clock
task identity
execution metadata
CopperList context
This is a move we wanted to do before v1 as it allows us to enrich the context without breaking the API.
The same structure is used across runtime execution, simulation, monitoring, and Python integration.
Fewer workarounds in graph construction
Several changes reduce friction when building larger systems:
tasks now accept up to 12 inputs
outputs can be explicitly marked as not connected (__nc__)
bridges can opt in or out of simulation (run_in_sim)
These remove the need for placeholder components and simplify graph definitions.
Stronger debugging and inspection
Runtime lifecycle information is now a first-class part of logs, and remote debugging includes snapshot caching.
Combined with Python iteration over recorded runs, this makes offline analysis and replay significantly more useful.
Closing the loop
v0.14 brings exploration, simulation, monitoring, and deployment closer together.
You can prototype behavior, inspect it in a running system, refine it, and deploy it without switching environments or rewriting infrastructure.
That continuity is the core of the release.
