Real-Time Computer vs. Robot Controller: Boundaries and Test Method

Engineers reviewing a mobile manipulator with installed robot-side edge AI hardware in a robotics lab.
Short answer: low average latency is not proof of real-time behavior, and real-time-capable hardware is not automatically a robot controller. Define the deadline, cycle time, allowed jitter, percentile and worst-case limits, test load, and owner of each control function. Then measure the complete sensor-to-command path under the installed workload.

Real-time, low latency, and deterministic are different claims

Term Useful engineering meaning Evidence needed
Low latency A task completes quickly in the tested condition. End-to-end distribution, not a single average.
Real-time A task must complete within a defined deadline for the intended system behavior. Deadline, miss policy, test duration, load, and observed misses.
Deterministic Timing variation is bounded enough for the specified function. Cycle and jitter distribution including tail values and worst observed case.
Real-time-capable The platform provides hardware/software features that can support time-sensitive work. Application-level validation using the delivered configuration.

A mean of 2 ms can hide occasional 40 ms events. If the function has a 10 ms deadline, the mean looks good while the tail fails. Report at least the median, P95, P99, P99.9, maximum observed value, sample count, test duration, and missed-deadline count. A maximum observed value is evidence from that test, not a universal upper bound.

Map the responsibility boundary before measuring

System element Possible responsibilities Keep explicit
Robot-side AI computer Sensor acquisition, preprocessing, inference, localization, planning support, logging, communication It does not become a safety or motion controller because it has CAN FD or EtherCAT.
Robot controller or PLC Robot-specific state machines, motion requests, sequencing, drive coordination Define accepted commands, acknowledgements, timeouts, and fallback behavior.
Drive or actuator controller Low-level current, torque, speed, or position loops Document cycle ownership and behavior when upstream messages stop.
Safety system Functions assigned by the approved safety architecture Do not transfer these responsibilities through marketing language.

Define the timing budget from end to end

Measure the path the application depends on. A perception-to-controller example can include sensor exposure, capture, transfer, preprocessing, inference, postprocessing, message serialization, network or bus transfer, controller receipt, and acknowledgement. Timestamping only the inference call leaves most of the path unmeasured.

Stage Record Typical source of variation
Sensor acquisition Source timestamp, arrival timestamp, dropped or late frames Exposure, synchronization, driver buffering
Application pipeline Queue time and execution time for each stage CPU/GPU contention, memory pressure, batching
Communication Send, receive, acknowledgement, sequence number Network load, bus cycle, serialization, retries
Controller response Receipt and accepted/rejected state Controller cycle, state machine, timeout policy

A repeatable EtherCAT, CAN FD, or ROS 2 test plan

  1. Freeze the build. Record computer model, module memory, power mode, storage, kernel, JetPack, ROS 2 distribution and middleware, application commit, interface settings, sensors, and cables.
  2. Define the threshold. State the required cycle, maximum allowed jitter or end-to-end deadline, sample count, test duration, warm-up, and failure rule.
  3. Create a background load. Run the intended camera, inference, logging, networking, and storage tasks concurrently. An idle-system result is only an idle-system result.
  4. Use synchronized timestamps. Document clock source and timestamp location. If two devices use different clocks, record how offset and drift are handled.
  5. Run steady-state and exception cases. Include startup, thermal steady state, heavy I/O, application restart, and approved communication interruption scenarios.
  6. Export raw observations. Preserve the time series or histogram bins, deadline misses, system logs, temperature, frequency/throttling state, and configuration manifest.
Minimal acceptance record: test ID; date; hardware serial/configuration; software versions; power mode; connected devices; workload; timing definition; clock method; duration; sample count; P50/P95/P99/P99.9; maximum observed; deadline misses; temperature and throttling; errors; pass/fail decision; reviewer.

How to read platform claims correctly

The MScape 2026.7.V2 brochure lists EtherCAT master support, Linux RT, and Xenomai for relevant N Series configurations. These features make an application test possible; they do not establish the timing of a customer’s full robot. Confirm the delivered software image, EtherCAT master configuration and licensing, slave topology, update cycle, network layout, and concurrent AI workload.

For camera-rich AGX Orin systems, compare N203 and N210 against the physical interface plan. Use the robotics interface validation guide for connector and protocol checks. Neither product choice removes the need to measure the installed application.

Common test mistakes

Reporting only average latency

Add tail percentiles, maximum observed value, missed deadlines, duration, and sample count. Otherwise the reader cannot judge rare delays.

Testing the bus without the AI workload

Run the production-like camera, inference, recording, and network load at the same time. Resource contention can change the result.

Using interface support as a controller claim

A supported bus describes a communication capability. System responsibility comes from the architecture, software, validation, and safety design.

Publishing a number without the configuration

A timing result cannot be reproduced when the kernel, power mode, middleware, devices, load, and timestamp method are missing.

FAQ

Does Xenomai guarantee my control-cycle target?

No. It is part of a real-time-capable software path. The delivered configuration and complete application must be tested against a defined target.

Should AI inference sit inside a safety loop?

Assign safety functions through the machine’s approved safety architecture. Do not infer a safety role from AI performance or interface support.

What data should I send with an EtherCAT inquiry?

Send the slave list, topology, distributed-clock requirements, desired cycle, allowed jitter, payload, concurrent sensor and AI workloads, software baseline, and failure behavior.

Request a configuration-specific timing review.
Share the bus topology, cycle target, full workload, software versions, power and thermal constraints, and control boundary through the MScape inquiry page.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top