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-20ms8-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 分布式部署方案实验采用三主机配置主机1ROG笔记本运行仿真环境(AWSIM Labs)托管AVP Managers和U-YOLO模块部署1个Autoware实例主机2Nitro PC运行第2个Autoware实例处理车辆2的所有自治功能主机3Victus笔记本运行第3个Autoware实例处理车辆3的所有自治功能网络配置要点使用专用5GHz WiFi频段固定IP地址分配启用QoS保证关键话题优先级3.2 资源消耗实测数据三主机配置下的资源使用情况主机CPU平均负载内存占用网络延迟主机172%8.2GB16.24ms主机254%6.5GB30.42ms主机346%5.8GB22.15ms关键发现仿真环境是资源消耗大户占主机1 70%CPUZenoh通信内存占用稳定在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的零拷贝传输模式4. 局限性与未来改进方向当前系统存在以下主要限制取车功能不完善Autoware的Freespace规划器对非结构化区域支持有限临时解决方案手动指定取车点坐标检测泛化能力不足对非标准车辆如卡车、摩托车识别率低改进方向引入多模态传感器融合集中式协调瓶颈管理器节点故障会影响整个系统计划采用RAFT共识算法实现管理器集群未来重点改进方向包括集成V2X通信增强环境感知测试真实停车场点云地图支持开发基于强化学习的动态路径规划经过实际测试DMV-AVP系统在办公停车场场景约50个车位下可实现3-5辆车的稳定协同泊车平均泊车时间较人工减少40%。系统代码已开源为学术界和工业界提供了可扩展的研究平台。