Until now, Copper demonstrated strict determinism within a single process or a single embedded system. With 0.15, this extends to distributed systems.

Imagine a robot composed of multiple subsystems: two computers and several MCUs, each running their own Copper process. With 0.15, you can deterministically replay logs across all of what we call “subsystems” (processes or embedded devices) as a single unified execution. Your entire robot can now be replayed locally as one process with 100% fidelity.

And it does not stop at a single robot.

The same model applies to fleets. You can now deterministically replay a swarm of robots as one coherent system. Distributed autonomy becomes reproducible, testable, and debuggable end to end.

Traditionally, robot swarms have lived mostly in research environments, where reproducibility and safety constraints are relaxed. Copper brings this paradigm into real-world systems, where reliability, traceability, and safety are paramount. What was previously experimental can now be engineered, validated, and deployed with confidence.

To support this, we introduced a new configuration model for both subsystems and fleet of identical robots. A master config defines the full system, and composable instance files allow per-robot overrides such as IDs, calibration, or deployment-specific parameters. This provides a clean path from one robot to many.

On the runtime side, 0.15 introduces a multithreaded execution core. The new parallel-rt mode allows multiple CopperLists to run in parallel, increasing system bandwidth (higher Hz) with minimal latency impact, while preserving deterministic ordering and logging guarantees.

We also improved timing precision. Some applications require extremely tight cycle control, even on standard host systems. The rate limiter has been upgraded into a high-precision synchronization mechanism, enabling much tighter control over tick generation and execution cadence.

And there is much more in this release. We cannot wait to see what the ecosystem will create with those new capabilities.

Check out the full release notes for all the details.

And as usual, join us on discord if you have any question!

Humanoid robots dancing.
Quadrupeds doing parkour.
Drones flying complex trajectories.
Robots manipulating objects with increasing dexterity.

At the same time, machine learning has advanced rapidly. Perception systems that were considered difficult ten years ago are now common.

Note: This blog entry is based on the small keynote I gave at our copper-rs meetup, you can also check it out on our youtube channel

We are not talking about research prototypes or lab demonstrations but autonomous systems operating reliably in the real world.

Today the most visible example is probably Waymo. It represents one of the most advanced deployments of autonomy and required enormous investment in sensors, infrastructure, and engineering effort.

Even then, the economics remain difficult. Autonomy at scale is still extremely challenging.

The gap between impressive research demonstrations and reliable autonomous products is much larger than it appears from the outside. Copper started from the desire to understand where that gap comes from.

Robotics Works in Controlled Conditions

Most robotics projects follow a similar trajectory.

Early development tends to move quickly. A robot learns to navigate a hallway, follow a road, or operate inside a structured environment such as a warehouse.

These early results are often good enough to produce convincing demonstrations. They show that the core approach works and that the system can perform useful tasks.

However, the real challenge begins once the robot leaves controlled conditions.

Robots deployed in the real world encounter environments that are fundamentally unpredictable. Lighting conditions change, sensors occasionally misbehave, and unexpected situations appear that were never part of the initial design.

This shift fundamentally changes the development process.

The Long Tail Problem

Autonomy development is dominated by what is commonly called the long tail.

Many situations a robot encounters are common and easy to handle. A car driving down an empty road or a robot navigating a clear corridor represents the majority of operating time.

But safe autonomy requires handling far more than common cases. It must also handle rare events that occur only occasionally.

Examples include unusual lighting conditions, sensor edge cases, unexpected obstacles, or combinations of circumstances that were never seen during initial testing.

As development progresses, improvements become harder because each new issue tends to correspond to increasingly rare situations. Collecting the relevant data becomes more expensive and reproducing failures becomes more difficult.

Eventually progress slows dramatically because the engineering loop breaks down. Failures happen rarely and inconsistently, which makes them extremely difficult to analyze and fix.

Closing this loop requires the ability to reproduce failures reliably.

Determinism as a First Principle

Reproducing failures in robotics systems is harder than it should be.

Ideally, debugging a failure would follow a simple workflow. A robot run is recorded, the relevant inputs are captured, and the system is replayed offline in order to reproduce the exact same behavior.

In practice this often fails because robotics software stacks are not deterministic. Small sources of nondeterminism accumulate throughout the system: thread scheduling, asynchronous messaging, operating system behavior, memory allocation patterns, and timing variations.

When these effects interact, the same inputs can produce slightly different outputs on every run. This makes debugging extremely difficult because a failure that appears once may never appear again under identical conditions.

Copper was designed around the idea that deterministic replay should be a fundamental property of the system. Given the same inputs, the system must produce exactly the same outputs. This guarantee allows failures observed in the field to be reproduced reliably during development.

In Copper this property is continuously tested. Recorded runs are replayed automatically and the resulting outputs are compared against the original execution. Any divergence indicates that determinism has been broken somewhere in the system.

This constraint strongly influences the rest of the design.

Performance Without Sacrificing Modularity

Autonomous systems operate in a tight control loop that continuously processes sensor data and generates actions.

The latency of this loop directly affects how the robot behaves. Faster loops allow the system to react more quickly to environmental changes.

Unfortunately many robotics frameworks introduce significant overhead through serialization, message passing layers, buffering, and dynamic scheduling.

Developers frequently respond by merging multiple components together into large processing blocks. Doing so reduces communication overhead but also eliminates many advantages of modular systems. Debugging becomes harder and reusable components become scarce.

Copper approaches the problem differently. The runtime is designed so that the cost of decomposing a system into small components remains extremely low. This makes it possible to preserve modularity without sacrificing performance.

Maintaining small components has several benefits. Individual stages can be inspected independently, intermediate data can be logged for debugging, and components become reusable across projects.

These properties become particularly valuable when diagnosing failures in the long tail.

Modern Computers Are Not Optimized for Robotics

Another challenge arises from the hardware itself.

Modern CPUs are complex parallel machines designed to maximize throughput across many tasks. They rely on deep cache hierarchies, speculative execution, and multiple cores to achieve high performance.

This architecture works well for workloads such as web servers or video streaming, where throughput matters more than predictable latency.

Robotics systems have different requirements. A robot must process sensor data and react within predictable time bounds. Small variations in execution timing can accumulate and degrade system behavior.

Bridging the gap between hardware optimized for throughput and software that requires low latency requires careful control over memory access patterns and scheduling.

Copper attempts to align software execution with the underlying hardware architecture rather than fighting against it.

Navigating Design Tradeoffs

Designing a runtime for robotics involves balancing several competing constraints.

Low latency and high throughput do not always align. Hardware optimized for bandwidth can introduce unpredictable delays.

Algorithm designers prefer abstract representations of computation, while efficient execution requires awareness of hardware details such as memory layout and caching behavior.

Safety considerations push systems toward static guarantees, while experimentation during development requires flexibility.

Finally, increasing AI capability often requires more compute resources, which increases cost and power consumption in deployed robots.

Copper was designed by explicitly acknowledging these tensions and choosing design points that favor reliability and reproducibility.

Copper as Compiler, Operating System, and Runtime

The resulting system does not fit neatly into a single category.

Copper behaves simultaneously as a compiler, an operating system, and a runtime for compute graphs.

The compiler component moves as much work as possible out of runtime and into compile time. Tasks such as scheduling decisions and memory layout can be resolved before the robot ever executes the program.

Treating Copper as an operating system allows the runtime to avoid many behaviors of general-purpose operating systems that introduce unpredictable timing, such as virtual memory and dynamic scheduling.

Finally, Copper provides a safe compute graph abstraction that allows robotics algorithms to be expressed naturally while maintaining strong safety guarantees.

Rust plays a central role here because it provides memory safety and predictable performance without introducing hidden runtime costs.

Generating a Specialized Runtime

When a robotics application is compiled with Copper, the system analyzes the graph of tasks that define the robot’s behavior.

From this graph it generates a specialized execution plan and memory layout tailored to that particular application.

The tasks are ordered in memory so that execution follows a predictable sequence. Memory buffers used to pass data between tasks are laid out sequentially, improving cache locality and reducing latency.

This approach turns the pipeline into a highly efficient execution path aligned with the behavior of the processor’s cache and prefetch systems.

Real-Time Execution and Logging

Copper separates two concerns during execution.

The real-time loop processes sensor data and produces actuation outputs as quickly as possible. This path avoids unnecessary work and keeps latency low.

A secondary process handles logging and data persistence. Logging occurs between cycles so that it does not interfere with the real-time loop.

Occasionally the system records keyframes that capture internal state. These keyframes allow debugging tools to jump directly into a replay without requiring the entire execution history from the beginning of the log.

This mechanism helps maintain deterministic replay even when logs are incomplete or partially corrupted.

Toward Reliable Autonomy

Robotics will not become widespread simply because algorithms improve.

Reliable autonomy requires infrastructure that allows engineers to reproduce failures, understand system behavior, and iterate quickly on real-world deployments.

Copper explores one possible approach to this problem by combining deterministic replay, compile-time system generation, and data-oriented execution.

The project is open source and actively evolving as more real systems adopt it.

Observability with the remote deterministic debug/replay API

We added a full observability API with deterministic replay: see below our Copper time traveler debugger prototype based on this API so it is easier to see visually. Either some local tooling like this one can play and replay deterministically 2 versions of your application and do visual A/B comparisons of your algorithmic change or imagine that at scale on a CI/CD remote controlling the replay over aggregated cut logs.

Copper can speak with your units, including validating of you are mixing apples and oranges in your code at compile time. We created a new cu29-units crate so you can painlessly use units types that are fully integrated with copper's serialization and reflection!

use cu29::units::si::acceleration::meter_per_second_squared;
use cu29::units::si::angular_velocity::radian_per_second;
use cu29::units::si::f32::{
    Acceleration, AngularVelocity, MagneticFluxDensity, ThermodynamicTemperature,
};
use cu29::units::si::magnetic_flux_density::microtesla;
use cu29::units::si::thermodynamic_temperature::degree_celsius;
use serde::{Deserialize, Serialize};

/// Standardized IMU payload carrying acceleration, angular velocity, and optional magnetometer data.
#[derive(Clone, Copy, Debug, PartialEq, Serialize, Deserialize, Encode, Decode, Reflect)]
pub struct ImuPayload {
    pub accel_x: Acceleration,
    pub accel_y: Acceleration,
    pub accel_z: Acceleration,
    pub gyro_x: AngularVelocity,
    pub gyro_y: AngularVelocity,
    pub gyro_z: AngularVelocity,
    pub temperature: ThermodynamicTemperature,
}

Log visualization

we also added a simple log visualizer that can spawn rerun on recorded data from a standard copper log called cu29-logviz (instead of having to record with rerun). We started to build a compatibility layer between the Copper standard types and rerun so automagically you have the right type of visualization for your component. Thanks to Yang Zhou (NYU) for this amazing contribution!

Centralized Linux/std resources

Copper started to use a new concept of resources ie. for example which serial port do you want to dedicate for which bridge in copper, a kind of HAL system so your tasks can run anywhere. It was limited to embedded devices but now get generalized to Linux! So you can all of the sudden start using an RC controller on linux or FPV goggles or GPSes.

This cement copper as an operating system that is completely uniform between running as a process or running baremetal on microcontrollers. Thanks again to Yang Zhou for this one!!

Standardized GNSS payload, and ublox compatiblity.

ublox has an advance cross-constellation API now that we fully map into standard Copper messages. This unlocks very cheap GPS devices and a lot of advanced functions.

And a bunch of smaller improvements and bug fixes… take it while it is hot!

As robotics systems scale, particularly in high-reliability sectors, execution and determinism becomes foundational. We’re excited to collaborate with Tolle Labs to bring Copper Robotics’ deep experience in scalable robotics execution into their stack and advance the development of robust Physical AI systems

Tolle Labs builds autonomy-first aerial robotics systems serving critical verticals such as construction, defense, and gaming & simulation environments. The company integrates AI, computer vision, and advanced flight control into field-deployable unmanned systems engineered for precision, reliability, and mission adaptability. Alongside its application-layer innovations, Tolle develops core flight-control technologies such as Airavat : a high-performance autopilot designed for robust, multi-vehicle operations.

Through this collaboration, Copper Robotics will work closely with the Tolle team to integrate copper-rs, our deterministic, Rust-native runtime into their active autonomy stack. The pilot will evaluate execution predictability, latency control, system observability, and integration efficiency under real-world operational constraints.

Copper Robotics is already deployed across multiple robotics platforms, and this engagement extends our execution layer into a production-oriented aerial autonomy environment. Together, we aim to demonstrate how deterministic runtime infrastructure can streamline increasingly complex autonomy systems while maintaining strict control over system behavior.

We look forward to sharing more updates as the pilot progresses.

This walkthrough is designed for newcomers who want a clear mental model of what Copper is and why it exists but also existing Copper users who want to discover the latest features, marked as New in the timeline.

We cover the core concepts behind Copper by showing real tooling, real workflows, and real systems. From observability and determinism to AI inference, embedded development, and distributed execution.

We will touch on:

• ConsoleMon, Copper’s TUI monitor - New: refreshed look and bandwidth pane

• Offline config viewer and DAG visualization - New: updated visuals

• New: DAG statistics combining structure with runtime performance

• New: Exporting logs to the MCAP format

• New: Visualizing Copper logs in Foxglove

• Determinism in Copper: Why it matters and how we can actually prove it

• New: AI and ML inference with HuggingFace

• Live visualization using Rerun

• Embedded and bare metal development - Flight controller example

• Missions - Quick overview using the flight controller

• New: Resource bundles - What problem they solve and how they work

• Multiprocessing and distributed Copper - New, kind of: Zenoh bridge

Feel free to use the index to jump to the parts that matters to you.

It almost made me a full on AI assisted coding skeptic. But as I was developing a new set of components on top of Copper for making a good platform to build drones on, it completely blew my mind, here is my analysis of why…

Good, principled Engineering will never go away.

Determinism and observability have always been the #1 non negotiable feature of Copper

• For roboticists productivity: I have a saying that “if a bug is reproducible, it is already dead”. Most robotics frameworks including ROS do not guarantee deterministic replay so you won’t have any guarantee that you can reproduce a bug.

• As a proof of safety: To use a dataset as a proof of safety in your safety case: it is easier if 1. you can prove that your robot always runs the same way out of the same data and 2. if you prove that your data coverage is good enough for your problem space. Proving that your robot safe like this is the only way you have if you integrate complex ML inference in your architecture.

Zero performance cost modularity

• Robots are complex and already very untangled between physics, EE, OS, algorithms, you have unpredictable side effects. If you untangle also your robot code you are in for a very bad experience.

• Robotics frameworks usually use a variant of microservice architecture to isolate pieces of the code from the rest of the system. But doing so usually adds a ton of overhead.

• Instead of letting the system be randomly driven by an OS, Copper uses the same principle with that modular structure but uses it to basically build an OS around it!

• This allows copper to optimize end to end your robot at compile time to squeeze everything possible from your underlying hardware.

It allows you to build smaller, more testable and discrete modules because that has virtually no execution overhead!

Copper is built on Rust with Rust and for the good reasons.

Robots needs to be close system programming, see the 2 points I made earlier but when you ask non system programming specialists to produce performent algorithms with C++, you end up chasing undefined behavior in safety critical code all the time. As robots will get more useful being closer and closer to people, killing in the egg any stack and memory corruptions instead of discovering them maybe with some magic linter, worse on CI and even worse on the robot itself is a no brainer.

Copper 😼 & Rust 🦀 as a containment for LLM entropy

LLM has the tendency to produce too much code and locally fix things, this generates a bunch of spaghetti code if let loose across a large piece of code.

Copper has some very precise semantics about what a Task is with a very clear execution & memory model for anyone implementing them. Copper in debug mode can also monitor for the general realtimeness of the tasks with a custom memory allocator catching allocations made at the wrong moments and RTSAN.

Unit tests can emulate one cycle of the execution very easily so your small components by design can be basically designed by unit tests.

Added to this the memory opinionated Rust, if you give those expected inputs & outputs to your digital coding friend, it has almost no choice but to produce correct code.

LLMs excel at plagiarizing & translating so feed them with good examples!

With the structured nature of the tasks, natural patterns emerges, having built a set of task examples for any types helped a lot, you see the LLM catching patterns like forgetting less and less to deal with the Time Of Validity of the sensor data for example.

LLMs don’t work with a reliable feedback loop

LLM loves to hallucinate and if you don’t ask them to verify their work they will definitely take the easy route and say: “done boss! happy boss?” without even compiling their code! It is critical to rub their mistakes to their nose.

With Copper it is easy to make the AI coding agent start the robot in a simulation, log that deterministically then have the agent extract the logs (in JSON) and have them check the results with tools like jq to pinpoint any issues.

Same thing with actual logs from the real world, import them and ask you LLM to find the defect and work with it toward resolving it and extracting the step for deterministic reproduction is trivial.

After a little bit of PID tuning this BMI088 basically worked flawlessly, here is its first flight

cu-bmi088: a fully AI coded component with Copper, implemented in one shot with Codex

The BMI088 is a kind of a classic IMU you can find it all types of robots, the context here is a flight controller for a quad copter

What was given as input:

• a working example of another IMU (the mpu9250)

• the datasheet of the bmi088

• the expected output in the form of a message expecting SI units

• a set of resources (this is a new type of component in Copper to expose hw and various system resources)

What this says about the future

FPV of Copper passing its first (very sketchy) powerloop

Large language models don’t change what makes systems robust. They don’t relax constraints, and they don’t replace discipline. If anything, they do the opposite: they amplify the consequences of whatever engineering choices were already present. In systems built on loose assumptions, implicit state, and weak boundaries, LLMs accelerate entropy. In systems built from first principles, they are forced to operate within real limits.

This is why the question is not whether LLMs will become better at writing code for robots, but whether our systems are structured well enough to tolerate probabilistic contributors at all. Determinism, decomposition, and enforceable invariants are not legacy ideas; they are the only way to keep feedback meaningful when behavior is no longer authored line-by-line by a human.

First-principles systems age well precisely because they constrain entropy. They make change observable, regressions attributable, and corrections local. This is critical in robotics, a discipline already riddled with externalities. That was true before LLMs existed, and it remains true now. Copper was not designed with LLMs in mind; it was designed to make complex systems observable, deterministic, and constrained. As a result, LLMs can be used without destabilizing the system, with their usefulness emerging as a side effect of those foundations rather than the reason they exist.

If you like what we are doing, please drop a star our repo on Github, you also want to test out Copper on your project join us on discord, we can help!

We also have a bunch of tutorials on our Youtube Channel to help you started.

This release moves Copper closer to its long-term goal: a single deterministic robotics runtime that runs on workstations, on embedded microcontrollers, on real robots, and inside simulators. The target is robotics that operates on the ground, in the air, on the water, and eventually in space.

Below is what’s new.

Bridges: Multi-Channel I/O

Bridges generalize what used to be separate “sources” and “sinks” into a single logical unit that owns one or more channels (UART, CAN, ELRS radios, ESC buses…).

They let tasks in Copper operate over real transports declaratively, while sharing resources like serial ports safely across crates.

With 0.11, Bridges land end-to-end:

• Config parsing for typed Tx/Rx channel sets

• Runtime scheduling that handles multi-channel dispatch

• Graph APIs that visualize bridges as first-class components in missions

• Monitoring that renders those channels directly in the TUI DAG and matches the DOT export exactly

For users, this means you can build complex robot I/O pipelines without writing glue code. For us, it’s the core of how Copper will handle multi-sensor, multi-bus robots going forward.

A Copper-Native Flight Controller (MVP)

A flight controller is a perfect target for showcasing Copper’s determinism and low-latency scheduling.

We’re waiting on new rp2350-based FC boards for live flight tests, but the full stack already runs beautifully on our devkit, including SD-card logging and deterministic replay!

ELRS/CRSF Radio Link (host + firmware)

Our CRSF/ELRS bridge works in both environments. RC commands flow into Copper tasks, and telemetry (LQ, battery, failsafe) flows back through the radio link.

Demo end to end ELRS → DSHOT running on our Copper Development Kit

Bidirectional DSHOT (RP2350)

The RP2350 PIO implementation drives ESCs with DSHOT300 timings and decodes one-wire telemetry bursts. Bridges expose four static DSHOT channels into the task graph.

MSP Everywhere (no_std + Bridge)

MSP remains the lingua franca for Betaflight, Cleanflight, INAV, and countless tools.

We now support MSP in no_std, built atop the new embedded registry so multiple crates can safely share UART handles. Stream RC data, sensor packets, tuning commands without writing MSP plumbing.

PID Control in Firmware

cu_pid now works in no_std and depends only on alloc.
The same PID loops you use on Linux now run unchanged on MCUs.

Taken together MSP + PID + CRSF + DSHOT: Copper now has the core of a flight controller, implemented entirely in Rust, end-to-end deterministic, and fully pluggable into the Copper task graph.

Remote Operation & Telemetry

ELRS/CRSF enables Remote Ops beyond just flying applications

The radio link works identically for all kinds of robots on host or MCU.
This allows remote manual real time operations over ELRS (2.4GHz and 900Mhz).

We ship a demo (cu_elrs_bdshot_demo) showing ELRS + DSHOT working together.

Tooling & Monitoring Upgrades

Bridge-Aware Monitoring

The console TUI now includes:

• Direct rendering of bridge nodes in the DAG

• Matching DOT export → live graph parity

• More compact layouts

• Patched tui-nodes tuned for multi-channel connectors

• Cleaner merged connectors and better icons

Enhancements & Maintenance

• Optional channel routes make mission authoring less verbose.

• Embedded CI now automatically exercises ARM-only components.

• Dependency refresh (ron 0.12, cudarc 0.18, rerun 0.27).

• Simplified structured logging backend: we removed rkv after Mozilla confirmed lmdb backend deprecation. Replaced with a simple lock + bincode dump for now.

• Console state corruption fixed when exiting cu_consolemon.

• Numerous QoL polish items across bridges, missions, and monitoring.

Bug Fixes

• Simulation generation now correctly builds Sink proxies when a task listens to two upstream tasks.

Looking Ahead

Bridges are the long-term foundation for how Copper talks to the physical world.
Flight controllers are the first vertical we’re bootstrapping, but the same stack extends to ground robots, manipulators, and embedded perception.

Each release rotates through a new specialty, building up an open, deterministic robotics SDK in Rust—from devkits to real hardware.

If you like what we are doing, throw us a star on Github, it would mean the world to us!

⭐⭐ https://github.com/copper-project/copper-rs ⭐⭐

Copper’s unified vision: Robots come in all shapes and forms and we want your algorithms to compile and be deployed unchanged on Linux/macOS and on MCUs (or both in tandem). Train or prototype on your workstation, deploy to the edge, then replay the exact logs back on a workstation build to debug with full tooling.

With Copper v0.10 the runtime can run on its own with no OS required! It can log straight on flash storage like an SDCard /eMMC and because Copper controls time and logs consistently, you can log replay a baremetal run on your desktop with the exact same codebase compiled as a normal Copper application.
By removing the OS middle man, Copper is getting closer to power safety critical applications with strict real time requirements.

What does this unlock?

Well, an entire new class of embedded robotic systems now becomes possible with Copper.

• Drones
  Run your flight controller directly on Copper: no need for a second companion computer just to run autonomy logic. Less weight, less complexity, one unified stack.

• Vehicle ECUs
  Most vehicles run distributed MCUs with electronic control units (ECUs). Copper now fits inside those architectures, enabling high-level functions directly on embedded control.

• “Big Brain / Small Brain” architectures
  Mix a higher-level Linux computer with multiple MCU-based controllers without changing your development workflow. Same config, same log format, same simulation, same replay. One system, end-to-end.

• AI at the edge
  Microcontrollers are getting NPUs and accelerators. Pair those with Copper and you can run sensor-near AI processing with zero messaging glue and full determinism.

• Road to safety
  Copper behaves like a compiler + runtime, not a scripting layer. Combined with baremetal (no OS or kernel), this opens a credible path toward functional safety certification.

Order a Copper Baremetal Reference platform & kit!

Hardware wise, we have selected the Pimonori Pico plus 2W as our first baremetal reference platform. It features a very well-documented RP2350B board with some beefy specs: 16 MB QSPI flash, 8 MB PSRAM, USB-C, Qwiic, and an accessible SWD debug header. It offers a great range of ready made sensors and actuators like cameras and SDCard slots.

If you want a packaged up and tested hardware kit ready to deploy Copper on with the MCU + Plate + sdcard reader + CMSIS-DAP probe + cable), ping us at info@copper-robotics.com and we’ll get you set up.

What’s next

We’ll keep building on Rust’s embedded ecosystem: sensor implementations, actuator implementations and algorithms adapted for MCU constraints, and of course new additional architectures as demand grows (e.g., ESP32).

Also, any time we have an improvement on the main stack like an improved scheduler, it will automatically translate into an improvement on the baremetal version so stay tuned!

Key Additions

Transform Library (inspired by ROS tf2, but way faster and safer)

Copper now includes cu_transform, a spatial transform and velocity tree designed for fast, zero-allocation queries with timestamped data. It brings real-time motion reasoning into the core of the runtime.

Deterministic Background Tasks

Tasks can now be scheduled asynchronously in the background, enabling long streaming computations (e.g., SLAM backends, GPU pipelines) without blocking real-time execution. This unlocks complex pipelines on constrained hardware.

Keyframes + Log Checker

New structural keyframes and a fsck command for Copper logs make debugging and validation easier — with statistics and corruption checks built in. We're getting closer to full deterministic replay.

Runtime Rate Limiting & Logging Controls

You can now cap the runtime frequency (e.g., 100Hz cap for battery savings) and toggle logging per task. That’s production flexibility built in to adapt to small and big hardware.

Task API Overhaul (Minimal Migration, Major Wins)

We’ve changed the task API to make lifetimes explicit on inputs and outputs. It’s a minimal adjustment but it enables safe background execution, better testability, and clearer semantics across the board.

Why It Matters

Copper is no longer just an experimental framework. It is becoming a full-stack runtime for robotics products: built in Rust, tuned for determinism, and shaped by real use in the field.

If you're a CTO evaluating how to scale beyond ROS or a systems engineer tired of gluing together fragile Python and C++ layers, now’s the time to take a closer look. Copper brings:

• 🔒 Memory safety, concurrency without fear

• ⚡ Fast logs, zero copy, everything linear both in memory and on disk.

• 🧠 A growing library of tasks, transforms, and observability tools

• 📦 Fully declarative task graphs and lifecycle management

Looking Ahead

This release lays the foundation for what’s coming next: smarter automated tuning and scheduling, tooling built for roboticists.

Find the full release note here.

Want to build on Copper? Feel free to reach out below and don’t forget to star us on GitHub!

Let us share with you a cool project moving their stack over to Copper. From their own words:

We are the Utah Student Robotics Club at the University of Utah, and each year we design and build a lunar berm building and excavation robot to compete in NASA’s Lunabotics competition — which we were proud to win this past May!

Our robot took a full year to design and build and for next year’s challenge, we’re building on that success with a similar overall design, upgraded hardware and electronics, and a shift in the software stack: adopting the Copper framework.

The software team’s primary goal this next year is focusing on improving autonomy by making use of smarter localization methods using LIDAR and other sensing technologies.

With the goal of more robust autonomy comes challenges involving fusing sensor outputs from multiple sources like apriltags, LIDAR cameras, IMUS, and wheel rotary encoders to increase the accuracy of the world map and robot pose.

By switching to Copper I hope to leverage the determinism and re-simulation on data from real sensors and logs to be able to more easily tackle autonomy at next year's competition!

Here is a little video of their trial run of a Copper pipeline running using a Unitree L2 implementing KISS-ICP. The visualizer is rerun.

Thank you so much to Matthew Ashton Knochel for sharing his progress with the project and if you need more info about the it, feel free to contact them directly!

Missions

In real-world robotics, a robot’s behavior is not unique, you often want variations of them, for example a datacollect mission or an autonomous navigation mission (you can also think of those as modes). With Copper’s new Mission Config, you can now declaratively define multiple missions that reuse the same task and connection structure but selectively activate subsets of the graph. This eliminates duplication and enables dynamic switching between modes like as another example a fallback or degraded behavior.

Missions streamline deployment and testing by making mode-specific logic explicit and composable. See this simple example DAG and its matching configuration below. Either the green or red paths will be enabled.

(
    missions: [ (id: "autonomy"),
                (id: "datacollect"),
              ],
    tasks: [
        (
            id: "src",
            type: "tasks::ExampleSrc",
        ),
        (
            id: "autonomy_task",
            type: "tasks::AutonomyTask",
            missions: ["autonomy"],
        ),
        (
            id: "datacollect_task",
            type: "tasks::DataCollect",
            missions: ["datacollect"],
        ),
        (
            id: "sink",
            type: "tasks::ExampleSink",
        ),
     ],
    cnx: [
        (src: "src", dst: "autonomy_task", msg: "i32", missions: ["autonomy"]),
        (src: "src", dst: "datacollect_teak", msg: "i32", missions: ["datacollect"]),
        (src: "autonomy_task", dst: "sink", msg: "i32", missions: ["autonomy"]),
        (src: "datacollect_task", dst: "sink", msg: "i32", missions: ["datacollect"]),
    ],
)

Modular config

Robot configs can get messy fast. That’s why Copper now supports Modular Config: the ability to split configuration files into clean, reusable modules.

Each config module can define tasks, connections, logging, and hardware parameters, and can be included with parameter overrides (e.g., same motor config, different pins). This makes configs more maintainable, DRY, and easier to scale across platforms and variants.

Perfect for teams managing multiple robots or hardware layouts.

Here is an example:

// main_config.ron

(
    tasks: [],
    cnx: [],
    monitor: (
        type: "cu_consolemon::CuConsoleMon",
    ),
    logging: (
        file: "robot.copper",
        level: "debug",
    ),
    includes: [
        (
            path: "basic.ron", // see the included file below.
            params: {},
        ),
        (
            path: "motor.ron",  // see the included file below
            params: {
                "id": "left",
                "pin": 4,
                "direction": "forward",
            },
        ),
        (
            path: "motor.ron",
            params: {
                "id": "right",
                "pin": 5,
                "direction": "reverse",
            },
        ),
    ],
)

// basic.ron

(
    tasks: [
        (
            id: "source",
            type: "FlippingSource",
            config: {
                "rate": 10,
            },
        ),
    ],
    cnx: [],
)

// motor.ron

(
        tasks: [
            (
                id: "motor_{{id}}",
                type: "cu_rp_gpio::RPGpio",
                config: {
                    "pin": {{pin}},
                    "direction": "{{direction}}",
                },
            ),
        ],
        cnx: [
            (src: "source", dst: "motor_{{id}}", msg: "cu_rp_gpio::RPGpioPayload"),
        ],
    )

All those have been release as of v0.8.0.

Full examples are in the example directory.

Any question? Join us on discord!

As usual, if you like what we are doing, drop a ⭐ on our github repo !

So, in this new release the Copper to ROS2 bridge is here … and with it, a progressive escape hatch from ROS2's tangled web of complexity and indeterminism. Copper is built for modern robotics teams that want determinism, performance, and a Rust-first stack. But what if you're still deeply embedded in ROS2?

Don't Rip and Replace… Migrate progressively

Our community built the zenoh_sink_ros bridge for exactly this scenario. It lets you keep your ROS2 system running as-is, while gradually moving individual tasks over to Copper. Start with your most performance-critical pipelines like perception, sensor fusion, etc and leave the rest of the non critical ones in ROS2 untouched. You’ll see gains from day one.

How It Works

Copper can emit ROS2-compatible topics over Zenoh, using the rmw_zenoh backend. No need for ROS2 builds or colcon. Copper sends the data, and your existing ROS2 nodes receive it like any other topic.

See the implementation here:
🔗 cu_zenoh_sink_ros

Once connected, you can:

• Port a node (e.g. sensor fusion) from ROS2 to Copper.

• Wire its output to a ROS2 consumer over Zenoh.

• Validate it in production.

• Repeat with the next component.

We recommend starting from the top of your ROS2 graph ie. nodes that publish to the rest of the system. This makes it easier to drop Copper in as a fast, deterministic producer, without needing to rewrite the rest of the pipeline. That’s why this first bridge is a copper sink, not a source as it is designed to emit messages to the rest of ROS2.

Beyond ROS2: Zenoh as a Universal Bridge

The community also released a pure cu_zenoh_sink that emits messages in your choice of serialization (ie. anything supported by Rust SerDe actually). This lets you:

• Connect Copper to a non-Copper Rust process (e.g. for data logging, or visualization).

• Build a Copper-powered swarm of robots using Zenoh as the transport layer.

• Create mixed-language architectures where Copper tasks communicate with Python or C++ over lightweight Zenoh messages.

This is your escape route not only from ROS2, but from the overhead of traditional robotics middleware entirely.

Special thanks to Julien Enoch from Zettascale (the creator of Zenoh) for his support!

Questions?

Join us on our Discord Server and if you like what we are doing at Copper don’t forget to ⭐ our github repo!

One of Copper's superpowers is bringing high-level, safe autonomy to really constrained environments; not just technically (power, weight), but also in practical business terms like BOM cost.

To show this off, we’ve been putting some time into a quadcopter demo with three goals in mind:

• Create a solid, end-to-end tutorial series on YouTube to help you bring Copper to life in your own projects.

• Drop half a dozen new components in the upcoming v0.7.0 release ready for you to use. including flight controller communication, controls, and fast CV-based fiducial localization.

• Build a working demo and reference platform to make it easier (and cheaper) to get started with these kinds of applications.

Got an autonomous robotics project in mind? Reach out — we're here to help!

More soon!

Her name is “Perroquet” on her maiden flight a Radxa SBC running Copper autothrottling and fighting the wind to stay in front of the marker.

Join us at the Robotics Summit & Expo at the Boston Convention and Exhibition Center on April 30-May 1.

Guillaume has a talk session: Bridging Robotics and Systems Programming: Why Rust is a Game Changer at 11:30 AM on May 1.

In the session, through real-world examples and Rust code snippets, we’ll explore how Rust excels in managing concurrency, writing error-free algorithms, and bridging the gap between low-level control and high-level design under the Copper framework.

By the end, you’ll see how Rust can streamline robotics development, making it more integrated, efficient, and reliable.

You can explore the agenda and register for the event here: https://www.roboticssummit.com/

We are looking forward to seeing you!

But what about throughput?

This release focuses on pushing large buffers through Copper's compute graph—such as images, matrices, and point clouds.

For example, here's a Video4Linux video source running at 4K 30fps, seamlessly processed through Copper and streamed to Rerun.

We achieved this by leveraging Direct Memory Access (DMA), allowing data to flow directly from the camera without passing through the main CPU. The data remains untouched until it's finally streamed to Rerun.

But it doesn’t stop there! Copper now supports NVIDIA® CUDA®.

Our buffer management system enables efficient tracking of memory buffers in heterogeneous architectures, essentially, any memory not directly controlled by the CPU, such as GPU memory or NUMA setups. We've integrated Copper with cudarc, allowing users to seamlessly transfer images and buffers to and from the GPU, and share them across tasks for image processing, linear algebra, neural networks, and more.

We can't wait to see what our users will create with Copper and the power of CUDA kernels at their fingertips!

Other notable highlights in this release

This release has been incredibly busy! We received 10 external contributions—an exciting first for us—demonstrating the growing momentum of the Copper ecosystem.

• We simplified the creation and initialization of Copper applications with a prefix and a builder pattern:

let mut application = CaterpillarApplicationBuilder::new()
        .with_context(&copper_ctx)
        .build()
        .expect("Failed to create application.");

• We have a new driver for the Livox Lidar Tele15 that is very useful for long range applications like highway driving.

• We also simplified the automatic generation of Copper projects by asking at creation which version of Copper the user wants to use : either local, git or the latest official release.

• Logging: we added a couple parameters to the application config to be able to tune the output: those large images challenged the default parameters! We can also completely disable the task logging for people using external loggers.

• We now have a new Debug Output panel in the little TUI monitoring component

And much more, feel free to check out the detail release note here!

Join us for an internship at Copper Robotics!

We are redefining how robot software is built with our modern stack in Rust.

This is a chance for you to work in a professional setting on an Open Source project and build your portfolio.

Responsibilities

• Working on meaningful improvements to the stack like improved parallelism, distributed workload, AI based scheduling etc...

• End to End ownership. You are here to learn what it is like to be a Software Engineer. We will help of course but we believe that the best way to learn is to actually engage in meaningful work and own it.

Qualifications

• Be proficient in Rust is a must prior to joining.

• Good understanding and interest in system programming and computer architecture. ie. if you need to google what "cache coherency" or "memory prefetching" means, this might not be an internship you'll enjoy...

• Good working English.

• Good communication skills (especially if remote)

• A good sense of humor, we are serious about what we are doing while having a blast!

Pluses

• Robotics: algorithms, hands on builds, drivers, integrations, competitions etc...

• ML: Fast inference, accelerated computing (SIMD/GPU), Q learning.

• Contributions to APIs or development tooling.

How to Apply?

Our interview process is straightforward and hands-on. Instead of traditional whiteboard challenges like inverting a binary tree, we want to see you tackle a real-world task directly related to Copper. Here’s how it works:

• Visit our GitHub repository: https://github.com/copper-project/copper-rs

Browse through the open issues and pick one that interests you and feels like in your alley.

Dive in, comment on the issue or ping us on our discord server about how you plan to solve this and work on a solution. When it is ready, post a PR! Feel free to ask questions or engage with us if you need guidance on discord!

This approach helps us evaluate how you think, collaborate, and solve problems while giving you a taste of what it’s like to contribute to Copper and something to show not only to us but to any recruiter!

We look forward to seeing what you can do. Let us know if you have any questions or need help getting started!

By leveraging WAKU Care’s automated ticket handling, data-driven maintenance insights, and proactive support strategies, Copper’s users can now achieve optimized runtime and superior service management, taking their robotics systems to new heights.

Check out the WAKU Robotics website to explore more their solutions!

Looking Ahead: More Collaborations to Come

This partnership with WAKU Robotics is just the beginning. Copper Robotics is committed to continuous growth and innovation, and we are excited to explore future collaborations with other leading companies in the robotics and automation sectors. Together, we can push the boundaries of what’s possible and deliver even greater value to our users.

We look forward to working with more industry leaders to bring new solutions that will enhance the performance, reliability, and efficiency of robotics systems across all industries.