R
Member
ROS2 里服务调用超时是最让人恼火的一类问题：客户端没报错、服务端看着也在跑，就是等不到响应。按这个清单从上往下查，通常能定位到。
第一，先看 executor：单线程 executor 里一个回调卡住，后面的服务回调全被堵住，表现为偶发超时，改成多线程 executor 或把耗时回调拆到单独的回调组，往往就好了。第二，看 QoS：服务默认是可靠传输，但如果客户端和服务端的 QoS 配置被改过（比如一方改成了 best effort），握手失败时调用会直接超时而不报错，先对齐两边的 QoS 再谈别的。第三，看服务端的处理时长：服务回调里做了耗时操作（比如等另一个服务或查数据库），客户端默认超时时间一到就断，这时要区分是服务端真慢还是客户端等得太短，日志里把请求到达时间和响应时间都打出来。第四，看网络与 DDS：多机通信时域 ID 不一致、组播被交换机禁掉，都会表现为服务时通时不通，用 ros2 node list 和 topic list 先确认双方在同一个域里看得见彼此。
还有一个经验：超时只在启动初期出现时，先查节点启动顺序，客户端在服务端还没 ready 时就发请求，第一次超时后重试反而能通，这类问题靠 wait_for_service 解决而不是调大超时。
你们的 ROS2 服务超时最后定位到的根因最多的是哪一类？executor 阻塞、QoS 还是 DDS 网络？
第一，先看 executor：单线程 executor 里一个回调卡住，后面的服务回调全被堵住，表现为偶发超时，改成多线程 executor 或把耗时回调拆到单独的回调组，往往就好了。第二，看 QoS：服务默认是可靠传输，但如果客户端和服务端的 QoS 配置被改过（比如一方改成了 best effort），握手失败时调用会直接超时而不报错，先对齐两边的 QoS 再谈别的。第三，看服务端的处理时长：服务回调里做了耗时操作（比如等另一个服务或查数据库），客户端默认超时时间一到就断，这时要区分是服务端真慢还是客户端等得太短，日志里把请求到达时间和响应时间都打出来。第四，看网络与 DDS：多机通信时域 ID 不一致、组播被交换机禁掉，都会表现为服务时通时不通，用 ros2 node list 和 topic list 先确认双方在同一个域里看得见彼此。
还有一个经验：超时只在启动初期出现时，先查节点启动顺序，客户端在服务端还没 ready 时就发请求，第一次超时后重试反而能通，这类问题靠 wait_for_service 解决而不是调大超时。
你们的 ROS2 服务超时最后定位到的根因最多的是哪一类？executor 阻塞、QoS 还是 DDS 网络？