Real-Time Performance Optimisations for Multi-Axis Robotic Systems using copper-rs

Real-time execution is essential for safety-critical robotics systems in autonomous vehicles, surgical robots, and industrial automation. The real-time performance of traditional middleware frameworks are often constrained by design limitations which are difficult to address with minimal modifications to application code.

Consequently, this article will explore the practicality of robotic frameworks outside of well-established ecosystems. Copper-rs is positioned as a direct competitor to ROS 2, offering OS-independent, real-time, deterministic scheduling. I discuss a case study on an open-loop, 18 degrees of freedom (DoF) hexapod robot, demonstrating copper-rs on a multi-axis robot that demands low latency in a high frequency message environment. I aim to provide empirical evidence justifying claims about determinism, observability, and runtime latency that make copper-rs uniquely suitable for real-time applications.

Real-time Considerations in Robotics

Operating System

For real-time applications, the fairness of scheduling principles in default Linux (CFS and Round-Robin) are unsuitable and liable to priority inversions. Furthermore, locking primitives such as spinlock_t disable preemption, driving sentiment towards two soft real-time platforms: Linux with a PREEMPT_RT patch and QNX.

Studies target QNX for multi-axis robotic systems which demand high bandwidth capability to drive numerous joints, though lack the empirical evidence necessary for widespread adoption. Conversely, the PREEMPT_RT patch in Linux uses forced-threaded interrupts, sleep spinlocks and real-time mutexes to construct a preemptive event-driven system kernel.This uncertainty in the current best solution leaves a lot to be desired.

copper-rs does not claim to be a replacement for Linux or RTOS. It exists within its own category, supporting both baremetal and GPOS targets. Accordingly, we consider copper-rs capacity to bypass OS constraints.

Middleware Frameworks

The supporting middleware may introduce latent behaviour. ROS 2 has maintained its position as the primary framework for robotic applications, offering modularity and distributed execution in a way that doesn't compromise on convenience.

Complex behaviour in ROS 2 can be described by a network of topics and nodes that emphasise flexibility and loose, composable design. As a result, the default model for inter-process communication using the Data Distribution Service (DDS) protocol is unfit for real-time performance, suffering from copying overheads, data serialisation, and asynchronicity which significantly reduce throughput.

Demand for time-critical solutions that guarantee performance and reliability have surged and copper-rs has emerged to bridge the real-time gap.

copper-rs: A Case Study into Rust-first Robotics

Where ROS 2 Struggles

In ROS 2, communication is facilitated by a Data Distribution Service (DDS) layer. Nodes are mapped to processes in the underlying OS and execute behaviour through callbacks on a single/multi-threaded executor. In asynchronous mode, the execution of the callback is freed by delegating the sending process to the DDS. This is the first fundamental flaw in the ROS 2 framework: callbacks are executed without strict time or sequence ordering. OS scheduling, thread preemption and system load all affect callback execution in a way that breaks determinism.

Figure 1 Illustration of ROS 2 system. Source: https://doi.org/10.1109/RTSS59052.2023.00026

The second fundamental issue in ROS 2 is inter-process data transport. In the DDS layer, DataWriters and DataReaders are registered for callbacks to publish and receive messages from a topic. Messages must be serialised (expensive) and transported via the underlying transportation protocol, by default set to UDPv4. Every step introduces runtime latency and despite community effort for enhancements like EtherCAT (the underlying network protocol) and Agnocast (zero-copy communication), latency and jitter remains an issue in DDS.

Figure 2 Interprocess communication over TCP/UDP. Source: https://doi.org/10.23919/ICCAS66577.2025.11301358

copper-rs

Beyond ROS 2, competing frameworks have redefined the robotics execution layer seeking proven real-time performance. The 3rd of July 2026 marked the first stable release of copper-rs: a Rust-first robotics runtime that is designed with determinism as a first principle.

The copper-rs runtime is categorically different to ROS 2, more closely resembling a time-triggered operating system than a middleware framework. In a typical workflow, tasks (nodes), payloads (messages), and bridges to middleware are statically described in a configuration file (copperconfig.ron) and checked at compile-time.

Based on user-defined configuration, copper-rs generates a task graph and custom deterministic scheduler to execute tasks in a pre-computed order. Two lists are generated which form the order of execution: CopperList and CuTasks.

Figure 3 copper-rs task lifecycle. Source: https://github.com/copper-project/copper-rs/wiki/Task-Lifecycle

You can read the rust docs about how copper-rs provides deterministic replay by serialising the internal state of tasks (freeze) here.

Figure 3 illustrates the task lifecycle and usage of the scheduler. All tasks in CuTasks are executed synchronously and communicate over shared buffers to reduce runtime latency. In the best effort section, high throughput jobs are executed to minimise the interference with the critical path. This is essential for visual perception, motion planning, and control to run at low-latency in the time-critical section. copper-rs' low latency and time-triggered scheduling principles make it ideal for real-time, multi-axis robotics systems. Consider the table below which provides an overview of optimisations to latency and jitter.

Modularity and Observability

Complex behaviour in robotics often relies on sensors, cameras, and safety monitors on the critical path. In high data frequency environments we observe the declining performance of ROS 2. Developers choose to generalise behaviour and reduce log capture points to achieve lower-latency in production at the cost of modularity and observability. The same scenario is significantly less likely in copper-rs because it is significantly less latent by design, and has 12x higher logging throughput than ROS 2.

Thread Pools and Real-time Scheduling

copper-rs exposes parallel-rt and rt-scheduling for std targets, offering multi-threaded execution and real-time scheduling without sacrificing deterministic behaviour. Each thread pool's processor affinity, scheduling policy and on_error behaviour can be configured.

Available scheduling policies are:

• Fair - Fair time-sharing (SCHED_OTHER / CFS)
• Nice - Fair scheduler with a niceness bias
• Fifo - SCHED_FIFO hard real-time
• RoundRobin - SCHED_RR, same as Fifo except threads at the same priority are time-sliced in turn

You can read more about parallel-rt and rt-scheduling in the copper-rs documentation.

copper-rs on a Hexapod Robot

This section presents the findings of a 4 week case-study using copper-rs to drive an open-loop, 18DoF hexapod robot. Time constraints meant compromises were made to some of copper-rs core design principles. I provide an overview of copper-rs performance on multi-axis robotic systems based on anecdotal experience, evaluating the runtime quantitatively in a high message frequency environment.

Specification

• Servo2040 (RP2040)
• Raspberry Pi 5 8GB
• Zeee 2S Lipo Battery 5200mAh 7.4V 80C
• 18 TD-8130MG 30 KG Digital Servos
• Leg model by Emre Kalem

Figure 4 Hexapod robot model

How It Works

1. On initialisation, a source task (clock.rs) triggers the main loop at the target frequency and serialises (freeze) the current timeframe for resim.

2. The payload emitted by the source task is read from the buffer by the Gait task (gait.rs), which stores the description of the hexapod robot (Spyder) defined by the custom motion planner (spyder_ik).

3. gait.rs calls the motion planner to produce joint angles in radians based on the current command and emits the ServoFrame payload.

4. Finally, the ServoMapper task maps the joint angles to pulse widths, encodes to bytes and emits a PWMFrame payload that can be sent over the serial to a Servo2040 (rp2040) board.

Figure 5 Hexapod runtime performance metrics

Figure 5 shows performance metrics pulled live from the consolemon console monitor. This run represents the baseline without optimisation. Observe that the maximum latency for end-to-end is 730.364μs and the end-to-end jitter is 362.720μs. Furthermore, some tasks have achieved sub-microsecond latency. Average payload size is 144 bytes ([f64; 18]) at 30Hz. Note that the results have no direct comparison and are otherwise inconclusive.

Copper-rs' capacity for real-time performance is worth further investigation. The framework is 'metamorphic' by design: for any given task graph copper-rs will generate a deterministic scheduler that unblocks time-critical tasks along the hot path.

Combine scheduling with direct improvements to latency and it becomes abundantly clear why copper-rs should be considered alongside competing middleware. To raise areas for investigation:

• Directly improve performance of RP2040 by rewriting Micropython firmware in Rust
• Reduce data size by using smaller data types than f64

In terms of real-time performance, the following are applicable given the project does not move to a baremetal approach:

• Use copper-rs parallel-rt to isolate latency-critical work onto dedicated cores with real-time priority
• Define scheduling policies for thread pools with rt-scheduling

Logging

Figure 6 copper-rs DAG for hexapod robot

copper-rs offers various tooling that effectively demystifies the DAG concept. Run (just dag) to visualise data transportation as a series of tasks, bridges, and payloads.

Figure 7 Debug logs generated for serial bridge

Figure 8 Raw data sources in Foxglove using copper-rs MCAP export

Figure 9 No colcon build or launch files: execute with cargo run.

Serial Bridge and Zenoh Controller

copper-rs supports a plethora of middleware through the Bridges API. A bridge lets copper-rs talk to an external transport (serial, CAN, DDS, etc.) and facilitates communication with Zenoh, iceoryx, ROS 2 and more. Users should consider the effect on latency and determinism when using bridges, especially for real-time applications. A Zenoh bridge is used for teleoperation, broadcasting the command that dictates movement direction to the Gait task.

Using the same bridge API, I define a serial bridge in (bridges.rs) responsible for reading and writing from the RP2040 resource.

Rust-centric Workflow

Copper-rs feels purposefully ergonomic: having compile-time checks makes iterative development easier and eliminates some of the gripes I had debugging ROS 2. Additionally, copper-rs utilises the speed of Rust to offer significant reductions to latency over other robotics frameworks.

That being said, the adoption of Rust in the robotics ecosystem will be a long and arduous process. Comparatively, robotics has far fewer software engineers than any typical technological discipline. Familiarity with Python and C++ is widespread, so despite its drawbacks, ROS 2 wins in adoptability. The rigidity of copper-rs design principles mean it feels great in the final stages, but might take significant investment throughout the development cycle.

Hexapod Motion Planner

This project uses a custom, geometry-based motion planner that exposes a gait generator for hexapod robots with the following core features:

1. Home position, link lengths, angle resolution and fields that mathematically describe the robot are specified in the SpyderBuilder.
2. The user calls build to construct a Spyder, exposing standing position, LUT generation and export functionality.
3. Inverse kinematics, change of basis and LUT generation are handled for the end-user to simplify usage.

In the future, I plan to port from LUT generation to a live IK model and integrate sensor data. If you want to contribute, I would appreciate it!

Going forward, I hope to create a hexapod runtime that works straight out of the box, for aspiring roboticists who are uninterested in the complexities of robotics frameworks. copper-rs' Rust oriented approach is surprisingly well suited — simply define the hexapod parameters in copperconfig.ron and run it with cargo run. Logging naturally follows, and with more time I would like to have simulation (Bevy) integrated into the project.

Figure 10 Rviz simulation of hexapod robot

Plans for Future Development

• Go baremetal with copper-rs

If the entire copper-rs runtime can be run on a RP2350 why use the Pi 5? This is an open-loop hexapod robot that has no object awareness or visual perception so compute is no issue. This could significantly reduce runtime latency and jitter: no serialisation overhead for USB CDC and full control over resources and scheduling.

• Go 100% Rust with Zenoh controller (telemetry) and RP2040 firmware

The RP2040 firmware and controller could be written in Rust to remove Python dependency in this project. Micropython suffers from high memory usage and poor real-time performance which throttles the performance of the system.

• Add a determinism regression test

Inclusion that guarantees the binary produced on resimulation is bit-for-bit identical which is a great addition to CI.

Conclusion

In this article, I present a case study on an open-loop, 18 degrees of freedom (DoF) hexapod robot, demonstrating copper-rs on a multi-axis robot that demands low latency in a high frequency message environment. I discuss claims about determinism, observability, and runtime latency, providing an initial framework for quantitative analysis of copper-rs.

Additionally, this article addresses key architectural limitations in the default ROS 2 framework, in particular:

• The cost of the Data Distribution Service (DDS)
• Asynchronous communication and the effect of callbacks on execution order
• The impact of the underlying OS

I make direct comparisons between ROS 2 and copper-rs, evaluating each in the context of real-time robotic systems. The results of the case study exceeded expectations, achieving a baseline maximum end-to-end latency of 730.364μs on native Linux. Furthermore, subsequent improvements to application code continue to reduce the maximum latency and jitter. I provide a comprehensive overview of scheduling, memory-allocation, and key design principles which contribute to the remarkable performance of copper-rs.

The source code is available on CodethinkLabs: feel free to contribute!

Source code: https://gitlab.com/CodethinkLabs/spyder_robot

References

A. N. Nagiwale, P. K. Uttam and S. E. Talole, "A Real-Time Software Framework for Multi-axis Robotic Systems Using ROS 2 and EtherCAT," 2024 IEEE Pune Section International Conference (PuneCon), Pune, India, 2024, https://doi.org/10.1109/PuneCon63413.2024.10895565

AutomationDirect.com. “What Is EtherCAT? From AutomationDirect.” YouTube, February 16, 2024. https://www.youtube.com/watch?v=rt-ykjEL4Y8

J. -H. Kim, J. -H. Choi, Y. -C. An and T. -Y. Kuc, "Evaluation of RTOS for Robotic Applications with ROS2 on Embedded Systems," 2025 25th International Conference on Control, Automation and Systems (ICCAS), Incheon, Korea, Republic of, 2025. https://doi.org/10.23919/ICCAS66577.2025.11301358

ROS2 Real-time Performance Optimization and Evaluation. https://link.springer.com/article/10.1186/s10033-023-00976-5

Ye, Y., Nie, Z., Liu, X. et al. ROS2 Real-time Performance Optimization and Evaluation. Chin. J. Mech. Eng. 36, 144 (2023). https://doi.org/10.1186/s10033-023-00976-5

D. Casini, J. Chen, J. Li, F. Reghenzani, H. Teper. "A Survey of Real-Time Support Analysis and Advancements in ROS 2". arXiv:2601.10722. https://doi.org/10.48550/arXiv.2601.10722

X. Luo, X. Jiang, N. Guan, H. Liang, S. Liu and W. Yi, "Modeling and Analysis of Inter-Process Communication Delay in ROS 2," 2023 IEEE Real-Time Systems Symposium (RTSS), Taipei, Taiwan, 2023, https://doi.org/10.1109/RTSS59052.2023.00026

Zhang Z, He W, Wu F, Quesada L and Xiang L (2024) Development of a bionic hexapod robot with adaptive gait and clearance for enhanced agricultural field scouting. Front. Robot. https://doi.org/10.3389/frobt.2024.1426269

copper-rs. “Copper Tasks Lifecycle Overview.” Copper Tasks lifecycle overview - Copper Wiki. https://copper-project.github.io/copper-rs/Task-Lifecycle/

copper-rs. "Copper Robotics" Copper Robotics website. https://www.copper-robotics.com/

ROS 2. "ROS 2 Platform Support". https://www.ros.org/reps/rep-2000.html

“Bridging Robotics and Systems Programming: Why Copper-Rs Is a Game Changer.” 2026. Guillaume BINET 2026. https://fosdem.org/2026/schedule/event/SK8EGJ-copper-rust-robotics-runtime/

Copper Robotics. "What are we solving for with copper-rs?" Youtube, March 9, 2026. https://youtu.be/IuduPa_nyks?si=I7dVYDD7wVOc4FqY

Tokyo Rust. "Copper: The OS for Physical AI" Youtube, July 15, 2026. https://youtu.be/XxaSLWtGHxM?si=sttKzCPy9MlbVc6J

ROS 2 Agnocast: Supporting Unsized Message Types for True Zero-Copy Publish/Subscribe IPC. https://arxiv.org/pdf/2506.16882v1