7天落地YOLO安防检测：跌倒识别+闯入预警完整方案记录

前言
做安防AI落地，最怕的不是模型精度不够，而是“Demo很惊艳，上线全完蛋”。去年年底，我接手了一个智慧养老社区的安防改造项目，甲方要求7天内完成POC验证，核心指标就两个：老人跌倒检出率>95%且误报<1次/小时、电子围栏闯入响应<200ms。

这篇文章不讲虚的理论推导，纯记录这7天里我们团队从选型、训练、部署到踩坑填坑的完整工程链路。所有代码片段、配置参数均来自实际生产环境，希望能给同样在做YOLO安防落地的兄弟提供一些可复用的经验。

一、 需求拆解与技术选型（Day 1）

1.1 为什么选YOLOv8n而不是v10/v11？

很多人觉得做项目一定要用最新模型，但在安防边缘端场景下，推理延迟和部署稳定性远比mAP高0.5个点重要。我们对几款主流模型做了实测对比（测试平台：Jetson Orin Nano + TensorRT FP16）：

最终选择YOLOv8n的理由很简单：

• Orin Nano上4.2ms的推理速度，留给后处理和多路视频解码还有充足余量；
• Ultralytics生态完善，导出ONNX/TensorRT一行命令搞定；
• 预训练权重在人体姿态、小目标上的泛化能力足够支撑迁移学习。

1.2 整体架构设计

这不是一个单纯的检测任务，而是“检测+逻辑判断”的复合系统。我们设计了如下流水线：

关键设计点：检测和姿态估计是解耦的。YOLOv8n只做人体bbox检测，跌倒判定依赖轻量级关键点模型（RTMPose-tiny），两者异步运行，避免单模型过重导致帧率崩塌。

二、 数据集构建与针对性训练（Day 2-3）

2.1 数据从哪来？

公开数据集（如URFD、Le2i）场景单一，直接用在养老院走廊里效果极差。我们的数据策略是“30%公开数据 + 70%现场采集”：

• 现场采集：安排3名同事在不同光照、衣着、遮挡条件下模拟跌倒，每个摄像头点位录制20分钟视频；
• 负样本增强：特意收集了弯腰捡东西、蹲下系鞋带、靠墙休息等易误报动作各200条；
• 标注规范：bbox只标人体躯干（不含四肢延伸），减少因肢体模糊导致的框抖动。

2.2 针对安防场景的训练Trick

直接用默认配置训练，召回率卡在82%上不去。以下是我们调优后有效的改动：

# train.yaml 关键修改项imgsz:640# 安防摄像头多为1080p，640是性价比最优解batch:32# Orin Nano内存有限，batch不宜过大epochs:200# 小数据集需要更多epoch收敛mosaic:0.5# 降低mosaic强度，避免过度破坏人体结构完整性mixup:0.1# 低强度mixup，防止小目标被淹没close_mosaic:30# 最后30轮关闭mosaic，精细化回归# 损失函数调整box:7.5# 提高box loss权重，安防对定位精度敏感cls:0.5# 类别少，降低分类loss权重dfl:1.5# 保持默认DFL，对小目标边界有帮助

重点说一下mosaic=0.5的原因：标准mosaic会把4张图拼接，人体经常被裁切得支离破碎。但安防场景中人体通常是完整出现的，过强的mosaic反而让模型学到了错误的上下文关系。降到0.5后，验证集召回率直接从82%跳到91%。

2.3 训练监控与早停

不要盲目跑满200 epoch。我们设置了双重早停条件：

• patience=20：val_map连续20轮不提升则停止；
• 业务指标监控：每10轮在真实测试视频上跑一次跌倒检出率和误报数，当连续两轮误报>2次/小时时强制回退到上一个checkpoint。

最终在第147轮收敛，测试集结果：

• 人体检测 mAP@0.5:94.7%
• 跌倒场景召回率：96.2%
• 易混淆动作误报率：0.7次/小时

三、 跌倒识别：不止是检测，更是状态机（Day 4）

这是整个方案中最容易被低估的部分。单纯靠一帧检测结果判断跌倒，误报率根本压不下来。我们设计了一个基于时序的状态机：

3.1 核心判定逻辑（伪代码）

classFallStateMachine:def__init__(self,fps=25):self.state="Standing"self.fall_frame_count=0self.still_frame_count=0self.fps=fpsdefupdate(self,bbox,keypoints,velocity_y):aspect_ratio=bbox.w/bbox.h torso_angle=compute_torso_angle(keypoints)# 躯干与垂直线夹角ifself.state=="Standing":# 触发条件：宽高比骤变 + 下落速度ifaspect_ratio>1.2andvelocity_y>15.0:self.state="Falling"self.fall_frame_count=0elifself.state=="Falling":self.fall_frame_count+=1# 连续8帧以上保持倒地姿态才转入Falleniftorso_angle<30andself.fall_frame_count>=8:self.state="Fallen"self.still_frame_count=0# 超过20帧仍未确认，视为误触发，复位elifself.fall_frame_count>20:self.state="Standing"elifself.state=="Fallen":# 检查是否静止（bbox中心位移<3像素/帧）ifis_stationary(bbox):self.still_frame_count+=1else:self.still_frame_count=max(0,self.still_frame_count-2)# 静止15帧（约0.6秒）才触发告警ifself.still_frame_count>=int(0.6*self.fps):self.state="Alert"returnTrue# 触发告警# 如果躯干角度恢复，说明站起来了iftorso_angle>60:self.state="Standing"returnFalse

3.2 为什么不用端到端的行为识别模型？

试过SlowFast和TimeSformer，问题很现实：

• 推理太慢，Orin Nano上单路就要30ms+；
• 需要固定长度的视频clip作为输入，无法做到逐帧实时响应；
• 训练数据需求量大，我们几百条模拟数据根本喂不饱。

状态机的优势在于可解释、可调参。上线后运维人员反馈“某个点位误报多”，我们可以直接调整该点位的velocity_y阈值或still_frame_count，而不需要重新训练模型。这在ToB交付中极其重要。

四、 闯入预警：区域碰撞与Tracking（Day 5）

4.1 电子围栏的实现

闯入检测的本质是“目标跟踪 + 几何运算”。我们没有用复杂的语义分割来定义区域，而是采用多边形ROI + 射线法判定点位关系：

defis_inside_roi(bbox_center,roi_polygon):""" 射线法判断点是否在多边形内 比OpenCV的pointPolygonTest快3倍（纯numpy实现） """x,y=bbox_center n=len(roi_polygon)inside=Falsep1x,p1y=roi_polygon[0]foriinrange(1,n+1):p2x,p2y=roi_polygon[i%n]ify>min(p1y,p2y)andy<=max(p1y,p2y):ifx<=max(p1x,p2x):ifp1y!=p2y:xinters=(y-p1y)*(p2x-p1x)/(p2y-p1y)+p1xifp1x==p2xorx<=xinters:inside=notinside p1x,p1y=p2x,p2yreturninside

4.2 Tracking选型：BoT-SORT vs ByteTrack

实测对比（同一检测器、同一视频流）：

安防场景中ID稳定性比绝对精度更重要——一个人从树丛后走出来换了个ID，就会触发两次闯入告警。最终选了BoT-SORT，2.8ms的开销完全可接受。

4.3 防抖与去重

原始检测结果会有短暂跳出ROI再跳回的情况，导致告警闪烁。加了两个简单策略：

• 进入确认：连续N帧（默认5帧）都在ROI内才判定为闯入；
• 离开缓冲：离开ROI后保留M帧（默认15帧）的track记录，期间再次进入不重复告警。

这两个参数做成配置文件热加载，现场调试时不用重启服务。

五、 TensorRT部署与性能优化（Day 6）

5.1 导出与量化

# 导出ONNX（动态batch）yoloexportmodel=best.ptformat=onnxdynamic=Truesimplify=Trueopset=12# TensorRT转换（FP16 + 最小化workspace）trtexec--onnx=best.onnx\--saveEngine=best_fp16.engine\--fp16\--minShapes=images:1x3x640x640\--optShapes=images:4x3x640x640\--maxShapes=images:8x3x640x640\--workspace=2048

踩坑记录：Orin Nano的TensorRT版本与Ultralytics导出的ONNX存在算子兼容性问题。Simplify后的ONNX在某些版本下会生成不支持的Resize节点。解决方案是导出时加--no-simplify，然后用onnx-simplifier==0.4.3单独处理，指定--dynamic-input-shape。

5.2 多路视频解码优化

4路1080P@25fps的视频流，如果用CPU软解，Orin Nano直接拉满。必须用硬件解码：

# GStreamer管道（NVDEC硬解 + NVMM内存零拷贝）pipeline=(f"rtspsrc location={rtsp_url}latency=200 ! "f"rtph264depay ! h264parse ! nvv4l2decoder ! "f"nvvidconv ! video/x-raw(memory:NVMM),format=BGRx ! "f"appsink drop=true max-buffers=2")

关键点：

• latency=200：RTSP网络抖动缓冲，设太小会花屏，太大延迟高；
• memory:NVMM：解码后数据留在GPU显存，避免CPU-GPU来回拷贝；
• max-buffers=2：限制缓冲队列长度，防止积压导致延迟累积。

5.3 最终性能指标

六、 现场部署与踩坑实录（Day 7）

6.1 光照剧变问题

养老院走廊有扇大玻璃窗，下午阳光直射时画面过曝，傍晚又突然变暗。YOLO在这种极端光照下漏检率飙升。

解决方案：在预处理管线中加入自适应CLAHE（对比度受限直方图均衡化），根据图像平均亮度动态决定是否启用：

defadaptive_preprocess(frame):gray=cv2.cvtColor(frame,cv2.COLOR_BGR2GRAY)mean_brightness=np.mean(gray)# 过暗或过亮时启用CLAHEifmean_brightness<60ormean_brightness>200:clahe=cv2.createCLAHE(clipLimit=2.0,tileGridSize=(8,8))lab=cv2.cvtColor(frame,cv2.COLOR_BGR2LAB)lab[:,:,0]=clahe.apply(lab[:,:,0])frame=cv2.cvtColor(lab,cv2.COLOR_LAB2BGR)returnframe

这个预处理只增加0.3ms耗时，但过曝场景下的召回率从71%提升到89%。

6.2 摄像头安装角度陷阱

有一个点位的摄像头装在天花板角落，俯角接近60°。这个角度下人体bbox变得很短宽，和正常视角差异巨大，检测置信度普遍低于0.4。

教训：YOLO的anchor分布是基于常规视角统计的。俯角>45°的点位必须单独采集数据微调，或者在安装阶段就把摄像头俯角控制在30°以内。我们最终选择了后者——调整安装位置比重新训练划算得多。

6.3 告警风暴防护

上线第一天晚上，一只猫在围栏区域反复进出，3分钟内触发了47条告警。虽然单条告警逻辑没错，但缺乏全局频控。

紧急加了滑动窗口限流：同一ROI区域内，同类事件60秒内最多上报3次。同时增加了动物过滤（通过bbox面积+长宽比粗筛），第二天误报降到了可接受范围。

七、 复盘与经验总结

7.1 什么做得好

• 状态机设计：把“检测”和“业务判定”解耦，后期调优效率极高；
• 数据策略务实：没有追求万级数据量，而是精准补充现场负样本；
• 部署前置验证：Day 1就跑通了TensorRT pipeline，避免了最后一天才发现模型导不出来的悲剧。

7.2 什么可以改进

• 应该更早引入自动化评测：前3天都是人眼盯视频看效果，Day 4才写了自动评测脚本，浪费了太多主观判断的时间；
• Tracking应该做ROI感知：当前BoT-SORT在全图跟踪，其实只需要在ROI附近维护track即可，能进一步降低开销；
• 缺少长期漂移监控：POC通过了，但没建立线上数据回流机制。实际运行3个月后模型性能大概率会衰减，需要提前规划retrain流程。

7.3 给同行的建议

1. 别迷信mAP：安防场景下，Recall@特定IoU + 业务误报率才是真指标；
2. 先跑通再优化：Day 1就用最简配置把全链路串起来，哪怕精度只有60%，也比Day 5还在调训练参数强；
3. 预留现场调试接口：所有阈值、ROI坐标、告警频率都做成热配置，别让运维人员每次改参数都要重新编译部署；
4. 文档即交付：把每个参数的含义、调整方向、典型值写成README，你走后接手的人不会骂你。

附录：项目文件结构参考

yolo-security-poc/ ├── configs/ │ ├── detect.yaml # 检测模型配置 │ ├── fall_state_machine.yaml # 跌倒状态机参数 │ └── roi_zones.json # 电子围栏坐标 ├── models/ │ ├── best_fp16.engine # TensorRT引擎 │ └── rtmpose_tiny.onnx # 关键点模型 ├── src/ │ ├── detector.py # YOLO推理封装 │ ├── tracker.py # BoT-SORT封装 │ ├── fall_detector.py # 跌倒状态机 │ ├── intrusion.py # 闯入判定 │ ├── stream_decoder.py # GStreamer解码 │ └── main.py # 主调度循环 ├── eval/ │ ├── auto_eval.py # 自动化评测脚本 │ └── test_videos/ # 测试视频集 └── deploy/ ├── Dockerfile # 容器化部署 └── docker-compose.yml

写在最后
7天做出一个能用的POC不难，难的是把它变成能稳定运行半年的产品。这篇文章记录的只是冰山一角，真正的功夫花在那些没写出来的细节里——比如RTSP断线重连的指数退避、GPU OOM时的优雅降级、日志分级与磁盘清理……这些才是区分“Demo工程师”和“落地工程师”的分水岭。

如果这篇对你有帮助，欢迎点赞收藏。有问题评论区交流，看到都会回。

本文所述方案已在实际项目中验证，代码片段已脱敏处理。转载或引用请注明出处。