无信号灯路口安全预警系统：TTC算法与毫米波雷达实战

简介：针对干线公路与支路交叉口无信号灯场景的PDF论文，聚焦我国干线公路与支路平面交叉口普遍缺少信号灯、视距不足等安全隐患，面向智能交通系统研发人员、交通管理从业者及相关专业学生，提供一套基于雷达检测与无线预警的智能解决方案。资源包内为1个PDF文件，容量约586KB，已有85人浏览学习。该文档系统介绍了主路电子预警标志牌与支路车辆检测预警标志牌的组成原理，包括太阳能供电、LED屏显、无线信号收发、雷达传感器等技术细节，并阐述当支路车辆进入100米范围时触发预警信息、主路屏显“支路来车，减速慢行”的工作流程。文档还结合郑州至登封316快速通道、三门峡灵宝209国道、郑州S314省道等实际应用实例，说明其降低无信号灯交叉口事故率的成效，内容兼具理论分析与落地经验，可作为相关课题研究、系统开发及智慧公路建设的参考文献。

1. 无信号灯交叉口的安全预警，为什么不是加个红绿灯

干线公路与支路交叉口是事故重灾区，尤其是没有信号灯且需要支路让行的地方。干线车速普遍在 80km/h 以上，支路驾驶员在停止线前往往被路侧植被、路灯杆和 A 柱遮挡，等确认干线来车时，剩余反应时间已经不足 1.5 秒。智能预警系统不会替车辆做决定，而是用毫米波雷达和摄像头在 150 米开外持续跟踪目标，预测两车到达潜在碰撞点的时序，提前 4-6 秒通过路侧 LED 屏或车端语音提醒驾驶员。这套系统对交通工程技术人员、物联网开发者和算法工程师有实际落地价值，下面我把感知、冲突计算和发布验证的完整链路拆开。

2. 交通安全智能预警系统的感知选型：雷达与摄像头的互补边界

在建设无信号灯路口的智能预警系统时，最先被质疑的就是“装一个摄像头不就行了吗”。摄像头能看清车辆轮廓，但在夜间或逆光时测距测速都很不稳定，而干线公路的来车速度决定了系统必须准确估计位置和速度。毫米波雷达恰恰擅长测距测速，却分辨不出被遮挡的行人和两轮车。所以成熟方案通常是雷达与摄像头融合，让两种传感器互相补足盲区。

2.1 无信号灯路口传感器选型对照表

下面是基于实际路口常用设备整理的选型表。注意不同厂商型号差异很大，表中是一个相对常见的参数范围。

单目摄像头便宜但深度估计误差在 5% 以上，60 米外误差能到 3 米，对后面计算碰撞时间影响太大。双目摄像头如果做得好的话深度误差还能控制，但需要在路口做立体标定，工程成本不低于一套雷达。所以我的个人经验是：主干道来车检测用雷达加单目摄像头做冗余，支路停止线附近用双目摄像头看行人。

2.2 边缘计算与时间同步，雷达数据转世界坐标系

预警系统的计算不能放到云端，因为一个急刹车场景从检测到发布不允许超过 200ms。我在每个路口放一台边缘计算节点，一般选 NVIDIA Jetson Orin NX，理由是无风扇设计适合室外机箱，支持 PTP 时间同步。如果采购不到，用 i5 工控机加独立 GPU 也可以，但功耗会高一倍。所有传感器通过千兆交换机接入边缘节点，摄像头之间用 PTP 做时间同步，雷达则通过网络时间戳对齐。只有时间同步以后，融合进入预警模块的数据才是有意义的。

雷达输出的是极坐标，而冲突区域是建在世界坐标系里的，所以第一步要做坐标转换。下面是一段极坐标转世界坐标的代码，我在多个路口都用过类似写法：

# radar_to_world.py import math def radar_to_world(radius, azimuth_deg, height_m): """ 将雷达输出的极坐标点转换为路口本地世界坐标。 radius: 目标径向距离，单位米 azimuth_deg: 目标方位角，单位度，雷达正前方为0° height_m: 雷达安装高度，单位米 """ azimuth = math.radians(azimuth_deg) x = radius * math.sin(azimuth) # 以干线行车方向为X轴 y = radius * math.cos(azimuth) z = -height_m # 雷达向下俯视，目标高度为负 return x, y, z

代码逻辑说明：这里假设雷达安装在距地面约 5 米的立杆上，且正面朝向交叉口中心。把极坐标投影到世界坐标系后，X 轴对应干线来车方向，Y 轴对应支路方向。实际标定时我会用角反射器在路口几个固定点实测，再修正每个雷达的安装偏转角。如果不做这一层转换，后续的轨迹预测和冲突区域判断就全都建立在地基不稳的数据上。

实际部署中还要处理一个常见坑：雷达会报告路侧的护栏、树木等静止目标。我的做法是在坐标转换后加一个静止目标滤波，只保留连续 3 帧以上移动距离大于 0.5 米的目标。这一步能砍掉大部分误报，为后面冲突检测减负。

2.3 数据融合后的目标列表结构

时间同步和坐标统一后，下一步是把雷达和摄像头的检测结果关联成同一个目标。雷达提供距离、速度、位置，摄像头提供车辆类别和宽高等信息。融合后的数据我用一个简单的 Python 结构来承载：

# track_target.py from dataclasses import dataclass @dataclass class TrackTarget: target_id: int # 跨帧关联ID obj_type: str # 'car' / 'truck' / 'pedestrian' / 'unknown' x: float # 世界坐标X，单位m y: float # 世界坐标Y，单位m vx: float # 纵向速度，单位m/s vy: float # 横向速度，单位m/s confidence: float # 融合置信度，0.0-1.0 last_update: float # 时间戳，单位秒

参数说明：target_id 由关联算法产生，用于跨帧匹配同一个目标；vx、vy 是融合后的速度分量，雷达测得的径向速度会被投影到两条轴上；confidence 低于 0.3 的目标不会进入预警模块。如果只有雷达而没有摄像头，obj_type 会标记为 unknown，但速度和位置仍然可信，可以参与冲突计算。我在现场调试时，最常做的一件事就是把这块数据通过 Web 页面实时打印出来，观察某个目标 ID 是否在连续帧里漂移，一旦发生漂移就说明前后帧关联没有匹配好。

感知层的输出是每一个目标的轨迹，这些轨迹就是下一章冲突检测的原料。

3. 冲突检测算法：TTC 计算与分级预警的落地实现

感知层把路口变成了一组带时间戳的位置速度记录，接下来要回答最核心的问题：支路车和干线车会不会在同一个时间出现在同一个位置。这里我习惯用 TTC（Time to Collision，碰撞时间）来衡量，它比直接测车距更能反映真实危险程度。

3.1 冲突区与车辆状态怎么建模

我通常会在路侧地图上手工标注一个矩形冲突区，覆盖支路车穿越干线时最可能占用的区域。这个矩形不需要很大，一般取 3 米乘 3 米到 5 米乘 5 米，具体取决于最宽车道宽度。每个目标维护一个状态向量：

# state_vector.py state = { "x": 0.0, # 世界坐标X "y": 0.0, # 世界坐标Y "vx": 0.0, # 纵向速度m/s "vy": 0.0, # 横向速度m/s "ax": 0.0, # 纵向加速度m/s2 "ay": 0.0 # 横向加速度m/s2 }

如果加速度值为 0，就用匀速度模型外推未来位置；如果加速度来自雷达多帧速度差分，就用匀加速模型。实际路口上，驾驶员在接近停止线时加速度变化快，所以我只预测未来 3 到 5 秒，超过这个窗口的预测值有很强的不确定性，不建议直接用于报警。

3.2 TTC 计算公式与分级阈值

TTC 在这里定义成两车分别到达冲突区时间差的绝对值，时间差越小，风险越高。实际计算中，还要考虑支路车辆是否已经减速到接近停止，如果是，说明驾驶员在做让行决策，系统可以降低一级报警。下面是常用的分级阈值：

这些阈值不是拍脑袋定的。限速 80km/h 的干线公路，每秒钟车辆前进约 22 米，7 秒对应 150 米，正好匹配雷达检测距离的可靠范围。路口限速越低，一级阈值可以收缩到 5 秒左右，但二级和三级阈值最好不要低于 2.5 秒，否则驾驶员来不及做出有效反应。

3.3 用 Python 跑通一个最小可测试的冲突预警

理解 TTC 最好的方式是写一段可以运行的最小代码。下面模拟一辆干线车和一辆支路车，计算它们到达冲突区的时间差：

# ttc_demo.py import math class ConflictZone: def __init__(self, center_x, center_y, radius=3.0): self.center_x = center_x self.center_y = center_y self.radius = radius def distance_to_vehicle(self, x, y): return math.hypot(x - self.center_x, y - self.center_y) class VehicleTrack: def __init__(self, x, y, vx, vy): self.x = x self.y = y self.vx = vx self.vy = vy def time_to_reach(self, zone, max_horizon=10.0): # 到冲突区中心的向量 dx = zone.center_x - self.x dy = zone.center_y - self.y speed = math.hypot(self.vx, self.vy) if speed < 0.1: return float('inf') # 静止目标视为不会到达 # 距离向量在速度方向上的投影 dot = (dx * self.vx + dy * self.vy) / speed distance = max(0.0, dot - zone.radius) ttc = distance / speed return ttc if ttc < max_horizon else float('inf') def judge_risk(t_trunk, t_branch): delta_t = abs(t_trunk - t_branch) if delta_t < 2.8: return "三级（紧急）" elif delta_t < 4.5: return "二级（警告）" elif delta_t < 7.0: return "一级（提示）" else: return "无风险" # 场景：干线车距冲突区中心50m，速度22m/s；支路车距冲突区20m，速度6m/s zone = ConflictZone(0, 0) trunk = VehicleTrack(50, 0, 22, 0) branch = VehicleTrack(0, 20, 0, -6) t1 = trunk.time_to_reach(zone) t2 = branch.time_to_reach(zone) print(f"干线车到达时间={t1:.1f}s, 支路车到达时间={t2:.1f}s") print(judge_risk(t1, t2))

代码逻辑说明：这里用当前位置到冲突区中心的距离沿速度向量的投影来估算到达时间，并减掉冲突区半径作为安全余量。如果车辆已经停住，时间返回无穷大，系统会判定为让行状态，不会误报。实际工程中不能只靠绝对时间差，还需要增加状态判断：支路车速度低于 0.5m/s 且持续 2 秒以上时，即使 TTC 很小也只提示，不触发紧急报警，因为驾驶员的意图已经很明显是在让行。

这个最小示例能验证整个链路是否打通。替换成真实的雷达数据和融合模块，就能立刻看到 TTC 曲线。现场调参时，我在这个函数后面加过日志，记录每一帧的 TTC 和车辆 ID，再和人工录下的事故现场交叉验证，这样比较容易找出阈值调的过紧还是过松。

4. 预警发布与通信链路：从路侧屏到车端的实时分发

预警判定只是算法，真正让驾驶员看到需要一条吞吐量不大但时延极低的链路。这里不需要在路口部署 5G 基站，而是在一台边缘节点上把消息同时挂载给多个出口。我一般避免经过云端，因为网络抖动在高峰期能达到几百毫秒，足以让一次预警从提前 5 秒变成提前 2 秒，意义就完全不同了。

4.1 在边缘节点上本地发布预警消息

最常见的做法是边缘计算节点上运行一个本地 MQTT Broker（mosquitto），预警判定程序将消息发布到主题road/safety/alert。路侧屏程序和车端接收程序各自订阅这个主题，实现一对多的分发。发布端代码：

# alert_publisher.py import paho.mqtt.client as mqtt import json broker_host = "127.0.0.1" broker_port = 1883 topic = "road/safety/alert" client = mqtt.Client(client_id="edge_alert", protocol=mqtt.MQTTv311) client.connect(broker_host, broker_port, keepalive=30) msg = { "timestamp": "2025-01-01T08:00:00.123Z", "zone_id": "QY-K01", "risk_level": 2, "ttc": 3.2, "branch_lane": "B01", "trunk_velocity_kmh": 72 } client.publish(topic, json.dumps(msg), qos=1) client.disconnect()

代码逻辑说明：预警判定程序把风险等级、TTC 和所在车道编码成 JSON，通过 MQTT 发布到本地 Broker，区域内的所有订阅端同时收到。使用 QoS=1 保证至少送达一次，防止 LED 屏漏报。参数说明：keepalive=30 是心跳间隔，超过 30 秒没有任何消息 Broker 会断开连接；生产环境建议加账号密码认证，否则局域网里其他设备也能订阅到这个预警消息。

4.2 消息字段与 V2X 扩展方向

消息字段设计得越简单越好，方便后续扩展。实际使用中我倾向于以下字段：

如果路口已经部署了 RSU 和 OBU，可以将 risk_level 和 ttc 映射到 C-V2X 的 BSM 消息里。但大多数一期工程只做 LED 屏提示和声光报警，没必要把消息链拉得太长。等到车端渗透率提高以后，再增加一条到 RSU 的 UDP 转发即可。

4.3 路侧 LED 屏与声光报警的解耦设计

预警订阅端的代码要尽量轻，避免阻塞在网络请求上。我写过一个很简单的订阅函数：

# alert_subscriber.py def on_message(client, userdata, msg): alert = json.loads(msg.payload) if alert["risk_level"] >= 2: led_display.show(alert["branch_lane"] + "注意来车") sound_alarm.trigger() elif alert["risk_level"] == 1: led_display.show("注意观察") else: led_display.clear()

逻辑说明：这里把显示和控制逻辑拿到 MQTT 回调里，任务本身很轻，不会阻塞主循环。声光报警器用的是独立 GPIO 或继电器，即使 LED 屏出现花屏，报警器仍然能触发。这样设计的好处是排障时段分明：看 MQTT 里有没有消息，就知道是感知端问题还是显示屏端问题，不用两头猜。

5. 无信号灯智能预警系统现场调参的 3 个关键技巧

系统原型在办公室跑通只是第一步，到了干线公路路口才能发现真实世界的麻烦。我在几个路口踩过坑以后，总结出三个最关键的动作：先标安装，再录像回放，最后用日志做统计验收。

5.1 安装位置与 ROI 区域先于算法优化

雷达和摄像头的安装位置决定了一半的预警质量。我的常用参数是：雷达安装高度 5-6 米，向下倾斜 2-3 度，避免直接看到路面上的金属护栏；摄像头与雷达安装在同杆，视野覆盖停止线和冲突区。安装后第一时间配置 ROI 区域，把路侧树木、波形护栏等干扰区域从检测区里划掉。这一步如果不做，后面调 TTC 阈值会非常痛苦，因为大量非车辆目标会进入预警模块。

5.2 用录像回放而不是连续调优来做阈值修正

现场实时调参很容易被偶然出现的大货车或行人带偏，我的做法是架设一台录像机，连续录制 2-3 个小时，然后在办公室回放轨迹数据，离线调整冲突区域和 TTC 阈值。这样每次改动都可以在同一段数据上做 A/B 对比，不会因为时间不同导致的交通流差异而误判效果。

5.3 用一个统计脚本验收触发率与误报率

系统调好后，不能只靠感觉验收。我一般把预警日志按天导出，人工标记其中真正有效的预警和虚假预警，再写一个脚本统计。比如统计某段时间内 120 次报警中有 11 次误报，那么准确率就是 90.8%，漏掉一次真实冲突，漏报率就是 0.8%。只有当误报率低于 10% 且漏报率低于 1% 时，才敢把系统正式交给路管部门评估。这个脚本也可以用简单的 shell 命令计算，但我更推荐直接读日志用 Python 生成日报表，字段包含时间、等级、TTC、视频帧号和人工判定结果。这样得出的统计值就可以作为系统验收的数据基础。

本文还有配套的精品资源，点击获取