第1章 机器人系统概述
做机器人系统开发这些年，我最大的感触是：别急着写代码。很多新手一上来就调电机、跑SLAM，结果连系统怎么挂的都不知道。这一章，我们先搭个全局框架——搞清楚机器人到底由什么组成、ROS是什么东西、开发流程该怎么走。
本章核心目标：建立机器人系统的整体认知，理解ROS的定位，掌握从需求到部署的标准开发路径。
1.1 机器人系统组成
一台能用的机器人，绝不只是「电机+轮子+摄像头」。我个人习惯把系统拆成四个层次，你想想看，任何一个环节掉链子，整机就废了。
这四层的关系，说白了就是感知-思考-行动的循环。我在项目中遇到过最典型的坑：感知层数据延迟太大，决策层算完路径，机器人已经撞墙了。嗯，这里要注意——实时性是贯穿所有层的红线。
| 层次 | 典型硬件/软件 | 常见问题 |
|---|---|---|
| 感知层 | LiDAR、摄像头、IMU | 数据噪声、时间戳不同步 |
| 决策层 | ROS Navigation Stack、MoveIt | 算力不足、规划死锁 |
| 控制层 | MCU、PID控制器 | 响应滞后、震荡 |
| 执行层 | 电机、减速器、编码器 | 机械间隙、堵转 |
避坑提醒：我曾经在项目里只关注算法，忽略了执行层的机械间隙。结果仿真跑得飞起，实车一跑就偏。记住：仿真不是现实，每个层次都要单独验证。
1.2 机器人操作系统（ROS）简介
ROS不是真正的操作系统，它是个分布式通信框架。你想想看，一个机器人可能有3个摄像头、2个激光雷达、1个机械臂，如果每个模块都自己写通信协议，项目还没开始就结束了。
ROS的核心就三件事：
- 节点（Node）：每个功能模块是一个节点，比如「摄像头节点」「路径规划节点」。
- 话题（Topic）：节点之间通过话题发布/订阅数据。比如摄像头节点发布
/camera/image话题。 - 服务（Service）：请求-响应模式，适合一次性调用，比如「打开机械臂夹爪」。
我个人习惯把ROS比作消息总线——所有节点插上去就能通信，谁挂了也不影响其他节点。但注意，这不是银弹。
小经验：刚开始学ROS，别急着看源码。先跑一遍 roscore，再用 rosrun 启动两个节点，用 rostopic echo 看数据流。亲眼看到消息在节点间传递，比读十篇教程都管用。
ROS2相比ROS1，最大的改进是去中心化和实时性。ROS1依赖一个Master节点，Master挂了整个系统就瘫了。ROS2用DDS（数据分发服务）做底层通信，每个节点直接点对点通信。我在做工业机器人项目时，ROS1的Master单点故障让我吃过亏，后来切到ROS2才解决。
| 特性 | ROS1 | ROS2 |
|---|---|---|
| 通信架构 | 中心化（Master） | 去中心化（DDS） |
| 实时性 | 不支持 | 支持（需RT内核） |
| 多机器人 | 复杂 | 原生支持 |
| 跨平台 | Linux为主 | Windows/macOS/Linux |
我的建议：新项目直接上ROS2。ROS1虽然生态成熟，但官方已经停止更新。别在旧技术上浪费时间。
1.3 机器人开发流程概览
很多团队做机器人，上来就写代码，写到一半发现需求没对齐，或者硬件选型错了。我总结了一套五阶段流程，每个阶段都有明确的交付物。
这里我想重点说说联调测试阶段。很多团队把联调当成「最后一步」，结果所有问题堆在一起爆发。我建议：从第一天就开始联调。哪怕只有一个传感器和一个电机，也要让它们先跑通。
血的教训：我曾经在一个AGV项目里，硬件团队和软件团队各自开发了3个月。联调那天发现——电机驱动板的CAN总线协议和ROS节点的定义完全对不上。改协议？硬件要重新打板，软件要重写驱动。前后多花了2周。如果早期就做接口联调，这2周完全可以省掉。
具体到每个阶段，我习惯用检查清单来卡进度：
- 需求分析阶段：机器人要做什么？在什么环境？负载多少？精度要求？
- 系统设计阶段：选什么传感器？用什么主控？通信协议是CAN还是EtherCAT？
- 联调测试阶段：每个模块单独测过吗？接口对得上吗？极端情况（堵转、丢包）处理了吗？
- 部署运维阶段：现场网络稳定吗？OTA升级失败怎么回滚？日志怎么收集？
一个小技巧：在需求分析阶段，花一天时间画一张系统数据流图——从传感器原始数据，到最终电机输出，中间经过哪些节点、哪些话题、哪些变换。这张图画清楚了，后面80%的坑都能提前发现。