自动驾驶 Apollo 源码分析系列，感知篇(三)：红绿灯检测和识别

人在驾驶过程中会注意红绿灯的信息，而自动驾驶更离不开红绿灯信息，有了红绿灯信息，自动驾驶车辆才能更好地与车路进行交互。本篇分析 Apollo 6.0 中红绿灯检测和识别中的相关算法逻辑及部分代码实现。

先看感知架构图。

Apollo 中的红绿灯

Apollo 默认有 2 个前视摄像头：

• 25mm 焦距看远处，视距长，但 FOV 小。
• 6mm 焦距看近处，视距短，但 FOV 大。

两个摄像头都可以检测到红绿灯，它们相互冗余，但是同一时刻只能以一个为主。

Apollo gitee 仓库图示

Apollo gitee 仓库图示

上面的图片是来自于长焦相机，能看得很远，但视野窄，下面的正好相反。

Apollo 红绿灯模块定义了红绿灯 5 种状态：

• 红
• 黄
• 绿
• 黑
• 未知

算法流程

在 Apollo 中红绿灯模块有一套固定的处理流程：

1. 预处理阶段
2. 处理阶段

预处理阶段-信号灯投影

预处理阶段第一个任务就是要根据车辆定位信息从高精度地图中查询红绿灯的物理信息，得到信号灯的物理坐标，然后再通过相机模型和标定好的相机内参，将信号灯从 3D 世界中投影到 2D 图像当中变成一个 Bounding Box。

信号灯的物理位置信息长这样：

signal info:
id {
  id: "xxx"
}
boundary {
  point { x: ...  y: ...  z: ...  }
  point { x: ...  y: ...  z: ...  }
  point { x: ...  y: ...  z: ...  }
  point { x: ...  y: ...  z: ...  }
}

预处理阶段-相机选择

前面讲到有 2 个相机，那么选用哪个呢？

优先选择长焦的相机，因为长焦能将远处的信号灯显示的比较大且清晰，容易做颜色识别。

什么时候选择短焦呢？

当长焦没有办法检测到所有红绿灯的时候。

同一个算法处理周期，只有一个摄像头的图片才能够进行处理。

预处理阶段-图片信息及缓存同步

在自动驾驶中，因为考虑到车辆行驶速度很快，因此障碍物的识别一般要求实时，也就是 30FPS 以上。

但相对于障碍物，红绿灯的位置信息没有那么重要，重要的是它的语义信息，也就是红绿颜色变化，但这种频率是非常低的，所以对于红绿灯检测而言，我们不需要那么高的频率，也因此不需要针对每一帧图片都做红绿灯处理。

因此，我们可以隔一个固定的时间周期去查询高精度地图中的红绿灯信息，然后选择最近的图片缓存一起送入到红绿灯处理模型当中，其它的图片就可以丢掉了。

处理阶段-修整(Rectifier)

预处理会产生一张图片和对应的红绿灯信息(2D bbox)，但因为误差问题，2D bbox 和实际上观察到的红绿灯是有偏差的，甚至很大，所以要基于 bbox 设置一个 ROI 区域。

将带有 ROI 信息的图片传输给一个 CNN 做检测，最终会输出一系列的信号灯结果。

处理阶段-识别(Recognizer)

检测是为了估算位置，而识别是要分辨信号灯的颜色。

将 ROI 和信号灯结果连同图像输入给一个 CNN，这个 CNN 就会给出信号灯的颜色信息。

预处理阶段-修正(Revisor)

因为交通灯都会闪烁，所以前一个流程的结果可能不准确，因此需要结合历史信息进行推断。

比如，收到的信号是绿或者红，那么直接输出。

如果是黑色，或者是未知状态，就要根据历史缓存进行推断，如果前面的状态不是黑色或者未知就输出历史状态，否则输出黑色或者未知。

并且，黄灯只能在绿色和红色之间，如果顺序不对就会被丢弃。

上面的内容来自于 Apollo Gitee 仓库的说明，很明显红绿灯识别是个多阶段任务。

我一直在想能不能用端到端的模型一步到位呢？

比如用 LSTM 直接输出最终的结果？

这个需要尝试一下。

理论知识讲解完后，就要开始在代码层面验证了。

参考

1. https://gitee.com/ApolloAuto/apollo/blob/master/docs/specs/traffic_light.md