嵌入式AI与计算机视觉

引言：边缘智能体正在从“能跑模型”变成“能做闭环” 过去几年，端侧 AI 的讨论大多停留在模型能不能塞进设备：摄像头能不能跑目标检测，MCU 能不能跑唤醒词，工业网关能不能离线识别异常。到了 2025 和 2026 年，问题已经变了。现在更值得关心的是：设备能否在本地理解环境、调用工具、管理状态，并在网络不稳定甚至完全离线时完成一个业务闭环。 这也是边缘硬件和 AI Agent 结合后最有价值的地方。真正落地时，模型只是其中一层，摄像头、麦克风、传感器、NPU、DSP、缓存、队列、OTA、日志和安全策略都会影响最终效果。如果只把注意力放在参数量和 TOPS 上，很容易做出一个演示很好看、现场不稳定的系统。 本文关注的主题是 把 ESP32-S3 当作常开感知节点，用低功耗语音、低帧率视觉和本地规则 Agent 完成离线闭环。 它不是简单地把云端大模型搬到开发板上，而是围绕功耗、内存、实时性、隐私、硬件加速和工程可维护性重新设计一套端侧智能系统。 端侧智能体参考架构 输入设备Camera / MicSensor / Bus 预处理ISP / DSP滤波 / 特征 模型推理NPU / GPUINT8 / Cache Agent 决策状态 / 工具策略 / 记忆 设备执行GPIO / UARTMQTT / CAN 云端同步日志 / OTA模型更新 从传感输入到动作反馈，端侧 Agent 需要处理的不只是模型推理。 一、先把系统边界画清楚 边缘 Agent 与普通边缘推理最大的区别，是它要处理“感知—判断—动作—反馈”这条链路。一个只会输出分类结果的模型，通常只需要输入张量和输出张量；一个能工作的端侧智能体，还需要记住最近发生了什么、知道哪些工具可以调用、判断什么时候应该上报云端，以及在失败时如何降级。 实际项目中，最容易出问题的往往不是模型本身，而是层与层之间的数据移动、线程调度和异常恢复。摄像头帧缓冲占了多少内存，音频采集是否会被日志阻塞，NPU 算子有没有回退 CPU，工具调用有没有超时，这些细节都会决定系统能不能长期运行。 二、硬件平台：先看数据路径，再看 TOPS 很多选型文档会把 TOPS 放在第一位，这当然重要，但如果只看 TOPS，很容易踩坑。端侧系统的瓶颈经常出现在摄像头到内存、内存到 NPU、NPU 到 CPU、CPU 到显示或总线这些路径上。尤其是视觉和多模态任务，数据搬运的代价可能比模型计算还高。...

前言 在边缘设备上部署深度学习模型，一直是嵌入式 AI 领域最具挑战性的课题之一。当你训练好了一个准确率令人满意的 PyTorch 模型，满心欢喜地想把它搬到 ARM 开发板上跑一跑，却发现原始模型推理一次需要好几秒，这样的性能在实际产品中根本无法使用。这时你才意识到，训练和部署之间，隔着一道看不见却异常宽阔的鸿沟。 这道鸿沟的两边是完全不同的世界：训练端追求的是灵活的算子支持、便捷的调试接口、高效的分布式训练；而部署端追求的却是极致的推理速度、最小的内存占用、最低的功耗开销。大多数框架都是为训练设计的，即使像 PyTorch 这样优秀的框架，其 C++ 前端 LibTorch 在嵌入式设备上的表现也往往差强人意。 于是我们需要专门的推理框架。在众多推理框架中，腾讯开源的 NCNN 是一个相当特别的存在。它从诞生之初就是为移动端和嵌入式设备设计的，没有历史包袱，从内存管理到算子实现都围绕 ARM 架构深度优化。更重要的是，NCNN 是纯 C++ 实现，没有任何第三方依赖，这意味着你可以轻松将它集成到各种奇葩的嵌入式环境中。 我第一次接触 NCNN 是在一块瑞芯微 RK3399 开发板上部署目标检测模型。当时用 PyTorch 推理一帧 YOLO 需要约 800ms，用 TensorFlow Lite 也需要 400ms 左右，而用 NCNN 优化后，同样的模型在同一硬件上只需要 120ms，这还没开启 Vulkan GPU 加速。那一刻我真切感受到，一个好的推理框架带来的性能提升，往往比换一颗芯片还要显著。 这篇文章会带你完整走一遍 NCNN 的部署流程：从模型训练完成后的 ONNX 导出，到 onnx2ncnn 转换，再到模型优化、INT8 量化、最后编写 C++ 推理代码。文中所有命令和代码都经过实际验证，你可以照着一步步操作。 一、为什么选择 NCNN？ 在深入具体操作之前，我们先聊聊为什么在众多推理框架中选择 NCNN，它的核心优势在哪里，又有哪些局限性。 1.1 推理框架的选型维度 选择一个推理框架，通常需要考虑以下几个维度： 维度 说明 重要程度 性能 同样硬件上的推理速度 ⭐⭐⭐⭐⭐ 模型支持 能否正常转换你的模型 ⭐⭐⭐⭐⭐ 易用性 文档是否完善，社区是否活跃 ⭐⭐⭐⭐ 跨平台 支持多少种目标硬件 ⭐⭐⭐⭐ 二进制体积 对资源紧张的 MCU 很重要 ⭐⭐⭐ 许可证 是否允许商业闭源使用 ⭐⭐⭐⭐ 用这个维度表来评估 NCNN，你会发现它在大多数项上得分都很高：性能在 ARM CPU 上属于第一梯队，模型支持覆盖了绝大多数常见算子，Apache 2....

前言 在深度学习从学术研究走向工业落地的今天，推理性能已经成为决定项目成败的关键因素。 你可能有过这样的经历：花了几个月时间精心训练了一个准确率 99% 的模型，结果一到生产环境就傻眼了——单帧推理需要 500ms，离业务要求的 30ms 差了十万八千里。这时候你面临两个选择：要么花几十万升级硬件，要么想办法把模型跑快一点。 TensorRT 就是帮你实现第二个选择的神器。作为 NVIDIA 推出的深度学习推理优化器，它能让同样的模型在同样的硬件上跑出 4 到 20 倍的性能提升，而且精度损失可以控制在 1% 以内。更重要的是，这种提升是「免费」的——不需要改变网络结构，不需要重新训练，只需要多一道「编译」工序。 这篇文章是我过去三年使用 TensorRT 的经验总结。从最基础的环境搭建，到 ONNX 模型转换，再到 INT8 量化校准，最后到生产级的 C++ 部署，我会把每一个坑、每一个优化技巧都毫无保留地分享给你。如果你正在做模型部署，或者正在为推理速度发愁，这篇文章就是为你准备的。 一、为什么我们需要 TensorRT？ 在深入技术细节之前，我们先来回答一个最基本的问题：既然 PyTorch 和 TensorFlow 本身就能跑推理，为什么还要折腾 TensorRT？ 1.1 训练框架的设计目标不是推理 PyTorch 和 TensorFlow 作为训练框架，它们的设计优先级是： 灵活性 - 支持任意计算图的动态构建 易用性 - Python 接口、自动微分 通用性 - 支持从 CPU 到多 GPU 的各种硬件 推理性能从来都不是它们的首要设计目标。为了灵活性，PyTorch 每次执行都要重新遍历计算图，每一个算子都要走通用的 CUDA kernel，这中间浪费了大量的性能。 举个例子：一个简单的 Conv + BatchNorm + ReLU 组合，在 PyTorch 里会执行三次独立的 kernel 调用，每次都要读写全局显存。而 TensorRT 会把这三层融合成一个 kernel，中间结果全部存在寄存器里——光这一项就能带来 2-3 倍的性能提升。...

前言 在计算机视觉的众多技术中，光流法（Optical Flow）可以说是最古老也最具生命力的算法之一。从 1950 年代心理学家 Gibson 首次提出视觉运动感知理论，到 1981 年 Lucas 和 Kanade 发表那篇经典论文，再到今天深度学习时代的 RAFT、GMFlow 等现代光流网络，这项技术已经走过了半个多世纪的历程。 我第一次接触光流法是在大学的计算机视觉课程上。当时教授在黑板上写下那个著名的光流方程 Iₓu + Iᵧv + Iₜ = 0，然后告诉我们：“这个简单的方程，蕴含了理解运动的全部秘密。” 那时候我还不太理解这句话的含义，直到后来在实际项目中用它实现了一个简单的视频目标跟踪系统，才真正体会到光流法的强大之处。 在今天的边缘计算和嵌入式 AI 场景中，光流法依然占据着不可替代的地位。相比于深度学习的目标跟踪算法，传统光流法具有以下优势： 计算量小：不需要复杂的神经网络，可以在资源受限的嵌入式设备上实时运行 无需训练：不需要标注数据，开箱即用 实时性好：很多优化后的实现可以轻松达到 30 FPS 以上 适用范围广：从无人机的视觉导航，到视频防抖，再到动作识别，光流法无处不在 本文将带您从零开始深入理解光流法的原理，从最基本的亮度恒定假设，到经典的 Lucas-Kanade 算法，再到 OpenCV 中的各种光流法实现。我们会通过大量代码示例，让您不仅理解理论，更能在实际项目中应用这项技术。 一、什么是光流法？ 1.1 光流的定义 简单来说，光流就是空间中运动物体在成像平面上像素运动的瞬时速度。当你盯着窗外行驶的汽车时，视网膜上汽车图像的移动速度就是光流。 更正式的定义是：给定图像序列 I(x, y, t)，光流法的目标是为每个像素点 (x, y) 找到一个速度向量 (u, v)，使得： I(x, y, t) = I(x + u·dt, y + v·dt, t + dt) 这个等式表达的就是：经过微小的时间间隔 dt 后，像素点 (x, y) 移动到了 (x + u·dt, y + v·dt)，而亮度保持不变。...

前言 在人机交互技术不断演进的今天，手势识别作为一种自然、直观的交互方式，正在从实验室走向实际应用。从智能电视的手势操控，到 VR/AR 的手部追踪，再到工业场景中的无接触控制，手势识别正在改变我们与数字世界互动的方式。 然而，手势识别技术的落地面临着诸多挑战：复杂的光照环境、多变的手部姿态、不同的肤色差异、实时性要求……这些问题让很多开发者望而却步。直到 Google 推出了 MediaPipe —— 一个跨平台的机器学习应用框架，让高精度的实时手势识别变得触手可及。 MediaPipe 最令人惊叹的地方在于它的平衡艺术：在保持毫秒级延迟的同时，能够稳定检测出手部的 21 个三维关键点，即使在普通手机上也能流畅运行。这种性能与精度的完美平衡，让 MediaPipe 成为了手势识别领域的事实标准。 本文将从零开始，系统地讲解如何使用 MediaPipe 构建一套完整的手势识别系统。我们不仅会讲解基础的关键点检测，还会深入到静态手势分类、动态动作追踪、性能优化、移动端部署等高级主题。无论你是想做一个简单的手势控制小项目，还是开发专业的人机交互产品，这篇文章都能为你提供实用的指导。 一、为什么选择 MediaPipe？ 在开始实战之前，我们首先要回答一个问题：市面上有这么多手势识别方案，为什么要选择 MediaPipe？ 1.1 真正的跨平台一致性 很多开源项目只针对特定平台优化，换个设备性能就急剧下降。MediaPipe 的设计理念是"一次开发，处处运行"： 移动端：Android 和 iOS 原生支持，针对手机 NPU 进行了深度优化 桌面端：Windows、macOS、Linux 全平台支持 Web 端：通过 WebAssembly 直接在浏览器中运行 边缘端：支持 Raspberry Pi、Jetson Nano 等嵌入式设备 更重要的是，在所有平台上，MediaPipe 输出的关键点格式完全一致，算法逻辑可以无缝迁移。 1.2 令人难以置信的性能 让我们来看一组实际测试数据（单帧处理时间）： 设备 CPU 模式 GPU/NPU 加速 iPhone 15 Pro 2.3ms 0.8ms 骁龙 8 Gen 3 3.1ms 1.2ms Intel i7-13700K 1.8ms 0.6ms Raspberry Pi 4B 28ms - 即使在 Raspberry Pi 这种资源受限的设备上，MediaPipe 也能达到约 35 FPS 的处理速度，这在以前是无法想象的。...

前言 2026 年，AI 算力正在经历一场深刻的范式转移。 当所有人都在追捧千亿参数大模型的时候，另一股更接地气的力量正在悄然壮大——边缘 AI。根据 IDC 的预测，到 2027 年，超过 50% 的数据处理将在边缘侧完成，而不是集中在云端数据中心。 这股趋势在计算机视觉领域表现得尤为明显。安防摄像头、工业检测设备、智能驾驶辅助系统、服务机器人……这些场景对目标检测算法不仅要求**低延迟、高可靠性、隐私安全，而这些恰恰是云端推理无法满足的痛点： 延迟问题：云端推理往返延迟通常在 100ms 以上，无法满足实时检测需求 带宽成本：4K 视频流每秒 10Mbps，24 小时上传是 100GB 以上 隐私安全：敏感场景不允许视频流离开设备 断网运行：工业场景必须支持离线工作 于是，如何在算力有限的边缘芯片上跑起 YOLO，就成了嵌入式 AI 工程师的核心课题。 YOLOv8 作为 Ultralytics 推出的新一代检测模型，在精度和速度上达到了新的平衡，但默认导出的 PyTorch 模型在边缘设备上根本跑不起来——300+MB 的显存占用、100ms+ 的推理时间，完全无法满足产品级要求。 本文将带你从零开始，完整走完 YOLOv8 从训练好的 .pt 模型到边缘设备部署的全过程：ONNX 导出、NCNN 转换、INT8 量化、NEON 优化，最终在树莓派 5 上达到 25 FPS 的实时检测速度。 ![YOLOv8 边缘设备部署流程 一、为什么边缘 AI 是未来？ 1.1 云计算的天花板 很多初学者常常有一个常见的误区：“既然云端算力这么强，为什么不直接把视频传到云端做检测？ 我在某智能安防项目踩过这个坑。一开始方案很简单：摄像头 RTSP 流拉流 → FFmpeg 编码 → HTTP 上传 → 云端 GPU 推理 → 结果返回。...

前言 在 AI 技术快速落地的今天，边缘计算正成为一个不可忽视的重要方向。与云端推理相比，边缘计算具有延迟低、隐私性好、带宽占用少等天然优势。然而，要在嵌入式设备上实现实时 AI 推理，仅仅依靠通用 CPU 的算力是远远不够的。一张 4K 分辨率的图像包含超过 800 万像素，即使是最简单的颜色空间转换操作，如果全部由 CPU 完成，也需要耗费数十毫秒，这对于要求 30fps 以上的实时应用来说是无法接受的。 瑞芯微的 RK3588 芯片正是为了解决这一问题而设计的旗舰级边缘计算平台。它不仅集成了 8 核 ARM CPU 和 Mali-G610 GPU，更重要的是内置了专门的 AI 加速单元——6TOPS 算力的 NPU（神经网络处理器）以及 RGA（2D 图形加速引擎）。这两个硬件加速单元是 RK3588 能够实现实时 AI 视频分析的核心所在。 然而在实际开发中，许多开发者并没有充分发挥这些硬件加速能力。最常见的问题是用 CPU 做图像预处理然后送 NPU 推理，或者在各硬件单元之间进行了不必要的内存拷贝。这些做法不仅浪费了宝贵的硬件资源，还可能导致整个系统的性能下降 5-10 倍。 本文将从底层原理出发，深入解析 RK3588 的 RGA 2D 加速引擎和 NPU 神经网络加速器的工作机制，结合大量可运行的代码示例，带你掌握边缘计算平台的性能优化技巧。我们会详细讲解如何构建零拷贝的数据流水线，实现 VPU-RGA-NPU 的全硬件加速，最终达到 4K 视频下 30fps 以上的 AI 分析能力。 一、为什么边缘计算需要硬件加速？ 在深入讲解 RGA 和 NPU 之前，我们首先需要理解为什么在边缘计算场景下硬件加速是必不可少的。 让我们来看一个典型的 AI 视频分析应用的处理流程： 视频解码：将 H.264/H.265 压缩码流解码为原始图像帧 图像预处理：缩放、裁剪、颜色空间转换、归一化 AI 推理：运行神经网络模型进行目标检测、分类或分割 后处理：解析推理结果、绘制检测框、逻辑判断 编码输出：将结果叠加后重新编码输出 如果全部用 CPU 来处理这五步，以 4K@30fps 的视频流为例：...

前言 在计算机视觉领域，颜色检测是最基础也最实用的技术之一。红色作为一种醒目的颜色，在交通标志、安全警示、工业自动化等场景中应用广泛。今天我们来深入探讨如何用 OpenCV 实现红色物体的识别，并在此基础上实现多目标跟踪功能。 这篇文章不是简单的 API 调用演示，而是从原理出发，结合实际场景中的问题，一步步构建一个健壮的检测与跟踪系统。我们会遇到光照变化、噪声干扰、部分遮挡等实际问题，然后逐一解决。 一、为什么选择 HSV 颜色空间？ 当我们谈论颜色检测时，很多新手第一反应是直接在 RGB 图像上做阈值处理。比如，红色物体的 R 通道值比较高，那么我们设定一个阈值，只保留 R > 200 的像素。但实际一试就会发现，这种方法效果非常差。 问题出在哪里？RGB 颜色空间虽然直观，但它把亮度和颜色信息混在一起了。同一个红色物体，在强光下和阴影下，RGB 值可能差异巨大，但人眼感知到的颜色其实是一样的。这就导致基于 RGB 的阈值检测非常不稳定。 这时候 HSV 颜色空间就派上用场了。HSV 把颜色信息分解成三个独立的通道： H (Hue, 色调)：表示颜色的种类，取值范围在 OpenCV 中是 0-179 S (Saturation, 饱和度)：表示颜色的鲜艳程度，0-255 V (Value, 明度)：表示颜色的明亮程度，0-255 HSV 的优势在于，颜色信息主要由 H 通道决定，而 V 通道单独控制亮度。这意味着，即使光线变化导致 V 值波动，只要 H 值在我们设定的红色范围内，我们仍然能稳定地检测到目标。 二、红色在 HSV 空间中的特殊性 红色有个有意思的特性：它在色相环的两端都有分布。在标准的 0-360 度色相环中，红色出现在 0 度附近和 360 度附近。OpenCV 为了用 8 位表示，把这个范围减半成了 0-179，所以红色就分布在 0-10 和 170-179 这两个区间。 这是很多初学者容易踩的坑。如果你只检测 0-10 这个区间，会发现稍微偏紫红或者偏橙红一点的物体就检测不到了。正确的做法是同时检测这两个区间，然后把结果合并。...