Skip to main content

FAQs

Does rmw_robotops modify my DDS messages or add latency?​

No, it does not modify messages. rmw_robotops is purely observational — it adds trace context metadata to DDS fields but does not touch message payloads, QoS settings, or the DDS wire format.

Latency: The tracing layer always sends the real message first and emits trace events afterwards. Target overhead is < 1µs median per message. Formal benchmarks are in progress — see rmw_robotops issue #41.

Can rmw_robotops crash my robot?​

No. All tracing code runs inside catch(...) blocks — exceptions are caught and swallowed, never propagated to the underlying DDS or to robot node code. If consecutive tracing failures exceed the threshold (default 100), the circuit breaker auto-disables tracing and logs a warning. The robot continues operating normally.

How do I disable tracing at runtime without restarting?​

Set ROBOTOPS_TRACING_ENABLED=false in the environment. This reduces tracing overhead to a single boolean check per message — no queue, no background thread, pure passthrough. You can also set it in the YAML config under tracing.enabled: false.

Which DDS implementations does rmw_robotops support?​

All of them. rmw_robotops is DDS-agnostic — it delegates to whatever you specify via ROBOTOPS_UNDERLYING_RMW. Common values: rmw_fastrtps_cpp, rmw_cyclonedds_cpp, rmw_connextdds.

How do I migrate a fleet of robots to rmw_robotops?​

Rolling migration is safe: robots running rmw_robotops and robots running the vanilla RMW can coexist in the same fleet. Trace context is propagated through DDS metadata — nodes without rmw_robotops simply don't carry or emit trace context, but they don't break anything for nodes that do.

Steps:

  1. Install robot-agent and rmw_robotops on one robot
  2. Set RMW_IMPLEMENTATION=rmw_robotops and ROBOTOPS_UNDERLYING_RMW=<your-current-rmw> in the systemd override
  3. Restart your robot's nodes
  4. Verify traces appear in the Robot Ops dashboard
  5. Roll out to the rest of the fleet

What's the overhead on robot hardware?​

Performance targets for rmw_robotops:

MetricTarget
Added latency (median)< 1µs per message
CPU overhead< 5% vs. underlying RMW
Hot-path allocationsZero

Formal benchmarks are in progress — see rmw_robotops issue #41. The robot-agent itself uses a 500 MB FIFO buffer and TF deduplication to keep its footprint low.

Where is my data stored?​

Telemetry is streamed to the Robot Ops backend (api.robotops.com) over gRPC and is queryable via ROSQL backends including Parquet, ClickHouse, and TimescaleDB. While offline, data is buffered locally in MCAP files under /var/tmp/robot_agent/buffer.

How do I get an API key?​

Sign up at robotops.com and navigate to Settings → API Tokens in the dashboard. Keys are prefixed with sk_.

Are the packages versioned in lockstep?​

Yes. robot_agent, rmw_robotops, robotops_msgs, and robotops_config share major version numbers — a major bump means a breaking change somewhere in the ecosystem and all components update together. Minor and patch versions evolve independently within a major version, maintaining backward compatibility.

How do I get help?​