FEO: Recording & Replay

[johannes-esr]

[dejanpan]

@johannes-esr I hope that you do not mind me kidnapping this issue. We from Apex.AI would like to propose the following way to implement this feature. We are also adding a way to visualize the recorded and replayed data. I can create a new issue if you do not want me to pollute this issue.

---

Abstract

Integrate ROS 2‑compatible observability tooling—the rosbag2 data recorder/replayer together with RViz 2, RQt, and PlotJuggler—into Eclipse S‑CORE. This enables deterministic record‑and‑replay debugging as well as rich runtime visualisation for Software‑, Hardware‑, and Vehicle‑in‑the‑Loop (SIL/HIL/VIL) workflows, accelerating fault‑diagnosis and test‑case reuse across the development life‑cycle.

Motivation

S‑CORE currently lacks a unified mechanism to capture, replay and visualise runtime data (to the best of our knowledge). The ROS 2 ecosystem already provides mature, permissively‑licensed tools that solve these pain‑points. Adopting them will give S‑CORE:

• Deterministic reproduction of failures (via ros2 bag play).
• Consistent introspection GUIs for node graphs, logs and sensor data (via RViz 2 & RQt).
• Interactive signal analysis of large time‑series logs (via PlotJuggler).

These capabilities map directly onto the SIL → HIL → VIL test chain used by S‑CORE adopters and align with the project’s code‑centric, iterative philosophy.

Rationale

• De‑facto standard – ROS 2 tools are battle‑tested in robotics and AV projects.
• Low integration cost – tools are standalone binaries/Qt apps distributable via existing Bazel rules or container images.
• Inter‑project synergy – many potential contributors already know ROS 2 tooling, lowering the entry barrier to S‑CORE.
• Avoids NIH – leverages community maintenance instead of building bespoke GUIs.

Specification

1. Enable cooperation via standardized APIs
2. File‑based configuration
3. Data persistency
4. Communication
5. IDL support
6. Reprocessing and simulation support
7. Logging support

Backwards Compatibility

The proposal is additive. Existing modules that do not publish via ROS 2/DDS remain unaffected. Where a bridge is required, it will be optional. No public APIs are removed.

Security Impact

Bag files may capture sensitive or safety‑critical data. Guidance will be added on encryption at rest, access control, and sanitising logs before sharing. The tools themselves run in user‑space and do not escalate privileges.

Safety Impact

Recording and replaying data does not alter runtime behaviour when not active. Mis‑use (e.g. replaying in a live vehicle) can be mitigated by requiring the feature flag and by gating playback to non‑production builds. ASIL classification: QM (quality‑managed) as the tooling is diagnostic only.

License Impact

All proposed tools are under Apache‑2.0 (rosbag2, RViz 2, RQt) or GPL‑v3/LGPL‑v3 with explicit runtime exceptions (PlotJuggler). Redistribution is therefore compatible with the EPL‑2.0 license used by S‑CORE, provided PlotJuggler remains a separate executable.

How to Teach This

• Quick‑start guide in the score‑dev docs showing: bazel run //examples:demo_sim --record, then ros2 bag play demo.db3 and visualise with RViz 2.
• Video walkthrough (2 min) embedded in docs.
• Continuous‑integration notebooks generating example bag‑files for newcomers to experiment with.

Details

Established Capabilities

1. rosbag2 – the standard ROS 2 recording/playback tool – can capture any number of topics into a database and later replay them to reproduce test results. This is invaluable for regression testing and bug reproduction, eliminating the need to re-run physical tests every time.
2. RViz 2 – a 3D visualization GUI – allows viewing of robot/vehicle state, sensor data (camera images, point clouds, etc.), and environment information in real-time. Its plugin architecture supports many message types and topics, giving a comprehensive view of the system’s perception and actions.
3. RQt – a Qt-based GUI framework – hosts numerous plugins for introspection (e.g. node graphs, topic publishers/subscribers, logging consoles, parameter tuning, etc.) within one unified interface. This provides a one-stop dashboard for monitoring S-CORE at runtime, far more convenient than scattered command-line tools.
4. PlotJuggler – a powerful time-series data visualizer – is well-integrated with ROS; it can subscribe to live ROS 2 topics or open recorded rosbags to plot and analyze numeric data streams. It enables advanced analysis like filtering, merging, and applying mathematical transforms to signals, which is critical for tuning algorithms and investigating anomalies (e.g. latency spikes, oscillations).

Leverage Community and Familiarity:

By using off-the-shelf ROS 2 tools, S-CORE benefits from ongoing community development and support. Many automotive and robotics developers are already familiar with these utilities, reducing training effort. This also aligns S-CORE with industry-standard workflows, making it easier for new users (especially those coming from a ROS 2 background) to adopt the platform.

Avoid Reinventing the Wheel:

An alternative approach would be developing custom observability solutions or relying on proprietary tools (e.g. traditional automotive tools like CANoe/CANape for logging and analysis). However, building new tools would require significant effort and duplicate functionality that already exists in ROS 2. Proprietary tools, while powerful, often come with licensing costs and integration overhead. In contrast, ROS 2 tools are free, open-source, and integrate natively via the ROS 2 API. This proposal thus chooses the more efficient path of integrating existing tools rather than inventing new ones for S-CORE.

Isolation and Additivity:

Importantly, integrating these tools does not interfere with the core real-time or safety-critical operation of S-CORE. They can be run on separate hardware or in non-critical contexts. For instance, it’s recommended to run RViz 2 on a developer workstation rather than on an in-vehicle embedded computer for performance reasons. Because the integration is additive, existing S-CORE deployments can choose not to include these tools (via the feature flag) if resource constraints or safety certifications prohibit extra software. This modular approach provides flexibility: use the tools in development and testing phases, but omit them in production releases of a vehicle if necessary.

[armin-acn]

Target is v1.0 but work on architecture can start asap.