分布式多车自主泊车系统设计与Autoware实践
1. 分布式多车自主泊车系统DMV-AVP的设计与实现
在自动驾驶技术快速发展的今天，自主代客泊车(Autonomous Valet Parking, AVP)已成为最具商业落地潜力的场景之一。传统AVP系统多采用集中式架构，当面对多车协同泊车场景时，往往面临扩展性差、单点故障等问题。DMV-AVP系统创新性地采用分布式架构，通过Autoware自动驾驶框架和Zenoh通信中间件，实现了多主机环境下的稳定协同泊车。
1.1 系统架构概览
DMV-AVP基于DMAVA(Distributed Multi-AV Architecture)架构扩展而来，主要由两大核心模块组成：
Unity集成YOLOv5停车位检测模块(U-YOLO)：通过安装在路侧单元(RSU)的俯视摄像头，实时检测停车场内的空余车位。该模块采用YOLOv5目标检测算法，识别精度达到90%以上，处理延迟控制在100ms以内。
多车AVP协调框架(AVP-CF)：包含全局协调管理器(AVP Managers)和单车执行节点(AVP Node)两个层级。管理器负责车位预约、车辆排队等全局状态维护，而执行节点则负责单车级的路径规划和运动控制。
提示：系统采用容器化部署，每个车辆自治功能运行在独立的Docker容器中，通过Zenoh实现跨主机通信。这种设计既保证了模块间的隔离性，又便于系统扩展。
1.2 关键技术选型解析
1.2.1 Autoware自动驾驶框架
Autoware是目前最成熟的开源自动驾驶框架之一，DMV-AVP基于其最新Universe版本构建，主要利用了以下核心组件：
- 定位模块：采用NDT匹配算法，定位精度达到±10cm
- 规划模块：基于A*算法的全局路径规划，配合MPC局部轨迹优化
- 控制模块：PID与模型预测控制混合策略，横向控制误差<0.1m
# Autoware中典型的控制指令发布示例 from autoware_auto_control_msgs.msg import AckermannControlCommand def publish_control(steer, speed): cmd = AckermannControlCommand() cmd.lateral.steering_tire_angle = steer # 转向角度(rad) cmd.longitudinal.speed = speed # 目标速度(m/s) control_pub.publish(cmd)1.2.2 Zenoh通信中间件
相比传统的ROS 2通信，Zenoh在分布式场景下展现出三大优势：
- 跨主机发现：自动处理网络拓扑变化，节点加入/退出无需手动配置
- 数据高效路由：支持基于内容的路由，减少不必要的数据传输
- 资源占用低：实测单节点内存占用<50MB，适合资源受限设备
通信性能对比：
| 指标 | ROS 2(DDS) | Zenoh |
|---|---|---|
| 端到端延迟 | 15-20ms | 8-12ms |
| 带宽利用率 | 较高 | 低30% |
| CPU占用 | 12-15% | 5-8% |
1.3 停车位检测模块实现细节
U-YOLO模块的创新之处在于将YOLOv5检测器无缝集成到Unity仿真环境中。具体实现流程：
- 图像采集：Unity场景中的RSU摄像头以15FPS采集俯视画面
- 目标检测：图像发送到YOLOv5服务器进行车辆检测
- 车位匹配：通过几何关系计算检测框与预设车位的重叠区域
- 状态发布：将空闲车位ID列表通过ROS 2话题发布
# 启动YOLOv5检测服务的典型命令 python detect.py --weights yolov5s.pt --img 640 --conf 0.5 \ --source http://simulator:8080/video_feed实际测试中发现，检测精度受以下因素影响较大：
- 光照条件变化（建议停车场照度>200lux）
- 车辆颜色与地面对比度（浅色车辆在明亮地面易漏检）
- 摄像头安装高度（推荐4-6米俯视角）
2. 多车协同泊车算法设计
2.1 分布式协调架构
AVP-CF采用"集中决策+分布式执行"的混合架构：
AVP Managers（集中式）：
- 车辆计数管理器：维护活跃车辆列表
- 状态管理器：同步各车生命周期状态
- 队列管理器：管理下车区的车辆排队顺序
- 预约管理器：处理车位分配请求
AVP Node（分布式）：
- 每车独立运行的决策单元
- 实现基于有限状态机(FSM)的行为控制
- 与Autoware规划/控制模块交互
注意：虽然采用集中式协调，但所有管理器都设计为无状态服务，任一节点故障都能快速恢复，避免单点问题。
2.2 协同泊车状态机
系统核心是如图所示的七状态有限状态机：
[等待开始] --> [导航至下车区] --> [到达下车位置] --> [排队处理] --> [前往停车位] --> [到达停车位] --> [完成泊车]状态转换触发条件：
| 当前状态 | 触发事件 | 下一状态 |
|---|---|---|
| 等待开始 | 收到用户泊车指令 | 导航至下车区 |
| 导航至下车区 | 到达下车区坐标(±0.5m) | 到达下车位置 |
| 到达下车位置 | 队列管理器分配排队序号 | 排队处理 |
| 排队处理 | 前车完成离开+车位可用 | 前往停车位 |
| 前往停车位 | 到达预约车位中心(±0.3m) | 到达停车位 |
2.3 冲突解决机制
多车协同中的典型冲突场景及解决方案：
车位竞争冲突：
- 采用两阶段提交协议：
- 车辆请求临时保留车位
- 管理器确认无冲突后转为永久预约
- 采用两阶段提交协议：
路径交叉冲突：
- 基于时空立方体(STC)算法进行4D轨迹规划
- 关键区域设置虚拟交通灯
通信中断处理：
- 心跳超时(>3s)触发安全停车
- 采用最后已知状态进行保守决策
// 车位预约请求处理伪代码 bool reserveSpot(int vehicle_id, int spot_id) { if (spots[spot_id].isReserved()) { return false; // 冲突检测 } spots[spot_id].setTempReservation(vehicle_id); if (checkAllManagersConsistent()) { spots[spot_id].confirmReservation(); return true; } spots[spot_id].clearReservation(); return false; }3. 系统部署与性能优化
3.1 分布式部署方案
实验采用三主机配置：
主机1（ROG笔记本）：
- 运行仿真环境(AWSIM Labs)
- 托管AVP Managers和U-YOLO模块
- 部署1个Autoware实例
主机2（Nitro PC）：
- 运行第2个Autoware实例
- 处理车辆2的所有自治功能
主机3（Victus笔记本）：
- 运行第3个Autoware实例
- 处理车辆3的所有自治功能
网络配置要点：
- 使用专用5GHz WiFi频段
- 固定IP地址分配
- 启用QoS保证关键话题优先级
3.2 资源消耗实测数据
三主机配置下的资源使用情况：
| 主机 | CPU平均负载 | 内存占用 | 网络延迟 |
|---|---|---|---|
| 主机1 | 72% | 8.2GB | 16.24ms |
| 主机2 | 54% | 6.5GB | 30.42ms |
| 主机3 | 46% | 5.8GB | 22.15ms |
关键发现：
- 仿真环境是资源消耗大户（占主机1 70%CPU）
- Zenoh通信内存占用稳定在200-300MB/节点
- 网络延迟波动主要来自无线信道干扰
3.3 典型问题排查指南
在实际部署中遇到的常见问题及解决方法：
话题同步失败：
- 检查Zenoh路由器是否正常运行
- 验证ROS_NAMESPACE设置是否正确
- 使用
zenoh-bridge-ros2d1 info命令诊断连接
车位检测不稳定：
- 调整摄像头曝光参数
- 在Unity中增加辅助标记点
- 更新YOLOv5模型权重
控制指令延迟：
- 优化Autoware参数：
control: control_period: 0.05 # 将控制周期从默认0.1s改为0.05s predicted_path_resolution: 0.5 # 降低路径预测分辨率 - 启用Zenoh的零拷贝传输模式
- 优化Autoware参数：
4. 局限性与未来改进方向
当前系统存在以下主要限制：
取车功能不完善：
- Autoware的Freespace规划器对非结构化区域支持有限
- 临时解决方案：手动指定取车点坐标
检测泛化能力不足：
- 对非标准车辆（如卡车、摩托车）识别率低
- 改进方向：引入多模态传感器融合
集中式协调瓶颈：
- 管理器节点故障会影响整个系统
- 计划采用RAFT共识算法实现管理器集群
未来重点改进方向包括：
- 集成V2X通信增强环境感知
- 测试真实停车场点云地图支持
- 开发基于强化学习的动态路径规划
经过实际测试，DMV-AVP系统在办公停车场场景（约50个车位）下，可实现3-5辆车的稳定协同泊车，平均泊车时间较人工减少40%。系统代码已开源，为学术界和工业界提供了可扩展的研究平台。