KeyChan's blog

1. 视觉分割任务回顾：从像素预测到结构理解

视觉分割是计算机视觉体系中一类基础而关键的任务。与图像分类主要回答“图像中包含哪些语义概念”不同，分割进一步要求回答“这些对象在图像中的具体位置、形状与边界是什么”。这意味着分割并非以整幅图像或候选框为单位进行判断，而是直接作用于像素层面，需要对图像中每一个像素给出明确的归属结果。

正因为输出粒度从“区域”细化到“像素”，视觉分割不仅考验模型的语义理解能力，更对其空间表达能力、上下文建模能力以及结构化预测能力提出了更高要求。在进入可提示分割与通用分割模型的讨论之前，有必要首先对分割任务本身的定义、输出形式以及任务类型进行系统回顾，从而为后续模型结构与问题设定的演进奠定清晰而统一的概念基础。

回看整个 2025 年，感觉这一年很难用具体结果来概括。更多时候，我还是在投入去做一件不太显眼、却有点基础的事情：在 AI 的辅助下，重新整理学习新事物的方式。

1. 逐渐理解“广泛”的价值

这一年，我对“学习”本身的看法有了一些变化。过去，我更习惯把学习理解为获取知识点，但在实际过程中逐渐发现，这样的理解有些片面。真正影响学习效率的，似乎并不是知道了多少信息，而是这些信息在大脑中是否能够形成稳定的连接，并且在适当时候否能被成功调用。

从这个角度看，学习更像是在不断构建的网络。每一次学习，本质上都是在神经元之间建立新的连接，或强化已有的连接。当连接逐渐增多、结构逐渐清晰，新东西带来的认知负荷就会减轻，理解也会变得顺畅一些。

1. 地面站的角色与系统位置

无人机的飞行并不是由单一模块“完成”的。飞控依靠高速传感器与控制算法维持姿态稳定；任务系统通过算法或人工设定飞行目标；机体结构与动力系统负责把这些指令转化为推力与力矩。除此之外，还有一个位置很特别、却经常被低估的环节——地面站（Ground Control Station, GCS）。

地面站不是飞行之外的附属软件，更像无人机系统的外环控制中心：状态如何被看见、参数如何被管理、任务如何被配置、风险如何被提前预知处理，几乎都从这里进入。把它放回系统整体去理解，是构建可靠无人机体系的第一步。

1. DETR 出现的原因

在目标检测的发展历程中，YOLO 与 DETR 往往被视为两种截然不同的技术路线，其差异不仅体现在网络结构或训练策略上，更反映了对“目标检测这一问题应当如何建模”的根本理解差别。

直观而言，YOLO 系列方法遵循的是一种密集预测思路：模型在图像的各个空间位置上独立判断是否存在目标，并同时回归其类别与边界框位置。这种做法强调局部决策与并行计算，因而具备极高的推理效率，但也不可避免地会对同一目标产生多次冗余预测，必须借助非极大值抑制等后处理机制进行去重。具体可参考： 物体检测评估指标和YOLO-v1实现思路

1. 从物理世界到“可控信息”——飞控软件的使命

在前几篇内容中，我们已经从系统工程视角初步对无人机有了一定的理解，从空气动力学角度探讨了“为什么能飞”，从传感器与硬件角度认识了无人机如何感知世界，并在控制算法篇中建立了“飞控如何决策与调节”的基础框架。

然而，所有物理量、传感器读数与控制规律最终都必须通过软件进行组织、调度与执行，才能形成一个真正稳定、可控的飞行器。本章从软件角度展开，属于飞控软件的基础部分，为保证后续章节的连贯性，建议完整阅读，使后续的体系结构、调度机制、通信框架等内容更易衔接。

1. 为什么 async/await 不能解决并发问题

Swift Concurrency 带来的第一个直观变化，是 async/await 让异步调用读起来像同步代码。之前一长串回调嵌套，现在可以按顺序写清楚：先请求网络，再解析，再更新状态。但在真实项目里，异步“写起来舒服”只是表面，很多时候真正的痛点不在于“怎么写异步逻辑”，而在于“多个任务同时访问同一份状态时发生的问题”。线程变多、任务变多、入口变多之后，只要可变状态没有明确的限制，就可能带来问题。

获取服务端配置就是一个非常典型的并发场景：有本地缓存，有后台刷新，有多处调用，有UI依赖结果，还有可能叠加服务端推送。表面上只是“拉一份配置下来”，但内部状态在多个任务之间来回穿插，如果不做隔离，async/await 并不能有效处理这些逻辑。

1. 为什么 UIKit 项目也需要现代异步能力？

现在的应用，无论是前端、Flutter 还是移动端原生，都有一个共同趋势：异步操作越来越多、界面状态变化也越来越频繁。Web 有 async/await + Promise 统一异步流程，用事件流和状态管理驱动 UI；Flutter 用 sync/await + Future/Stream 处理异步，用 BLoC、Provider、Riverpod 聚合状态并更新界面。这些体系之所以能稳定，是因为都遵循了同一种现代异步模型：异步逻辑线性化、事件流可组合、UI 完全由状态驱动。

UIKit 项目同样也面临这些问题，随着 Swift Concurrency、Combine 和 @Published 逐渐成熟，UIKit 也具备了和 Web、Flutter 类似的现代异步能力：async/await 负责逻辑，Combine 管事件流，状态集中在 ViewModel，由 UI 自动响应变化。

1. 从零搭建一个 PyTorch 模型

在正式讨论 PyTorch 之前，我们先从一个最小可用训练流程入手：用最少的代码搭建并训练一个小型神经网络。通过这个过程来快速建立对 PyTorch 的整体认知：数据从哪里来？如何流入模型？损失如何计算？梯度如何反向传播？参数又是如何被更新的？ 后面章节会对这些环节再做细致拆解，我们先做一个“总览式体验”。

1.1 整体思路：从数据到参数更新

我们开始搭建的最小神经网络包含四个核心阶段：

1. 数据准备：把原始数据转换为张量，并按批次（batch）组织；
2. 模型构建：用 nn.Module 定义前向计算逻辑；
3. 损失与优化器：定义“好坏标准”和“如何更新参数”的规则；
4. 训练循环：反复执行前向、反向和参数更新。

1. 时间依赖与梯度消失：序列建模的困境

在很多经典的图像任务中，我们通常假设不同样本之间是独立同分布的（i.i.d.）——也就是说，一张图片与另一张图片在统计上是相互独立的，模型只需要把一张图片看作一个整体输入来处理即可。卷积网络（CNN）则利用图像内部像素之间强烈的局部相关性，通过卷积核在空间上提取局部到全局的层级特征。

但在处理序列任务（sequence modeling）时情况就完全不同了：语言、语音、时间序列信号都具有明显的时间依赖，同一个序列内部，不同时间步之间往往高度相关。要正确预测下一个值、下一个词或下一个声音，模型必须记住同一条序列中之前发生过什么。这一点正是循环神经网络（Recurrent Neural Network, RNN）诞生的核心动机。

1. 控制系统的物理与数学基础

在研究飞控算法（Flight Control Algorithm）之前，理解姿态描述方式、闭环反馈思想及采样周期的作用至关重要。本章节主要介绍这些基础概念，为后续的建模与 PID 控制奠定直观认知。

1.1 坐标系与姿态描述

无人机的姿态描述通常基于两个参考系：惯性系（Inertial Frame）与机体系（Body Frame）。

• 惯性系：固定在地面或某个空间参考点上，其坐标轴多采用“东北下（NED）”方式定义，即以北（North）、东(East)、下(Down)三个方向作为基准，用来描述无人机相对于地球的运动状态。
• 机体系：固定在无人机机体上，原点通常位于质心，$x_b$ 轴沿机头方向，$y_b$ 轴指向右翼，$z_b$ 轴指向机体下方。