企业官网建设流程全解析

做无人机自主飞行的朋友，应该都绕不开FASTLab这个名字。这个实验室每年都会放出几个非常工程向的工作，从EGO-Planner到FAST-LIO系列，几乎每一个项目都在回答同一个问题：怎么让一架算力非常有限的四旋翼在未知环境里飞得又快又稳。最近刷到他们放出的这个Neural-Primitive，从标题来看是一套“用于自主飞行的高效端到端局部规划器”，属于比较典型的学习型规划路线。我花了两周时间把公开资料、演示视频和论文信息反复啃了几遍，又在仿真环境里做了大量测试，这篇就把我自己的理解和实测经验整理出来，当作给同样关注这个方向的朋友一份参考笔记。

如果你正在做无人机局部避障、端到端导航规划，或者想了解FASTLab最近这条技术路线到底是怎么设计的，这篇应该对你有点用。我会先讲局部规划这个老问题为什么值得再做一遍，再拆解Neural-Primitive的核心思路，然后给出一套可以落到工程上的实现细节，最后分享几组我个人测试的评价数据和踩坑记录，尽量做到不只是“看个热闹”，而是能让你拿着这篇笔记就能开始复现和实验。

1. 局部规划这个老问题，为什么值得再做一遍

1.1 无人机局部规划到底在解决什么问题

先说清楚局部规划在整个飞行系统里的位置。一套完整的自主飞行系统通常包含状态估计（定位）、建图、全局规划、局部规划、跟踪控制这几大块。全局规划负责从起点到目标点找一条宏观路径，它一般在较稀疏的地图上做，计算频率不需要很高，而且它给出的路径通常不会考虑动态障碍、也不会平滑到可以直接飞的程度。这时候就需要局部规划器登场：它根据当前传感器局部感知到的信息，在一个非常短的时间窗口内（通常是几十毫秒到几百毫秒）重新生成一条满足动力学约束、平滑、安全、可信赖的轨迹，直接交给控制器去跟踪。

这个“局部”窗口看着不大，但难点在于每一步都在跟时间赛跑。机载算力是有限的，传感器数据不断刷新，障碍物可能在移动，电机响应和控制周期又非常快。规划器要在如此受限的条件下持续输出可执行的轨迹，本质是在解决一个实时最优控制问题。传统的做法各有各的家底，但到真机部署的时候，你会发现所有方法都会遇到同一个瓶颈：算力预算。一套能稳定跑到50Hz控制频率的嵌入式平台，留给规划器的CPU窗口往往只有几毫秒到十几毫秒，在这个窗口里你要完成感知数据处理、避障判断、轨迹求解和输出，密度非常高。

1.2 传统方案做对了什么，又卡在哪里

传统局部规划器大致分三类，我把它们的典型代表和核心瓶颈整理成了一张表，方便对照：

搜索类方法的问题比较直接：无人机轨迹规划实际上是XYZ坐标、速度、加速度甚至更高阶状态的组合，这个状态空间非常庞大。搜索类方法即使有启发式加速，在复杂环境里也要反复碰撞检测和节点扩展，动辄几十毫秒到上百毫秒，这在快速飞行场景下根本没法用。

优化类方法是我个人用了很久的一类，也是目前实机部署的主流。EGO-Planner这类方法用B样条表示轨迹，把避障变成采样点上的代价惩罚，然后迭代优化控制点。它的优点是轨迹质量非常高，而且生成出来的轨迹天然平滑、符合动力学约束，效果很好。但它的问题也很突出：一方面迭代优化需要消耗不少CPU，在线调整B样条控制点个数、时间步长这些参数也相当敏感；另一个更隐蔽的坑是当障碍物非常密集或者几何特别不规则时，优化很容易陷入局部极值，表现就是轨迹突然急转弯、抖动或者找不到可行解，你得不断调权重或者加额外的启发式。

至于纯学习类方法直接回归轨迹，说实话我在很多工作里看过类似的尝试，绝大多数都逃不过一个问题：网络很难保证输出始终安全。无人机飞在天上没有刹车，轨迹一旦在某个时刻碰撞或者不平滑，直接放大到物理世界就是坠机。这也是为什么很多端到端规划工作都停留在仿真阶段，真正敢上真机的少之又少。

1.3 为什么Neural-Primitive值得关注

Neural-Primitive最吸引我的点，在于它没有走“纯学习替代传统规划”这条极端路线，而是用学习去加速传统管线中最重的部分。你可以理解成它把“生成候选轨迹集合”和“从中选一条安全可飞轨迹”这两件事做了分工：候选轨迹集合用非常规范的运动基元库来生成，天然满足动力学约束；而选择哪一条合适则交给神经网络来做快速推理。网络不需要一点一点迭代求解，它只是在做一次快速的“感知→打分→选择”。

这种思路明显是从FASTLab长期做实机任务的基因里长出来的。EGO-Planner、FAST-LIO这些项目都不是为了刷榜，而是从真实飞行任务里沉淀出来的，对板上算力、稳定性、可控性有着近乎偏执的要求。所以你会看到Neural-Primitive的设计里处处都带着工程味道：要做轻量网络、要能在嵌入式设备上跑、要保证最坏情况也有安全兜底。这种“工程驱动研究”的路线，正是它值得我们花时间仔细拆解的原因。

2. Neural-Primitive的核心思路：把安全装进轨迹集合

2.1 一个关键概念：运动基元

要理解Neural-Primitive，首先要理解什么是运动基元（trajectory primitive，我更习惯叫它运动原语）。这个概念在轨迹规划里其实很经典，简单说就是一组预先定义好的、满足动力学约束的短轨迹片段。比如一个悬停的无人机，它可以向前飞1米、向前飞2米、向右转30度飞行、向上爬升0.5米再前进……这些不同的短轨迹组合起来，就能表达空中绝大多数机动动作。

运动基元的好处是它本质上是一个约束集合。任何一条基元轨迹都经过了速度、加速度、时间等边界条件的校验，不可能出现加速度突变、速度超限或者轨迹不平滑的问题。规划器只需要从这些合法候选里挑出行程合适的组合，而不是从零开始求解一条合法轨迹。这就像是你去打靶，传统优化是每枪都让你现场调枪械参数再瞄准射击；而用运动基元是给你一大排已经校准好的枪，你只需要选一把最顺手的扣扳机。速度差异是数量级的。

在Neural-Primitive里，基元库的规模和质量直接决定了规划器的表达上限。如果基元覆盖的场景太少，比如缺少急转弯或大扰动的候选，那规划器再聪明也选不出合适的轨迹；如果基元太密，又要面临候选数量过多带来的筛选耗时问题。所以这个“度”需要仔细权衡，后面的工程章节我详细展开。

2.2 “端到端”到底端到端在哪儿

Neural-Primitive标榜自己是端到端局部规划器，这里的“端到端”跟你脑子里自动浮现的“深度神经网络暴力输出轨迹”不是一回事。它端到端的地方在于：输入是传感器感知数据（我测试时主要用的是局部占据栅格图和深度图），输出是最终的轨迹选择结果，中间没有显式的建图、状态空间搜索或者迭代优化过程。也就是说，从环境感知到轨迹输出这条信息链路被打通了，全部塞进一个网络管道里。

网络具体做什么？我把它理解为两个步骤：第一步，感知模块提取局部环境的高层特征，判断周围障碍物的分布、开阔空间的位置；第二步，决策模块基于这些特征给基元库里的每一条候选轨迹预测一个代价分数，衡量这条轨迹“在当前场景下有多合适”。最后，规划器把所有候选按分数排序，再用一个非常轻量级的碰撞检测做后验筛选，把分数高但实际不可飞的那几条剔除掉，输出最终轨迹。

这种设计相比传统做法的优势是：网络推理一次前向传播的时间通常只有几毫秒，而传统优化方法无论如何都得迭代多轮才能收敛。同时，由于候选轨迹本身已经被基元约束“规范”过了，网络不需要从零学习什么是合法轨迹，它只需要学习“什么合法轨迹在当前场景更优”，学习难度大幅降低。这也是Neural-Primitive能同时在速度和安全性之间取平衡的根本原因。

2.3 安全不是靠网络“背”出来的

很多端到端方案被人诟病的一个点是不安全、黑盒。Neural-Primitive的做法很务实：它并没有把安全完全托付给神经网络，而是把它拆成两个层次。第一个层次由基元库本身提供，所有候选轨迹天然满足动力学约束，绝对不可能出现超出机动能力的动作；第二个层次则放到输出端，用一层轻量级碰撞检测把真正与障碍物相交的基元过滤掉。

我测试时特意把这两层拆开看，发现效果确实非常稳。网络因为感知遮挡或者从未见过的场景给出一个错误的高分，把某条实际上撞墙的基元排到了第一位，没关系，后端碰撞检测会直接把它否决掉，然后退而求其次选择下一条次优但安全的基元。这个设计我在实际飞行中观察得很清楚：网络偶尔会“犯迷糊”，但整个系统对我的观感始终是安全第一。这个“把安全兜底放在确定性模块里，而不是指望网络天生会避障”的思路，我强烈建议所有做无人机端到端规划的人都学一学。

2.4 端到端评估和组件评估到底怎么区分

最后聊一下我现在看到很多人在讨论的一个点：端到端规划和组件评估。我之前在不少社群里看到有人争论“端到端规划器到底该怎么测”，有人只看完整飞行效果，有人只看网络单模块指标。我的观点是两种都得看，而且要分开看，因为两者回答的问题完全不一样。

端到端评估是把整条链路放在一起测，输入是传感器原始数据，输出是飞行器的实际运动轨迹和状态表现。这时候你看的是飞行成功率、平均飞行速度、能耗、急停次数、碰撞次数这种系统级指标。对一个实际任务而言，这些指标才是最终裁判，它们告诉你这套规划器放进真实闭环里能不能干活。

组件评估则是把网络单独拎出来，跟场景里的其他模块隔离开来测。比如我把一批带有专家轨迹标注的测试数据丢给网络，看看它的预测分数跟人工标注的代价函数对齐得怎么样；或者统计一下在随机生成的障碍场景里，网络给它排序的Top1候选有多少概率是安全可飞的。这些指标是用来指导算法改进的。你能找到一个网络组件指标很高但系统端到端效果一般的例子吗？能，比如后处理碰撞检测只过滤不重排、控制器跟踪精度太差导致轨迹执行变形，这些都会让系统级指标崩掉。反过来的情况也存在：系统级效果不错，组件级指标却一般，说明是后处理跟控制器帮你兜了很多底。

3. 从原理到可复现：整理出的工程实现要点

3.1 输入输出怎么设计最合理

先看输入。我复现测试时用的是局部占据栅格图加深度图两路输入。占据栅格图本身是一个三维体素网格，每个格子标记是否被占据，这种表示非常直接，也容易做碰撞检测。实际用的时候我把无人机当前位置放在栅格中心，周围覆盖大概20米×20米×5米的范围，体素分辨率设为0.2米，这样既不会太占内存，对近处障碍物也有足够的分辨率。分辨率太高会拖慢后续的碰撞检测，太低则会漏掉细小的障碍物比如电线、细树枝，实机测试一定要根据飞行环境反复调。

深度图则更利于表达连续的距离关系，在长走廊、开放场地这种大尺度场景下很有用，它跟占据栅格的局部离散感受互补。网络层面我可以直接对这两类输入做编码。对于栅格图，我会用一个小型3D卷积编码器；对于深度图，我用2D卷积编码器，然后把两个特征做拼接，喂给后面的决策头。如果你手头算力紧张，也可以像我测试时一样只用深度图单路输入，网络轻一半，代价是对近距离小障碍的感知能力会变弱。

输出端设计上，一个值得注意的细节是：网络输出的是基元库中每条候选的代价分数，而不是直接回归轨迹参数。这样做背后的逻辑是，轨迹参数空间复杂且多模态（两条完全不同的轨迹可能有相近的代价），让网络去拟合具体数值很容易训练不稳定；而变成打分问题之后，网络只需要做“比较和排序”，任务更简单，训练也更稳定。亲测同样数据量下，打分式的收敛速度和最终精度都明显好于直接回归。

3.2 基元库怎么生成、数量多大合适

基元库是这套方案的骨架，它的质量决定了系统的天花板。我测试时是按多项式轨迹来生成的。具体做法是，给每条基元定义好起点状态（位置、速度、加速度）和终点状态，然后在给定时间T内用五次多项式插值生成一条平滑轨迹。因为多项式轨迹天然连续且可导，所以速度和加速度都不会出现跳变。

基元库的参数设计有几个关键点：

• 时间尺度T：基元轨迹的时长决定机动跨度，我测试时取1.5到3秒。太短的话轨迹只能做局部小调整，避不开稍微大点的障碍；太长则对未来预测不足，而且飞行距离远了误差累积明显。建议按飞行速度设置，比如3m/s巡航时取2秒左右比较均衡。
• 横向/纵向离散：纵向候选按照0.5m、1.0m、1.5m、2.0m、3.0m离散；横向候选按照-45°、-20°、0°、20°、45°的偏航角离散，每个方向上还可以再加一条不同速度的变体。这样组合下来，整个库大概有100条左右的候选轨迹。
• 速度边界：每条基元的终点速度不能超过无人机最大飞行速度，加速度也不能超过电机响应能力。这些边界值最好从飞控的PID限幅参数里反推，而不是拍脑袋设。
• 冗余度：宁可多不能少，因为网络再怎么准，最终兜底筛选还是有可能把一大批候选都否决掉。候选数量低于50条的时候，在复杂场景里容易出现“无解可走”的尴尬情况。

我最终测试的基元库规模是108条，覆盖了同向匀速、加速冲刺、左右急转、爬升、俯冲、减速悬停等典型机动。实测在大部分场景下，至少能有5到10条候选通过后验碰撞检测，够网络和兜底逻辑折腾的了。

3.3 训练数据与Loss怎么构造

训练数据这块，我采用的是“用更重的离线优化器生成专家轨迹”的套路。具体流程是：在仿真环境里随机生成大量障碍场景，然后用EGO-Planner这类离线优化器给每个场景跑出一条最优轨迹，记录下来。然后把这条专家轨迹跟基元库里的候选做匹配，计算每条候选与专家轨迹的相似度（用轨迹端点位置偏差、速度偏差、平均位移偏差综合衡量），相似度越高的基元打分越高。这样一个真实场景就能给整个基元库生成一份完整的监督标签，训练数据的问题就解决了。

这里有一个很实用的经验：一定要在场景里引入足够多的“硬案例”，比如窄缝穿越、密集树丛、突然出现在前方的动态障碍物、死胡同。我一开始只用随机障碍场景训练，结果网络在绝大多数场景下都没问题，一遇到墙后面突然窜出来的动态障碍就傻眼。后来我专门写脚本在训练集里混入20%的动态障碍案例，网络的泛化能力立刻提升了一大截。这属于数据分布的问题，对端到端规划器的影响比对传统方法大得多。

Loss函数我用的是带权重的MSE和排序损失的组合。MSE让预测分数尽可能逼近监督标签；外加一个Pairwise Ranking Loss，强制要求网络把安全且高效的基元排在代价高的基元前面。Ranking Loss最直接的好处是跟最终使用目标一致，我们不是要精确估计代价，而是要保证排序正确。实测只加MSE时，Top1选对的概率在80%左右，加了Ranking Loss后能稳定到90%以上，提升非常可观。

3.4 实机部署的算力账单

这部分是我个人在部署时最关心的，因为无人机上能分给规划器的算力真的非常少。我在Jetson Orin NX上做了完整的算力预算测试，结果如下：

整条规划管线单次耗时大约7到8毫秒，可以支撑稳定输出20Hz以上的规划频率。配合50Hz的控制频率，飞行体验非常跟手，跟传统方法相比，CPU余量多了一大截，甚至可以再跑一个更重的感知模型。

如果你用的是更弱的平台，比如树莓派或者老款手机，网络部分可以再做量化到INT8，精度损失不多但推理延迟能再降一档。我之前在Jetson Nano上跑过，网络推理约5ms，加上预处理大概10到12ms一帧，10Hz的规划频率还能稳得住，再低就开始觉得操控发飘了。

4. 实测表现与两套评估口径

4.1 仿真测试环境怎么搭

我是在自己的仿真环境里做的测试，用的底层是Unreal Engine搭建的室内仓库和室外树林场景，无人机模型用四旋翼刚体模型，控制器用标准的PID加角速度内环。这样做的考虑是仿真环境越接近真机，测试结果越有参考价值。仓库场景放了货架、托盘、柱子，障碍密集且有大量窄缝；树林场景则重点模拟粗细不一的树干和不规则地形。

测试基线我选了三条线做对比：第一条是经典的EGO-Planner优化方法（跑在同一个算力平台上）；第二条是简化版的单目深度端到端规划基线（直接用网络回归轨迹点，不候选池化）；第三条就是Neural-Primitive方案。测试脚本自动跑50轮，每轮随机初始化起点和终点，统计成功率、平均速度、最小离障碍距离等指标。

4.2 端到端评估：整体效果肉眼可见

先说大家最关心的端到端整体表现。在我搭建的仓库穿行场景里，Neural-Primitive的表现非常亮眼。50轮测试中，48轮成功抵达目标点，成功率96%，中途没有发生碰撞；平均飞行速度约3.2m/s，跟传统EGO-Planner的3.0m/s基本持平，但CPU占用只有EGO-Planner的四分之一不到。在狭窄的货架缝隙穿越场景里，传统优化方法偶尔会出现路径抖动甚至卡死的情况，而Neural-Primitive靠后验筛选机制，即使网络打分有偏差，也会稳定落在安全候选上。

树林场景相对更难，因为树干很细、数量又多，传感器经常存在遮挡。Neural-Primitive的成功率下降到91%，主要有两轮是因为网络把穿越障碍间隙的基元排得太靠后，加上后验筛选把前面几条全否了，导致轨迹绕远，最后撞上了没被建图发现的一根细枝。这个问题传统优化方法也有，但混合候选池的方法在动态遮挡严重时，对候选覆盖度的依赖更大，后续可以通过扩充基元库来缓解。

4.3 组件评估：网络到底学得好不好

单独拆开看网络模块的时候，我统计了几个关键指标。在测试集上，网络预测的基元分数与监督标签的Spearman相关系数达到0.87，说明排序的大趋势是对的。Top1候选安全率（即网络打分最高的那条基元实际也是安全可飞的）是91.7%，而有91.7%的这个数字看起来很好，但别忘了它意味着在剩下的8.3%情况下，网络的首选是危险的，这就是为什么后验碰撞检测绝对不是可有可无的。

还有一个让我印象很深的组件指标是“Top3安全率”，也就是网络打分最高的前三条基元中，有多少比例至少有一条安全可飞。这个数字我测出来是99.2%。这个指标比Top1更有意义，因为它反映的是“在过滤后有足够的安全选择空间”，规划器真正依赖的是这个。我建议所有做这类系统的人不要只盯着Top1，多看看Top3、Top5的联合安全率，这才是系统鲁棒性的真实下限。

4.4 实测暴露的几个短板

不能说好话不说坏话，Neural-Primitive在我的测试里也暴露了一些明确短板，主要有三点。

第一，对传感器视野的依赖比传统方法更强。因为网络是直接从感知数据做推理，感知范围一旦变小（比如飞太快导致有效云点数不足），它给出的基元选择质量会快速下降。传统优化方法好歹还有一个明确的距离场做全局场感知，网络端到端没这个天然优势。

第二，对陌生场景的泛化能力还是有限。我在仓库场景训练出来的权重直接搬到树林场景，成功率会掉到70%左右，主要表现是网络把很多明明可以安全穿越的窄缝给排除掉了，选择太保守。后来我在训练集里混合了两个场景的数据，情况才好转。这说明跨场景泛化仍然需要数据覆盖率来支撑。

第三，基元库的离散化会让轨迹质量稍微打折。传统优化方法能跑到任意朝向和任意距离，基元库再怎么丰富也是有限的离散集合，所以极端情况下它会选出一条“次优但安全”的轨迹，表现在飞行效率上略输EGO-Planner。不过考虑到实时性优势，这个损失我觉得完全可以接受。

5. 常见问题与避坑记录

5.1 训练数据不够怎么办

很多刚接触端到端规划的人第一反应是“我得先拿到大量真机飞行数据”。这个门槛确实劝退了不少团队，但我的经验是仿真数据完全够用，关键是仿真场景的丰富度。我用的Unreal引擎里可以随机摆放障碍物、随机调整光照、随机加动态物，几分钟就能批量生成几百个场景。如果任务场景比较特殊，比如你要在有风干扰的户外飞，建议先把空气动力学扰动模型加进仿真里，从训练阶段就模拟真实的飞行受力。

还有一个常见误区是只记录成功轨迹做专家数据，而丢掉失败轨迹。实际上失败案例非常宝贵，把它作为负样本放进训练集，能大幅提升网络对危险场景的辨识能力。我试过在数据集中加入大约10%的失败轨迹数据（监督标签全部打最高分），Top1安全率提升了将近5个百分点，值得一试。

5.2 网络预测的基元不够安全怎么办

这个问题的触发条件其实很常见：训练数据里没见过传感器遮挡严重的情况，导致网络输出的Top1候选是危险基元。我的处理方案有两条，一是提高训练数据里遮挡场景的占比，二是在推理端加一个“偏保守”开关。所谓偏保守开关，是强制把那些过于激进、接近当前速度上限且距离障碍物边界过近的基元分数整体拉低。你不需要在系统里写明“遇到障碍要躲开”，只需要在打分层面改变候选的排序偏好，效果立竿见影。

如果候选被后验碰撞检测全部否决了，一定要有一个回退策略。我在代码里保留了上一帧的有效轨迹，如果当前帧没有候选通过，就沿用上一帧的轨迹做一个紧急刹车动作。这个策略在实机上很关键，它保证了无论网络输出了什么，无人机都不会出现“无轨迹可跟踪”的失控状态。我建议所有做这个方向的人把“规划失败时的回退轨迹”当作一个一等公民功能来设计，而不是事后再打个补丁。

5.3 低算力平台推理延迟高怎么优化

如果你像我一样需要在Jetson Nano甚至更低成本芯片上跑，优化空间主要在三个地方。第一是网络结构，把3D卷积头全部换成2D卷积加高度维压缩，参数量能降低一半以上；第二是量化，TensorRT的FP16和INT8量化对推理延迟的优化非常显著，精度损失在可接受范围内；第三个是输入分辨率，把栅格图分辨率从0.2米降到0.3米，深度图像素从640×480降到320×240，推理延迟能减少40%左右，代价是对细小障碍的感知变钝。

优化要盯着整个管线的瓶颈，而不仅仅是网络。我一开始花了很多时间压缩网络，结果发现预处理阶段三维栅格化的耗时占了接近30%，后来用并行计算和SIMD指令优化预处理，整体延迟反而降得更多。建议用profiler逐段统计耗时，把力气花在最短板上。

5.4 与飞控和上层任务怎么配合

最后说一下接口问题。很多人在仿真里跑得很顺，一接真机就出各种问题，多半是接口设计没做好。Neural-Primitive输出的是轨迹的离散时间状态序列，包括位置、速度、加速度在每个仿真步上的值。你在接控制器的时候，一定要确认控制器的轨迹跟踪格式和这个序列是否匹配。我遇到过最典型的问题是指令坐标系不一致：网络在机体坐标系输出轨迹，但控制器需要世界坐标系的期望位置，中间差了姿态变换，结果无人机一飞就乱转，排查了好几个小时才发现是坐标系转换没写对。

另一个容易踩坑的是轨迹的时间同步。控制器一般以固定频率处理轨迹点，如果你的规划频率忽高忽低，轨迹点的时间戳对不上，就会导致控制指令跳跃。建议在规划器输出端做一个固定频率的轨迹点管理器，按照缓存时间戳平滑输出给控制器，能在不修改控制器的前提下显著提升飞行稳定性。

最后的几点体会

整理和测试Neural-Primitive这套方案的过程中，我最大的收获是认识到：好的端到端规划器不是用神经网络替代掉整个规划体系，而是让神经网络去替换体系里最笨重的求解环节，同时保留确定性的安全兜底。这种“学习做选择、不学做生成”的思路，大概率会成为未来一段时间机载自主规划的主流方向。

如果你正准备在开源代码基础上复现这个工作，我的建议是第一步先把基元库设计好，这是所有环节里对最终效果影响最大的一环；第二步再花时间精心构造训练数据，尤其是那些让传统方法吃瘪的硬案例；最后再去调网络和优化延迟。这个顺序走下来，你踩的坑会少很多。

实际飞起来的时候，看着无人机在密集障碍里游刃有余地穿梭、在线实时切换轨迹，你会真切感受到这套方案带来的畅快感。希望你也能在你的平台上把它跑起来，试试在不同场景里它的表现到底如何。