第2章 AMR系统架构总览

第2章：AMR系统架构总览：感知层、决策层、执行层、通信层的分层架构与数据流

各位工程师朋友，咱们今天聊聊AMR的系统架构。说实话，我刚入行那会儿，看着一堆传感器、控制器、电机，脑子里也是一团浆糊。后来带我的老工程师丢给我一句话：「你把它拆成四层来看，就清楚了。」嗯，就是今天要讲的——感知层、决策层、执行层、通信层。

这四层架构，说白了就是AMR的「五官、大脑、手脚和神经」。我做过好几个项目，每次架构设计都绕不开这个框架。你想想看，一台AMR要自主移动，它得先知道自己在哪、周围有什么（感知层），然后决定怎么走、去哪（决策层），最后控制轮子动起来（执行层），整个过程还得跟外部系统保持沟通（通信层）。

下面这张图，是我习惯用的架构总览。你可以把它当作整章的地图。

2.1 感知层：AMR的「五官」

感知层负责采集环境数据。我习惯把它分成两块：内部感知和外部感知。

内部感知：编码器（测轮速）、IMU（测加速度和角速度）、电池管理芯片。这些数据告诉AMR「我自己状态如何」。
外部感知：激光雷达（2D/3D）、深度相机、超声波传感器。这些告诉AMR「周围世界什么样」。

举个例子。我在一个仓储项目里，只用单线激光雷达做SLAM，结果在玻璃墙区域直接「瞎了」。后来加了深度相机做视觉辅助，才把定位精度拉回来。所以我的建议是：感知层一定要多传感器融合，别指望一个传感器包打天下。

💡 我的小技巧： 感知数据的时间戳对齐是个坑。我曾经因为激光雷达和IMU的时间戳差了50ms，导致建图出现重影。后来统一用ROS 2的time stamp机制，问题才解决。

2.2 决策层：AMR的「大脑」

决策层是AMR最核心的部分。它接收感知层的数据，然后做出「下一步该干嘛」的决定。我一般把它拆成三个子模块：

全局路径规划：从A点到B点，走哪条路？常用A*、Dijkstra。我习惯用A*，因为它带启发式搜索，效率高。
局部路径规划：遇到动态障碍物怎么办？TEB、DWA这些算法就是干这个的。说白了就是「躲着走」。
行为决策：什么时候该停？什么时候该让？用状态机或者行为树来管理。比如「遇到行人→减速→绕行→恢复路径」。

这里有个坑。我在一个工厂项目里，全局路径规划算出来一条完美路径，但局部规划器每次遇到叉车就原地打转。后来发现是局部规划器的参数没调好——代价地图的膨胀半径设得太小了。嗯，调参这件事，真的得靠经验积累。

决策层数据流示例（伪代码）：

# 伪代码：决策层主循环
while robot_running:
    # 1. 获取感知数据
    laser_scan = get_laser_data()
    odom = get_odometry()
    
    # 2. 更新代价地图
    costmap.update(laser_scan, odom)
    
    # 3. 全局规划（如果目标点变了）
    if new_goal:
        global_path = a_star_planner(current_pose, goal_pose, costmap)
    
    # 4. 局部规划
    cmd_vel = teb_planner(global_path, costmap, current_pose)
    
    # 5. 发送给执行层
    send_to_motor_controller(cmd_vel)

2.3 执行层：AMR的「手脚」

执行层负责把决策层的指令变成物理动作。说白了就是让电机转起来、让轮子动起来。

执行层通常包含：

电机驱动：直流无刷电机、伺服电机，配驱动器（如ODrive、RoboMaster C板）。
运动控制：PID控制器，分速度环、位置环、电流环。我习惯先调速度环，再调位置环。
执行机构：差速轮、麦克纳姆轮、舵轮，还有举升机构、货叉等。

我记得有一次，决策层下发的速度指令是1m/s，但实际跑起来只有0.8m/s。查了半天，发现是电机驱动器的电流限幅设得太低了。所以我的经验是：执行层的参数一定要跟电机和机械结构匹配，不能光看理论值。

⚠️ 注意： 执行层的安全机制一定要独立于决策层。我曾经见过一个项目，决策层死机了，电机还在全速跑，差点撞人。后来加了硬件急停和看门狗，才放心。

2.4 通信层：AMR的「神经网络」

通信层负责把上面三层串起来，同时跟外部系统打交道。它分两部分：

内部通信：传感器→主控、主控→驱动器。常用CAN总线、UART、I2C、SPI。我个人偏爱CAN，抗干扰强，适合工业环境。
外部通信：AMR跟调度系统、车队管理系统、MES/ERP交互。常用Wi-Fi、5G、以太网，协议用MQTT、HTTP、ROS 2。

这里有个数据流的关键点。我习惯把通信层设计成异步消息总线的模式。比如用ROS 2的Topic/Publish机制，感知层发布传感器数据，决策层订阅并处理，执行层订阅控制指令。这样各层解耦，调试起来方便很多。

通信协议	适用场景	我踩过的坑
CAN总线	电机控制、传感器数据	波特率不匹配导致丢帧，后来统一用500kbps
MQTT	与云端/调度系统通信	QoS等级设太高，网络差时消息积压
ROS 2	内部模块间通信	DDS发现协议在跨网段时超时，得手动配置

2.5 数据流全景：从传感器到执行器

好了，四层都讲完了。咱们串起来看看完整的数据流：

感知层：激光雷达扫描一圈，得到点云数据。IMU给出姿态。编码器给出里程计。
通信层：这些数据通过CAN或ROS 2 Topic，传到决策层的主控。
决策层：主控运行SLAM算法，算出当前位置。然后全局规划出一条路径。局部规划器根据实时障碍物，生成速度指令。
通信层：速度指令通过CAN总线，下发到电机驱动器。
执行层：电机驱动器控制电机转动，AMR开始移动。同时编码器把实际速度反馈回去。

你想想看，这个过程每秒钟要循环几十次甚至上百次。任何一个环节延迟，都会影响AMR的实时性。我在一个项目里，就因为通信层的CAN总线负载太高，导致控制指令延迟了20ms，AMR走起来一卡一卡的。后来把一些非关键数据（比如电池电压）的发送频率降低，才解决问题。

数据流关键指标（我的经验值）：

感知层数据发布频率：激光雷达10Hz，IMU 100Hz，编码器 50Hz
决策层控制周期：20ms（50Hz）
执行层响应时间：<5ms（从收到指令到电机开始响应）
通信层端到端延迟：<10ms（内部），<100ms（外部）

最后说一句。这四层架构不是死的。我见过有些AMR把感知和决策合并到一块高性能工控机上，也见过把执行层拆成多个微控制器。关键是要理解每一层的职责和数据流的方向。搞清楚了这些，你设计AMR系统时就不会抓瞎了。

📌 我的建议： 刚开始做AMR项目时，先画一张类似上面SVG的架构图，把每一层的模块、接口、数据流标清楚。这张图就是你的「作战地图」。我每个项目都这么干，屡试不爽。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录