防爆胶轮车在采区巷道里倒车,采煤机在端头调向,支架搬运车驮着重物转弯——这几个场景放在地面上都不算太复杂,到了井下就完全是另一回事。巷道本身窄,装备自身体积大、盲区多,司机往往只能靠后视镜和经验判断周边有没有人。我参与过几个矿用装备智能化改造项目,最早团队也试过"装个摄像头+AI识别"的简单思路,结果井下跑了一圈回来全都得重新想。粉尘、水雾、低照度、电磁干扰,这套组合拳打下来,单一传感器几乎没有能全身而退的。
所以后来我们做了一套基于多传感器融合的井下装备周边人员碰撞预警系统,把视觉、毫米波雷达、UWB定位、热成像几个来源的数据揉在一起,才总算把检测可靠性和误报率压到可接受的范围。这篇东西主要把这些年从方案设计、传感器选型、空间标定、算法融合,到井下安装实测的完整过程整理出来,既是一份技术参考,也是一份踩坑记录。煤炭、非煤矿山做装备智能化、做安全监控的同行,以及准备往这个方向立项的团队,应该都能用得上。
1. 井下装备碰撞事故的根源与现状
在展开多传感器融合方案之前,得先把"为什么井下碰撞事故这么难防"这个问题掰扯清楚。很多人觉得,装备上加个声光报警器或者装个摄像头不就行了?市面上同类产品也不少,但真正的坎儿在于需求端面临的复杂度,远超地面开放场景。
1.1 作业环境的固有危险因素
井下空间是一个高度受限的三维环境,装备和人员的活动轨迹天然就是交叉的。采掘工作面附近的巷道宽度往往只有4到5米,一台采煤机或者支架搬运车开过去,剩余的空间可能就够一两个人侧身贴着帮站,行人避让装备的余地非常有限。司机坐在驾驶室里,车头车尾有几个关键的视觉盲区,车越大盲区越大,很多碰撞事故本质上是司机根本没看到人。
更麻烦的是,井下这个环境对"感知"这件事处处不友好。巷道照明是分段布置的,灯光照不到的地方就靠头灯,整体照度远低于室内标准;空气中常年飘着煤尘和水雾,能见度忽好忽坏;有些采区噪声大到面对面喊话都听不清,声光报警在嘈杂环境下很容易被忽略。这些因素叠加起来,意味着任何一种检测手段,都必须先跟恶劣的物理环境作斗争,才有资格谈检测精度。
1.2 常规防护手段的短板
目前矿井里最常见的防护手段是人工指挥和声光报警。工作面端头作业时安排一个专职人员打手势、吹哨子引导车辆,这确实能挡住一部分事故,但问题也很明显:指挥人员本身也在盲区范围里,指挥动作和司机操作之间的时间配合一旦出错,反而容易出问题;长时间作业注意力下降,更是人之常情。
声光报警装置的问题在于它只解决了"提醒"环节,没有解决"发现"环节。蜂鸣器再响、爆闪灯再亮,前提是司机和周边人员都能收到信号、来得及反应。至于安装摄像头的方案,很多矿井布了几十路视频,最后还是靠调度员盯屏幕。人盯屏这件事的疲劳曲线我实测过,进入状态之后大概15分钟就会开始漏看,这不是责任心问题,是人类注意力的物理极限。
这些短板背后的本质,是缺少一个"不依赖人的主观状态、能在危险接近前主动给出可靠判断"的自动化感知环节。碰撞预警要做到的不是替代司机,而是在司机判断之前先把风险看出来。
2. 单一传感器的能力边界:谁也无法独挑大梁
方案设计阶段,我们把市面上能用的感知传感器挨个过了一遍,结论很直接:单靠任何一种传感器,在井下环境下都有致命的短板。这不是某个品牌的问题,是传感器物理原理和矿山环境之间的结构性矛盾。
2.1 视觉检测:白光环境下好用,井下直接"近视"
摄像头+AI目标检测是最先被考虑的方案,毕竟这几年YOLO系列算法成熟度很高,地面上行人检测效果确实不错。但井下光照分布极不均匀,巷道里一段亮一段暗,摄像头为了照顾暗区就得提高曝光,亮区就过曝;反过来说,井下作业面通常有强烈的局部光源,车灯、头灯、矿灯直射过来,逆光下的行人几乎是一团黑影。
粉尘和水雾对视觉的影响更是要命的。煤尘附着在镜头表面,哪怕是一层薄薄的灰,图像分辨率就肉眼可见地掉档。我们在地面测试时检测率能做到95%以上的模型,搬到井下粉尘环境里直接掉到80%出头,这还没算夜间无照明路段的情况。视觉传感器的另一个隐性成本是清洁维护,井下摄像头需要定期擦镜头,不然报警质量持续劣化,很多矿一开始兴致冲冲,后期连擦镜头的人员都排不出来。
2.2 毫米波雷达:知识盲区少,但巷道里全是"回声"
毫米波雷达是防碰撞领域的老兵,不受光照影响,对距离和速度的测量非常直接。它在井下有个老大难问题——多径效应。井下巷道是金属支护结构,顶板、帮壁、设备表面到处是金属反射面,雷达发射的电磁波会在这些表面之间来回反射,产生大量虚假回波。很多时候雷达屏幕上会出现"幽灵目标",明明前方没人,显示距离3米处有个反弹点;转过头真有人了,目标反而被淹没在杂波里。
另外,人体对毫米波雷达来说算"弱反射目标",尤其穿普通工装的矿工,雷达散射截面比金属设备小得多,探测距离和稳定性都受限。我们实测中,普通行人目标在干净环境下能被雷达稳定跟踪的距离约30米,到了井下金属支护密集的巷道里,有效跟踪距离可能砍掉一半,还伴随着间歇性丢点。
2.3 激光雷达、热成像、UWB各有苦衷
激光雷达的测距精度高、点云密度大,但粉尘和水雾对激光的衰减非常明显,几级浓度一上来,点云就开始"发糊"。热成像的原理是探测温差,能在完全无光的环境里看到人体热源,这本来很诱人,但井下底板、机械设备、电缆都会发热,热背景杂乱,人员识别要靠算法仔细抠特征;再加上防爆热成像模组成本偏高,批量部署的压力不小。UWB定位则完全是另一个思路:要给人员佩戴标签才能定位,外来的无关人员没戴标签就检测不到,而且它只能告诉系统"人在哪个位置",无法判断这个人面对的还是背对装备、处于什么姿态。
2.4 单传感器能力对比:没有一科全优
| 传感器类型 | 优势 | 井下主要短板 | 适合承担的融合角色 |
|---|---|---|---|
| 可见光摄像头 | 纹理细节丰富,可分类识别 | 低照度、粉尘遮挡、逆光 | 目标分类,身份确认 |
| 毫米波雷达 | 全天候测距测速,穿透粉尘 | 多径虚警,人体弱反射 | 距离、速度的核心测量 |
| 激光雷达 | 高精度测距,点云直观 | 粉尘衰减严重 | 近距离高精度复核 |
| 红外热成像 | 无光可见,识别热源 | 热背景杂乱,成本高 | 弱光/粉尘条件下的备份检测 |
| UWB标签定位 | 位置精确,坐标可直接用 | 依赖佩戴,无法识别未佩戴人员 | 已知人员位置校正 |
所以"多传感器融合"不是赶时髦,是这个场景下的必然选择。核心矛盾在于:每种传感器在某个维度上都有可靠的一面,在场景的另一个维度上又都不可靠,只有把互补信息叠加起来,才能得出一个足够可信的结论。
3. 多传感器融合的整体架构与传感器配置
明确了"必须融合"之后,紧接着的问题就是怎么搭这个系统。我们最后采用的分层逻辑很朴素:感知层各干各的,决策层统一仲裁。整套系统用一句话概括就是——把每一种传感器当成一个"专家委员",每个委员基于自身物理原理解读环境,融合层负责综合各委员的意见,在冲突时决定听谁的。
3.1 系统分层:感知、标定、融合、决策、执行
整个预警系统分为五层:
- 感知层:摄像头、毫米波雷达、UWB基站/标签、可选的热成像模组,各传感器独立采集原始数据。
- 标定层:解决传感器之间的"坐标系对齐"和"时钟对齐"问题,这是融合的数据基础。
- 融合层:将视觉目标、雷达点云、UWB坐标等异构数据关联到同一个物理目标上,形成统一的对象列表。
- 决策层:基于统一目标列表计算碰撞风险,输出分级报警或联动指令。
- 执行层:声光报警器、显示屏、车载控制器联动,必要时执行减速或停车。
这个分层的意义在于解耦。传感器品牌、型号可以后续替换,只要感知层输出的数据格式不变,融合和决策就不用重写。项目后期我们换过一版性能更好的雷达,融合层代码一行没改,这就是分层架构的收益。
3.2 传感器组合怎么定:主力、辅助与备份
传感器配置不用贪多,关键是角色定义清楚。我们最终的主力组合是"可见光摄像头+毫米波雷达",摄像头干识别、雷达干测距,两者互为校验。热成像作为无光场景的备份检测,UWB作为已知人员的实时位置基准。这个组合覆盖了井下最常见的三类风险场景:有光条件下的行人识别、粉尘/无光条件下的人体探测、已知人员精确定位。
选型时有几个容易被忽略的细节。第一,摄像头的镜头视场角要跟雷达的方位角范围匹配,否则目标出了雷达视野、只剩视觉数据,融合就没意义了;第二,雷达的探测仰角不能只盯着地面,井下有些人员从侧帮或者高处平台经过,垂直视场角买小了,目标直接从扫描平面外面溜过去;第三,UWB基站的布局要避免跟金属支护柱体太近,否则定位误差会从0.3米量级恶化到1米以上。
3.3 空间标定:把不同坐标系拧成一股绳
多传感器融合的第一步是外参标定。摄像头输出的像素坐标、毫米波雷达输出的极坐标、UWB输出的世界坐标,本质上都是对同一个物理空间的"不同语言描述",空间标定的任务就是建立这些语言之间的翻译关系。
摄像头和雷达的联合标定,常用方法是在车辆前方布置若干角反射器和标定板,同时采集雷达回波和图像,找到同一目标在两个坐标系下的对应点,然后求解旋转矩阵R和平移向量t。这一步看着简单,实际在井下做有特殊的麻烦:巷道空间太窄,标定场景架不开,我们最后是在井上检修车间完成初标,下井安装后再用车体上固定的两个基准反光板做微调校验。
标定结果要保存成参数文件,并且每次设备维护后复查一遍。我见过有项目用了半年后报警位置持续偏了20多厘米,查来查去是安装支架螺栓松动导致传感器角度变化,重新标定后立即恢复,教训就是标定不是一次性工作,要纳入定期维护项。
3.4 时间同步:毫秒级偏差带来的连锁误差
空间对齐之外,时间同步是另一个基础难点。视觉每秒25帧到30帧,雷达每秒10帧到20帧,UWB标签刷新又是另外一个频率,三个传感器各自按自己的节拍输出数据。假如不对齐时间,融合层看到的"当前时刻"实际上是三个不同时刻的快照——以20公里/小时行驶的装备,0.1秒时间差异对应的目标位置偏差就有0.5米以上。
工程上常见两种方案:硬同步和软同步。硬同步通过信号线触发所有传感器同一时刻采样,精度最高,但对设备硬件有要求。软同步则是给每帧数据打上时间戳,融合时通过插值算法把各传感器数据对齐到同一个时刻。我们在项目中选用了软同步,用PTP协议同步系统时钟,实测时间偏差控制在10毫秒以内。对碰撞预警这个量级完全够用,一个是省去了定制触发行,二是传感器型号更换时不用改线。
4. 融合算法从检测到决策的完整链路
架构搭好了,传感器数据接进来了,接下来的核心问题是算法。这个部分我按检测、关联、融合、决策四步走来讲,每一步都有对应的工程选择逻辑。
4.1 视觉检测:在低照度上调优模型的实用路线
视觉通道的目标检测主干直接采用轻量化的YOLO系列,骨干网络在井下低照度场景做了专门微调。一个非常实用的做法是:不直接用公开数据集训练完的权重,而是先采集目标矿井的真实图像,标注"戴安全帽的人员"和"穿反光衣的人员"两类样本,再结合公开行人数据集做迁移学习。井下人员和地面行人外观差异明显,反光衣在强光下的光晕、安全帽的形态,单靠通用模型识别效果会打折扣。
低照度处理上,最简单有效的方法不是堆图像增强算法,而是给摄像头配一个宽动态功能,避免车灯直射导致人物过曝。如果夜间或粉尘条件下图像质量确实不行,就把视觉通道的置信度调低,把判断权更多让渡给雷达——这个思路对降低整体误报率很关键,后面第五节还会展开说。
4.2 雷达通道:从杂波里把人抠出来
毫米波雷达数据处理的第一步是恒虚警率检测(CFAR),把超过背景杂波强度的回波点挑出来。井下环境杂波强烈,CFAR的阈值设置直接影响虚警率。第二步是聚类,把同一个目标的多个回波点聚成一簇,DBSCAN这类基于密度的聚类算法在井下数据上比固定网格法稳定得多,因为它能适应目标距离变化带来的点密度变化。
雷达的优势在于能直接给出目标的径向速度和距离。这个信息对碰撞风险判断极有价值:目标距离20米,相对速度5米/秒,跟目标距离20米、相对速度0,危险等级完全不同。视觉很难直接算出径向速度,雷达则是天然自带这个参数。
4.3 目标关联与跟踪:别把一个人认成三个人
同一时刻视觉目标、雷达目标、UWB目标可能各有各的列表,融合层的第一个任务是判断哪些条目指向同一个物理目标,这一步在目标检测里称为数据关联。常见做法是用匈牙利算法解决匹配问题,把"视觉框的中心点+雷达的距离角度+UWB的坐标"统一投影到车辆坐标系下,两两计算距离代价矩阵,代价最小且低于阈值的条目合并成同一个目标。
匹配完成后,用卡尔曼滤波对目标的位置和速度做平滑预测。这样做有两个实际收益:一是目标框不再忽大忽小,报警状态更稳定;二是短时间某一传感器丢帧时,滤波器可以根据历史状态预测位置,不至于报警状态频繁闪断。测试里有个很有趣的现象:加了跟踪滤波之后,一个行人从车前方横穿时,报警连续性从"时断时续"变成了"持续有效",因为单帧偶尔识别失败被滤波器自动修正了。
4.4 决策级融合与分级报警:什么时候报,报了怎么报
决策逻辑上我们采用了"置信度+区域"双要素模型。每个融合后的目标先计算一个综合置信度,来源包括视觉识别分数、雷达回波强度、目标跟踪帧数;然后判断目标所处的风险区域——装备周围划分为两个区域:警示区(距离15到6米)和危险区(距离6米以内)。目标进入危险区且综合置信度超过阈值,触发一级报警,声光报警器启动;接近速度高时,触发联动减速信号。
报警阈值怎么确定是个精细活。阈值太高会漏报,阈值太低会整天误报,司机被闹得麻木之后反而把报警当背景音。我们调试时使用的一个经验法则是:现场的虚警容忍度,取决于误报方式。停车误报比减速误报严重得多,所以停车指令的判定条件比普通报警苛刻得多,要求目标连续3帧以上都处于危险区且置信度持续高于高阈值,宁可多给驾驶员0.3秒的反应时间,也不能因为单帧瞬时误判让装备在巷道里急停。
5. 井下实测中的典型问题与排查链路
再好的设计进了现场都会原形毕露。这一章写的是我们在井下安装实测阶段碰到的几个典型问题,按完整的排查链路来还原,希望能帮后来的人少走一些弯路。
5.1 金属支护引发的虚警风暴:从调阈值到区域屏蔽
第一台样机下井测试时,雷达通道几乎每隔一两分钟就报一次警,报警位置集中在巷道侧帮。打开原始点云一看,密密麻麻的反射点分布在两帮,典型的金属支护多径反射。一开始我们尝试提高CFAR阈值,虚警确实少了,但远处真人目标也跟着丢了,此消彼长,明显是方向错了。
排查路径是逐步收敛的:先把目标从点云聚类层面区分成"静止目标"和"动态目标",金属支护是静止的,人员一般带有移动特征,把静止目标直接过滤掉,虚警率立刻降了一多半。剩下的一部分静止目标偶尔因为装备自身运动产生微多普勒,会短暂被识别为动态,于是再引入"区域屏蔽"——在车的坐标系里标定出巷道两帮的固定区域,这些区域的报警直接抑制。两道措施叠加后,误报降到平均每小时1到2次,可以进下一步测试了。
同行如果遇到类似虚警,建议按这个顺序排查:先看回波是否来自静止目标,再看是否位于已知结构区域,最后才考虑动阈值,不要一上来就动全局参数。
5.2 粉尘遮挡视觉时,雷达如何兜底:融合的胜负手
有一次在掘进巷道测试,前方有掘进机作业,粉尘浓度大,摄像头画面几乎一片灰。视觉通道检测率掉到六成以下,单独用视觉根本没法用。但整个系统在融合状态下报警功能依然稳定,原因是雷达通道在这种场景下几乎不受影响,CFAR照常工作,人的回波虽然弱但还在。
这给了我们一个明确的设计原则:融合系统必须能够在主传感器失灵时"降级工作",而不是直接瘫痪。工程实现上就是给每个融合目标记录"证据来源组合"。目标同时有视觉和雷达证据时,置信度最高;只剩雷达证据时,置信度下调但仍可触发报警;只剩视觉证据时,因为缺少测距信息,只触发提示不触发联动。这个分级设计的意义在于,系统的失效模式是"性能下降"而不是"彻底失效"。
5.3 标定漂移:振动环境下传感器"慢慢跑偏"
前面提到过标定要定期复查,这个问题的触发来自一次真实故障。项目运行两个月后,调度反馈某辆车报出的目标距离总是偏远,比如屏幕上显示3米,现场实际大概2米5。当时怀疑是雷达本身精度问题,换了雷达后依旧,最后检查到摄像头的安装支架,发现固定螺栓在持续振动作用下松动了小半圈,摄像头光轴偏移,导致视觉与雷达的融合目标位置偏差增大,跟踪结果整体偏移。
修复方案分两步:第一步重新拧紧螺栓并加装防松垫片,重新做外参标定;第二步把所有车载设备的固定支架标准改成每周巡检一次,并在软件里增加一个"标定健康度"监测,周期性用车辆前方的固定参照物检查投影误差,一旦误差超限就提示重新标定。井下设备长期振动是常态,凡是安装在车体上的传感器,固定方式必须按振动环境设计,这是花钱买来的教训。
5.4 联动停车:技术完全可行,责任边界要提前谈明白
系统做到最后,一个绕不开的话题是:检测到危险区域内有人,要不要直接让装备刹停?技术上车载控制器联动制动完全可以实现,但这里面的责任边界问题比技术问题复杂得多。我们调研过不同矿的做法,有的要求只报警不联动,给司机留决定权;有的允许联动减速,但要求司机踩下确认踏板才能继续行驶;还有的在低速移库场景下允许自动刹车。
我的建议是:项目立项阶段就把联动策略跟矿方安全、生产部门谈清楚,形成书面确认。技术侧能做的,是给联动策略提供多种挡位配置,比如"仅报警"、"报警+降速"、"降速+急停"三档,管理侧根据矿上的规程选择。纯技术判断会替代司机决策的情况必须避免,系统定位始终是辅助安全手段,不是自动驾驶大脑。
6. 工程化落地的几个补充经验
6.1 防爆改型与防护等级:不能等做完再想
井下设备必须满足矿用防爆要求,传感器、控制器、线缆接口全都要按防爆标准整改。常见的方案是本质安全型(Ex ib)和隔爆型(Ex d),摄像头和雷达属于低功耗设备,走本质安全型比较合理;控制器如果功率大,往往要加隔爆外壳。这一块的坑在于:选型时买的常规工业级摄像头和雷达,普遍没有防爆认证,需要外送做防爆改型和认证,周期长、费用不低,而且改型后外壳、散热、接口都可能变化,要留足时间和预算。
另外,粉尘环境对防护等级的要求是IP65及以上,屏幕和按钮也要防尘防水。实测中我们发现,设备防尘网的日常清理频率直接影响可靠性,建议在设备布局图上明确标注清洁点位和周期,写进维护规程。
6.2 安装位置与走线:盲区覆盖和线束保护要兼顾
传感器的安装位置决定了盲区覆盖效果。实测下来,设备前向的视觉和雷达装在驾驶室前方高处,视野开阔但容易被顶板滴水影响;后向传感器装在高位尾翼上,对车辆正后方人员的探测效果最好。侧向盲区是融合覆盖最薄弱的区域,通常需要额外加装两侧短距雷达。布线时所有线缆必须穿防爆软管,避免与车体运动部件干涉,接头要打胶密封,这些细节直接决定系统能稳定运行多久。
6.3 验收评估方法:用三类指标量化系统能力
系统上线前的验收评估,建议用三类指标量化:检出率、误报率和响应时间。检出率统计方式是设置标准测试场景,安排人员在不同距离、不同速度、不同粉尘模拟条件下通过危险区域,统计正确触发比例,一般要求不低于95%;误报率以每班次误报次数计算,控制在个位数以内;响应时间测量从目标进入危险区到报警输出的延迟,实测值建议控制在200毫秒以内。
验收一定要在真实工况下进行,模拟环境数据再漂亮,井下粉尘一盖就现原形。我们首轮验收时特意选择掘进作业时段,让系统在粉尘浓度高的条件下跑完整班,这比在干净环境下测一百次都有说服力。
最后再分享一个小技巧:系统投入运行后,一定要保留完整的报警日志,包括时间、位置、传感器证据组合、报警级别、司机处置动作。这些数据是后续调优和事故回溯的重要依据。我见过不少项目把重点放在算法上,忽略了日志积累,结果出了问题连当时发生了什么、系统怎么判断的都说不清楚。日志就是预警系统的事故黑匣子,这一项设计和部署时就应该考虑进去。