去年年底接手了一个安防升级项目项目内部代号就定为 dz-1065核心需求很明确给某小区做一套高空抛物检测系统。说实话这类需求在安防圈子里已经不算新鲜了几乎每个物业都有被高空抛物折磨的经历——砸坏车、砸坏阳台玻璃、差点砸到人但真正能把是谁扔的查清楚的少之又少。传统做法是装几个朝天探头等出了事再翻录像但真到那时候画质够不够、角度对不对、楼层能不能分清全是问题。这套 dz-1065 方案从需求梳理到硬件选型再到算法调试和现场部署前后迭代了三版中间踩的坑比想象中多得多。今天把整个设计过程和技术细节完整整理出来给正在做同类项目的朋友一个参考。无论你是安防集成商、算法工程师还是物业方想了解这类系统到底能做成什么样这篇内容应该都能帮到你。1. 首先要搞清楚高空抛物检测系统到底在解决什么网上聊高空抛物检测的帖子很多但多数一上来就谈算法、谈模型反而把最核心的问题带偏了。我一个做了七八年安防项目的朋友说过一句大实话这类系统真正难的从来不是拍到高空抛物而是找到抛物的人。摄像头拍下一团黑影往下掉十秒钟的录像放在你面前你能说出它是从 15 楼掉下来的还是 18 楼掉下来的吗说不出来这就是高空抛物检测系统要解决的第一大难题——抛掷源定位。拆开来看一套完整的高空抛物检测系统要同时回答三个问题第一有没有高空抛物发生。这是检测环节系统要在 24 小时全天候条件下从画面里自动找出正在坠落的物体而不是等物业人员事后一帧一帧翻录像。第二抛物是从哪里来的。这是定位环节系统要给出尽可能精确的楼层和窗户范围把排查范围从整栋楼 30 多户缩小到一两户。第三有没有保存完整证据链。出事之后物业要能快速调出抛物过程录像最好还附带楼层标注信息这样不管是调解还是交给相关部门都有据可依。这三个问题对应着系统设计的三个核心子系统前端感知采集、边缘检测与定位算法、平台存储与告警联动。听起来好像不复杂但真正落地时你会发现每一个环节都有大量细节问题需要处理。另一个容易被忽略的点是实时性。很多人以为这类系统只要后台慢慢分析就行但实际场景是高空抛物发生在几秒之内如果系统检测延迟超过 10 秒那物业人员基本就错过目击时机了再想去确认是哪一户的窗户已经来不及。所以 dz-1065 方案从一开始就定了调子——检测必须在边缘侧实时完成中心平台只做结果汇聚和存储。也正因如此后面算法选型、硬件配置、网络架构都是围绕着边缘实时处理来设计的而不是简单堆一套服务器集中跑分析。2. 系统架构与硬件选型仰角相机、补光与边缘算力的取舍2.1 整体架构四层链路各管一段dz-1065 的整体架构可以拆成四层前端采集层 → 边缘计算层 → 平台管理层 → 告警联动层。前端采集层就是那一排仰角安装的摄像机负责把整栋楼的外立面从下往上看全。边缘计算层是整个系统的核心它直接接入摄像机的视频流在本地完成目标检测、轨迹跟踪、抛物判定和楼层定位只有确认是抛物事件之后才把告警信息和录像片段上传到平台。平台管理层负责事件存储、录像检索、楼栋和相机管理。告警联动层则对接物业的值班大屏、手机推送和声光报警器。为什么一定要强调边缘计算因为一台摄像机 24 小时不间断的视频流如果全传到中心服务器再分析对带宽和服务器性能的要求都很高而且网络一旦波动实时性就没了保障。把算法跑在靠近摄像头的位置本地实时处理等真正有事件再上传这样既保证了响应速度也大大降低了后端存储和带宽成本。2.2 相机选型与安装位置先把视角算清楚高空抛物检测的相机选择和普通监控完全不同。普通监控是越广越好恨不得一个摄像头看整个停车场高空抛物检测则要求纵向分辨率够用因为目标是从楼顶往下掉的你需要看清楚每一层窗户的位置。以一栋 18 层住宅楼为例按每层 3 米层高计算总高度在 54 米左右。如果相机安装在楼前 10 米处仰角大约 4560 度进行架设用一台 400 万像素2560×1440的摄像机理论上画面纵向能覆盖整个楼面但问题在于楼层越高在画面里压缩得越厉害。顶层窗户在画面里往往只有几十个像素的高度对于检测算法来说这个分辨率只能算是勉强可用。所以 dz-1065 方案里对不同高度的楼采用了不同的相机策略楼栋类型推荐相机配置说明15层以下小高层400万像素红外一体机单台覆盖焦距 4mm6mm18层26层中高层400万像素变焦球机/枪机单台仰角覆盖需注意顶层分辨率26层以上超高层多台相机分层覆盖低区、中区、高区各用一台交叉拼接相机安装的位置也有些讲究。我们总结下来就是一句话尽量正对楼面避免大角度斜射。如果相机装在楼的侧面画面透视关系会很复杂楼层标定做起来痛苦定位误差也大。2.3 边缘计算设备算力够用就好别盲目堆料算法跑在边缘侧那边缘设备选什么样的我们测试过两条技术路线一条是嵌入式智能盒子体积小、功耗低、价格便宜适合批量部署另一条是小型工控机加主流 GPU性能强、算法适配灵活但成本高出一个量级。对于普通小区项目嵌入式智能盒子基本够用。目前市面主流的盒子算力在 820 TOPS 之间跑一个优化过的轻量化检测模型加多目标跟踪算法能稳定处理 1080P 画面下 1520 帧每秒的视频流。要说明的是高空抛物目标小、轨迹计算要求帧间连续帧率太低会导致轨迹断裂所以我们最终把检测帧率控制在 1520 帧而不是像有些人想象的那样跑满 30 帧——因为算力消耗和实际收益的性价比在这里是最优的。2.4 补光与夜间策略这一块最容易被人忽略夜间是高空抛物的高发时段但恰恰也是成像最麻烦的时段。普通监控在夜间的处理很简单开红外灯补光就行。但高空抛物检测对夜间画面的要求要苛刻得多——目标可能是一包垃圾、一个饮料瓶尺寸小、运动快如果红外补光不均匀或者曝光时间过长运动目标就是一道模糊的拖影算法根本认不出来。这里有一个被很多人忽略的细节红外波段下深色物体和深色背景之间的对比度常常很低。比如夜晚从窗户抛出一个黑色塑料袋红外画面里它和黑暗的楼体背景几乎融为一体。我们实测下来单纯依赖红外模式的检测率会下降不少。解决思路有两个方向一是选用低照度性能更好的传感器在微弱环境光下仍然能输出清晰画面二是适当增加近红外补光同时锁定曝光参数避免画面亮度频繁跳变。dz-1065 最终采用的是低照度枪机智能补光组合效果比单靠红外好很多。3. 检测算法主链路小目标检出、轨迹跟踪与行为研判3.1 为什么通用检测模型直接拿来用会翻车很多人一开始的想法是高空抛物检测嘛拿一个训练好的目标检测模型把视频流丢进去检测到下落物体就报警。但实际操作后会发现通用目标检测模型在高空抛物场景里几乎不可用。原因很具体抛物目标在画面中的尺寸实在太小了。一个矿泉水瓶从 20 层落下在 1080P 画面里可能只有 12×12 像素一个烟头甚至只有 4×4 像素。通用模型训练时主要针对常规尺寸目标几十到几百像素对小目标的召回率本来就不高。再加上大仰角视角下目标形状不断变化——开始是一个点越落越大还可能旋转——模型很容易漏检或者误检。所以我们做的第一件事不是选个现成模型凑合用而是把检测策略整体调整。3.2 模型选型与改进小目标检测的几个关键动作dz-1065 在算法上采用了一套标准的检测-跟踪-判定三段式流程核心模型基于 YOLO 系列做了针对性改进。首先是输入分辨率调整。模型输入从常规的 640×640 提升到 1280×1280 或更高把画面中的小目标放大到模型更容易提取特征的程度。当然分辨率提升计算量也会成倍增长所以不是越高越好需要结合边缘设备的算力做平衡。我们在嵌入式盒子上实测1280 分辨率下的处理速度仍然能满足 15 帧每秒的实时要求。其次是多尺度特征融合的加强。高空抛物的目标在人头大小的物体如整袋垃圾到指尖大小的物体如烟头之间跨度极大单靠标准特征金字塔还不够。我们对浅层特征层做了额外上采样拼接相当于专门给小目标检测头多喂了一些细粒度信息。第三是数据增强策略。高空抛物场景的目标不是静止的而是快速运动、带运动模糊的所以训练时就需要叠加随机运动模糊、光照变化、缩放抖动这些增强手段让模型见过足够多运动中的样本而不只是清清晰晰的静态样本。3.3 多目标跟踪把检测框串成可靠的轨迹检测模型只解决这一帧画面里有没有疑似目标的问题但单帧检测结果意义不大甚至容易误报。真正要做的是把连续多帧中同一个目标的检测框串联成一条轨迹然后基于轨迹来判定这是不是一次抛物。跟踪算法上我们采用的是一种基于检测的关联跟踪方案核心思路是对每一帧检测出的目标框计算它和上一帧所有轨迹之间的相似度然后通过匈牙利匹配建立关联。相似度综合考虑了位置距离、尺寸变化和外观特征。如果连续多帧都能正确关联就形成了一条稳定轨迹。高空抛物场景里有个特殊情况目标在坠落过程中速度极快相邻两帧之间的位置跳跃可能达到几十甚至上百像素。如果匹配算法只允许目标在很小的范围内移动轨迹就很容易断裂。解决方法是动态调整搜索范围并允许丢失几帧后通过预测位置重挂。丢失帧数过多就终结轨迹这样既能保证连续性又不会把无关目标错误关联。3.4 抛物行为判定不是所有从天上掉下来的东西都报警轨迹有了接下来是关键问题——怎么判断这条轨迹是高空抛物而不是树叶飘落飞鸟经过或者小孩子从窗台扔了个玩具但没出楼面我们的判定逻辑可以浓缩成一个核心原则真实抛物必须具有明显的垂直下落特征和持续的加速行为。说白了自由落体运动是有物理规律的物体在竖直方向的速度会随时间逐渐增大而树叶是飘的飞鸟是振翅飞的它们在竖直方向上的速度变化率跟自由落体差别很大。下面是一段简化后的轨迹判定核心逻辑用 Python 风格示意def is_parabolic_trajectory(track, frames, speed_threshold2.5): track: 轨迹点序列每个点包含 (x, y, frame_id) 返回值: True 表示符合抛物特征 if len(track) 6: return False # 计算竖直方向上的平均速度序列 velocities_y [] for i in range(1, len(track)): dy track[i].y - track[i-1].y dt track[i].frame_id - track[i-1].frame_id velocities_y.append(dy / dt) # 自由落体的速度应持续增大 min_v min(velocities_y) max_v max(velocities_y) if max_v - min_v speed_threshold: return False # 竖直方向总位移需超过一定像素数排除抖动和树影 total_dy track[-1].y - track[0].y if abs(total_dy) 40: return False # 水平位移不能过大否则更像飞鸟 total_dx abs(track[-1].x - track[0].x) if total_dx abs(total_dy) * 1.5: return False return True这只是一个基础版本实际工程上还会加上抛物线拟合、抖动滤波、轨迹置信度评分等逻辑。但这个核心思路没有变用物理特征去筛掉非抛物事件而不是让模型学习什么是抛物。模型负责找出可能的目标物理规则负责做最终判断。这套组合的好处是误报率下降非常明显而且规则可解释现场调试时可以抱着电脑一帧一帧跟你说清楚为什么报、为什么不报。4. 从像素坐标到楼层窗口单目方案下的抛掷点定位逻辑4.1 为什么不硬上 3D 重建要让系统回答从哪一层扔下来的表面上有两条路一是用双目视觉或者深度相机做 3D 定位直接算出物体在三维空间中的轨迹和起抛点二是在单目画面里做几何映射。我们很快排除了第一种方案。原因很现实高空抛物场景的观测距离远、视角大仰角双目相机的基线距离有限在 50 米外对一个小目标做深度估计误差会大到没有任何实用价值。而且高空环境光照变化剧烈深度相机在这种条件下稳定性也差。单目方案 几何标定反而是最务实的选择。4.2 楼层标线法把复杂的 3D 问题降维成 2D 分区dz-1065 采用的定位方法我叫它楼层标线法。思路非常简单既然我们要回答的是哪一层楼那就不一定非要重建出精确的 3D 坐标只要把每层楼的边界在画面中精确标定出来再把物体轨迹的起点映射到对应的楼层区间即可。具体做法分三步走第一步现场标定。相机安装调试完成后在画面里手动画出每一层楼的分界线——就是每户阳台或者窗户的上下沿。这一步听着简单实际很考验耐心。因为有畸变、有遮挡标线必须做在像素级别。好在多数住宅楼每层结构基本一致我们可以把楼顶和楼底的两个极端点标定完中间楼层按等比例插值生成再人工逐层微调。第二步轨迹起点映射。检测到抛物轨迹之后取轨迹的前几个有效点目标刚出现时的位置用最小二乘拟合出一条延长线沿着轨迹的逆方向回溯直到它和楼体立面相交。那个交点所在的楼层区间就是系统判断的抛掷源楼层。第三步附加上下文修正。实际场景里抛物者不一定会站在窗边把手臂伸出窗外很多时候是从阳台栏杆内向上抛目标在画面中第一次出现时已经越过栏杆了。所以仅仅用第一帧位置来判断是不够的必须结合运动方向外推。这也是我们踩过坑之后才补上的逻辑——最早版本直接取第一帧位置结果定位系统性偏高了半层到一层。4.3 定位误差分析与输出策略单目定位能做到多准我的经验是在标定精确、安装规范的前提下定位误差可以控制在一层楼范围以内。但想精确到具体这户还是隔壁那户难度就大了因为水平方向和垂直方向各有误差叠加。实际部署中我们系统对外输出的不是一个精确的楼层数字而是一个带置信度的楼层候选列表。比如最可能 15 层次可能 14 层再次可能 16 层置信度分别是 0.72、0.21、0.07。物业人员拿到这个结果再结合轨迹录像回放很快就能锁定向导。为什么这样设计因为单目定位天然存在模糊地带——当抛物起点恰好在两层楼交界处时任何算法都会摇摆。如果硬要输出一个精确楼层反而容易误导排查。输出候选列表 让物业人员做最终人工确认是目前平衡准确率和可用性最好的方式。4.4 现场校准部署后一定要做的关键动作标定做完不等于万事大吉。现场实测时我们发现如果相机支架有微小松动或者因为风吹日晒位置有偏移之前标定好的楼层线就全偏了。所以 dz-1065 在部署流程里加入了一道现场抛投校准环节。具体做法是在不同楼层比如 8 楼、12 楼、16 楼用系了长线的重物做模拟抛投系统记录每次检测到的定位结果与真实楼层对比反过来微调标定参数。实测过的一个 24 层小区项目里校准前定位偏差最大到了两层校准后缩小到了半层以内。5. 全天候部署中踩过的坑误报、夜间、多目标遮挡与数据瓶颈5.1 误报来源大盘点光靠算法根本防不过来dz-1065 在测试阶段经历过一轮又一轮的误报轰炸我估计每个做这类系统的人都逃不开这几个坑误报来源现象描述我们的处理策略飞鸟俯冲飞行时轨迹近似抛物线增加水平/垂直位移比约束飞鸟水平位移明显更大树叶飘落轨迹不规则、速度慢设置最小的速度与位移阈值飞虫单帧出现轨迹短而散要求轨迹至少连续 6 帧以上才判定云影/树影光线变化导致背景明暗突变先做目标检测而非全图运动检测从源头过滤雨滴/雪花大量小目标同时出现引入天气模式雨天优先过滤小尺寸快速目标印象最深的是树叶。有段时间系统几乎天天误报看录像回放发现是小区绿化带的落叶被风卷起来从画面底部刮进检测区域。它跟抛物轨迹在形态上确实有点像都是斜向下运动。后来我们结合颜色特征和运动速度双重条件才压住这个误报源。所以说算法调优不能光看检测率指标必须针对每个误报场景单点突破。5.2 夜间成像红外画面里的隐形目标夜间的坑比白天多得多。红外模式下画面整体偏灰背景和目标的对比度低尤其是深色垃圾袋、深色衣物包裹的物体跟漆黑的墙面混在一起检测器经常视而不见。解决这个问题我们在 dz-1065 里做了三件事。一是把检测置信度阈值在夜间模式下适当调低宁可多出一些候选也不能漏掉真实目标后面还有轨迹判定环节兜底。二是在图像进入检测模型前先做一层自适应对比度增强专门拉伸低灰度值区域的细节。三是给相机配置了定向补光装置让它把光线集中投射在楼体表面而不是直射居民窗户既提升了夜间的成像清晰度又照顾到了住户感受。5.3 多栋楼遮挡与边缘盲区单台相机的死角问题高层小区里楼栋之间的距离往往很近A 栋的抛物轨迹很可能在画面后半段被 B 栋遮挡。更麻烦的是有些抛物是贴着墙面落下的轨迹在画面里几乎是一条与楼体平行的直线看起来极不自然算法会倾向于判定为不是抛物。这种情况靠单台相机是搞不定的。dz-1065 在多栋楼并排的场景里采用交叉覆盖方案每一栋楼至少有一台主视角相机正对楼面相邻楼之间的空隙由另一组相机的大角度视野来覆盖。多路视频接入同一个边缘计算节点各检测各的但事件都汇总到同一平台平台按时间戳合并同一个抛物事件的不同视角录像。这样物业查看的时候能同时看到两个角度的画面定位的把握也大得多。5.4 训练数据从哪里来自建模拟数据集的完整套路检测模型的训练数据是另一个大坑。公开数据集中基本没有高空抛物场景的专门数据集就算有场景单一换一个小区效果就会明显下降。所以 dz-1065 的数据来源主要靠自建。我们的做法主要有三条线并行。第一条是实地模拟抛物数据采集我们在不同高度楼层、不同朝向窗户用不同尺寸和材质的物体矿泉水瓶、纸团、塑料袋、烟盒等做模拟抛物架设大量相机从多角度拍摄再对视频逐帧做标注。这项工作听着枯燥但得到的数据质量是任何公开数据集都比不了的。第二条线是从现有夜间监控录像中挖候选样本。很多小区的老监控常年开机虽然没有专项检测但录像里经常记录下真实的抛物事件。用半自动方式从录像里剪辑出抛物片段再人工筛选和补标注效率比纯人工拍摄高不少。第三条线是离线增强生成。有限的真实样本加上大量离线增强——模拟不同的光照条件、运动模糊程度、相机视角变化能把样本数量翻好几倍。但增强生成只能作为补充不能完全替代真实数据因为增强出来的样本和真实场景的纹理差异始终存在。6. 实测结果、调参经验与可复用的部署清单6.1 性能指标怎么定别只看检测率系统做完测试验收时很多人只关心一个问题检测率多少但是单看检测率远远不够。高空抛物检测系统的性能需要一整套指标来评估指标定义我们的设计方案指标实测水平检出率实际抛物事件中被系统识别出的比例≥95%约96%漏报率实际抛物事件未被识别的比例≤5%约4%误报率系统告警但实际并非抛物事件的次数≤3次/天/栋平均1.5次/天定位准确率告警楼层与实际楼层一致或相差1层内的比例≥85%约89%告警延迟从抛物发生到平台弹出告警的时间≤10秒约3秒这里有个经验不要追求 100% 检出率。如果把检测阈值压得很低检出率可能从 96% 提到 98%但误报次数会成倍增长。一旦误报过多物业人员会逐渐对系统告警产生疲劳开始不看推送这样的系统实际上就废了。我们在实际项目里的做法是优先压低误报率在保证误报可控的前提下再尽量提升检出率。6.2 调参的核心经验阈值、轨迹缓存与分级告警参数调优是这个系统里最磨人的工作但也是最值得写的干货。先说置信度阈值。高空抛物检测适合采用区分时段的阈值策略——白天光线好目标清晰阈值可以设高一点比如 0.4夜间目标模糊阈值调低到 0.25让更多候选进入后续判定流程。这个策略让夜间实测效果好了不少。再说轨迹缓存长度。抛物事件从出现到落地往往只有 24 秒但我们要求系统在触发告警时能回传事件前 7 秒的录像。为什么是 7 秒因为很多时候抛物者的手臂已经提前一点时间伸出窗户这 7 秒能把人伸手的动作一起录下来对物业确认是哪一户非常关键。另外强烈建议做分级告警。dz-1065 把告警分成三个级别蓝色疑似抛物轨迹特征明显度较低、橙色符合抛物特征置信度中等、红色轨迹清晰、置信度高且疑似目标体积较大。三级告警对应不同的推送策略——蓝色只在值班大屏上滚条橙色推送物业管理员红色才触发手机短信加声光报警。这样可以让真正严重的事件得到最高优先级关注。6.3 可复用的部署落地清单如果你准备照这套思路做自己的高空抛物检测系统我建议按以下顺序推进现场勘察。确认楼栋高度、楼层数、窗户朝向、周围遮挡物、光线条件判断需要几台相机、安装在什么位置。这个阶段一定不要省勘察不到位后面全是返工。相机安装与角度调整。按仰角 4560 度安装现场通过监视器逐层确认画面里的窗户清晰可见顶层不能因为压缩得太厉害而看不清。楼层标定与抛投校准。画楼层线做模拟抛投验证定位精度误差大就微调标定参数。边缘设备配置与算法部署。把训练好的模型、跟踪模块和判定规则部署到边缘设备设置好时段阈值和告警推送策略。试运行与调参。试运行至少一到两周每天记录误报和漏报情况针对高频误报场景做专门处理。正式验收。用不同楼层、不同物体的模拟抛投做逐项测试确认各项指标达成后交付。6.4 演进方向多机联动与跨视角融合这套方案目前主要跑的是单机独立模式但后续演进空间很大。比如多台相机之间可以做跨视角轨迹融合A 相机看到的抛物起始位置可能偏模糊但相邻楼栋的 B 相机恰好从侧面看到了那个窗户两个视角一交叉定位精度会有明显提升。另一个方向是把人和物联动起来。当轨迹判定为抛物事件后回溯轨迹起点附近的窗户区域检测是否有人的手臂或者身影在抛物前出现在窗边。这一步如果能做通等于把物证和人证同时补齐了对物业维权的帮助会大很多。最后分享一个我在整个 dz-1065 项目里最深切的体会这类系统算法只是载体真正决定成败的是对现场的理解。楼体的结构、窗户的样式、住户的日照习惯、甚至小区里种了什么树都会直接影响系统的检测效果。你在实验室里把模型调得再漂亮到了现场不贴合实际情况照样会被误报和漏报打回原形。所以我一直相信做高空抛物检测系统一半是算法工程另一半是现场工程——耐下心来做标定、测视角、调参数比堆再多的模型结构都管用。希望这篇内容能给正在做类似项目的你一些实实在在的参考。