1. 整体思路一套巡检系统怎么做到“见人识车”先把这个标题拆开看。无人机巡检好理解就是让飞机代替人顶着摄像头去园区、工地、厂区这些地方转。真正麻烦的是后面四个字——人车追踪。很多人拿到项目第一反应是“用目标检测模型识别行人和车辆”。这句话没错但只对了一半。检测是“这一帧看见了”追踪是“持续知道它往哪走”。从“看见”到“锁定”中间隔着跟踪算法、轨迹管理、云台联动、多机任务接力一堆事。这篇文章就围绕这个项目把我实际落地时踩过的坑、验证过的做法按模块完整讲一遍。先说项目的整体目标某园区日常巡检中无人机按预设航线飞行实时识别画面中的行人和车辆输出位置、类别、轨迹并在发现异常时触发告警和云台瞄准。这个目标拆开之后其实包含四个子问题用什么算法识别目标识别出来之后怎么保证目标不丢目标的像素坐标怎么换算成能驱动云台和地图的坐标多架无人机同时飞行时怎么不重复追踪、不互相干扰。四个子问题对应四个模块感知层、跟踪层、坐标变换层、调度层。这套分层思路我在实际项目中反复验证过也是推荐读者直接采用的架构。所有模块按顺序串成一条数据流相机采集画面 → 检测模型输出目标框 → 跟踪器关联前后帧 → 坐标换算上抛 → 任务管理器更新全局状态 → 云台或航线控制器执行响应。后面所有内容都是围绕这条数据流展开的。1.1 核心需求拆解人车追踪在一个巡检项目里不同角色关注的点完全不一样。甲方最关心的是“能不能发现人、发现车能不能形成有效记录”研发最关心的是“目标会不会丢、ID会不会跳变、告警及时不及时”。这两类诉求要并行满足缺一不可。从功能需求端看系统至少要支持行人检测、车辆检测、目标持续跟踪、目标轨迹保存、异常告警、云台联动。其中“目标轨迹保存”很容易被忽略但它恰恰是巡检项目的验收关键后面单独讲。从性能需求端看地面站画面延迟要控制在可接受范围机上推理帧率不能拖垮飞控多机并发时通信带宽要足够。实际项目中我定的指标是单机机上检测延迟小于 80ms跟踪状态更新频率不低于 10Hz双机并发时地面站画面不卡顿。需求拆解阶段最容易犯的错是把所有需求堆在一起做最后每个功能都做不深。正确做法是先把需求按“必选”和“可选”分层检测、跟踪、轨迹是必选告警和云台联动是业务增强项。必选功能决定系统能不能用增强项决定系统好不好用。这个优先级排序决定了后面做架构时的取舍方向。从用户视角再补一层。巡检现场的操作员通常不是算法工程师他们不会去看置信度分数和IOU阈值他们要的是一个可操作的界面地图上能看到目标当前位置视频画面上目标框要稳定跟随告警要弹出带位置信息的截图。这类易用性需求如果前期不纳入设计后期现场验收会非常痛苦。所以在做技术方案时我要求所有检测结果必须先经过跟踪器平滑再展示给用户而不是直接裸奔显示检测框。1.2 为什么选“检测加跟踪”而不是单模型硬扛有一个很容易被提出来的方案直接用视频目标检测模型对每一帧都独立检测不单独做跟踪。这个方案在技术上看最“省事”但在实际巡检场景里根本不可行。原因有几个。其一检测模型对每一帧是独立判断的所以同一辆车在第 10 帧被识别成“轿车”第 12 帧可能被识别成“货车”第 15 帧可能完全漏检。没有跟踪器做时间维度的平滑输出结果会像心电图一样跳变甲方看到第一眼就会质疑系统稳定性。其二无人机视角下目标尺度变化剧烈目标距离远时只有几十个像素贴近时占满整个画面纯检测模型在这种尺度变化下很难稳定输出。跟踪器可以在目标过小时用运动模型维持轨迹在目标过大时补充局部上下文信息。换个生活化的类比检测模型像一个近视眼的人看远处的东西一会儿认得出、一会儿认不出跟踪器就是旁边一个人一旦认出了某样东西就一直盯着它即使近视眼看不清了也能凭记忆判断它大概在哪。单模型方案相当于让近视眼一个人干所有事双模块方案相当于给近视眼配了个帮手两人协作稳定性完全不同。另一个容易被忽视的原因是业务需求本身需要“追踪”。巡检系统要求的目标是“知道这个人是几点几分出现在哪个区域、往哪个方向走的”这要求系统具备跨帧关联能力也就是必须对同一个目标分配一个稳定ID。纯检测模型根本给不了这个能力——它只会告诉你这一帧有一个人不会告诉你这一帧的人和上一帧的人是不是同一个。所以检测加跟踪不是可选项而是必选项。1.3 系统分层与数据流我实际采用的分层结构是四层感知层、跟踪层、转换层、决策层。每一层只依赖下一层提供的接口不跨层调用。感知层负责从原始视频流中提取目标信息核心是检测模型和预检策略。跟踪层负责把感知层的离散检测结果串成连续轨迹核心是目标关联和数据关联。转换层负责把像素坐标转换成地理坐标或相对坐标核心是坐标系换算。决策层负责根据追踪目标状态触发业务动作比如告警、云台锁定、航线调整。数据流是单向的任何一层处理完就立即向上抛送不等待上层回执。这个设计的最大好处是解耦。比如感知层的检测模型要换只要输出格式不变跟踪层完全不用动。同理如果甲方突然要求把行人识别换成船舶识别只需要在感知层加一个类别后面的流程全部复用。我见过很多项目把逻辑写在一个大循环里看起来简单后期稍微改一个需求就要动全局这种代码在巡检项目里活不过三个版本迭代。单向数据流还有一个额外收益每一层的处理状态都可以独立监控。我在实际项目中给每一层都加了状态日志感知层输出检测帧率跟踪层输出活跃轨迹数量转换层输出坐标质量分数。线上运行的时候哪个模块出了问题看状态日志就能定位不需要从头到尾排查代码。这个监控习惯我强烈建议所有做类似项目的同学都建立起来。2. 核心算法层检测、跟踪、跨镜接力的细节2.1 目标检测选型与预检分帧目标检测模型的选择直接决定整个系统的性能上限。巡检项目中无人机算力有限不能拿超大模型硬跑但精度又不能太低否则跟踪器再强也救不回来。我最终选型是 YOLO 系列的中型版本输入尺寸 1280 分辨率在嵌入式平台上可以跑到 15 到 20 FPS。这个帧率看起来不高但对于巡检场景完全够用因为目标移动速度相对较慢15 FPS 的采样率足以覆盖连续跟踪需求。这里有一个关键工程技巧不要对每一帧都做检测。无人机视频流通常是 30 FPS但检测模型达不到这个速度。盲目逐帧检测会让计算资源跑满飞控实时性受到威胁。我的做法是设定一个检测频率通常在 10 到 15 FPS 之间每 2 到 3 帧取一帧送入检测模型其余帧直接交给跟踪器用运动模型预测。这个“预检分帧”策略的核心逻辑是检测是昂贵的跟踪是廉价的。跟踪器基于卡尔曼滤波做的运动预测计算开销比检测小两个数量级完全可以用跟踪结果填补检测的空白帧。实测中在目标做匀速或缓变速运动时分帧策略和逐帧检测的结果差距非常小但算力占用下降了大约一半。如果目标突然转向或加速跟踪器预测会短暂漂移但下一帧检测结果到来时会立即修正不会造成目标丢失。置信度阈值也是一个需要单独调的参数。巡检场景中行人目标往往比较小置信度天然偏低如果阈值设到 0.5人还在 100 米外时就会被直接过滤掉。我把检测置信度分成两档机上检测阈值设低比如 0.25目标少的时候尽量多输出候选目标地面站展示阈值设高比如 0.45只有高置信度结果才推送给操作员查看。这种分层阈值策略既保证了追踪连续性又保证了用户体验。2.2 目标跟踪IOU 匹配与“锁车”逻辑跟踪器的核心任务只有一个把当前帧的检测框和已有的轨迹集合进行匹配匹配上的更新轨迹没匹配上的新建轨迹或删除轨迹。我采用的主流方案是 ByteTrack 框架核心匹配逻辑基于 IoU交并比。简单解释一下一个检测框和一个已有轨迹的预测框重叠得越多越可能是同一个目标。ByteTrack 的聪明之处在于它把检测框分成高置信度和低置信度两批先用高置信度框做第一轮匹配再用低置信度框做第二轮匹配。这样设计的好处是即使目标短暂被遮挡或自身置信度下降只要预测框还在附近跟踪器依然能维持它的轨迹。实际代码中我做了进一步优化给每个轨迹增加了一个状态机候选态、激活态、丢失态。候选态指轨迹刚建立只有连续若干帧都匹配成功才转为激活态避免把误检当成真实目标。激活态轨迹正常参与匹配和轨迹显示。丢失态指目标暂时失配允许它存活一段时间等待重新匹配。这里透露一个经验丢失态存活时间需要根据目标类型调整。行人的移动速度慢允许存活 30 帧车辆速度快允许存活 15 帧。为什么因为车辆移动快预测框漂移速度也快如果存活时间太长重新匹配到的检测框很可能是另一个目标造成ID切换。这个细节在文档里几乎找不到但直接影响目标的追踪稳定性。“锁车”逻辑是云台联动中的关键。当跟踪器确认某个目标是重点关注对象时比如越界人员、违停车辆决策层会把这个目标的轨迹状态标记为“锁定”。锁定状态下系统不会对这个目标做常规的丢失处理即使目标短暂失配也不会删除轨迹而是持续用运动模型外推位置同时发送控制指令驱动云台旋转。这个状态机设计避免了一个常见问题目标稍微抖动一下云台就失去目标。锁定后云台会有一个持续的小幅搜索运动直到重新检测到目标为止。ByteTrack 核心逻辑的简化示意如下class Tracker: def __init__(self): self.tracks [] self.next_id 1 def update(self, detections, frame): # 第一轮高置信度检测框匹配 high_conf [d for d in detections if d.conf 0.5] # 第二轮低置信度检测框匹配 low_conf [d for d in detections if 0.25 d.conf 0.5] # 对每个激活态轨迹用卡尔曼滤波预测当前位置 for track in self.tracks: if track.state active: track.predict() # 匹配流程计算检测框和轨迹预测框的IoU matches_high self.linear_assignment(high_conf, self.active_tracks(), threshold0.7) matches_low self.linear_assignment(low_conf, self.lost_tracks(), threshold0.5) # 更新匹配到的轨迹未匹配的检测框创建新轨迹 self.update_tracks(matches_high, matches_low, low_conf, high_conf)这段代码省略了详细的关联矩阵计算但展现了跟踪器的结构。这里最核心的调优点是那个匹配阈值。阈值设太高目标稍微变形就匹配不上设太低容易把两个邻近目标搞混。我针对无人机视角调试下来的经验值是激活态轨迹的匹配阈值设为 0.7丢失态设为 0.5。2.3 关键参数与调试参考跟踪系统的参数非常多但真正决定效果的骨干参数就那么几个。我在这里列出我实测用过的参数和调试思路供参考。先看输入侧。检测模型输入分辨率 1280推理频率 10 FPS置信度阈值低档 0.25、高档 0.45。再看关联侧。激活态 IoU 阈值 0.7丢失态 IoU 阈值 0.5丢失存活时长行人 30 帧、车辆 15 帧。卡尔曼滤波参数方面位置噪声取 1e-4速度噪声取 1e-2这个比值决定了滤波器是更信任检测结果还是更相信运动模型。速度噪声大滤波器会更依赖检测结果响应快但抖动明显速度噪声小轨迹更平滑但滞后严重。形态学参数值得提一下。无人机在高空俯拍时一个行人可能只有 20 乘 40 像素且很容易被树木、建筑遮挡。我加了一个基于轨迹历史速度的凸包预测当目标被假设遮挡时用最近 5 帧的平均速度外推一个凸包区域检测结果落到凸包区域内的目标优先匹配给该轨迹。这个方法对“人从树底下走过”的场景效果显著行人被树冠短暂遮挡后轨迹存活率提升了大约三成。我整理了一个实际参数对照表方便读者对照参考参数项推荐值范围调整方向说明检测输入分辨率960-1280分辨率越高检测越准但算力消耗增加检测频率10-15 FPS目标移动快则提高算力紧张则降低高置信度阈值0.45-0.55误报多时调高漏检多时调低低置信度阈值0.20-0.30主要用于遮挡场景维持轨迹激活态 IoU 阈值0.65-0.75目标形变明显时可调低丢失态 IoU 阈值0.45-0.55目标重新出现时匹配宽容度位置噪声1e-4 - 1e-3抖动大时调低滞后大时调高速度噪声1e-3 - 1e-2平滑性和响应速度的平衡行人丢失存活帧25-40遮挡频繁场景调大车辆丢失存活帧10-20车辆移动快存活太长容易串ID这些参数是孤立的但实际调试时要联动调整。比如调低了置信度阈值后检测框数量会增加如果 IoU 阈值保持不变可能会出现同一目标被两个轨迹反复抢占的情况。我一般建议按“检测漏检率、轨迹断裂率、ID切换率”三个指标来整体评估当前参数组合分项优化避免头痛医头。2.4 相对坐标与统一坐标检测和跟踪输出的都是像素坐标但巡检业务真正需要的是无人机能飞过去、云台能转过去的目标位置。这就涉及像素坐标到相对坐标的转换。第一步是把图像中心点和目标框中心点的偏差换算成云台角度偏差。公式不复杂水平角偏差 目标中心 x 坐标减图像中心 x 坐标再乘以水平像素焦距的倒数。垂直角偏差同理。关键在于这个换算是在目标距离未知的情况下做的换算出来的云台角度只能保证“目标在画面中心附近”没办法保证精确居中。想精确居中需要知道目标相对无人机的距离。距离怎么来我在项目中用了两种方案结合。第一种是基于单目视觉假设假设地面是平面已知无人机高度和相机俯仰角利用像素坐标反算目标在地面的位置。这个方法在 30 米高度以下误差尚可接受在 60 米以上误差明显变大。第二种是加入激光测距模块或者使用无人机自带的下视测距作为辅助信息显著提升距离精度。实际项目用的是第二种方案距离精度从大约 8 米误差缩小到 2 米以内云台锁定稳定性提升非常明显。还有一个坐标必须统一的问题。巡检项目往往涉及地图、地面站、飞控、云台四套坐标系如果不在系统层面统一人和车的位置呈现出来会完全对不上。我采用的做法是建立一个统一的经纬度坐标系所有模块输出前先转换到这个坐标系。无人机经纬度由飞控提供目标经纬度由目标相对无人机位置叠加无人机自身位置计算得出。地面站收到的是统一坐标呈现在地图上的点和实际位置偏差能控制在几米以内已经满足巡检业务对“异常事件发生位置”的定位需求。3. 工程落地从单机到联合巡检的实操要点3.1 单机自主巡检怎么跑单机巡检是最小可行系统先把一条航线跑通、跑稳才能谈多机协同。单机系统的运行逻辑用一句话概括无人机沿预设航点飞行检测到目标后进入追踪模式追踪结束返回原航线继续巡检。我在项目中遇到的第一个坑是航线执行和目标追踪之间的“争夺”。如果无人机正在执行航线系统突然发现了一个需要重点观察的目标飞控应该继续执行航线还是转向追踪这个决策不能简单交给飞控需要在决策层做状态管理。我的做法是设置一个任务优先级默认执行巡检航线当锁定目标出现时插入追踪任务追踪结束或目标丢失后自动恢复原航线。这个状态转换必须做成平滑的否则飞控会频繁切换模式导致机体震动。我用的方案是航线暂停后先让无人机悬停 1 到 2 秒稳定姿态再执行追踪转向动作追踪完成回到原航线的当前位置后重新激活航线任务。整个过程从操作员视角看就是飞机在目标上方短暂停留了一下然后继续飞。单机巡检还有一个很容易漏掉的事电池和航线时长的匹配。巡检航线的长度必须预设安全余量因为追踪任务会额外消耗飞行时间。我在航线规划时按照正常飞行时间乘以 1.3 的系数来预留电量确保飞机在任何时刻都有足够电量返回起飞点。这个系数是我从实际项目中试出来的不同机型、不同风况会略有差异但取 1.3 作为默认值要比取 1.1 稳妥得多。3.2 多机联合巡检的任务调度多机联合巡检比单机复杂一个维度核心问题变成数据融合和任务分配。数据融合方面核心原则是避免多名飞机同时追踪同一个目标。我的方案是建立目标的全局唯一 ID。当检测器输出一条目标轨迹时本机上生成局部 ID如果这个目标进入了另一架飞机的视野且被识别为同一目标就会发生串扰。解决思路是把轨迹数据统一上传到地面站由地面站做全局匹配匹配成功就给目标分配全局 ID并通知相关飞机停止对该目标的重复告警。多机任务分配我用了一个简单但有效的策略距离优先。当某架飞机发现目标异常后如果目标超出当前飞机的有效观测范围地面站就把该目标的任务移交给离目标最近的另一架飞机。这个策略实际跑起来效果不错但它依赖一个前置条件地面站必须实时维护各飞机的坐标和电量信息。当收到目标交接命令时接手机需要先飞到目标附近建立观测视角再启动追踪。交接过程如果出现中断会直接造成目标丢失所以交接指令需要带一个重试机制建议至少重试 2 到 3 次。还有一个容易被忽略的细节多机并发时的通信带宽规划。每架飞机都在持续上传视频流或者关键帧如果同时传输全分辨率视频通信链路会直接打满。我的做法是调整上传策略机上的视频流只在本地录制远程地面站默认只接收检测框、轨迹、告警等元数据只有操作员主动点击某个画面时才切换全视频流。这样通信压力大幅下降多机并发的稳定性显著提升。联合巡检实际落地中最大的坑是时间同步。两架无人机同时看到同一个目标如果它们的时间基准不一致地面站在做全局匹配时会发现同一目标的位置数据对不上。最简单的解决办法是在无人机端统一使用 GPS 时间每一帧检测结果都带上 GPS 时间戳。地面站按时间戳对齐多机数据目标位置的一致性立刻得到大幅改善。3.3 日志、回放与验收闭环很多研发人员觉得日志是最无聊的部分但在巡检项目里日志和回放系统决定项目能不能交付。原因很简单。巡检系统的价值是“事后可追溯”一旦现场发生异常事件甲方关心的不是当时系统实时响应了什么而是事后能不能把当时的画面、轨迹、告警全部调出来作为证据。如果没有周密的日志系统系统跑得再流畅验收时也会遇到难以证明自身价值的尴尬。我的日志设计方案有三层。第一层是原始视频流在机载存储中保留足够时间第二层是结构化日志记录每一帧的检测结果、跟踪器状态、目标轨迹点、云台角度、坐标转换参数第三层是事件日志记录告警发生时间、告警类型、锁定目标ID、上报结果。三层层层递进形成了一个完整的证据链。这里要特别强调一次日志格式设计。巡检日志需要支持事后回放回放的逻辑是读轨迹点 → 定位视频时间戳 → 截取对应画面 → 叠加显示目标框。如果日志里只记录检测结果而没记录跟踪器状态回放时画面上就会出现检测框跳跃的问题因为那个是原始检测结果而非平滑后的轨迹状态。正确的做法是在日志里同时记录跟踪器输出结果回放时直接显示跟踪轨迹操作员看到的画面才能和真实运行时一致。日志回放系统还有另一个隐藏价值目标跟踪算法的迭代调优。每次现场飞行之后我都会把日志拉回实验室用回放系统逐帧检查算法在哪一帧丢失了目标、在哪一帧产生了ID切换。这种基于真实数据的复盘效率远高于随机去现场试飞。我建议任何做巡检项目的人都要把这个回放系统当作第一优先级工程任务来开发。3.4 资源占用与机上推理优化算法跑在机上而不是地面站是巡检项目的必然趋势。原因是通信链路不可靠如果依赖地面站实时推理一旦链路抖动目标追踪能力会瞬间归零。但机上推理意味着算力受限必须做细致的资源优化。我在项目实施中采用的核心优化手段有三个。第一是 TensorRT 加速部署把训练好的检测模型转换成推理引擎在嵌入式平台上帧率能提升大约 2 到 3 倍。第二是输入尺寸动态调整在远距离巡检时用 960 分辨率减少计算量进入追踪模式后自动切换回 1280 分辨率保证锁定精度。第三是推理频率自适应巡航阶段固定 10 FPS追踪阶段提高到 15 FPS云台联动时甚至临时提高到 20 FPS。这三项优化叠加之后机上推理占用从接近满核降到了总体算力的六成左右留给飞控、云台控制和通信模块的算力余量充足。我还给推理模块加了单独的看门狗如果一次推理耗时超过 200ms看门狗自动强制降低输入分辨率保证推理不堵塞。机上算力分配还有一个容易踩的坑多线程竞争。检测、跟踪、坐标转换、云台控制四件事如果都在主循环里跑任何一个模块阻塞都会拖垮整个链路。我的处理方案是用多线程加队列解耦相机线程推帧入队检测线程取帧推理跟踪器单独线程处理检测结果控制线程监听跟踪状态。四个线程之间通过队列传递消息任何线程挂掉都不会阻塞其他线程。这个架构在单机上实测运行非常稳定。4. 常见问题与排查技巧实录4.1 目标丢掉或 ID 频繁跳变目标丢失和 ID 跳变是追踪系统最典型的两类问题但它们成因不同、解法也不同。目标丢失常见原因有三类。第一类是检测漏检目标尺寸太小、被遮挡或者光照条件差检测模型根本没输出。这种问题优先调整阈值和检测频率或者增加红外通道做补充。第二类是预测偏差过大目标做了检测模型没预料到的突然转向卡尔曼预测框跑到远处去了导致匹配失败。这种情况可以适当增大速度噪声让滤波器更信任当前检测结果。第三类是帧率过低目标移动速度太快两帧之间目标位移太大检测框和预测框的 IoU 低于阈值。解决办法是提高检测频率。ID 跳变的根源是匹配错误。最常见的是临近目标交错两个目标擦肩而过时跟踪器把 A 的轨迹匹配到了 B 的检测框两个 ID 发生交换。这个问题解决起来比较棘手常规 IoU 匹配解决不了。我的经验是加入外观特征辅助匹配——给每个轨迹保存一个特征向量匹配时同时考虑 IoU 和外观相似度。虽然这会增加一些计算开销但显著减少交错场景的 ID 交换次数。4.2 云台瞄准滞后或过冲云台锁定目标时的滞后和过冲本质上是一个控制问题但很多人会把原因归到跟踪算法上。滞后表现为云台转动滞后于目标移动目标始终位于画面偏边缘位置过冲表现相反目标在画面中心附近来回摆动。滞后最常见的原因是云台控制指令频率太低。如果跟踪器的更新频率是 10Hz而云台控制要求 50Hz 的指令流那么云台的动作天然会有 100ms 的延迟。我的做法是跟踪器每次更新时不直接输出目标位置而是输出目标运动轨迹的预测值云台控制器每 10ms 取一次预测位置并发送控制指令。这样云台得到了平滑连续的目标轨迹滞后问题消除明显。过冲问题多半出在云台 PID 参数上面。云台控制面对的是大惯量系统比例增益过大会让云台冲过头。我调试时采用的做法是先固定积分和微分参数单独调比例增益观察到轻微的过冲后回调 20%再微调微分参数抑制超调。这个过程通常需要现场反复测试建议开发一套云台控制参数的远程调节工具不需要每次改参数都重新编译固件。4.3 告警风暴与置信度误报告警风暴是巡检项目运营阶段高频出现的问题。系统把每个被识别到的目标都当成异常目标上报结果地面站屏幕上告警弹窗堆满操作员只能被迫屏蔽所有告警。这是非常典型的“系统跑得没问题、业务却没法用”的案例。我的经验是给告警模块加三层过滤。第一层是置信度过滤低于高阈值的检测结果不上报告警。第二层是轨迹成熟度过滤只有持续追踪 3 秒以上且轨迹稳定的目标才可能触发告警避免单帧误检造成误报。第三层是业务规则过滤比如当目标出现在指定禁止区域内才告警在允许区域内仅记录不告警。置三层过滤后误报率大幅下降。我印象最深的一次现场测试原始检测每天会触发上百次告警加完过滤规则后单天有效告警量降到了 10 条以内操作员终于愿意把告警声音开起来了。做过滤时不要求一步到位可以先从置信度开始逐层丰富规则。4.4 实战勘误与调试禁忌最后分享几条我在项目实战中总结出来的调试禁忌。第一条不要在真机上边飞边调算法参数。飞机在天上定位问题和停机调参的代价都很高所有参数先用日志回放系统离线调优确认无误再上真机验证。第二条不要忽视光照条件变化。无人机巡检的时间跨度往往从早上持续到傍晚同一个位置的同一目标不同时刻的检测置信度会差别很大。我后来给系统加了光照判断模块画面过亮或过暗时自动切换曝光参数和检测阈值。第三条不要用单一测试视频评价系统。现场场景千变万化单一测试视频只能验证特定场景下的效果建议至少准备三种不同场景的测试素材按场景分别评估后再合并。只有逐个场景把问题解决整个系统的稳定性才有保障。我个人的体感是人车追踪项目里算法只占四成工作量六成精力都在工程化打磨上——怎么把检测结果稳定呈现、怎么让云台跟手、怎么让告警不扰人、怎么让日志可复现、怎么在多机并发下不打架。把这些事做扎实从现场交付的角度来看远比在算法指标上多刷 1 个百分点更有价值。这套路子在多个巡检项目里跑下来确实很稳。
