RK3588边缘AI实现111FPS无人机电力巡检：YOLOv8异步处理系统全解析

1. 项目概述：当无人机巡检遇上边缘AI

最近在折腾一个挺有意思的项目，核心目标是在一块RK3588开发板上，让YOLOv8目标检测模型跑到111 FPS，并构建一套完整的异步视频处理系统，最终落地到无人机自主电力巡检的场景里。这听起来像是一个纯粹的“炫技”性能数字，但背后其实是一系列非常实际的工程挑战和需求。

电力巡检，尤其是高压输电线路的巡检，是个苦差事。传统的人工巡检需要巡线员翻山越岭，效率低、风险高、成本巨大。无人机巡检的出现是个巨大的进步，但早期的无人机巡检更像是“会飞的相机”，拍完照片和视频，还得人工回来看，发现问题滞后，而且海量的视频数据回传和人工筛查本身就是个新负担。所以，行业一直在追求“机载实时智能分析”——让无人机在飞行的过程中，自己“看懂”画面，实时发现缺陷（比如绝缘子破损、金具松脱、导线上有异物等），并立刻上报或标记。

这就是我们这个项目的出发点。RK3588作为一款性能强劲的国产边缘计算SoC，拥有强大的CPU、NPU和视频编解码能力，是机载AI的理想平台。YOLOv8则是当前目标检测领域的“当红炸子鸡”，在精度和速度上取得了很好的平衡。但直接把YOLOv8模型往RK3588上一丢，离“111 FPS”和“实时系统”还差得远。这里面的核心矛盾在于：视频流是连续的，而AI推理是批量的、有延迟的；视频的采集、解码、预处理、推理、后处理、结果渲染/发送，这些环节如果串行执行，帧率会被最慢的那个环节（通常是推理）卡死，延迟也会累积得无法接受。

因此，“异步视频处理系统”就成了关键。它的核心思想是“流水线”和“解耦”，让各个处理模块并发工作，像工厂的流水线一样，一帧图像在推理，下一帧已经在预处理，再下一帧正在解码，互不等待。最终的目标是让整个系统的吞吐量（FPS）逼近甚至超过单个AI推理环节的峰值速度，同时保持稳定的低延迟。111 FPS这个数字，就是在我们特定模型（轻量化的YOLOv8n）、特定输入分辨率（比如416x416）和充分优化后，整个异步流水线能达到的稳定吞吐量。这意味着无人机每秒可以分析超过100帧高清画面，对于快速飞行的巡检无人机来说，这大大提升了缺陷检测的覆盖率和实时性。

2. 核心需求与方案选型背后的逻辑

为什么是RK3588 + YOLOv8 + 异步架构？这个组合不是拍脑袋定的，而是针对电力巡检这个具体场景，权衡了性能、功耗、成本、开发难度和生态后的结果。

2.1 硬件平台：为什么是RK3588？

在边缘AI设备选型时，我们主要看几个方面：算力（特别是AI算力）、功耗、接口丰富度和软件生态。

• 算力与能效比：RK3588集成了6TOPS算力的NPU（神经网络处理单元）。对于轻量化的YOLOv8n模型，这绰绰有余。更重要的是，它的CPU是4xA76+4xA55的大小核架构，既能处理重负载，也能在轻负载时用小核省电。对于长时间飞行的无人机，功耗和发热是硬约束，RK3588在这方面的表现比较均衡。
• 强大的多媒体能力：它内置了强大的视频编解码器（VPU），支持多路4K视频的同步编解码。这对于需要处理无人机高清图传视频流的场景至关重要。我们可以用VPU进行高效的H.264/H.265硬件解码，把CPU和NPU解放出来去做更重要的AI推理。
• 丰富的接口：RK3588拥有充足的PCIe、USB、MIPI等接口，可以方便地连接无人机的飞控、图传模块、各种传感器（如激光雷达避障）等，实现高度集成。
• 国产化与生态：在当前的产业环境下，采用国产主控平台是一个重要的考量点。瑞芯微的RKNN-Toolkit2工具链经过几年发展，对PyTorch、TensorFlow、ONNX等模型格式的转换支持已经比较成熟，社区资源和案例也越来越多，降低了开发门槛。

注意：选择RK3588也意味着要直面其生态的“坑”。比如，RKNN SDK的版本与模型算子支持的匹配问题、内存访问的优化、不同核心间的任务调度等，都需要投入精力去研究和调试，不像在NVIDIA Jetson平台上那么“傻瓜化”。

2.2 算法模型：为什么是YOLOv8及其轻量化？

电力巡检的目标相对固定，主要是输电线路上的各种部件（绝缘子、均压环、防震锤、导线等）及其缺陷。这类目标通常具有特定的形状和纹理，但尺寸变化大（远近不同），且背景复杂（天空、山林）。

• YOLOv8的综合优势：YOLOv8在YOLO系列中是一个集大成的版本，它提供了分类、检测、分割三种任务模型，结构清晰，代码友好。其检测模型在精度和速度的权衡上做得很好，自带多种尺度的模型（n, s, m, l, x），方便我们根据硬件能力选择。其Anchor-Free的设计和更高效的标签分配策略，使得它在处理尺寸变化大的目标时表现更稳定。
• 轻量化的必然性：机载设备的计算资源和功耗是严格受限的。我们不可能在无人机上部署一个YOLOv8x模型。通常的选择是YOLOv8n（nano）或YOLOv8s（small）。我们的目标是111 FPS，这几乎注定要从YOLOv8n起步，甚至需要对其进行进一步的剪枝、量化等优化。轻量化不是在牺牲精度，而是在给定的硬件预算下，寻找精度损失最小、速度提升最大的那个最优模型。
• 针对性的改进：对于电力巡检，我们还可以对YOLOv8进行一些针对性的改进。例如，由于巡检目标多为细长型或小目标（远处的绝缘子），可以借鉴一些针对小目标检测的改进，如添加注意力机制（像SimAM、无参数注意力）到Neck部分，或者修改特征融合网络（如用BiFPN替代PANet），在不显著增加计算量的前提下提升对小缺陷的敏感度。损失函数方面，可以尝试替换CIoU为更适应我们目标形状的EIoU或SIoU。

2.3 系统架构：为什么必须是异步处理？

这是本项目从“一个demo”升级为“一个可用系统”的关键。一个简单的同步处理流程是这样的：取流 -> 解码 -> 预处理 -> 推理 -> 后处理 -> 渲染/发送。假设推理耗时10ms，那么整个流程一帧就需要至少10ms，理论最高FPS就是100。这还没算上其他环节的时间，实际会更低。而且，如果某一帧推理偶然慢了（比如15ms），后续所有帧都会被阻塞，造成卡顿。

异步处理系统的核心是生产者-消费者模型和线程/进程池。我们将整个流程分解为多个独立的阶段，每个阶段由一个或多个工作线程（或进程）负责，阶段之间通过线程安全的队列（如Python的queue.Queue， C++的moodycamel::ConcurrentQueue）传递数据（通常是帧图像和对应的元数据）。

一个典型的设计如下：

1. 视频采集/解码线程：专责从USB摄像头或网络拉流（RTSP）中获取码流，并调用RK3588的VPU进行硬件解码，将解码后的帧放入“原始帧队列”。
2. 预处理线程池：多个线程从“原始帧队列”取帧，进行尺寸缩放、颜色空间转换（BGR2RGB）、归一化等操作，为NPU推理做准备，然后将处理后的张量放入“推理输入队列”。
3. 推理线程（可多个）：从“推理输入队列”取张量，调用RKNN接口在NPU上进行推理，将原始输出张量放入“推理输出队列”。这里是关键，NPU的推理是异步的，RKNN的inference接口通常是非阻塞的，我们可以通过回调或轮询方式获取结果，实现推理线程内部也流水线化。
4. 后处理线程池：从“推理输出队列”取推理结果，进行解码（将模型输出的网格信息解码成具体的框坐标、类别和置信度），执行非极大值抑制（NMS），最终得到检测框列表，放入“结果帧队列”。
5. 渲染/发送线程：从“结果帧队列”取帧和对应的检测结果，进行绘制（画框、标标签），然后通过HDMI显示，或者通过RTMP推流、UDP发送给地面站，也可以将结构化结果（框坐标、类别）通过串口或网络发送给飞控。

这样设计的好处是：

• 高吞吐：当推理线程在处理第N帧时，预处理线程已经在处理第N+1帧，解码线程在获取第N+2帧。系统的整体FPS由最慢的阶段平均耗时决定，而不是单帧的总耗时。只要队列管理得当，系统吞吐量可以非常接近推理阶段的极限速度。
• 低延迟：虽然单帧走完全程的时间可能没变甚至略增（因为队列等待），但系统的响应延迟更稳定。因为渲染线程总是拿到最新一帧的可用结果，避免了因推理波动带来的卡顿感。对于无人机控制，稳定的低延迟比绝对的低延迟更重要。
• 资源充分利用：CPU的多核可以并行处理解码、预处理、后处理等任务，NPU也能被持续喂饱数据，避免空转。

3. 从模型训练到RKNN部署的全链路实操

3.1 数据集准备与模型训练

电力巡检没有完全通用的公开数据集，通常需要自己采集和标注。

1. 数据采集：使用巡检无人机，在不同天气、光照、角度下拍摄输电线路的高清视频或照片。重点覆盖各类缺陷样本（绝缘子自爆、锈蚀、均压环缺失、导线上悬挂异物等）。
2. 数据标注：使用LabelImg、CVAT等工具进行标注。类别需要仔细定义，例如：insulator（完好绝缘子）、broken_insulator（破损绝缘子）、damper（防震锤）、spacer（间隔棒）、bird_nest（鸟巢）等。标注质量直接决定模型上限。
3. 数据增强：YOLOv8训练内置了丰富的数据增强（Mosaic, MixUp等）。针对巡检场景，可以额外增加模拟云雾、模拟雨滴、亮度对比度随机变化等增强，提升模型在恶劣天气下的鲁棒性。
4. 模型训练与剪枝：
   • 使用Ultralytics YOLOv8框架，从yolov8n.pt预训练模型开始微调。
   • 训练后，可以使用一些剪枝工具（如Torch-Pruning）对模型进行结构化剪枝，移除冗余的通道或层。一个实操技巧：剪枝后必须进行微调（fine-tune），否则精度会急剧下降。微调时的学习率要设得非常小（如初始lr的1/10到1/100）。
   • 我们实验发现，对YOLOv8n的Backbone部分进行适度剪枝，在精度损失小于1%的情况下，能将参数量和计算量减少20%以上，这对边缘部署非常有利。

3.2 模型转换与RKNN优化

这是将PyTorch模型“翻译”成RK3588 NPU能理解的指令的关键一步，也是最容易出问题的一步。

1. 导出ONNX：使用YOLOv8的export功能导出ONNX模型。务必指定opset=12或更高，并启用动态轴（dynamic=True），以便后续部署时支持可变输入尺寸（虽然为了性能，我们通常会固定一个尺寸）。

   yolo export model=yolov8n_custom.pt format=onnx opset=12 dynamic=True

2. ONNX简化与优化：使用onnx-simplifier工具对导出的ONNX模型进行简化，合并冗余算子，这对RKNN转换的成功率有很大提升。

   python -m onnxsim yolov8n_custom.onnx yolov8n_custom_sim.onnx

3. RKNN转换：使用RKNN-Toolkit2进行转换。这里需要编写一个Python转换脚本。

   from rknn.api import RKNN rknn = RKNN(verbose=True) # 配置 rknn.config(mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform='rk3588') # 注意：YOLOv8的输入通常是0-1范围，但这里我们配置了归一化。预处理时需保持一致。 # 加载ONNX模型 ret = rknn.load_onnx(model='yolov8n_custom_sim.onnx') # 构建RKNN模型 ret = rknn.build(do_quantization=True, dataset='./dataset.txt') # 量化是关键！ # 导出RKNN模型 ret = rknn.export_rknn('./yolov8n_custom.rknn')

   关键点——量化：do_quantization=True是必须的。NPU通常使用INT8精度进行推理，这能大幅提升速度、降低功耗和内存占用。量化需要一个校准数据集（dataset.txt里指定的一系列图片），用于统计激活值的分布。校准集最好是训练集的一个子集，能代表真实数据分布。
4. 模型精度验证：在PC上使用RKNN-Toolkit2的模拟推理功能，或者在RK3588开发板上加载RKNN模型，用测试集跑一遍，对比与原PyTorch模型精度的差异（mAP）。如果精度下降太多（>3%），需要检查量化校准集是否合适，或者尝试使用更复杂的量化算法（如RKNN-Toolkit2可能支持的不同量化策略）。

3.3 异步处理系统的C++核心实现

为了极致性能，系统的核心流水线我们使用C++实现。Python更适合做原型和工具链，但在资源紧张的嵌入式环境，C++能提供更确定的内存和性能控制。

1. 框架选择：我们采用生产者-消费者模式，使用std::thread和线程安全队列。也可以考虑使用更高级的框架如Intel TBB或Microsoft PPL，但为了依赖简洁，我们自实现。
2. 队列设计：队列中存储的不仅是图像数据，还有帧号、时间戳等元数据。我们使用一个自定义的FramePacket结构体。

   struct FramePacket { uint64_t frame_id; int64_t capture_ts; // 采集时间戳 cv::Mat raw_frame; // 原始帧（解码后） cv::Mat net_input; // 预处理后的张量 std::vector<DetectionResult> results; // 检测结果 // ... 其他状态标志 };

   使用std::shared_ptr<FramePacket>来传递，避免拷贝开销。
3. 解码模块：利用RK3588的MPP（Media Process Platform）库进行硬件解码。MPP解码后得到的是RK_S32格式的帧缓冲区，我们需要将其转换为OpenCV的Mat对象。这里有个坑：MPP解码输出可能是NV12格式，而模型输入需要RGB，这个颜色转换可以在预处理阶段用CPU做，但更优的方案是利用RK3588的RGA（Raster Graphic Acceleration）硬件加速器来做缩放和颜色空间转换，能极大减轻CPU负担。
4. 预处理与后处理集成：预处理（缩放、归一化）和后处理（解码输出、NMS）是计算密集型的。我们将其实现为独立的类，并在线程池中调用。为了加速，可以：
   • 使用OpenCV的UMat（如果支持OpenCL）或直接操作内存。
   • 将后处理中的NMS等操作，尝试用Neon指令集（ARM SIMD）进行优化。
   • 最重要的：确保预处理输出的内存布局（例如NHWC）与RKNN模型期望的完全一致，否则会导致推理错误或性能下降。
5. 推理模块封装：封装RKNN的C接口。关键点是实现异步推理：

   class RKNNInferencer { public: bool asyncInfer(std::shared_ptr<FramePacket> packet) { // 1. 设置输入 rknn_input inputs[1]; inputs[0].index = 0; inputs[0].buf = packet->net_input.data; inputs[0].size = packet->net_input.total() * packet->net_input.elemSize(); inputs[0].pass_through = FALSE; inputs[0].type = RKNN_TENSOR_UINT8; // 根据量化类型定 inputs[0].fmt = RKNN_TENSOR_NHWC; rknn_inputs_set(ctx, 1, inputs); // 2. 异步运行 int ret = rknn_run(ctx, nullptr); // 非阻塞调用 if (ret != 0) { /* 错误处理 */ } // 3. 将packet与这次推理关联，并放入“进行中”队列 pending_queue_.push(packet); return true; } void waitAndGetOutput() { // 4. 轮询或等待信号，获取推理完成的结果 int ret = rknn_outputs_get(ctx, 1, outputs, nullptr); if (ret == 0) { auto packet = pending_queue_.pop(); // 5. 将outputs中的数据解析到packet->results decodeOutput(outputs, packet->results); // 6. 将packet放入后处理队列 postprocess_queue_->push(packet); } // 7. 释放outputs rknn_outputs_release(ctx, 1, outputs); } private: rknn_context ctx; ThreadSafeQueue<std::shared_ptr<FramePacket>> pending_queue_; std::shared_ptr<ThreadSafeQueue<std::shared_ptr<FramePacket>>> postprocess_queue_; };

   这样，主线程可以不断调用asyncInfer喂数据，而另一个线程专门调用waitAndGetOutput取结果，实现了推理环节内部的流水线。

4. 性能调优与踩坑实录

目标是111 FPS，但一开始可能只有60-70 FPS。这最后的几十帧提升，需要精细的调优。

4.1 性能瓶颈分析工具

首先得知道慢在哪里。

• 系统级：使用top,htop,vmstat观察CPU各核心利用率。理想情况是所有核心都处于较高但非饱和的利用率。如果某个核心持续100%，可能就是瓶颈。
• 进程/线程级：使用perf工具进行性能剖析。

  perf record -g -p <pid> # 采样 perf report # 查看热点函数

• 自定义打点：在代码关键路径（如入队、出队、推理开始、推理结束）打上高精度时间戳（std::chrono::high_resolution_clock），计算各阶段耗时，输出统计报告。这是最直接有效的方法。

4.2 常见性能瓶颈与优化手段

1. 内存拷贝瓶颈：这是嵌入式开发中最常见的性能杀手。在队列间传递cv::Mat或数据缓冲区时，务必使用移动语义（std::move）或共享指针，避免深拷贝。解码后的帧缓冲区，尽量直接传递给后续模块处理，而不是先拷贝一份。
2. 锁竞争瓶颈：线程安全队列的锁如果竞争激烈，会严重拖慢速度。优化方法：
   • 使用无锁队列（如moodycamel::ConcurrentQueue），但实现复杂。
   • 使用多队列，例如为每个生产者-消费者对设立独立的队列，减少共享数据。
   • 批量操作：一次从队列中取出多个帧进行处理，分摊锁开销。
3. NPU利用率不足：如果推理线程总是等数据，说明预处理慢了。可以增加预处理线程池的线程数。反之，如果预处理队列总是满的，推理线程跟不上，可以尝试：
   • 模型量化：确保使用了INT8量化，这是最大的性能提升点。
   • 调整NPU频率：通过RK3588的驱动接口适当提升NPU的工作频率（需注意散热）。
   • 批处理（Batch Inference）：RKNN支持批量推理。如果单帧推理NPU算力有剩余，可以尝试将2-4帧打包成一个Batch送入NPU，能显著提升吞吐量。但这会增加单次推理的延迟，需要根据场景权衡。对于111 FPS的实时视频，通常单帧推理更合适。
4. CPU与NPU的协同瓶颈：数据在CPU内存和NPU内部内存之间的搬运（DMA）也有开销。确保输入输出内存使用的是RKNN API推荐的RKNN_TENSOR_NATIVE格式或RKNN_TENSOR_UINT8格式，并且内存已经过对齐，这能帮助驱动进行更高效的DMA传输。
5. 视频解码与显示瓶颈：
   • 解码：确保使用MPP硬解，并设置合适的缓存策略，避免因等待I/O而阻塞。
   • 显示/推流：如果需要在本地HDMI显示，使用DRM（Direct Rendering Manager）或Wayland直接渲染，比通过OpenCV的imshow高效得多。如果是推流，使用硬件编码器（如MPP的H.264编码）来减轻CPU压力。

4.3 我们遇到的“坑”与解决方案

• 坑1：RKNN量化后精度暴跌
  • 现象：转换后的RKNN模型在测试集上mAP下降了超过10%。
  • 排查：对比了PyTorch模型和RKNN模型在同一张图片上的输出，发现某些类别的置信度分布完全不对。
  • 解决：问题出在校准数据集上。最初只用了几十张图片，且图片多样性不足。我们重新准备了包含500张图片的校准集，覆盖了所有类别和各种场景。同时，在RKNN转换配置中，尝试了不同的量化算法（如normal改为dfp），最终精度损失控制在2%以内。
• 坑2：异步推理偶尔出现结果错乱
  • 现象：检测框和画面内容对不上，像是帧序乱了。
  • 排查：在FramePacket中增加了frame_id并打印日志，发现pending_queue_中取出的packet和rknn_outputs_get返回的结果不是一一对应的。原因是rknn_run是异步的，但rknn_outputs_get获取的是最早完成推理的那个结果，不一定是刚刚asyncInfer的那一帧。
  • 解决：RKNN的异步推理需要更精细的管理。我们为每次rknn_run分配一个唯一的req_id，并在rknn_outputs_get时指定这个req_id来获取对应结果。或者，更简单的方法是使用同步推理，但增加推理线程的数量（例如2个），让多个推理线程并行工作，也能充分利用NPU。我们最终采用了双推理线程的同步模式，因为对于YOLOv8n，单次推理时间很短（~9ms），同步调用简化了逻辑，且两个线程足以让NPU保持忙碌。
• 坑3：系统运行一段时间后FPS逐渐下降
  • 现象：刚启动时FPS能达到110，运行几分钟后降到80左右。
  • 排查：使用free命令观察内存，发现可用内存持续减少。怀疑是内存泄漏。
  • 解决：使用valgrind检查，发现在解码模块，从MPP缓冲区转换到cv::Mat时，没有正确释放MPP的MBuffer。在C++代码中，所有动态分配的内存（特别是来自C库的内存）都需要手动管理生命周期。修复内存释放逻辑后，FPS保持稳定。
• 坑4：在复杂背景（如树林）下误检率高
  • 现象：天空背景下检测很好，但当导线背景是茂密树林时，经常把树叶团误检为“鸟巢”。
  • 解决：这不是代码bug，是模型泛化能力问题。我们做了两件事：1) 在数据集中增加了大量背景为树林的负样本（即没有目标的图片），并在训练时适当提高负样本的权重。2) 在后处理中，对“鸟巢”这类特定类别，提高了置信度阈值（从0.25提高到0.5），并增加了基于形状（长宽比）的简单过滤规则。虽然有点“硬编码”的味道，但在工程上快速有效。

5. 系统集成与无人机巡检工作流

将这套系统集成到无人机上，才是项目的最终闭环。

5.1 硬件集成与供电

1. 核心计算单元：采用基于RK3588的核心板（如Rock 5B或厂商定制板），搭配载板。载板需要提供：
   • 至少一个MIPI CSI接口，用于连接无人机的云台相机。
   • USB或以太网接口，用于接收来自无人机数传链路的RTSP视频流（如果相机不直接连接）。
   • UART或CAN接口，用于与飞控通信，发送检测结果或接收指令。
   • 稳定的电源输入（通常12V），并设计好电源管理，防止电压波动导致系统重启。
2. 散热设计：RK3588在满负荷运行时发热可观。必须加装散热片甚至小型风扇。在无人机狭小空间内，风道设计很重要。
3. 减重与加固：选择轻量化的外壳，所有连接器做好防松处理，以应对无人机起降和飞行中的振动。

5.2 与飞控的通信协议

无人机飞控（如PX4, ArduPilot）通常通过MAVLink协议与外部设备通信。我们的RK3588系统可以作为一个“MAVLink Companion Computer”。

1. 通信链路：通过UART串口连接飞控的Telem2口。
2. 消息定义：
   • 下行（RK3588 -> 飞控）：当检测到缺陷时，发送自定义的MAVLink消息（例如MAVLINK_MSG_ID_VISION_POSITION_DELTA或自定义消息），包含缺陷类型、GPS位置（可从飞控获取或自身有GPS模块）、置信度、图片帧索引等信息。
   • 上行（飞控 -> RK3588）：接收飞控发送的无人机当前GPS位置、高度、姿态等信息，可用于辅助分析或地理标注。
3. 飞控端逻辑：飞控接收到缺陷消息后，可以触发几个动作：
   • 记录航点：在飞行日志中标记该点，方便后续复查。
   • 悬停报警：控制无人机悬停，并通过数传电台向地面站发送警报，通知飞手注意。
   • 自动复拍：执行一个小的机动，对疑似缺陷点进行多角度拍摄确认。

5.3 完整巡检工作流

1. 任务规划：在地面站软件上规划好巡检航线（waypoints），确保相机能覆盖所有待检线路。
2. 自主起飞与巡航：无人机按航线自动飞行，云台相机保持对线路的锁定拍摄。
3. 实时机载分析：RK3588系统持续接收视频流，以111 FPS的速度进行实时分析。
4. 缺陷识别与上报：一旦识别到预设的缺陷（置信度超过阈值），立即通过串口上报给飞控。飞控记录事件并通知地面站。
5. 数据归档：除了实时结果，系统也可以按时间或地理位置，将原始视频、分析结果和元数据保存到机载SD卡中，供后续深度学习模型迭代训练使用。
6. 安全返航：任务完成后自动返航。

5.4 实测效果与未来展望

在实际的测试飞行中，这套系统在晴天、微风条件下，对绝缘子串、防震锤等大部件的识别率（AP@0.5）能达到95%以上，对绝缘子自爆这类缺陷的识别率约85%。111 FPS的处理能力确保了即使在无人机高速巡航（约10m/s）时，也不会因为处理速度跟不上而漏检。延迟方面，从一帧图像进入系统到产生结果，平均延迟控制在80ms以内，对于非直接用于闭环控制（如避障）的检测任务来说，完全可接受。

当然，这只是一个起点。后续还有很多可以深化的方向：比如引入更轻量的Transformer-based检测模型、实现真正的端到端自动缺陷分类和评级、利用IMU数据进行图像防抖以提升识别率、甚至探索多机协同巡检的架构。每一次从实验室到野外飞场的测试，都会暴露出新的问题，也带来新的优化灵感。边缘AI落地的魅力，就在于这种软硬件紧密结合、不断逼近物理极限的挑战过程。