1. 分布式多车自主代客泊车系统概述停车场找车位这件小事相信每个司机都经历过在拥挤的停车场里兜圈子的痛苦。传统的人工代客泊车服务虽然解决了这个问题但成本高昂且难以规模化。随着自动驾驶技术的发展自主代客泊车(Autonomous Valet Parking, AVP)系统应运而生它能让车辆在停车场内自主寻找车位并完成泊车。但单车的AVP系统存在明显局限——当多辆车同时需要泊车时缺乏协同机制可能导致车辆争抢同一个车位或者行驶路线交叉造成拥堵。这就是为什么我们需要分布式多车自主代客泊车系统(Distributed Multi-Vehicle AVP, DMV-AVP)。DMV-AVP的核心创新在于将分布式系统理念引入AVP领域。不同于传统的集中式方案它通过多个独立但协同工作的计算节点来管理车队每个节点负责一辆车的决策和控制。这种架构带来了三个关键优势可扩展性新增车辆只需增加对应的计算节点系统容量几乎可以线性增长容错性单个节点故障不会导致整个系统瘫痪低延迟决策在本地完成避免了集中式系统可能出现的通信延迟2. 系统架构设计解析2.1 整体架构组成DMV-AVP建立在分布式多自动驾驶车辆架构(DMAVA)基础上主要由以下功能容器组成仿真与感知容器运行AWSIM Labs仿真环境包含停车场3D场景建模多辆ego车辆动力学仿真顶部摄像头(RSU)模拟YOLOv5车位检测模块车辆自主容器每个车辆独立一个Autoware自动驾驶栈ROS 2节点(namespaced)AVP节点(负责本车决策)Zenoh通信桥接地图生成容器Lanelet2高精地图生成3D点云地图处理各容器间通过Zenoh进行数据同步架构上实现了计算分离但状态共享的设计理念。2.2 关键技术选型考量Autoware Universe作为基础自动驾驶框架被选中主要因为开源且模块化设计完整覆盖感知-规划-控制全流程原生支持ROS 2 Humble活跃的开发者社区支持Zenoh作为通信中间件相比传统ROS 2通信的优势在于极低延迟(实测30ms)自动话题发现与路由跨主机通信无需复杂配置支持数据持久化和查询YOLOv5用于车位检测的选择依据在Roboflow overhead车辆数据集上mAP0.5达92.3%Python生态完善易于集成支持ONNX格式部署灵活在NVIDIA GPU上可达60FPS3. 核心模块实现细节3.1 多车AVP协调框架(AVP-CF)AVP-CF采用管理者-节点两级架构AVP管理者(集中式)车辆计数管理器维护活跃车辆注册表状态管理器同步各车生命周期状态队列管理器管理下车区的车辆排队预约管理器处理车位分配与冲突解决AVP节点(每车独立) 实现基于有限状态机(FSM)的决策逻辑状态包括等待开始导航至下车区排队处理车位选择与预约泊车执行等待取车取车执行关键设计原则全局状态集中管理局部决策分散执行。这种混合架构在保证一致性的同时避免了完全集中式的单点故障风险。3.2 Unity集成YOLOv5模块(U-YOLO)U-YOLO模块的工作流程图像采集顶部摄像头以15Hz频率捕获1280×720 RGB图像通过ROS 2话题发布原始图像帧车辆检测图像发送至YOLOv5推理服务器(ONNX运行时)使用预训练模型(yolov5s)检测车辆边界框置信度阈值设为0.6NMS阈值0.45车位状态判定预先定义车位多边形区域(使用Lanelet2格式)计算检测框与车位区域的IoU(交并比)IoU0.3判定为占用否则为空闲结果发布通过ROS 2发布包含车位ID和状态的数组Zenoh同步到所有车辆节点# 伪代码车位状态判定逻辑 def check_parking_spot_status(detections, spots): spot_status {} for spot in spots: spot_status[spot.id] available for det in detections: iou calculate_iou(det.bbox, spot.polygon) if iou 0.3: spot_status[spot.id] occupied break return spot_status4. 分布式协同机制实现4.1 车位预约协议为避免多车争抢同一车位设计了基于令牌的预约协议车辆检测到空闲车位后向预约管理器发送预约请求管理器检查该车位当前状态若空闲则分配并广播更新若已被占返回拒绝并建议最近可用车位车辆收到确认后在本地更新车位地图预约有效期持续至车辆完成泊车或显式释放协议实现的关键ROS 2服务接口/avp_manager/reserve_spot(请求预约)/avp_manager/release_spot(释放车位)/avp_manager/query_spots(查询车位状态)4.2 分布式状态同步通过Zenoh实现的同步机制保证各主机状态一致车辆注册新车辆启动时向车辆计数管理器注册分配唯一的vehicle_id和ROS 2命名空间同步当前停车场状态快照定期心跳各AVP节点每500ms发布状态心跳包含位置、速度、当前状态、目标车位状态管理器聚合后广播差异更新冲突解决当检测到状态不一致时(如两车报告预约同一车位)根据车辆优先级(先到先得)进行仲裁强制后请求的车辆重新规划路径5. 实验验证与性能分析5.1 测试环境配置硬件配置主机1ROG游戏本(24GB RAM, RTX 3070)主机2Nitro台式机(24GB RAM, RTX 3060)主机3Victus笔记本(16GB RAM, RTX 3050)软件版本Ubuntu 22.04 LTSROS 2 HumbleAutoware Universe 2023.12Zenoh 0.7.0Docker 24.05.2 关键性能指标通信延迟平均RTT26.06ms(两主机), 30.42ms(三主机)峰值延迟150ms(满足实时性要求)数据包丢失率0.1%资源占用CPU利用率45-75%(取决于主机性能)内存占用每个Autoware实例约4-6GBGPU利用率YOLOv5推理约35%协调性能车位分配成功率100%(无冲突)状态同步延迟100ms从下车到泊车完成平均时间82秒6. 实际部署考量与优化建议6.1 生产环境部署建议网络配置使用专用5GHz WiFi网络或千兆以太网为Zenoh通信配置QoS优先级部署NTP时间同步服务硬件选型每车配备边缘计算设备(NVIDIA Jetson AGX Orin)中央服务器用于运行管理者和仿真环境停车场部署多个摄像头覆盖盲区安全措施ROS 2启用SROS加密通信实现车辆身份认证机制定期更新AI模型防御对抗攻击6.2 常见问题排查指南问题1车辆无法发现可用车位检查YOLOv5服务是否正常运行验证摄像头校准参数是否正确确认车位多边形定义是否准确问题2状态同步延迟高检查网络带宽和延迟优化Zenoh配置(减少冗余数据)考虑降低状态更新频率(如改为1Hz)问题3Autoware规划失败验证Lanelet2地图完整性检查车辆定位是否准确调整规划器参数(如增加采样点)这套系统我们已经在实际停车场测试环境中验证了基本功能下一步计划增加更多现实场景的容错处理比如临时障碍物避让、网络中断恢复等机制。对于想要尝试类似项目的开发者建议先从单车AVP开始逐步扩展到2-3车的协同场景这样更容易定位和解决问题。