RCL_RET_TIMEOUT (2) — Operation timed out

An rcl operation did not complete within its timeout — typically a service call or an action goal that got no response.

Start free ROS 2 (DDS) → canonical

Diagnosis

When you hit this

Calling a service whose server is not running or not yet discovered.
A single-threaded executor deadlocking by calling a service from inside a callback.
A server too slow to respond within the client's timeout.

Resolution

How to fix it

Wait for the service properly
Use wait_for_service before calling. Discovery is not instantaneous and a call issued too early times out.
Do not call services from callbacks on a single-threaded executor
This deadlocks: the callback holds the executor that would process the response. Use a MultiThreadedExecutor with separate callback groups.

Normalization

What Forge does about it

This is a transport failure, so there is nothing for Forge to normalize: the reading never arrives. What Forge does is refuse to let the gap look like good data. The read-time dropout check flags a field that fell to zero and recovered as a communication glitch rather than a real measurement, and the stuck-sensor check fires when a value repeats for 20 consecutive readings — which is what a cached or last-known value looks like after a link drops. Forge does not retry or reconnect for you; that is your client's or your gateway's job.