31.4.1 ROS2开发：服务与Action

可视化演示

对比ROS2 Service同步请求-响应与Action异步目标-反馈-结果通信机制，展示QoS可靠性配置对数据传输的影响。

核心概念定位

餐厅后厨与前厅之间，有些问题急如星火。你按服务铃问“果汁机有空吗？”，服务员抬头就能答——这种“一问一答、立等可取”的沟通，就是 ROS2 中的 Service。而有些任务是马拉松，比如“为一桌二十人准备晚宴”，下单后要备菜、烹饪、上菜，中途还得汇报进度、允许顾客改主意——这种“长期执行、分步反馈、可取消”的协作，就是 ROS2 中的 Action。

技术上看，Service 采用同步请求-应答模型：客户端发出请求后，服务端处理完并返回响应，整个过程短促、双向、有始有终。Action 则在更长的时间尺度上工作，它定义了目标（Goal）、过程反馈（Feedback）和最终结果（Result）三段式消息流，客户端可以在任意时刻取消任务。两者的选择标准很简单：短时、一次性、不需要中间反馈 用 Service；长时、需要进度、可中途取消 用 Action。

所以进店后先想清楚：你只是要“一壶水的答案”，还是要“一整套餐的交付”？选对机制，机器人协作才不会乱套。

接口定义

餐厅刚开业时菜单上只写菜名，顾客点“随便”后厨就懵了。后来菜单有了标准化编号和规格说明。ROS2 也是同样的道理：通信双方必须先约定“消息长什么样”。srv 文件就像菜单上的“编号+价格”——短、平、快；action 文件则像一本菜品说明书——目标、过程、成品全都写清楚。

srv 接口把一次通信分成两段：请求段（request）和响应段（response），中间用 --- 隔开。action 接口则分成三段：goal（目标）、result（最终结果）和 feedback（过程反馈）。看两个实际的接口定义：

规格写清楚，系统才不会出现“我要牛排你却端来沙拉”的乌龙。定义接口文件，就是在为机器人的协作立“菜单规范”。

# 加法器服务：int64 a / int64 b 作为请求，int64 sum 作为响应int64 aint64 b---int64 sum

# 倒计时动作：target 是目标，finished 是最终结果，progress 是过程反馈int64 target---bool finished---float32 progress

服务通信实现

顾客按服务铃，服务员走到桌边听清需求，转身处理，再回来答复。如果顾客不急，可以回座位等水送过来——这时他说“水好了叫我一声”，这就是异步。ROS2 的 Service 通信同样有这两种姿态。

实现上，Service 由服务端（Server）和客户端（Client）组成。服务端用 create_service 创建并注册回调，客户端用 create_client 建立连接。调用的关键区别在于：同步调用会阻塞当前线程直到拿到响应，适合主流程必须先拿到数据再往下走的场景；异步调用立即返回一个 future 凭证，等响应到达后由 executor 触发回调，主线程不阻塞。

使用异步时，客户端可以一边等服务端计算，一边继续发布话题或处理其他回调。但要注意：服务端只有在其节点被 spin 时才会处理请求，因此两端都必须有正在转动的 executor，否则就会“服务员在休息，没人接你的铃”。

聪明的服务员会灵活选择“立等可取”与“稍后通知”。写代码时多想想：这一问，主线程能不能等？

Action机制

点牛排时，顾客不想站在明火旁干等。厨房发一个取餐牌（Goal 已接收），之后每完成一步就广播进度（腌制完成、翻面、装盘），最后上桌（Result）。顾客也可以中途大喊“不要了”（Cancel）。这正是 Action 的完整生命周期。

实现上，Action 通信由 Action Server 与 Action Client 组成。服务端接收 goal、调度执行体、周期性发布 feedback、最终发布 result，并响应取消请求；客户端发送 goal、注册 feedback 回调、接收 result、可随时发起 cancel。底层虽然由多组 Topic 与 Service 组合实现，但对用户暴露的是统一的三段式 API。

与“手动写 Service + 轮询”相比，Action 的价值在于把进度和取消都标准化了：你不需要自己造轮子去维护“任务状态机”，框架替你完成了大部分调度和错误处理。

Action 就是给机器人“点菜”的完整闭环：长期任务永远有进度条，也永远有紧急刹车。

QoS配置

有的菜必须趁热送到，比如滚烫的砂锅汤；有的菜可以慢慢送，比如水果拼盘。餐厅对不同菜品选择不同配送方式。ROS2 通信也一样，用 QoS（Quality of Service，服务质量）策略决定消息“配送”的保障等级。

QoS 是一组策略参数的集合，核心包括：Reliability（可靠性）、History（历史策略）、Depth（队列深度） 和 Durability（持久性）。对 Service 与 Action 这种需要双向确认的通信，RELIABLE（可靠投递）是默认且常见的选择——请求不能丢，丢了要重发。而传感器流常用 BEST_EFFORT（尽力而为），丢几帧无所谓。

配置 QoS 时最关键的一点是兼容性：通信双方的 QoS 参数必须兼容才能建立连接。比如服务端用 RELIABLE，客户端用 BEST_EFFORT，就可能出现握手失败或收不到消息的情况。这就像顾客说“必须闪送”，外卖平台却说“只能平邮”——这单根本接不了。

给 Service 与 Action 配上合适的 QoS，就像在菜单上注明“此菜需趁热食用”——配送方式定对了，沟通才不凉。

回调处理

餐厅忙时，一个服务员要同时处理 A 桌加菜、B 桌结账、C 桌投诉。他必须有个工作节奏：先记下 A 桌需求，转身给 B 桌递账单，再安抚 C 桌。ROS2 的节点也是如此——多个事件同时在催你，需要执行器（Executor）统一调度回调函数。

ROS2 节点处理事件靠回调函数：收到 Service 请求会调用服务回调，收到 Action 反馈会调用反馈回调。SingleThreadedExecutor 单线程挨个执行回调，像只有一位服务员跑堂；MultiThreadedExecutor 用线程池并行处理，像多人分工接待。选哪种取决于回调是否耗时：如果某个回调里有等待硬件 IO 的阻塞操作，单线程执行器会被卡住，其他回调全部排队。

Action 的 feedback 回调触发频率通常很高，必须写得轻量——不要在反馈回调里做重计算或磁盘写入。一句话：回调要短小精悍，就像服务员不会站在一桌旁边聊十分钟。

管理好回调，就是管理好接待节奏。多线程不是万能药——一个不讲武德的阻塞回调照样会让线程池的线程饿死。

工程实践

成熟的餐厅会记账：排班表、进货单、顾客反馈。机器人开发也离不开这些幕后功夫——调试工具、生命周期、性能监控就是 ROS2 的“运营台账”。

开发时最常用的是命令行工具：ros2 service list 查看当前有哪些服务，ros2 service call 手动调用服务测试；ros2 action list 查看 Action，ros2 action send_goal 手动下发目标。这些命令能快速确认“服务员有没有在岗、接不接单”。此外要留意生命周期管理：Lifecycle Node 提供了 unconfigured→inactive→active→finalized 的状态机，适合有启动顺序要求的复杂机器人系统；性能监控则关注消息频率、回调耗时和队列深度，排查“哪一环拖慢了整条链路”。

常见故障排查口诀：服务端没 spin，请求无人理；QoS 不兼容，握手直接断；回调里死等，全节点卡死。理解了整条链路的时延构成，问题定位就不难。

台账越清晰，餐厅越不容易翻车。把这条时延公式刻在脑子里，排查性能问题就有章可循。

AI 应用场景

Python 演示

import timeimport threading  class RoboRestaurant:    """机器人餐厅: 演示 Service 与 Action 两种通信模式"""     def __init__(self):        self._cancel_events = {}        self._serial = 0     # ---- Service: 一问一答 ----    def query_water(self, table):        """按服务铃: 请求一次, 立即返回响应"""        return {"table": table, "status": "water served", "cost_ms": 50}     # ---- Action: 从下单到上桌 ----    def place_order(self, meal, steps=3):        """点大餐: 逐阶段执行, 支持反馈与取消"""        self._serial += 1        goal_id = self._serial        cancel_event = threading.Event()        self._cancel_events[goal_id] = cancel_event         def _cook():            for i in range(1, steps + 1):                if cancel_event.is_set():                    print("[{}] cancelled: {}".format(goal_id, meal))                    return "cancelled"                time.sleep(0.2)                print("[{}] feedback {}/{}: cooking {}".format(                    goal_id, i, steps, meal))            print("[{}] result: {} served".format(goal_id, meal))            del self._cancel_events[goal_id]         threading.Thread(target=_cook, daemon=True).start()        return goal_id     def cancel_order(self, goal_id):        event = self._cancel_events.get(goal_id)        if event:            event.set()            return True        return False  if __name__ == "__main__":    restaurant = RoboRestaurant()    print(restaurant.query_water(3))      # Service 同步秒回    gid = restaurant.place_order("steak", 3)  # Action 长期执行    time.sleep(0.5)    restaurant.cancel_order(gid)          # 中途取消    time.sleep(0.5)

1. def query_water(self, table):Service 处理函数：一次请求立即算出并返回结果，对应服务端回调。
2. return {"table": table, "status": ...}构造响应体，相当于 srv 文件的 response 段。
3. cancel_event = threading.Event()为这次任务配备一个“取消信号旗”，对应 Action 的取消机制。
4. if cancel_event.is_set():执行循环中检查取消标志，收到信号就终止任务。
5. time.sleep(0.2)模拟耗时的烹饪步骤，现实中对应电机转动或路径规划。
6. print("[{}] feedback {}/{}...")每阶段输出进度反馈，对应 action 的 feedback 消息。
7. threading.Thread(target=_cook, daemon=True).start()后台线程执行长任务，主线程不被阻塞。
8. restaurant.cancel_order(gid)客户端发起取消请求，对应 Action 的 cancel goal。

常见误区

面试题