1. 为什么今天还在认真讲 ROS2 的 services——一个被低估却天天在用的核心通信机制刚接触 ROS2 的人十有八九会先被 topic话题吸引发布、订阅、数据流、实时可视化……画面感强上手快。但真正把机器人从“能动”变成“能干活”的往往不是那些哗啦啦刷屏的传感器数据而是几行简洁的 service call。比如你对机械臂说一句“抓取红色方块”它回你一句“已就位等待确认”再执行又比如你让导航系统规划一条路径它算完直接返回一串 waypoints而不是持续广播所有中间状态。这种“发个请求、等个应答、明确成败”的交互模式就是 services 的核心价值。我带过三十多期 ROS2 实战训练营发现一个高度一致的现象学员在写完第一个 publisher/subscriber 后信心爆棚可一旦要实现“用户点击按钮触发抓取”“远程发送指令重启底盘”“根据检测结果动态切换控制模式”这类真实功能时几乎全部卡在 service 的设计与调用逻辑上——不是找不到 service 接口而是不理解什么时候该用 service 而不是 topic不清楚request/response 的结构怎么定义才既安全又易维护更常遇到client 端超时没处理、server 端异常没捕获导致整个动作链静默失败。这根本不是语法问题而是对 ROS2 通信范式的底层认知断层。这篇内容不堆概念不列 API 文档就聚焦一个目标让你在三天内能独立设计、实现、调试并稳定运行一个生产级 service。我会拆解清楚service 和 topic/parameter/action 的本质区别在哪为什么 ROS2 的 service 默认不支持流式响应而你其实可以绕过限制如何用 .srv 文件定义强类型接口避免后期改字段引发的全链路崩溃client 端如何设置合理的超时与重试策略server 端怎样做输入校验和资源隔离防止一个坏请求拖垮整个节点。所有内容都来自我过去三年在 AGV 调度系统、手术机器人主控、工业分拣工作站三个真实项目中的踩坑记录。如果你正卡在“写了 service 但总收不到响应”“client 显示 timeout 但 server 根本没日志”“改了个字段编译通过运行时报类型不匹配”这类问题上这篇就是为你写的。2. Services 不是“增强版 Topic”——通信模型、适用场景与关键边界2.1 三类通信原语的本质差异一张表看懂何时该用哪个ROS2 提供四种核心通信机制topic、service、parameter、action。很多人误以为 service 是“带返回值的 topic”这是最危险的认知偏差。它们底层协议、传输语义、错误处理机制完全不同。下面这张表是我从 DDSData Distribution Service规范和 ROS2 中间件实现源码中提炼出的真实差异维度Topic发布/订阅Service请求/响应Action目标/反馈/结果通信模型多对多、异步、无连接、尽力而为best-effort严格一对一、同步阻塞默认、有连接、保证送达reliable客户端-服务器、长生命周期、支持取消与进度反馈典型延迟毫秒级取决于网络序列化无确定上限通常 100ms本地进程间但可配置超时超时即失败秒级到分钟级如路径规划、机械臂运动数据模式流式、持续、无状态每个消息独立离散、成对request response、有状态一次调用一个原子事务三段式goal目标、feedback过程反馈、result最终结果失败处理丢包无声订阅者无法感知是否漏消息显式超时timeoutclient 可捕获rclpy.executors.ExcutionFailed或rclcpp::exceptions::RCLError支持 goal 取消、preempt、aborted 等状态机client 可监听状态变化适用场景举例IMU 原始数据流、摄像头图像、激光雷达点云、状态心跳开关电机、读取设备固件版本、保存当前地图、校准传感器零点执行一段轨迹运动、执行 SLAM 建图任务、运行一个长时间视觉检测提示很多初学者试图用 topic 模拟 service 行为——比如定义/motor_cmd_req和/motor_cmd_resp两个 topic。这在单机测试时看似可行但一旦部署到多机网络或高负载环境你会立刻遭遇三大问题1无法保证 request 和 response 的配对没有唯一 ID 关联2response 可能比下一个 request 先到达造成逻辑错乱3没有超时机制client 会无限等待。ROS2 的 service 协议层基于 DDS Request-Reply天然解决了这三点。2.2 Services 的硬性边界什么绝对不能做尽管 service 强大但它有明确的设计边界。违反这些边界轻则性能骤降重则系统不可靠。我在某 AGV 调度项目中曾因忽视这点导致整条产线调度延迟飙升至 8 秒以上排查三天才发现根源。禁止传输大体积数据ROS2 service 默认使用 DDS 的RELIABLEQoS但其内部缓冲区有限通常 64KB~1MB取决于 DDS 实现。若你在.srv文件中定义uint8[] image_data并传入一张 1080p 图像约 2MB结果不是慢而是直接触发 DDS 内部断连server 端进程可能被强制 kill。正确做法用 topic 传图像service 只传string image_id或uint64 timestamp由 client 自行去 topic 订阅对应帧。禁止高频调用10Hzservice 是同步阻塞模型。每个 call 都需建立连接、序列化、网络传输、反序列化、执行、返回。实测在 i7-8700K Fast-RTPS 下纯空 servicerequest/response 各 1 字节极限吞吐约 120Hz一旦加入实际计算如坐标变换稳定上限约 25Hz。若你需要每 10ms 发送一次控制指令请毫不犹豫选择 topic —— 这正是/cmd_vel存在的根本原因。禁止嵌套 service 调用server 内再 call 其他 service这极易引发死锁。例如 A 节点的 service_server 在处理请求时同步调用 B 节点的 service而 B 节点恰好也在处理另一个请求并同步调用 A。两个线程互相等待对方释放服务句柄系统挂起。解决方案只有两个1将嵌套逻辑重构为 topic state machine2使用 action 替代因其设计上就支持异步协调。2.3 为什么 ROS2 不支持 streaming service以及我们怎么绕过它ROS2 的 service 协议严格限定为 “1 request → 1 response”。但现实中有强需求比如远程调试时想持续获取 CPU 温度流比如在线标定时需要连续接收特征点匹配结果。ROS1 有rostopic pub -r 10 /temp std_msgs/Float32 data: 65.2这种 hackROS2 则彻底移除了该能力。根本原因在于 DDS 规范Request-Reply 是原子操作不支持 partial response。强行扩展会破坏互操作性不同 DDS 厂商实现不一致。但我们有工程解法方案一推荐Topic Service 组合定义 service/start_temp_streamrequest:bool enable, response:bool success, string stream_topic_nameclient 调用后server 动态创建一个临时 topic如/temp_stream_0x1a2b3c并开始发布。client 订阅该 topic。停止时调用/stop_temp_stream。优势完全符合 ROS2 设计哲学资源可回收权限可控。方案二Action当需支持取消/进度若流式数据有明确终点如“采集 100 帧标定图”用 action 更自然。goal 包含int32 frame_countfeedback 返回int32 current_frameresult 返回float32[] all_temps。ActionLib 天然支持 cancel且 feedback 可高频100Hz发送而不影响 goal 处理。实操心得我在手术机器人项目中采用方案一为每个医生操作步骤分配唯一 stream topic 名如/scope_video_step3_drill配合 ROS2 lifecycle node 管理 topic 生命周期确保医生退出步骤时视频流自动关闭内存零泄漏。这套模式后来被团队固化为《ROS2 流式数据接入规范》第一条。3. 从零构建一个工业级 Service定义、实现、调用全流程详解3.1 .srv 文件设计不只是语法更是接口契约ROS2 service 的灵魂在.srv文件。它不是简单的数据结构声明而是 client 与 server 之间的法律契约。契约写得模糊后期维护成本指数级上升。以一个真实案例展开AGV 小车的“精准停靠”服务。原始需求“小车收到一个目标位置x,y,theta移动到该位置并精确停稳返回是否成功及误差”。新手常写# bad_example.srv float64 x float64 y float64 theta --- bool success这存在四大硬伤单位缺失x,y 是米毫米theta 是弧度还是度ROS2 不做单位推导坐标系不明相对于地图原点还是当前底盘中心必须显式声明精度要求未约定误差 1cm 5cmsuccess 判定标准是什么无诊断信息失败时只知道false不知道是定位丢失、电机堵转还是路径不可达。专业写法参考 ROS2 Navigation2 官方 srv 风格# dock_to_pose.srv # Request: target pose in map frame (REP-105) geometry_msgs/PoseStamped target_pose # Optional tolerance (meters radians). If not set, use default from param server. float64 xy_tolerance # default: 0.02 float64 yaw_tolerance # default: 0.05 --- # Response bool success # true if final pose error tolerance float64 final_error_xy # actual xy error (m) float64 final_error_yaw # actual yaw error (rad) string message # human-readable reason on failure (e.g., LOCALIZATION_LOST)关键细节解析使用geometry_msgs/PoseStamped而非裸 float继承了header.stamp时间戳和header.frame_id坐标系这是 ROS2 坐标变换的基础tolerance 字段设为 optional允许 client 指定严苛要求如装配作业需 ±1mm也兼容默认参数避免硬编码response 中final_error_*是调试黄金字段现场工程师无需连 gdb看一眼 response 就知是定位漂移error_xy 大还是转向不准error_yaw 大message字段必须是string而非uint8错误码——人类要读不是机器解析。ROS2 工具链如ros2 service call会直接打印该字符串。注意.srv文件修改后必须重新colcon build。ROS2 不支持热重载。我见过太多人改完 srv 忘记 rebuildclient 编译通过运行时报Type support not found for type xxx/srv/DockToPose查日志两小时才发现是缓存问题。建议在CMakeLists.txt中加入预编译检查if(NOT EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/srv/dock_to_pose.srv) message(FATAL_ERROR dock_to_pose.srv missing! Please check srv directory.) endif()3.2 Server 端实现健壮性远比功能更重要以 C 为例Python 逻辑类似但性能敏感场景强烈推荐 C。核心原则防御式编程资源隔离错误可追溯。// dock_server_node.cpp #include rclcpp/rclcpp.hpp #include nav2_msgs/srv/dock_to_pose.hpp #include geometry_msgs/msg/pose_stamped.hpp #include tf2_ros/transform_listener.h #include tf2_ros/buffer.h class DockServerNode : public rclcpp::Node { public: explicit DockServerNode(const rclcpp::NodeOptions options) : Node(dock_server, options) { // 1. 初始化 TF 监听器关键避免在 service callback 中 new tf_buffer_ std::make_sharedtf2_ros::Buffer(this-get_clock()); tf_listener_ std::make_sharedtf2_ros::TransformListener(*tf_buffer_); // 2. 创建 service server绑定回调 service_ this-create_servicenav2_msgs::srv::DockToPose( dock_to_pose, std::bind(DockServerNode::handle_dock_request, this, std::placeholders::_1, std::placeholders::_2) ); // 3. 从参数服务器加载默认容差支持动态重配置 this-declare_parameter(default_xy_tolerance, 0.02); this-declare_parameter(default_yaw_tolerance, 0.05); } private: void handle_dock_request( const std::shared_ptrrmw_request_id_t request_header, const std::shared_ptrnav2_msgs::srv::DockToPose::Request request, const std::shared_ptrnav2_msgs::srv::DockToPose::Response response) { // 步骤1输入校验第一道防火墙 if (request-target_pose.header.frame_id ! map) { RCLCPP_WARN(this-get_logger(), Target pose frame_id %s not map. Using map as fallback., request-target_pose.header.frame_id.c_str()); // 自动修正而非直接报错——提升鲁棒性 request-target_pose.header.frame_id map; } if (std::isnan(request-target_pose.pose.position.x) || std::isnan(request-target_pose.pose.position.y) || std::isnan(request-target_pose.pose.orientation.w)) { response-success false; response-message NaN detected in target pose. Check sensor fusion.; return; } // 步骤2容差解析支持 request 指定 or 参数默认 const double xy_tol (request-xy_tolerance 0.0) ? request-xy_tolerance : this-get_parameter(default_xy_tolerance).as_double(); const double yaw_tol (request-yaw_tolerance 0.0) ? request-yaw_tolerance : this-get_parameter(default_yaw_tolerance).as_double(); // 步骤3核心业务逻辑此处简化为伪代码 try { // a) 调用底层运动控制器如 nav2s controller server auto result motion_controller_-execute_to_pose(request-target_pose, xy_tol, yaw_tol); // b) 获取最终位姿从 odom 或 amcl geometry_msgs::msg::PoseStamped final_pose; tf_buffer_-lookupTransform(map, base_link, tf2::TimePointZero, final_pose); // c) 计算误差 response-final_error_xy calculate_xy_error(final_pose, request-target_pose); response-final_error_yaw calculate_yaw_error(final_pose, request-target_pose); response-success (response-final_error_xy xy_tol response-final_error_yaw yaw_tol); response-message response-success ? Docking succeeded. : Docking failed: tolerance exceeded.; } catch (const std::exception e) { // 捕获所有未处理异常避免 crash 整个节点 RCLCPP_ERROR(this-get_logger(), Exception in docking: %s, e.what()); response-success false; response-message std::string(Internal error: ) e.what(); response-final_error_xy 0.0; response-final_error_yaw 0.0; } } // 成员变量 rclcpp::Servicenav2_msgs::srv::DockToPose::SharedPtr service_; std::shared_ptrtf2_ros::Buffer tf_buffer_; std::shared_ptrtf2_ros::TransformListener tf_listener_; std::shared_ptrMotionController motion_controller_; // 业务类 };关键经验点TF 初始化必须在构造函数TransformListener构造会启动后台线程监听 TF若在 callback 中 new每次调用都新建线程内存爆炸输入校验前置NaN检查必须在业务逻辑前否则calculate_xy_error可能返回nan污染后续判断异常捕获全覆盖ROS2 node crash 会导致整个 namespace 下所有 topic/service 中断。用try-catch包裹全部业务代码是底线日志分级明确RCLCPP_WARN用于可恢复问题如 frame_id 不匹配RCLCPP_ERROR用于致命异常方便运维过滤。3.3 Client 端调用超时、重试与用户体验Client 看似简单却是故障率最高的环节。90% 的 “service 调用失败” 问题出在 client 端配置不当。# dock_client.py import rclpy from rclpy.node import Node from nav2_msgs.srv import DockToPose from geometry_msgs.msg import PoseStamped import time class DockClient(Node): def __init__(self): super().__init__(dock_client) # 创建 client注意QoS 配置必须与 server 匹配 self.cli self.create_client(DockToPose, dock_to_pose) # 关键设置超时。默认是 forever绝对不可接受 # 我们设定网络层超时 2s业务逻辑超时 15s总超时 17s self.cli.wait_for_service(timeout_sec2.0) # 等待 service 上线最多 2s # 构造 request self.req DockToPose.Request() self.req.target_pose.header.frame_id map self.req.target_pose.header.stamp self.get_clock().now().to_msg() self.req.target_pose.pose.position.x 1.5 self.req.target_pose.pose.position.y 2.0 self.req.target_pose.pose.orientation.w 1.0 self.req.xy_tolerance 0.01 # 比默认更严苛 def send_request(self): # 异步调用推荐避免阻塞主线程 self.future self.cli.call_async(self.req) # 设置定时器轮询 future 状态替代 spin_until_future_complete更可控 self.timer self.create_timer(0.1, self.check_response) def check_response(self): if self.future.done(): try: response self.future.result() self.get_logger().info(fDock success: {response.success}) self.get_logger().info(fError XY: {response.final_error_xy:.3f}m, Yaw: {response.final_error_yaw:.3f}rad) self.get_logger().info(fMessage: {response.message}) if not response.success: # 根据 message 内容触发不同 UI 反馈 if LOCALIZATION_LOST in response.message: self.show_localization_alert() elif MOTOR_BLOCKED in response.message: self.play_motor_blocked_sound() except Exception as e: self.get_logger().error(fService call failed: {e}) finally: self.destroy_timer(self.timer) self.timer None def main(argsNone): rclpy.init(argsargs) client DockClient() # 模拟用户点击触发 client.send_request() # 保持节点运行处理回调 rclpy.spin(client) rclpy.shutdown()避坑指南永远不要用spin_until_future_complete它会阻塞整个线程UI 冻结无法响应取消指令。用 timer 轮询是工业级实践wait_for_service必须设 timeout默认是 blocking forever。产线机器人启动时若dock_server因依赖未就绪而晚启动 5 秒client 就卡死 5 秒UI 白屏客户投诉超时值需分层设置wait_for_service发现超时 call_async内部 DDS 超时网络超时 业务逻辑超时server 端应主动检查并提前返回。三者叠加才能覆盖全链路response.message 是 UI 友好字段前端直接显示response.message比解析success布尔值有用十倍。我在医疗机器人项目中所有 service response.message 都遵循[ERROR_CODE] Human readable detail格式前端用正则提取 ERROR_CODE 做分类着色。4. 调试、监控与线上问题排查实战手册4.1 五步定位法从 “没响应” 到 “定位根因”当ros2 service call /dock_to_pose nav2_msgs/srv/DockToPose {...}无返回别急着查代码。按此顺序排查步骤操作预期输出根因指向1. 检查 service 是否注册ros2 node list→ros2 node info /dock_server应看到/dock_to_pose在Services:列表中server 节点未启动或 service 名拼写错误大小写敏感2. 检查网络连通性ros2 topic echo /parameter_events验证 DDS 发现机制应持续输出 parameter 变更事件多机网络配置错误如ROS_DOMAIN_ID不一致、防火墙拦截 UDP 7400 端口3. 抓包验证请求发出sudo tcpdump -i any port 7400 -w service.pcap Wireshark 过滤dds.rtps.sm应看到DATAsubmessagetype_id 为DockToPose_Requestclient 端 QoS 与 server 不匹配如 client 用BEST_EFFORTserver 要RELIABLE4. 查看 server 日志ros2 launch dock_server.launch.py --event-handlers console_direct应看到handle_dock_request called日志server 端 crash 或未进入 callback检查构造函数是否抛异常5. 检查 response 是否发出ros2 topic hz /dock_to_pose/_reply隐藏 topic应有消息频率如 1Hzserver 业务逻辑卡死或 response 对象未正确赋值如忘记response-success true实操心得我在某汽车厂项目中客户报告“dock service 偶发超时”。按上述流程第 3 步抓包发现95% 的请求包发出但仅 60% 的响应包返回。进一步用ros2 daemon stop ros2 daemon start重启 daemon 后恢复正常。根因是 ROS2 daemon 的 DDS participant 泄漏bug in older Fast-RTPS。解决方案升级 ROS2 Foxy patch 版本并在 launch 文件中添加--ros-args -p use_sim_time:true强制使用 sim time规避该 bug。这个案例告诉我们不要假设基础设施完美监控必须覆盖到 DDS 层。4.2 生产环境必备监控项Prometheus Grafana在 AGV 调度中心我们部署了以下 6 个核心 metrics全部接入 PrometheusMetric NameType描述告警阈值排查意义ros2_service_calls_total{servicedock_to_pose,statussuccess}Counter成功调用次数1h 内增长 10 次server 是否存活业务是否被调用ros2_service_calls_duration_seconds_bucket{servicedock_to_pose,le1.0}Histogram调用耗时分布le1.0桶占比 95%是否出现慢请求定位是网络还是计算瓶颈ros2_service_client_errors_total{servicedock_to_pose,error_typetimeout}Counterclient 端超时次数5m 内 3 次网络抖动 or server 响应慢ros2_service_server_errors_total{servicedock_to_pose,error_codeLOCALIZATION_LOST}Counterserver 端特定错误次数10m 内 5 次定位硬件问题如 UWB 信号弱ros2_service_queue_length{servicedock_to_pose}Gaugeserver 端请求队列长度 5server 处理能力不足需扩容ros2_service_active_requests{servicedock_to_pose}Gauge当前正在处理的请求数持续 1server 是否卡死在某个请求Grafana 面板截图文字描述顶部是dock_to_pose的成功率曲线绿色目标 ≥99.5%下方是耗时热力图X轴时间Y轴耗时分桶颜色深浅表示频次。当某天下午 2:15 出现成功率跌至 82%热力图显示大量请求堆积在le10.0桶我们立即登录 server 机器top发现motion_controller进程 CPU 占用 99%strace -p追踪到其卡在read()系统调用——根因是底盘驱动固件 bug导致串口读取阻塞。15 分钟内定位30 分钟内推送固件补丁。4.3 常见问题速查表附真实错误日志与修复命令现象典型错误日志根因分析修复命令/步骤Service not availableFailed to contact service /dock_to_pose: service not advertisedserver 节点未启动或node_name与 launch 文件中不一致ros2 node list确认节点名 →ros2 node info /your_node_name看 services 列表 → 检查 launch 文件中node name...Timeout exceeded while waiting for serviceFailed to wait for service /dock_to_pose: timeoutwait_for_service(timeout_sec...)设置过短或网络发现失败增加 timeout 至 5.0检查ROS_DOMAIN_ID两端是否一致ros2 daemon status确认 daemon 运行Type support not foundFailed to create client: type support not found for type nav2_msgs/srv/DockToPoseclient 包未find_package(nav2_msgs)或srv文件未在CMakeLists.txt中add_service_files检查package.xml有dependnav2_msgs/depend检查CMakeLists.txt有add_service_files(DIRECTORY srv FILES dock_to_pose.srv)colcon build --packages-select your_pkgClient received empty responseresponse is None或AttributeError: NoneType object has no attribute successserver 端未给response对象赋值或return语句提前退出在 server callback 末尾加RCLCPP_INFO(..., Leaving callback);确保所有分支都设置response-successService call hangs foreverros2 service call命令光标不动无输出server 端 callback 中有死循环或等待外部资源如 mutex未释放ros2 node list找到 server →ros2 node kill /server_name强制终止 → 用gdbattach 分析卡点注意ros2 node kill是最后手段。优先用ros2 lifecycle set /dock_server configure如果用了 lifecycle node优雅停止。我在某项目中因滥用kill导致底盘电机驱动器未收到STOP指令小车在惯性下滑行撞墙。教训所有 service server 必须实现 graceful shutdown hook在节点销毁前发送安全指令。5. 进阶技巧与架构演进思考5.1 如何安全地升级 service 接口——向后兼容的黄金法则业务迭代必然带来.srv修改。直接删字段、改类型会破坏现有 client。ROS2 社区公认的安全升级法新增字段在 request/response 末尾追加设默认值。旧 client 发送的 request 不含新字段ROS2 自动填充默认值如float64 new_field0.0废弃字段不删除改为注释# DEPRECATED: use new_field instead并在 server 端忽略其值重命名字段保留旧字段新增同义新字段server 端做映射if old_field ! 0.0: use old_field else use new_field类型变更如 float32 → float64必须新增字段旧字段标记 deprecated。ROS2 不支持同一字段类型变更。我们在导航系统升级中将DockToPose的target_pose从geometry_msgs/Pose升级为geometry_msgs/PoseStamped。做法新增字段geometry_msgs/PoseStamped target_pose_stamped保留旧字段geometry_msgs/Pose target_pose标注# DEPRECATEDserver 端逻辑若target_pose_stamped.header.stamp.sec ! 0用 stamped否则用 legacy pose 当前时间戳构造 stamped发布新版后给 client 团队 3 个月迁移期之后移除 legacy 字段。提示用ros2 interface show nav2_msgs/srv/DockToPose可随时查看当前接口定义。建议将.srv文件纳入 Git并在 PR 描述中明确标注 “BREAKING CHANGE” 或 “BACKWARD COMPATIBLE”。5.2 Service Mesh 思路当你的机器人系统超过 50 个节点单个 service 调用简单但当系统包含 20 台 AGV、5 台叉车、10 个充电桩、3 套调度引擎时/dock_to_pose可能有 50 个 server 实例每台车一个。client 如何知道调哪个方案一基础命名空间隔离/agv001/dock_to_pose,/agv002/dock_to_pose… client 根据目标 AGV ID 拼接 service 名。简单但硬编码扩展性差。方案二推荐Discovery Service创建一个中央fleet_discoveryservicerequest 包含string agv_idresponse 返回string service_address如/agv001/dock_to_pose。所有 client 先调 discovery再调目标 service。优势解耦支持动态扩缩容。方案三前沿ROS2 gRPC 混合架构对跨域如云边协同或高安全要求场景用 gRPC 替代部分 ROS2 service。例如云端下发任务用 gRPCTLS 加密JWT 认证车端内部通信仍用 ROS2 service。我们已在某港口项目落地/cloud_task_dispatch用 gRPC/local_dock_control用 ROS2 service通过 bridge node 转换。5.3 我的个人体会Services 是机器人的“API 界面”不是技术玩具写这篇内容时我翻出了三年前的第一版dock_server代码120 行无日志无校验超时设为 30 秒失败只返回false。现在同一功能的 server 是 850 行包含完整的单元测试覆盖率 82%、OpenTelemetry 链路追踪、Prometheus metrics、lifecycle 管理、以及一份 12 页的SERVICE_INTERFACE_SPEC.md。变化的不是技术而是认知——services 不是 demo 里的玩具它是用户可能是产线工人、医生、司机与机器人对话的唯一窗口。用户不会关心你用了 Fast-RTPS 还是 CycloneDDS他们只关心“我点了‘停靠’为什么没反应”、“误差 5cm 是正常吗”。把 service 当作产品 API 来设计定义清晰、文档完备、错误友好、监控到位、升级平滑。这才是 ROS2 工程师的核心竞争力。最后分享一个小技巧在每个 service 的 README.md 里用表格写明“谁会调用它为什么调用调用失败时用户看到什么运维如何快速诊断”。这份文档比代码更能体现一个工程师的成熟度。
