低空航拍中的 VLA 与 VLN：主线、复现与选题

如果直接把方向写成“低空 VLA 大模型”，它听起来很新，但也很容易失焦。
真正的问题不是名字够不够大，而是任务边界是否清楚、主线是否可复现、第一篇论文能否切得准。

基于一套完整的低空/空中视觉语言研究材料，我最后收束出的判断很明确：

最合理的切入不是直接泛讲“低空 VLA”，而是先以 Aerial VLN 为底座，再扩展到 navigation-centric Aerial VLA。

这篇文章想回答五个问题：

1. Aerial VLN 和 Aerial VLA 到底怎么区分。
2. 这个方向真正成熟的主线是什么。
3. 哪些数据集、benchmark、平台和代码库最值得优先吃透。
4. 如果今天就开始复现，最稳的路径应该怎么排。
5. 第一篇论文最可能的高质量切口在哪里。

一、为什么不能上来就泛讲“低空 VLA”#

“低空 VLA”这个说法最大的问题不是太前沿，而是太宽。

它很容易把几类其实差别很大的问题混在一起：

• 无人机视觉语言导航
• 真实飞控闭环
• 城市场景中的地理语义推理
• 低空短程技能动作执行
• 目标跟踪、搜救、投送、巡检
• 多机协同、世界模型、具身基准

如果边界不先讲清，后面就会连续出现三个问题：

• 老师会追问：你的任务到底是什么？
• 复现会失控：什么都想碰，什么都跑不通。
• 论文切口会失焦：最后只剩下“想做一个更大的系统”。

所以这套调研的核心结论不是“低空 VLA 很重要”，而是：

先把语言引导导航这条主线讲清，再把输出接口从导航结果扩展到可执行动作。

这就是为什么这条路线最后会落到一句很关键的话：

Aerial VLN 是任务定义，Aerial VLA 是动作生成接口。

二、Aerial VLN 和 Aerial VLA 到底怎么区分#

1. Aerial VLN 是任务#

Aerial VLN 讨论的是：无人机如何根据自然语言指令和视觉观测完成导航。

它的输入通常包括：

• 语言指令
• 第一视角或多视角视觉观测
• 可选的位姿、历史、地图、深度、里程计

它的输出可以是：

• 目标点
• 地标
• 航点
• 路径
• 离散导航动作
• 停止信号

也就是说，VLN 的核心是任务目标：要不要到达、能不能找对、路径是否符合语言条件。

2. Aerial VLA 是接口#

Aerial VLA 讨论的是：模型是否直接或分层地产生可执行动作。

它更关心输出接口，比如：

• 速度
• 姿态
• yaw rate
• 6-DoF 轨迹
• waypoint-action
• 技能动作
• 交互动作

对无人机场景来说，动作不只是一串飞控数值，也可以是更高层的技能：

• NAVIGATE
• APPROACH
• ORBIT
• CAPTURE
• TRACK
• ASK
• LAND
• RETURN
• SAFE_STOP

所以真正该记住的关系是：

VLN = 任务
VLA = 接口

• VLA 可以解决 VLN 任务。
• VLN 不一定已经进入 VLA 形态。
• 低空 VLA 最自然的落点，不是凭空定义一个新世界，而是在已有 aerial VLN 任务上扩展动作空间。

三、这条方向现在最稳的研究主线是什么#

从已有论文、数据集、平台、benchmark 和代码可获得性综合看，当前最稳的主线是：

AerialVLN
  ->
CityNav
  ->
OpenUAV / TravelUAV
  ->
OpenFly
  ->
navigation-centric Aerial VLA

这条主线的含义不是“论文越新越强”，而是它恰好对应了一条逐步增加真实度和动作复杂度的路线：

• 从 canonical 的空中 VLN benchmark 出发
• 走向真实城市级地理语义 grounding
• 再过渡到更 realistic 的连续飞行和任务级执行
• 最后才进入更像 aerial VLA 的动作生成范式

两条重要扩展支线#

主线之外，还有两条很值得盯住的支线。

支线 A：dialog-based aerial navigation#

AVDN -> TG-GAT -> FELA -> AerialVLA Online Dialogue

这条线关心的是：

• 当语言有歧义时，无人机何时继续飞，何时提问
• ASK / clarify / recover 这类交互动作如何建模
• dialog-based navigation 如何自然过渡到 interaction-aware aerial VLA

支线 B：fine-grained low-altitude control#

TravelUAV / realistic UAV-VLN
        +
UAV-Flow
        ->
fine-grained aerial action execution

这条线关心的是：

• 低空短程、细粒度、语言条件下的技能动作如何执行
• 导航和动作执行的边界在哪里
• 低空任务级动作词表应该如何定义

四、从时间线上看，这个方向是怎么长出来的#

如果把这条研究线摊开看，它不是突然从 2026 年的 aerial VLA 论文里长出来的。

2018：雏形阶段#

• R2R 把地面 VLN 做成了具身任务基准。
• LANI 在更简化的 2D 条件下，引入了 aerial-perspective instruction/trajectory 数据。
• 同期已经出现四旋翼语言控制相关工作，为后来的 aerial VLA 埋下伏笔。

2020-2022：交互分支出现#

• VLN-CE 强化了连续环境下的 VLN 设定。
• Aerial Vision-and-Dialog Navigation (AVDN) 开出了空中对话导航这一支。

2023：canonical baseline 成形#

• AerialVLN 成为空中第一视角户外 UAV VLN 的 canonical benchmark。
• TG-GAT 成为 AVDN 分支里第一批强 follow-up。

2024：真实度上升#

• CityNav 把重点转向真实城市 3D 扫描和地理语义 grounding。
• OpenUAV / TravelUAV 开始强调连续 6-DoF 轨迹、多视角感知和 assistant-guided benchmark。
• AeroVerse、EmbodiedCity 等工作开始把空中具身 benchmark 面扩得更宽。

2025：方法开始分叉#

• CityNavAgent、SkyVLN、FlightGPT、GeoNav、LookasideVLN 等工作，把 LLM planning、hierarchical memory、dual-scale reasoning 引入 aerial VLN。
• FELA 等后续工作进一步强化了对话导航里的 entity-landmark 对齐。
• BEDI、UAV-ON、UAV-Flow Colosseo 开始把研究从纯导航扩展到 embodied evaluation 和 imitation。
• OpenFly 把 toolchain + benchmark 平台化这件事推得更远。

2026：从 survey 到 aerial VLA#

• 总览型 survey 把 AVIN/AVDN、方法家族、数据集、平台、指标和 open problems 全部系统化。
• AutoFly 把问题更明确地往端到端 aerial VLA 上推。
• AerialVLA Minimalist 让“navigation-centric aerial VLA”这条说法第一次变得很自然。
• UAV-Track VLA 进一步把动作接口从导航扩展到动态跟踪。

换句话说，这个方向现在真正成熟的不是“泛无人机具身大模型”，而是：

从空中视觉语言导航，逐步走向更 realistic、更连续、更任务级的动作执行。

五、这份调研不是堆论文，而是按方法论构建的#

这份材料最可贵的地方，不是它列出了很多名字，而是它把“怎么调研这个方向”也一起定义清楚了。

1. 检索不是靠标题关键词硬搜#

这套调研明确反对只靠标题搜索。更稳的扩展方式是：

1. 从 seed papers 出发。
2. 读引用文献。
3. 查 citation graph。
4. 查作者和实验室后续工作。
5. 查 project page、GitHub、数据集页面。
6. 单独检索 benchmark、simulator、model name 和 dataset name。

它使用的主要来源包括：

• arXiv
• OpenReview
• CVF Open Access
• AAAI OJS
• ACM Digital Library
• IEEE Xplore
• Semantic Scholar
• OpenAlex
• PapersWithCode
• GitHub
• Hugging Face
• official project pages

Google Scholar、Connected Papers、CatalyzeX、Awesome Lists 只被当成发现入口，而不是最终证据。

2. 检索词是按任务簇设计的#

这套材料没有把“无人机具身”混成一团，而是分别设计了四组词：

• Aerial VLN
• Aerial VLA
• Embodied UAV benchmark
• Simulators and frameworks

这意味着它在一开始就区分了：

• 任务定义
• 动作范式
• benchmark 层
• 平台层

这也是为什么后面的结论会比“搜到几篇大模型论文”更稳。

3. 每个条目都有统一输出标准#

这份调研不是自由写摘要，而是给论文、数据集、benchmark、framework、代码库、团队都定义了统一 schema。

以论文为例，它要求至少记录这些字段：

• 标题、作者、年份、来源
• 任务轴和动作轴
• 输入模态和输出空间
• 用了哪些数据集和 simulator
• 主要贡献和局限
• 与 aerial VLN / VLA 的关系
• 可复现性等级
• 质量等级

这件事非常重要，因为如果不统一字段，最后很容易把“任务、动作、平台、可复现性”混着写。

4. 它把“核实”也做成了显式规则#

这份材料的质量控制不是一句“要严谨”，而是显式地给出了状态、质量和复现等级。

条目状态分四类：

• verified
• partially_verified
• needs_verification
• excluded

质量等级从 Q0 到 Q5：

• Q0：无关或低质量
• Q1：只有博客、demo 或弱证据
• Q2：有预印本或 workshop，但证据有限
• Q3：可靠的 arXiv / OpenReview 工作
• Q4：强 conference/journal 或被广泛使用的平台、数据集
• Q5：field-defining 的 survey、benchmark 或平台

可复现性从 R0 到 R5：

• R0：没有代码或数据
• R1：repo 存在，但不完整
• R2：只能跑 inference
• R3：可以 evaluation
• R4：可以训练
• R5：训练、评测、数据、模型都完整可复现

5. 它专门防止两个常见误判#

第一种误判是标题膨胀。

如果一篇论文标题写了 VLA，这份调研不会直接接受，而是继续追问：

• 最终输出到底是什么
• 有没有闭环执行
• planner / controller 在里面扮演什么角色
• action space 到底多强
• 是不是只是在导航任务上换了个名字

第二种误判是空中相关性不足。

只有满足下面至少一条，才会被纳入主调研：

• agent 本身就是 UAV / drone / aerial robot
• 数据集或 simulator 是 UAV-specific
• 任务是 aerial navigation / tracking / inspection / delivery
• 方法输出 UAV action 或在 UAV 环境里评测
• benchmark 明确评估 UAV embodied agent

进一步，如果要被归到“低空相关”，还需要涉及：

• urban low-altitude navigation
• building-level / infrastructure-level tasks
• inspection / patrol / delivery / rescue
• geofence / obstacle / altitude constraints
• near-ground / near-building operation

这几条规则其实决定了这份调研为什么没有滑向“泛 robotics 大杂烩”。

六、如果只看论文主干，应该按什么顺序读#

这份材料给出的阅读顺序非常克制，不是“从最新 VLA 论文开始”，而是：

survey -> dataset/platform -> method -> VLA extension -> benchmark

这条原则非常对，因为如果没有 VLN 底座，后面很容易把 action interface 误读成任务定义。

1. Week 1：先把领域定义清楚#

第一周最该读的是：

1. Vision-Language Navigation for Aerial Robots: Towards the Era of Large Language Models
2. AerialVLN
3. CityNav
4. Towards Realistic UAV Vision-Language Navigation: Platform, Benchmark, and Methodology

这四篇基本决定了：

• 什么是 aerial VLN
• 主线 benchmark 是谁
• realism 从哪里开始上升
• 后面为什么能顺理成章走到 aerial VLA

2. Week 2：理解 scale、realism 和方法支线#

第二周建议进入：

• OpenFly
• Aerial Vision-and-Dialog Navigation
• TG-GAT
• FELA
• CityNavAgent
• FlightGPT
• GeoNav
• SkyVLN
• LookasideVLN

这一周的重点不是把所有细节都吃透，而是理解三个问题：

• aerial VLN 如何从 baseline 走向更强的 reasoning
• dialog-based aerial navigation 到底成立在哪
• scale 和 realism 是怎么被工具链、地图和 VLM 方法推高的

3. Week 3：再从 VLN 走向 VLA#

真正进入 VLA 层时，这份调研建议看：

• AutoFly
• AerialVLA Minimalist
• AerialVLA Online Dialogue
• UAV-Track VLA

这一步其实是在问：

• action interface 什么时候开始变强
• 哪些工作已经从离散导航走到连续控制
• 哪些工作还只是“名字上更像 VLA”

4. Week 4：最后再看 broader benchmark#

最后一周才建议系统看：

• BEDI
• UAV-Flow Colosseo
• AeroVerse
• EmbodiedCity
• UAV-ON

这说明一个很关键的判断：

benchmark 扩展层很重要，但不应该先于主线任务定义。

七、哪些团队和机构值得长期跟#

这份调研没有把注意力只放在论文标题上，而是明确给出了“值得长期跟踪的团队”。

1. AerialVLN 主线源头#

• Northwestern Polytechnical University + University of Adelaide
• 代表工作：AerialVLN
• 价值：定义了第一代 canonical aerial VLN benchmark 和 simulator 语境

2. 大规模平台与 toolchain 方向#

• Shanghai AI Laboratory IPEC
• 代表工作：OpenFly
• 价值：这是当前最像“把 aerial VLN 平台化、规模化”的团队

3. realistic UAV-VLN 到 fine-grained control 的桥梁#

• Beihang University + CUHK MMLab / CPII + Hangzhou International Innovation Institute
• 代表工作：OpenUAV / TravelUAV, UAV-Flow, AerialVLA Online Dialogue
• 价值：这是当前最值得盯住的一条“从 realistic VLN 走向控制与对话式 aerial VLA”的连续线

4. dialog-based aerial navigation 主线#

• UCAS + Institute of Automation, CAS + MBZUAI / CMU / Tencent Robotics X
• 代表工作：TG-GAT, FELA
• 价值：这是 AVDN 分支里最清晰、最连续的后续方法线

5. real-city grounding 主线#

• University of Tokyo / Institute of Science Tokyo / ATR / NII
• 代表工作：CityNav
• 价值：这是城市级真实 aerial grounding 的关键来源

6. CityNav 之后的 reasoning 分支#

• EmbodiedCity / Tsinghua-related urban embodied group
• Sun Yat-Sen University + DP Technology + BUPT + ICT CAS + Tongji + Chulalongkorn
• Aerospace Information Research Institute, CAS / UCAS
• HKUST(GZ) Systems Hub / Intelligent Transportation
• National University of Defense Technology + Tsinghua University

对应的重要工作包括：

• CityNavAgent
• FlightGPT
• NavAgent
• SkyVLN
• GeoNav

这些团队共同推动的是：

• 城市场景语义推理
• 多尺度地图建模
• hierarchy / memory / VLM reasoning

7. Aerial VLA 方向的几个新源头#

值得单独盯住的还有：

• AutoFly 对应团队
• AerialVLA Minimalist 对应团队
• UAV-Track VLA 对应团队
• BEDI 对应团队
• UZH Robotics and Perception Group 及其 Flightmare 背景

它们分别对应：

• end-to-end aerial VLA
• navigation-centric aerial VLA
• embodied aerial tracking
• UAV embodied benchmark
• future continuous-control simulator 基础

八、哪些数据集和 benchmark 最值得先掌握#

这份调研里最有价值的一点，不是论文列表本身，而是明确给出了一个“先看什么、为什么”的顺序。

1. AerialVLN：最稳的起点#

AerialVLN / AerialVLN-S 仍然是最适合做起点的 canonical baseline。

它的关键特征是：

• 25 个城市级场景
• 8,446 条路径
• 25,338 条指令
• 第一视角 RGB / depth
• 离散 4-DoF 无人机动作空间
• 公开 simulator 和代码

它最大的价值是：简单、标准、后续工作多。

如果实验室还没有把任何一套 aerial stack 跑起来，从它开始比直接碰更新的 aerial VLA 项目稳得多。

2. CityNav：真实城市语义 grounding 的关键节点#

CityNav 是当前最强的 real-world 城市级语言目标空中导航数据集之一。

它的核心特征是：

• 32,637 条人类演示轨迹
• 覆盖 4.65 km² 真实城市区域
• 使用真实 3D 点云、RGB-D 和地理语义地图
• 输出仍然偏离散导航动作

它的重要性在于：这里开始真正引入了城市语义、地图辅助推理和真实场景 grounding。
如果只做 AerialVLN，会很容易停留在“synthetic city + discrete action”的阶段。

3. TravelUAV / OpenUAV：从导航走向 realistic execution#

TravelUAV / UAV-Need-Help 是目前最适合作为 realism-oriented 连续飞行平台的一个核心入口。

关键特征包括：

• 12,149 条轨迹
• 22 个场景
• 89 个对象
• 多视角 RGB / depth / LiDAR / state
• 连续 6-DoF 轨迹
• assistant-guided benchmark 设计

它的重要性不只是“更难”，而是它开始接近这样的问题：

• 如果语言目标是真实低空任务，动作接口要不要连续
• 如何把地图推理、视觉 grounding 和真实飞行执行接起来
• aerial VLA 应该从哪里过渡进来

4. OpenFly：更大规模的平台化扩展#

OpenFly 的定位更像“大规模平台 + benchmark + 数据生成工具链”。

它的特征包括：

• 100k 轨迹
• 18 个场景
• 15.6k 词汇规模
• 更强的平台化、自动化、toolchain 叙事

它更适合放在前面几套栈已经稳定之后。
原因不是它不重要，而是它的工程复杂度明显高于 AerialVLN 和 CityNav。

5. 什么时候该看 UAV-Flow 和 BEDI#

UAV-Flow / UAV-Flow-Sim 更适合回答细粒度动作执行问题：

• 30,692 条真实轨迹
• 10,109 条仿真轨迹
• 关注短程、语言条件下的 fine-grained UAV imitation

它不是长航程 aerial VLN 的替代品，更像是低空短程 skill execution 的关键补充。

BEDI 则更像 capability benchmark，而不是第一套导航复现环境：

• 覆盖 perception、planning、tool use、action 等子能力
• 更适合在实验室已经有一套可运行 agent 后，做能力审计

九、真正应该跟住的指标，不只是一组 SR/SPL#

如果只沿用地面 VLN 的指标体系，你很容易高估一篇 aerial 方法的真实价值。

经典 VLN 指标#

当前仍然应该保留的经典指标包括：

• SR
• OSR
• SPL
• NE
• nDTW

这些指标仍然是主线比较的基础。

UAV realism 指标#

一旦进入更 realistic 的平台，就必须额外看：

• collision rate
• altitude violation
• geofence violation
• smoothness
• latency
• safety stops
• energy / time

这部分非常关键，因为很多看起来“导航成功”的方法，一旦接入真实飞行语境，问题就会暴露在动作质量和安全约束上。

VLA / embodied 指标#

当问题不再只是“到没到”，还要看：

• task completion
• subgoal completion
• query quality
• tracking frames
• action validity

这也是为什么这份调研强调：

未来真正有价值的工作，不只是把动作从离散变连续，而是把安全、交互和任务完成度一起纳入评价。

十、平台层怎么选，决定了你后面是在做研究还是在修环境#

这份材料对平台层的判断很实用：不要把 simulator 当成背景，它本身就会决定你后续的问题定义。

1. AirSim：主线复现的老牌底座#

AirSim 对 aerial VLN 很重要，因为：

• AerialVLN
• TravelUAV
• 不少老的 UAV VLN 栈

都和它深度绑定。

它的优点是学界采用广、视觉效果够用、接口成熟；缺点是上游已经不再是一个高速演化的活跃底座，所以你要有“维护旧栈”的心理准备。

2. PX4 SITL / Gazebo / ArduPilot：更接近真实飞控#

如果目标是把语言导航往 controller-in-the-loop 推，这些栈会更重要。

但它们不适合作为第一步，因为一上来就会把大量精力烧在：

• firmware
• robotics toolchain
• simulator integration
• middleware

而不是研究问题本身。

3. Flightmare / Isaac Sim：更偏未来连续控制和 RL#

这类平台更适合未来的 aerial VLA、continuous control、synthetic data 和 sim-to-real 管线。

但如果当前任务还是“建立第一条稳定主线”，它们更像第二阶段平台，而不是第一站。

4. OpenUAV / TravelUAV 和 OpenFly：研究平台化的两个关键点#

• OpenUAV / TravelUAV 更适合 realism-oriented UAV-VLN 与 continuous execution
• OpenFly 更适合大规模平台、benchmark 自动扩展、synthetic-to-real 工程化

换句话说，一个偏 realistic execution，一个偏 platform scaling。

十一、现在有哪些代码库是真的能动，哪些还只是论文信号#

这部分很重要，因为它直接决定复现顺序。

这里最好把“能不能动”再说得更标准一点：

• R4：训练和评测主线都能建立起来
• R3：至少评测面可跑
• R1：repo 虽然存在，但还不构成真实复现入口

从这份材料的判断看，当前最稳的 R4 级主栈就是：

• AirVLN/AirVLN
• water-cookie/citynav
• prince687028/TravelUAV
• SHAILAB-IPEC/OpenFly-Platform

当前“可立即使用”或接近可立即使用的主力代码库#

最值得优先下手的几套是：

• AirVLN/AirVLN
• water-cookie/citynav
• prince687028/TravelUAV
• SHAILAB-IPEC/OpenFly-Platform

这些仓库共同特征是：

• 官方性明确
• 代码和脚本可见
• 数据或环境入口相对清楚
• 虽然重，但不是“只有论文，没有执行面”

部分可跑，但要谨慎判断的 R3 级栈#

这些工作很有价值，但更适合在主线稳定后进入：

• CityNavAgent
• TG-GAT
• AerialVLA Minimalist
• UAV-Flow
• BEDI
• FlightGPT

它们的问题通常不是“没有内容”，而是：

• 依赖栈更重
• 外部资源更多
• 训练和评测步骤分裂
• 代码可运行面不如主线 VLN 栈稳定

当前明显存在 paper-to-code gap 的 R1 级条目#

至少有几类工作现在不应该作为第一复现目标：

• FELA：官方仓仍写着 Code coming soon
• AutoFly：当前更像 project page，不像完整可执行 release
• UAV-Track VLA：公开样例和演示可见，但完整训练/评测面还需要进一步核查

这类工作适合：

• 阅读
• 方向判断
• 设计 future ablation

但不适合拿来做第一轮“必须跑通”的栈。

十二、如果今天开始复现，最稳的顺序是什么#

这份调研给出的复现排序，我认为是整个材料里最实用的一部分：

AerialVLN
  ->
CityNav
  ->
TravelUAV / OpenUAV
  ->
AerialVLA Minimalist on TravelUAV
  ->
OpenFly

为什么是这个顺序#

因为它不是按论文新旧排，而是按“研究线是否连贯 + 执行风险是否可控”来排。

Stage 1：AerialVLN#

这是 canonical baseline，对后续大量工作都有参照意义。

已知环境特征：

• Python 3.8
• airsim==1.7.0
• pytorch-transformers==1.2.0

已知风险：

• simulator 资源大，约 35 GB
• 端口 30000
• 图像通道顺序需要额外确认

Stage 2：CityNav#

这里的推荐不是直接上完整 VLNCE，而是先走 map-guided goal predictor 这条更短的成功路径。

已知环境特征：

• Python 3.10
• PyTorch 2.2.2
• CUDA 11.8
• 依赖包括 SoM、LLaVA、GroundingDINO、MobileSAM

这里真正的难点不是模型，而是依赖图非常重。

Stage 3：TravelUAV / OpenUAV#

这一步是主线里最接近 realistic continuous execution 的地方。

已知环境特征：

• Python 3.10
• torch==2.0.1
• cu118

已知风险包括：

• 仓库里是 requirement.txt 不是 requirements.txt
• README 和脚本文件名不一致
• 端口 30000 / 25000 不统一
• DDP_MASTER_PORT 80005 是无效端口

这类问题非常典型：真正难的不是论文想法，而是工程细节不一致。

为什么不要把这些环境混在一起#

调研给出的一个非常实用的规则是：

每一套主栈单独 conda 环境，不要合并。

原因很现实：

• AerialVLN
• CityNav
• TravelUAV
• UAV-Flow

它们的 Python 版本、Torch/CUDA 组合、依赖树都不同。
如果一开始试图“统一成一个研究环境”，最后大概率是在修环境，而不是在复现方法。

十三、dialog 和 fine-grained control 这条支线该怎么切#

如果后面你想做对话导航或细粒度低空动作控制，这份调研的判断也很清楚：

AVDN -> TG-GAT -> FELA#

这条线适合回答：

• 什么时候该提问
• 如何利用 query 消除歧义
• semantic grounding 如何提升对话导航

但它不是第一默认入口。
更准确地说，它是“主线稳定后”的专题分支。

UAV-Flow#

这条线适合回答：

• 短程、低空、语言条件下的动作执行
• imitation learning 风格的细粒度 aerial control

但它工程上是另一条独立栈：

• openvla 环境
• unrealcv 环境

而且默认训练路径就是 8 卡，明显不适合作为一开始的 first success route。

所以最稳的处理方式是：

• 主线先跑 AerialVLN -> CityNav -> TravelUAV
• 对话分支后上 AVDN -> TG-GAT
• UAV-Flow 放到更后面，或者在另一台机器上独立推进

十四、这份调研真正指出的研究缺口是什么#

这里最重要的不是“列出 open problems”，而是把它们翻译成能做论文的问题。

1. discrete-to-continuous mismatch#

当前 aerial VLN 仍然大量停留在：

• 离散动作
• synthetic data
• planner-controller split

而 aerial VLA 开始给出：

• 连续动作
• 更真实的执行接口

但二者之间的桥，还没有被系统搭稳。

2. safety-aware evaluation 太弱#

现在大量工作仍主要报告：

• SR
• SPL
• OSR

但对于真实 UAV 场景，这明显不够。
未来更有价值的评测，应当把 collision、altitude violation、latency、safe-stop 和 intervention 一起引入。

3. low-altitude task actions 还没有被明确定义#

这里最值得做的一件事，不一定是上来训练更大的模型，而是先把低空任务级 action vocabulary 定义清楚。

像下面这组动作就很有代表性：

NAVIGATE
APPROACH
ORBIT
CAPTURE
TRACK
ASK
LAND
RETURN
SAFE_STOP

这比空泛地说“做低空 VLA”要清楚得多。

4. dialog evaluation 还不成熟#

现在对话导航里最该补的，不只是最后有没有成功，而是：

• query timing
• query utility
• recovery behavior

也就是：问得值不值、问得晚不晚、问完有没有真正帮助恢复。

5. sim-to-real 还是太窄#

一条非常好的研究叙事是，把现有数据集看成 realism ladder：

AirVLN
  ->
CityNav
  ->
TravelUAV / OpenUAV
  ->
AirNav

这比只抓住其中一个 benchmark 单点突破，更有体系感。

十五、第一篇论文最可能的三个切口#

这份材料最后给出的三个方向，我认为都合理，但优先级不一样。

方向 A：在强 VLN 底座上加 task-level action head#

这是我认为最稳的第一选择。

核心问题是：

能不能在 TravelUAV / OpenUAV 这类平台上，保留语言导航问题本身，但把输出从 route / discrete action 扩展到 task-level action？

这条线的优点是：

• 贴近“低空 VLA”的外部表述
• 又不脱离更成熟的 VLN benchmark 主线
• 更容易设计出安全评测和动作词表

方向 B：把 CityNav 的语义 grounding 接到 TravelUAV 的执行接口上#

这条线更像“增强版主线”。

核心问题是：

能不能把 CityNav 的城市级语义推理能力，接到 TravelUAV 风格的 realistic execution 上？

它的价值在于：

• 把地理语义 reasoning 和连续执行之间的断裂补起来
• 比纯端到端 aerial VLA 更容易说清贡献

方向 C：主动提问的 aerial action#

这条线最前沿，但风险也最高。

核心问题是：

无人机何时应该继续飞，何时应该提问？

这条线的理论价值很强，但因为 benchmark、代码和 runnable 栈都不如主线稳定，所以更适合作为第二阶段支线。

十六、如果把它压成一句话，该怎么向老师汇报#

我觉得这套调研里最值得保留下来的，不是某篇论文名字，而是这一句话：

我们不是直接做泛化低空 VLA，而是先做更成熟的 Aerial VLN 主线，再把输出从导航结果扩展到任务级动作，这就是 navigation-centric Aerial VLA。

这句话的好处是：

• 任务边界清楚
• benchmark 入口明确
• 平台路线可复现
• 后续论文切口自然

如果再压缩成最短版本，那就是：

1. 先把 AerialVLN -> CityNav -> OpenUAV/TravelUAV -> OpenFly 这条主线吃透。
2. 再把动作接口从导航结果扩展到可执行任务级动作。
3. 第一篇论文优先做 task-level action extension，而不是空泛地追“更大的低空 VLA 模型”。

这不是更保守，而是更能落地。