无人车系统架构：感知、决策、控制、通信等模块的组成与数据流关系

无人车是一个典型的复杂嵌入式智能系统，其本质是“环境输入—计算决策—执行输出”的闭环。在项目交付场景中，无论是源码结构梳理、模型部署还是接线调试，都必须首先建立对系统架构的全局认知。本章将围绕感知、决策规划、运动控制、通信与线控底盘五大核心模块，剖析其功能边界、内部组成以及模块间的数据流关系，为后续章节的源码解读、模型封装和实车联调奠定架构基础。

上图展示了无人车五大核心模块的拓扑关系与数据流向。从工程交付视角看，这张图不仅是架构设计图，更是源码目录划分、模型部署位置、接线端子定义和调试排障路径的索引图。下面逐一展开各模块的组成细节与数据流设计要点。

2.1 感知模块：多传感器融合与数据预处理

核心原理：感知模块是无人车的“眼睛”，负责将物理世界的原始信号转换为结构化语义信息。在典型校园无人车或园区物流车项目中，感知硬件通常包括：前视单目/双目相机（用于车道线、交通灯、行人检测）、16线或32线激光雷达（用于障碍物点云聚类与可行驶区域提取）、毫米波雷达（用于远距离目标速度测量）、超声波雷达（用于近距补盲），以及GNSS+IMU组合导航系统（用于全局定位与姿态解算）。

数据流与处理流程：感知模块内部遵循“原始数据→预处理→算法推理→后处理→消息发布”的标准流水线。以相机为例，原始图像先经过畸变校正和曝光补偿，再送入YOLO系列或Transformer-based检测模型，输出带置信度的2D检测框；激光雷达点云则经过体素滤波、地面分割、欧式聚类，生成3D障碍物列表；GNSS/IMU数据通过卡尔曼滤波或因子图优化，输出频率为50Hz以上的平滑位姿。最终，感知模块通过ROS2或自定义中间件，以10~20Hz的频率发布包含障碍物数组、车道线多项式系数、自车位姿的自定义消息。

2.2 决策规划模块：从全局路径到局部轨迹

核心原理：决策规划模块解决“车应该怎么走”的问题，分为全局路径规划、行为决策和局部轨迹规划三个子层。全局路径规划基于高精地图或预先构建的栅格地图，使用A*、Dijkstra或RRT算法生成从起点到终点的粗粒度路径；行为决策层根据当前交通场景（路口、行人、障碍物）切换车辆状态，如“跟车行驶”“停车等待”“绕行避障”；局部轨迹规划则在全局路径约束下，结合实时感知信息，使用多项式拟合、样条曲线或优化方法生成未来1~3秒内平滑、安全、可执行的轨迹。

关键数据流：决策规划模块的输入包括：感知模块输出的障碍物列表、全局路径点、当前自车位姿、高精地图中的车道线信息。输出为一条带时间戳的轨迹序列，每个轨迹点包含目标x/y坐标、航向角、期望速度、期望加速度。该轨迹以20~50Hz的频率发布给控制模块。在工程实现中，轨迹消息通常定义为TrajectoryPoint[]数组，并附带轨迹ID和有效性标志。

# 轨迹点消息结构示例（ROS2接口定义）
float32 x            # 全局X坐标 (m)
float32 y            # 全局Y坐标 (m)
float32 theta        # 航向角 (rad)
float32 v            # 期望速度 (m/s)
float32 a            # 期望加速度 (m/s²)
float32 curvature    # 曲率 (1/m)
uint8 gear           # 挡位：0-P, 1-D, 2-R, 3-N
uint64 timestamp_ns  # 时间戳

2.3 控制模块：精确跟踪与执行器闭环

核心原理：控制模块是无人车“小脑”，负责将规划轨迹转化为底层执行器指令。横向控制常用纯跟踪（Pure Pursuit）、Stanley方法或模型预测控制（MPC），根据当前位姿与目标轨迹的横向偏差计算前轮转角；纵向控制采用PID或串级PID，根据速度偏差计算油门开度与制动压力。在低速园区场景中，纯跟踪+增量式PID已能取得良好效果；在高速或复杂工况下，MPC因其对约束的显式处理而更受青睐。

控制链路与反馈：控制模块以10~50Hz接收轨迹指令，同时以更高频率（通常100Hz以上）读取底盘反馈的当前车速、前轮转角、横摆角速度。控制算法输出经过限幅、斜率约束和滤波后，通过CAN总线或串口发送至线控底盘。底盘执行器（转向电机、驱动电机、制动阀）将实际状态反馈给控制模块，形成闭环。在交付项目中，控制模块必须包含“安全保护”逻辑：当检测到执行器反馈异常、指令超时或车辆状态超出安全边界时，立即触发紧急制动并切换至安全停车模式。

2.4 通信模块与数据分发机制

核心原理：通信模块是无人车各模块之间的“神经网络”。在主流无人车项目中，通信架构分为两层：内部模块间通信采用ROS2（基于DDS）或自定义共享内存机制，保证高带宽、低延迟的数据传输；与底盘执行器通信采用CAN总线或串口，保证实时性与可靠性。此外，远程监控与调度中心通过4G/5G或Wi-Fi与无人车通信，传输状态信息、任务指令和视频流。

数据流设计要点：在ROS2架构下，感知、决策、控制分别运行在不同进程或不同计算节点上，通过Topic进行异步发布/订阅，通过Service进行同步请求/响应。关键数据流包括：/perception/obstacles（障碍物列表）、/perception/localization（定位信息）、/planning/trajectory（规划轨迹）、/control/cmd（控制指令）、/vehicle/status（底盘状态）。在交付时，需要提供完整的通信拓扑图、消息接口定义文档以及各Topic的频率、队列深度、QoS策略配置说明。

2.5 案例拆解：某园区无人配送车的数据流联调

项目背景：某园区部署一台无人配送车，要求实现从A栋到B栋的自主行驶，最高车速5m/s，需通过一个丁字路口并避让行人。车辆采用前视相机+16线激光雷达+GNSS/IMU的感知方案，线控底盘支持CAN指令控制转向、驱动和制动。

初始现象：在首次实车测试中，车辆在直线行驶时出现明显的左右摇摆（横向振荡），且当行人出现在车辆前方3米处时，车辆制动过晚，最终在距行人约0.8米处才完全停稳，超出安全距离要求。

分析判断过程：通过录制bag包并回放，对比规划轨迹与控制指令发现：规划模块输出的轨迹在时间戳上存在约120ms的延迟，而控制模块以50Hz运行，导致控制指令跟踪的是“过时”的轨迹点。同时，横向控制采用纯跟踪算法，前视距离（lookahead distance）设置为1.5米，在低速下该值偏小，导致转向增益过高，产生振荡。纵向控制方面，制动指令的斜率限制设置过宽，导致制动力建立缓慢。

实际操作步骤：1）将规划模块的轨迹发布时间戳改为控制模块接收时刻的预测位姿进行补偿，消除120ms延迟；2）将纯跟踪前视距离从1.5米调整为2.8米，并增加速度自适应调整；3）将制动指令斜率限制从5m/s³收紧至2m/s³，同时增加紧急制动独立通道；4）重新录制bag包，验证横向偏差从±0.35米降至±0.08米，行人场景制动距离缩短至0.4米。

结果对比与复盘：调整后车辆行驶平稳性显著提升，横向振荡消失，制动距离满足安全要求。复盘经验：在无人车交付中，数据流的时间同步问题（时钟偏移、消息延迟）是导致控制性能劣化的首要隐性因素，必须在架构设计阶段就引入统一时钟源和消息时间戳校验机制。

2.6 常见误区与总结复盘

• 误区一：认为感知、决策、控制是三个完全独立的模块，忽略了它们之间的数据耦合。实际上，感知延迟会直接影响控制效果，规划轨迹的平滑度也会影响控制稳定性。
• 误区二：只关注模块内部算法，忽视通信中间件的QoS配置。例如，将感知Topic的QoS设置为不可靠传输，在Wi-Fi干扰下会导致丢帧，进而引发感知结果跳变。
• 误区三：在交付文档中只提供源码和模型，不提供数据流拓扑图和消息接口定义。这导致现场维护人员无法快速定位“消息未到达”或“消息格式不匹配”等基础问题。
• 误区四：忽略底盘反馈状态在数据流中的闭环作用。控制模块必须实时读取底盘实际转角、车速，否则无法实现精确跟踪，也无法检测执行器故障。

总结：无人车系统架构的核心在于“模块解耦、数据闭环”。在项目交付中，不仅要交付可运行的源码和模型，更要交付清晰的架构文档、数据流定义和调试工具链。理解感知、决策、控制、通信与线控底盘之间的数据流关系，是进行源码阅读、模型部署、接线检查和故障排除的基础。建议在交付物中增加一份“数据流速查表”，列出所有关键Topic、消息类型、频率和QoS策略，这将为后续的运维和二次开发提供极大便利。