Question
Gazebo Physics Engine Concurrency Limits with ROS Service Requests
Ira Lane
0 reputation · 23 Jan 2024, 01:23 UTC
58.5K views1
Loading…
0 reputation · 23 Jan 2024, 01:23 UTC
Gazebo's physics engine processes simulation steps on a single thread, which serializes incoming ROS service requests such as /set_model_state or /apply_body_wrench. When multiple clients issue concurrent requests, the server queues them, and the observed latency grows proportionally to the request rate. The goal is to characterize the maximum sustainable request throughput before step timing degrades beyond a deterministic threshold.
Gazebo Garden (2024) introduced a multi-threaded plugin API, yet the core physics stepping loop remains single-threaded for determinism. This creates a boundary where plugin callbacks may execute in parallel, but state mutations that affect the physics step are still serialized. The interaction between ROS 1 and ROS 2 transport layers further complicates queuing behavior, as each middleware implements its own callback threading model.
/set_model_state before the physics step deadline is missed in Gazebo Garden?35275 reputation · 23 Jan 2024, 06:03 UTC
Gazebo Garden does not publish a universal maximum request rate for /set_model_state or /apply_body_wrench. The physics engine's stepping loop remains single-threaded to preserve determinism, so the sustainable throughput is bounded by how many state mutations the next physics step can absorb before it overruns its deadline. The ROS 1 or ROS 2 transport layer only changes how requests queue before they reach the plugin; it does not remove the serialization at the physics boundary.
Confirmed: state-altering service calls are serialized into the main physics thread. The multi-threaded plugin API introduced in Garden permits parallel execution of non-mutating logic, but it does not allow concurrent mutation of physics state.
Likely: the ceiling is hardware- and model-dependent. Increasing middleware callback queue sizes may mask latency but will not raise true throughput, and an oversized queue can produce stale state updates applied several frames late.
ros
gazebo/set_model_state and log RTF, step time, and service round-trip latency.There is no Gazebo physics-specific parameter that sets a service queue depth or timeout for /set_model_state. Queue depth and timeout are governed by the ROS middleware (e.g., the service server's queue size and client timeout) and by how the Gazebo plugin processes incoming messages. Tuning those values changes buffering behavior, not the physics engine's ability to apply changes.
Is the degradation you observe rising service latency while RTF stays near 1.0, or RTF falling below 1.0? If latency grows but RTF holds, the middleware queue is absorbing the backlog; if RTF drops, the physics step itself is overrunning and the request rate must be reduced or the per-step work simplified.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 23 Jan 2024, 02:07 UTC
A useful operational signal is the physics step overrun warning that Gazebo emits when a step exceeds its allotted time. In Garden the core physics loop remains single-threaded for determinism, so any mutation from a ROS service such as /set_model_state or /apply_body_wrench is marshaled onto that thread. The multi-threaded plugin API can run validation or read-only work in parallel, but commits that affect the step are still serialized back to the main thread.
Queue depth is not a Gazebo physics parameter. For ROS 2 the service server queue size is set via ServiceOptions::queue_size on the server side, with a common default of 10. Raising it changes back-pressure and latency masking, not the physics step capacity. The step deadline itself is configurable in the engine settings, so any sustainable request rate is scene- and hardware-dependent and best characterized by monitoring RTF, step time, and the step overrun warning rather than a fixed documented limit.