Apollo自动驾驶项目中Occupancy网络输出未接入规划模块的技术解析

概述

在Apollo 10版本中，BEVFORMER障碍物检测器的Occupancy网络输出结果仅被保存为本地二进制文件，而未被传递至规划模块。这一技术实现细节引起了开发者社区的关注，本文将深入分析当前实现的技术背景、潜在影响以及未来可能的改进方向。

当前实现分析

在bevformer_obstacle_detector.cc文件中，GetOccResults()函数的主要功能是处理Occupancy网络的输出结果，但存在以下技术特点：

1. 数据处理流程：

   • 对每个体素(voxel)进行类别概率分析
   • 筛选超过阈值的有效体素点
   • 统计有效体素数量并记录日志

2. 输出方式：

   • 结果仅被保存到本地二进制文件
   • 文件路径由配置参数occ_save_path指定
   • 文件名使用时间戳作为标识

3. 缺失功能：

   • 未将处理结果存入frame_ptr_->detected_objects
   • 未通过消息机制向下游模块传递

技术背景与考量

这种实现方式反映了Apollo团队在Occupancy网络集成方面的阶段性决策：

1. 离线验证优先：当前实现更侧重于结果的可视化和离线分析，便于算法验证和调优
2. 系统集成复杂度：Occupancy网络输出与传统障碍物检测结果在数据结构上存在差异
3. 性能考量：大规模体素数据的实时传输可能带来性能挑战

潜在影响

这种实现方式对系统功能的影响包括：

1. 规划模块限制：规划算法无法直接利用Occupancy网络提供的环境感知信息
2. 系统功能割裂：虽然检测结果被保存，但无法形成完整的感知-规划闭环
3. 实时性损失：离线处理方式无法满足自动驾驶对实时性的严格要求

未来改进方向

根据技术讨论，Apollo团队可能考虑以下改进方案：

1. 点云聚类方案：

   • 将Occupancy检测结果转换为点云表示
   • 通过聚类算法生成背景障碍物信息
   • 与传统障碍物检测结果融合后传递至规划模块

2. 端到端集成方案：

   • 设计专门的消息类型承载Occupancy网络输出
   • 优化数据传输协议，确保实时性
   • 在规划模块中直接解析和使用Occupancy信息

3. 混合方案：

   • 保留离线保存功能用于调试
   • 同时实现实时数据传输通道
   • 根据应用场景灵活切换

技术建议

对于希望提前使用Occupancy网络结果的开发者，可考虑以下技术路线：

1. 自定义数据转发：

   • 修改GetOccResults()函数，增加结果转发逻辑
   • 设计适当的数据结构封装体素信息
   • 通过现有消息通道或新建专用通道传递数据

2. 结果后处理：

   • 监控保存的二进制文件变化
   • 实现文件监听和实时加载机制
   • 将加载的数据转换为规划模块可用的格式

3. 性能优化：

   • 对体素数据进行压缩或降采样
   • 采用共享内存等高效IPC机制
   • 实现数据差分更新减少传输量

总结

Apollo 10中Occupancy网络输出的当前处理方式反映了自动驾驶系统开发中的典型权衡：算法验证与系统集成的阶段性侧重。随着Occupancy检测技术的成熟，预计Apollo团队将逐步完善其与规划模块的集成方案。开发者社区可关注后续版本更新，或基于现有实现进行定制化扩展以满足特定需求。