无人机自主降落这件事，外行看热闹，觉得不就是让飞机自己落下来嘛，遥控器上按一下的事。但真上手做过的人都知道，让无人机稳稳当当地落在一个静止的H形标记上，和让它落在一辆正在行驶的车顶上，中间隔着的技术鸿沟比大多数人想象的要大得多。前者是"定点着陆"，本质是一个静态目标的位置控制问题；后者是"动态协同"，涉及目标运动预测、相对位姿估计、时延补偿、多机协同决策等一系列硬骨头。这个课题之所以被反复推荐为挑战赛题目，恰恰是因为它卡在了一个非常微妙的位置上：既不像纯视觉SLAM那样需要从零搭建庞大的系统工程，也不像简单的PID调参那样缺乏研究深度，它刚好是一个"有明确物理场景、有清晰评价指标、有足够技术纵深"的题目。

我前后参与过三届相关赛事的方案设计和评审工作，也带过几支队伍从零开始搭建移动平台降落系统。说实话，大部分队伍在第一个月都会走弯路，要么一上来就死磕视觉算法忽略了控制时延，要么把仿真跑通了但真机一飞就炸。这篇文章我想把整个技术链路拆开来讲清楚，从定点着陆的基础能力怎么打，到动态协同的核心难点怎么破，再到仿真验证和真机调试的实操细节，尽量把踩过的坑和验证过的方案都摊开来说。不管你是刚接触无人机控制的新手，还是已经做过定点降落想往动态方向进阶的老手，应该都能从中找到对自己有用的东西。

1. 定点着陆到底在练什么基本功

很多人觉得定点着陆太简单，不值得花时间，恨不得直接跳到移动平台降落。但我带过的队伍里，凡是定点着陆没练扎实的，后面做动态降落时无一例外都会遇到各种诡异问题。定点着陆看似只是"让飞机落到一个固定点上"，实际上它训练的是整个系统的核心能力：视觉检测的稳定性、位姿估计的精度、控制回路的响应特性、状态机的切换逻辑。这些东西在静态场景下你还能靠慢慢调参糊过去，一旦目标动起来，所有隐藏的问题都会成倍放大。

1.1 视觉标记检测：为什么ArUco和AprilTag是首选

定点着陆的第一步是让无人机"看到"降落点。常见的方案有几种：红外信标阵列、激光反射板、视觉标记。前两种需要额外硬件且作用距离有限，视觉标记方案因为成本低、信息丰富、便于扩展，成了绝大多数队伍的选择。

视觉标记里最主流的是ArUco和AprilTag。两者本质上都是二进制编码的方形标记，通过检测四边形轮廓、解码内部二进制图案来识别ID和计算位姿。ArUco是OpenCV原生支持的，调用起来最方便；AprilTag在远距离和部分遮挡场景下鲁棒性更好，但需要额外编译库。我的建议是：如果比赛允许用OpenCV，直接用ArUco起步，等遇到检测距离不够的问题再考虑换AprilTag。

这里有个容易被忽略的细节：标记的物理尺寸直接决定了有效检测距离。假设你的机载相机分辨率是1280×720，镜头水平视场角60度，标记边长15厘米。在3米距离上，标记在图像中的像素宽度大约是：

像素宽度 ≈ (标记实际宽度 / 距离) × (图像宽度 / (2 × tan(视场角/2))) ≈ (0.15 / 3) × (1280 / (2 × tan(30°))) ≈ 0.05 × 1108 ≈ 55 像素

55像素对于ArUco解码来说勉强够用，但位姿估计的精度会很差。一般建议标记在图像中至少占80到100像素宽，位姿估计才比较可靠。这意味着在3米距离上，你要么把标记做大到25厘米以上，要么换更长焦的镜头。很多队伍在仿真里用默认参数跑得好好的，一到真机就发现2米外就检测不到了，问题就出在这里。

提示：标记周围一定要留足够的白色边框，宽度至少是标记边长的四分之一。边框不够会导致轮廓检测失败，尤其是在光照不均匀的情况下。

1.2 位姿估计的坐标系链路

检测到标记只是第一步，真正难的是把图像中的像素坐标转换成无人机需要的降落引导信息。这里涉及一条完整的坐标系链路：图像坐标系 → 相机坐标系 → 机体坐标系 → 世界坐标系。每一层转换都可能引入误差。

相机坐标系到机体坐标系的转换靠的是相机外参，也就是相机安装在机身上的位置和角度。这个参数必须标定，不能靠卷尺量了填进去。我见过有队伍直接用设计图上的安装位置填参数，结果相机实际安装时偏了3度，导致降落时无人机总是往一个方向飘。标定方法很简单：把无人机固定好，在正下方放标记，读取检测到的位姿，和实际测量的位置对比，反复调整外参直到误差最小。

机体坐标系到世界坐标系的转换靠的是IMU和飞控的姿态估计。这里就引出了一个关键问题：IMU采样率。热搜词里有人问"无人机IMU采样率达不到200Hz会造成什么影响"，这个问题在动态降落场景下特别致命。IMU采样率不够，姿态估计的更新频率就跟不上，而移动平台降落时无人机需要快速响应目标运动，姿态环的延迟会直接导致相对位置估计出现滞后。一般来说，做动态降落建议IMU采样率至少400Hz以上，200Hz是底线，再低就会出现明显的控制振荡。

1.3 控制回路：从位置环到速度环的切换逻辑

定点着陆的控制逻辑通常分三段：远距离用位置控制飞向标记上方，中距离切换到速度控制缓慢下降，近距离用视觉伺服做精细对准。这个切换逻辑看起来简单，但切换时机和切换时的状态连续性很容易出问题。

我建议的切换策略是这样的：当标记检测稳定且距离大于1.5米时，用位置控制，目标点是标记正上方1.5米处；当距离在0.5到1.5米之间时，切换到速度控制，下降速度设为0.3米每秒，水平速度由视觉偏差乘以增益系数得到；当距离小于0.5米时，进入视觉伺服模式，直接用图像偏差驱动水平运动，垂直方向匀速下降。

切换时最忌讳的是目标点突变。比如从位置控制切到速度控制时，如果速度指令是直接从零跳变到0.3米每秒，无人机会猛地一顿。正确的做法是在切换点做速度前馈补偿，让切换瞬间的速度指令和切换前的位置控制输出速度连续。这个细节在仿真里可能看不出来，但真机上会非常明显。

2. 移动平台带来的三个核心难题

定点着陆练好了，接下来就要面对移动平台。很多队伍在这个阶段会低估难度，觉得"不就是目标在动嘛，我让无人机跟着动就行了"。实际上，目标一动，整个问题的性质就变了。定点着陆是一个调节问题，移动平台降落是一个跟踪问题，而且是一个存在时延和预测误差的跟踪问题。

2.1 时延：视觉处理和控制回路的隐形杀手

移动平台降落最核心的难点是时延。这个时延来自多个环节：相机曝光和读出时间（通常10到30毫秒）、图像传输时间（如果用图传）、视觉算法处理时间（20到100毫秒不等）、控制指令计算和下发的周期（5到20毫秒）、电机响应时间（10到50毫秒）。把这些加起来，从"相机看到目标"到"无人机实际做出响应"，端到端时延很容易超过100毫秒。

100毫秒意味着什么？如果移动平台以1米每秒的速度行驶，100毫秒内它已经移动了10厘米。如果无人机不做任何预测，只是简单地追踪当前检测到的目标位置，那它永远在追一个"过去的位置"，最终会导致一个稳定的跟踪误差，严重时甚至会引起振荡。

解决时延问题有两个思路：一是尽量降低各环节的延迟，二是对目标运动做预测补偿。降低延迟方面，可以在机载计算机上直接跑视觉算法，避免图传环节；用全局快门相机代替卷帘快门，减少运动模糊；优化算法，把检测频率提到30Hz以上。预测补偿方面，可以用卡尔曼滤波对目标运动状态做估计，预测未来100毫秒的位置，把这个预测位置作为控制目标。

我实测下来，卡尔曼滤波做预测补偿的效果非常明显。用一个简单的匀速模型加过程噪声，就能把跟踪误差从15厘米降到5厘米以内。如果目标运动有加速度变化，可以用匀加速模型或者交互多模型滤波，但复杂度会上升不少。

2.2 相对位姿估计：当标记不再正对相机

定点着陆时，标记通常水平放置，相机垂直向下看，标记在图像中是一个规整的正方形。但移动平台上的标记可能因为平台颠簸而倾斜，或者因为无人机从侧面接近而出现透视变形。这些都会影响位姿估计的精度。

更麻烦的是，移动平台上的标记可能被部分遮挡。比如平台上有其他设备挡住了标记的一角，或者无人机自己的影子落在标记上。ArUco和AprilTag都有一定的抗遮挡能力，但位姿估计的精度会下降。我的经验是，如果标记被遮挡超过30%，位姿估计的误差会急剧增大，这时候应该切换到备用策略，比如用平台的边缘特征或者用光流做辅助。

还有一种情况是标记完全丢失。这在动态降落中很常见，比如无人机转弯时标记暂时移出视野。这时候不能慌，正确的做法是进入"预测跟踪"模式：用卡尔曼滤波的预测值继续控制无人机运动，同时扩大搜索范围重新检测标记。如果超过一定时间（比如1秒）还没检测到，就应该爬升到安全高度重新搜索，而不是继续盲降。

2.3 平台运动预测：匀速模型够不够用

移动平台的运动模式取决于具体场景。如果是地面车辆，通常可以用匀速模型近似，但车辆会有加减速和转弯。如果是水面船只，运动更复杂，有波浪引起的周期性晃动。如果是另一架无人机，运动最灵活，但也最难预测。

对于挑战赛场景，大多数情况下移动平台是地面车辆，运动相对规律。匀速模型加过程噪声的卡尔曼滤波通常够用。但如果车辆频繁加减速，匀速模型的预测误差会比较大。这时候可以考虑用交互多模型滤波，同时维护匀速和匀加速两个模型，根据观测似然自动切换权重。

不过我要提醒一点：模型越复杂，需要调的参数越多，在比赛现场有限的时间内调好的难度也越大。我见过有队伍用了交互多模型滤波，结果参数没调好，效果还不如简单的匀速模型。所以我的建议是：先用匀速模型把系统跑通，如果实测发现预测误差确实大，再考虑升级模型。

3. 动态协同的进阶玩法

如果只是无人机追移动平台，那还称不上"协同"。真正的动态协同是指无人机和移动平台之间有信息交互，平台知道无人机的状态，无人机也知道平台的意图，双方配合完成降落。这个层次的技术难度和单方面追踪完全不是一个量级。

3.1 通信链路：谁给谁发什么

协同的前提是通信。常见的通信方案有几种：数传电台、WiFi、蓝牙、光通信。数传电台距离远但带宽低，适合传状态信息；WiFi带宽高但距离有限，适合传图像或者高频率的状态更新；光通信需要视距，但抗干扰能力强。

在挑战赛场景下，我建议用数传电台做状态信息交互，频率不用太高，10Hz就够。平台把自己的位置、速度、航向角发给无人机，无人机把自己的位置、速度、降落意图发给平台。这样双方都能做更好的预测和决策。

这里有个坑：通信时延和丢包。数传电台的时延通常在20到50毫秒，丢包率在良好环境下可以低于1%，但在有干扰的环境下可能到10%以上。如果无人机完全依赖平台发来的位置信息做控制，一旦丢包就会出问题。所以正确的做法是：平台信息只作为辅助，无人机自己的视觉检测仍然是主要信息来源，平台信息用来做预测补偿和一致性校验。

3.2 平台配合策略：减速还是不停

一个很实际的问题是：移动平台要不要为了配合无人机降落而减速甚至停下来？从技术难度上说，平台停下来降落最简单，但这就不叫动态协同了。从比赛评分角度，平台保持运动通常得分更高。

如果平台保持运动，它可以做一些配合动作来降低降落难度。比如保持匀速直线运动，避免急转弯；在无人机接近时稍微减速，给无人机更多调整时间；把标记区域调平，减少颠簸。这些配合动作不需要很复杂，但对降落成功率的提升非常明显。

我带队时用过的一个策略是：平台在无人机进入最后1米降落区时，把速度从1.5米每秒降到0.8米每秒，同时保持直线行驶。就这么一个简单的配合，降落成功率从不到50%提到了80%以上。

3.3 多机协同：一个平台多架无人机怎么调度

如果场景扩展到多架无人机同时降落到一个移动平台，问题就更复杂了。需要解决降落顺序、空中等待区管理、冲突检测和避让等问题。这已经超出了单机控制的范畴，进入了多智能体调度的领域。

一个可行的方案是集中式调度：平台作为调度中心，根据每架无人机的位置、电量和降落难度，分配降落顺序和时间窗口。无人机在等待区盘旋，收到降落许可后才进入降落通道。这个方案实现起来相对简单，但对通信可靠性要求高。

另一个方案是分布式协商：无人机之间通过通信协商降落顺序，平台只提供位置信息。这个方案鲁棒性更好，但实现难度大，容易出现死锁或者协商失败。对于挑战赛来说，集中式调度通常就够了，除非题目明确要求分布式。

4. 仿真验证：别急着上真机

我见过太多队伍，仿真还没跑通就急着上真机，结果一飞就炸，炸了又回去改代码，来回折腾浪费大量时间。正确的做法是先在仿真里把整个链路跑通，包括视觉检测、位姿估计、控制逻辑、状态机切换，全部验证无误后再上真机。

4.1 仿真环境选型：Gazebo还是AirSim

无人机仿真常用的环境有Gazebo和AirSim。Gazebo是ROS生态的原生仿真器，和PX4、ArduPilot的SITL配合得很好，适合验证控制逻辑和状态机。AirSim基于虚幻引擎，视觉渲染更逼真，适合验证视觉算法。

我的建议是：控制逻辑和状态机在Gazebo里验证，视觉算法在AirSim里验证，两者结合起来。如果时间有限，优先用Gazebo，因为控制逻辑出问题的概率比视觉算法大得多。

Gazebo里搭建移动平台降落场景，需要做几件事：创建一个带标记的移动平台模型，给平台加一个匀速运动的插件，配置无人机的相机传感器，把视觉检测节点和控制节点都跑起来。这些在ROS里都有现成的包可以用，但配置起来还是有不少细节要注意。

4.2 视觉仿真：渲染出来的标记和真实标记差在哪

仿真里的标记是完美渲染的，没有噪声、没有运动模糊、没有光照变化。真实相机拍出来的标记有噪声、有模糊、有反光。如果直接在仿真里调视觉算法的参数，到真机上大概率要重新调。

一个折中的做法是在仿真图像上加噪声和模糊。Gazebo的相机插件可以配置噪声参数，AirSim也可以通过后处理加噪声。更简单的做法是在视觉处理节点里手动加高斯噪声和运动模糊，模拟真实情况。这样调出来的参数到真机上迁移性会好很多。

还有一个细节：仿真里的相机内参是理想的，没有畸变。真实相机有畸变，尤其是广角镜头。如果仿真里不模拟畸变，到真机上标记检测的精度会下降。建议在仿真里也加上畸变模型，用真实相机标定得到的内参和畸变系数。

4.3 控制参数整定：仿真里调好的参数到真机还能用吗

仿真里调好的PID参数到真机上通常需要重新调，但好的仿真参数可以作为一个很好的起点。差异主要来自两方面：一是仿真里的电机模型和真实电机有差异，响应速度不同；二是仿真里没有真实的气动干扰和振动。

我的经验是：仿真里调好的参数，到真机上先把增益降低30%到50%，然后慢慢往上加，直到出现轻微振荡再往回退一点。这样比从零开始调快得多，也更安全。

5. 真机调试：从炸机到稳定降落

真机调试是整个项目中最刺激也最折磨人的环节。不管仿真里跑得多好，真机上总会遇到意想不到的问题。我总结了几条血泪经验，希望能帮你少炸几次。

5.1 第一次试飞：别直接上移动平台

第一次试飞千万不要直接上移动平台。正确的步骤是：先在室内悬停测试，确认基本飞行稳定；然后在室外做定点降落，确认视觉检测和控制链路正常；最后才上移动平台，而且平台先静止，再慢速移动，再正常速度移动。

每一步都要有明确的通过标准。比如定点降落的通过标准是：连续10次降落在标记中心20厘米范围内，且没有出现明显振荡。达不到这个标准就不要往下走，回去查问题。

5.2 安全保护：炸机是常态，怎么炸得便宜

炸机在调试阶段几乎是不可避免的，关键是怎么炸得便宜。几个实用的保护措施：给无人机装桨叶保护罩，虽然会增加一点重量，但能避免大部分桨叶损坏；在降落点周围铺软垫，减少撞击损伤；设置遥控器上的紧急切换开关，一旦发现异常立刻切回手动控制；在代码里加保护逻辑，比如检测到标记丢失超过一定时间就自动爬升。

我还会建议在第一次试飞时把无人机用绳子拴住，限制飞行高度和范围。虽然看起来有点土，但真的能省很多维修费。

5.3 常见问题排查：无人机为什么总是往一个方向飘

这是真机调试中最常见的问题之一。无人机在降落过程中总是往一个方向飘，怎么调参数都调不好。可能的原因有几个：相机外参标定不准，导致位姿估计有系统性偏差；IMU零偏没校准，导致姿态估计漂移；标记平面和地面不平行，导致位姿估计的俯仰角有偏差。

排查方法是：先把无人机固定在标记正上方，读取视觉估计的位置和实际位置对比，如果有一个固定的偏差，那就是外参问题；如果偏差随时间漂移，那就是IMU问题；如果偏差随无人机位置变化，那可能是标记平面问题。逐个排除，不要同时改多个参数。

5.4 降落成功率提升：从50%到90%的实战技巧

降落成功率的提升往往靠的不是什么高深算法，而是一堆细节的打磨。我总结了几条最有效的：把视觉检测频率提到30Hz以上，减少时延；用卡尔曼滤波做目标运动预测，补偿时延；在最后0.5米切换到大增益的视觉伺服，提高对准精度；给平台加配合减速策略；在降落判定里加容错，比如允许标记短暂丢失0.3秒不中断降落。

还有一个容易被忽略的点：降落末端的触地检测。很多队伍用高度判断触地，但气压计的高度在最后阶段噪声很大，容易误判。更好的做法是用视觉高度加IMU的加速度检测，或者直接在起落架上装接触开关。触地检测不准会导致无人机在已经触地后还在调整姿态，容易翻倒。

6. 算法选型与工具链的取舍

做这个课题，工具链的选择直接影响开发效率和最终效果。我见过有队伍在工具选型上纠结太久，浪费了大量时间。这里把我用过的几套方案对比一下，供你参考。

6.1 飞控平台：PX4还是ArduPilot

PX4和ArduPilot都是成熟的开源飞控，都支持外部位置估计输入，都能做定点降落。PX4的代码结构更清晰，模块化更好，适合做二次开发；ArduPilot的生态更成熟，社区支持更好，遇到问题更容易找到答案。

如果你们队伍有比较强的软件开发能力，想深度定制控制逻辑，选PX4。如果更看重稳定性和社区支持，选ArduPilot。两者在移动平台降落这个场景下都能用，没有本质差异。

6.2 机载计算机：树莓派够不够

机载计算机的选择取决于视觉算法的复杂度。如果只是跑ArUco检测，树莓派4B完全够用，能跑到30Hz以上。如果要用深度学习做目标检测或者语义分割，树莓派就不够了，需要上Jetson Nano或者Xavier。

我的建议是：先用树莓派把基础版本跑通，如果确实需要更强的算力再升级。不要一上来就买最贵的硬件，很多时候瓶颈不在算力，而在算法效率和代码优化。

6.3 仿真到真机的代码复用

仿真和真机的代码应该尽量复用，只替换底层接口。比如视觉检测节点，仿真里订阅Gazebo的相机话题，真机上订阅真实相机的话题，上层处理逻辑完全一样。控制节点也是，仿真里发给Gazebo，真机上发给飞控，控制逻辑不变。

这样做的最大好处是：仿真里验证过的逻辑，到真机上不需要重新验证，只需要验证接口层。能省大量时间，也能减少真机调试的风险。

7. 挑战赛课题的破题思路

如果你正在准备这个挑战赛课题，我建议按这样的节奏推进：第一周搭好仿真环境，跑通定点降落；第二到三周加入移动平台，在仿真里跑通动态降落；第四周把视觉算法迁移到真机，做定点降落测试；第五到六周做移动平台真机测试，逐步提高平台速度；最后一周做稳定性优化和比赛准备。

课题报告里要重点突出几个方面：系统架构的完整性，从感知到决策到控制的链路要清晰；关键技术的深度，比如时延补偿、运动预测、协同策略，要讲清楚原理和实现；实验数据的充分性，要有不同速度、不同场景下的降落成功率统计；创新点的提炼，哪怕是一个小的改进，只要说清楚为什么做、怎么做、效果如何，就是加分项。

我在评审时最看重的是队伍对问题的理解深度。有些队伍报告写得很漂亮，但一问细节就露馅，比如问到时延补偿的具体实现，说不清楚卡尔曼滤波的状态方程怎么建的。相反，有些队伍方案不复杂，但每个环节都讲得明明白白，实验数据扎实，这种报告得分反而高。

最后分享一个我在多次比赛中验证过的经验：预留至少三分之一的时间做意外情况处理。不管计划做得多好，总会遇到硬件故障、软件崩溃、场地限制等各种问题。时间留够，心态放平，遇到问题逐个解决，比赶进度赶出来的半成品强得多。