What does “real-time” actually mean in robotics?

Real-time means that actions happen within guaranteed time bounds, not just fast on average. Missing a deadline can be more critical than slow performance, especially for control, safety, and motion.

How does ROS 2 differ from ROS 1 in terms of real-time capabilities?

ROS 2 was designed with real-time support in mind, including DDS-based communication, configurable QoS profiles, and improved control over execution (executors/callback scheduling). ROS 1 lacks comparable QoS and executor mechanisms, making deterministic, low-jitter behavior significantly harder to achieve and less predictable in practice.

How can I ensure ROS 2 nodes meet latency requirements?

Latency control requires explicit executor selection, careful callback grouping, and correctly configured QoS profiles. Real-time capable operating systems and CPU isolation further improve predictability.

Which tools are available to measure latency, jitter and timing behaviour?

Tracing tools, middleware statistics, and OS-level profiling utilities are commonly used to measure real-time behaviour. Continuous measurement under realistic load is essential to identify timing violations.

How do I integrate existing interfaces such as CAN into real-time systems?

Real-time interfaces like CAN are typically handled by RT-MCUs or real-time tasks with priority scheduling. Proper buffering and prioritisation prevent non-critical traffic from affecting deterministic communication.

Do I need a real-time operating system to achieve real-time behaviour?

In most cases, yes. An RTOS or real-time Linux configuration is required to guarantee bounded latency and deterministic scheduling, especially for safety- or motion-critical tasks.

Which parts of a robot must be real-time, and which do not?

Motor control, safety monitoring and low-level sensor handling often require hard real-time behaviour. Perception, planning and user interfaces typically tolerate higher latency and variability.

Is real-time only a hardware problem?

No. Hardware capabilities are necessary but not sufficient. Scheduling policies, middleware configuration, software architecture and workload isolation are equally important.

How do MPU and RT-MCU systems work together in real-time designs?

RT-MCUs handle deterministic control tasks, while MPUs manage complex, non-real-time workloads. Clear interfaces and low-latency communication between them are essential.

Can real-time behaviour be added late in a project?

It is possible but risky. Real-time constraints are much easier to meet when they are considered early in architecture and platform selection.