洛桑联邦理工学院自主无人机集群：六机编队累计约2小时无碰撞

龙哥导读

无人机集群最难的，常常不是再发明一个漂亮算法，而是让六台真实飞行器同时装好、同时更新、同时起飞、同时交换轨迹，还能在通信延迟、丢包、气流扰动和深度噪声下不撞。洛桑联邦理工学院这项工作把硬件装配、批量部署、第二代机器人操作系统多机通信、机载感知、规划控制和飞后日志串成一条开源链路。最抓人的结果是：六机无障碍编队累计飞行约2小时未记录碰撞；但这个数字只属于室内动作捕捉场地，不能直接等同于户外完全自主蜂群。

如果把一台无人机飞稳看成“单人驾驶”，那么把六台无人机一起飞起来，更像让六名车手在一个狭小赛场里高速换位：每台机器都要知道自己往哪走，还要持续接收其他成员的计划，给通信抖动留余量，并在控制误差真正发生前把安全距离算进去。问题是，论文里的算法模块通常各自很漂亮，到了真实系统里却会被版本、网络、时间同步、相机标定、电池衰减和日志排查拖住。

SwarmNxt瞄准的正是这段最“脏”、也最决定能否复现的工程链。它没有宣称发明全新的规划器、控制器或深度网络，而是把已有模块改造成可在多架实体无人机上协同运行的第二代机器人操作系统，并补上批量配置、起飞前检查、飞后回收数据等工具。这篇论文真正的贡献，不是一个孤立算法，而是一套把无人机集群研究从“实验室手工活”推向可重复流程的基础设施。

官方项目Demo：实体无人机在室内动作捕捉场地执行多机换位与协同飞行。感知、规划和控制在机载计算机上运行；全局位置仍由外部动作捕捉系统提供。

先看画面里最容易被忽略的一点：这些不是仿真轨迹，也不是生成视频，而是真实四旋翼在同一空间中同时运动。换位时，多架机器会向中心聚拢，旋翼下洗气流相互干扰；随机巡游时，每架机器不断收到新的圆周目标点。Demo证明平台能够完成这类实体多机实验，却没有证明它能在废墟、强风或无外部定位的户外环境直接工作。

一、为什么“把六台机器一起飞起来”本身就是研究问题

单机系统出错，工程师还能接上显示器逐项排查；集群系统出错，故障会在机器之间传播。一台无人机时间没同步，可能让其他成员看到过期轨迹；一台机器的软件版本落后，可能让消息格式不一致；网络广播过多，又会把最关键的飞控通信挤在队尾。更麻烦的是，这些问题往往只在多机同时运行时出现。

论文把现有平台分成两端。商用无人机操作简单、可靠性成熟，却通常是封闭系统，研究者无法自由替换感知、规划和控制模块。微型开源平台很适合群飞教学与编队展示，但机载算力和传感器难以承担复杂视觉自主导航。更强的研究无人机可以运行图形处理算法，却常停留在第一代机器人操作系统、单机脚本或缺少集群级部署工具的状态。

SwarmNxt选择在OmniNxt硬件上继续搭建。单机约660克、轴距约0.27米，配有四路鱼眼相机、英伟达机载计算模块和PX4飞控。论文给出的物料成本约为每台2300瑞士法郎，装配约5小时，单机初始软件设置约1.5小时。这个价格并不便宜，但它换来的是360度视觉、机载图形计算能力和可修改的完整软件栈。

官方项目总览：平台以OmniNxt硬件为基础，上层连接主机、网络与多机软件管理。它强调的是从装配到飞行的完整链路，而不只是单个算法包。

这里最值得普通研发团队注意的不是“开源”两个字，而是开源到了哪一层。官方项目提供物料清单、焊接和装配步骤、飞控参数、主机与无人机配置、批量更新、起飞前检查、飞后日志回收以及控制面板。论文报告，一次并行部署初装约20分钟，后续增量更新约1分钟；起飞前检查约20秒，飞后集中回收日志约30秒。

这些时间不是说买来零件后一小时就能完成集群。物料采购在瑞士的估计周期约1.5个月，每台机器仍要独立装配、接线、标定。自动化真正节省的是后续反复实验的边际成本：当第十次改规划器参数时，不必登录六台机器重复敲命令，也不必靠人工记忆判断哪台漏更了。

二、系统总览：隔离通信域，再只放行必要消息

SwarmNxt的通信设计可以类比一栋有多个实验室的楼。每架无人机拥有自己的第二代机器人操作系统通信域，域内运行飞控接口、控制器、规划器、地图和感知模块；地面主机位于主通信域。不同房间默认不互相广播，只有经过“门卫”——域桥——允许的必要消息才跨域。

论文图2。左侧是地面主机与动作捕捉输入，中间的域桥选择跨域消息，右侧是每架无人机独立通信域中的PX4接口、控制、规划、地图、深度估计与安全节点。轨迹在无人机之间交换，规划和控制在机载端执行。

图中第一条主线是状态进入、轨迹出去。外部动作捕捉系统给出全局位置，经主机传给各无人机；每台机器在本地规划自己的轨迹，再把计划轨迹广播给其他成员。邻机不需要接管它的控制，只需知道“你接下来准备经过哪里”，就能在自己的规划中留出时空走廊。

第二条主线是飞控链路隔离。PX4与机载计算机之间通过轻量数据分发接口交换高速状态和指令。如果所有无人机挤在同一个广播域里，消息数量会随集群扩大而快速增加，关键飞控数据可能被无关通信拖慢。独立域把每台机器的内部交通锁在本地，域桥只搬运轨迹、状态和全局指令等必要信息。

第三条主线是“集中管理、分布执行”。地面主机负责全局操作、仪表盘和外部定位转发，但规划、建图与控制在每架无人机上运行。因而论文谨慎地把运动规划器称为去中心化规划算法，而没有把整个系统称为完全去中心化：只要全局位置仍来自动作捕捉和主机，系统就保留着中央依赖。

三、从轨迹到电机：规划、控制和视觉怎样接成闭环

导航栈由三块组成：高速去中心化同步运动规划器、100赫兹自适应模型预测控制器，以及可扩展立体匹配深度模型。三块并不是简单“装在一起”。为了让它们服务多机实体实验，团队修改了通信、地图更新、邻机过滤、电池补偿和安全监督。

规划器每0.1秒更新一次，向前看12步，也就是约1.2秒的规划窗口。它既考虑静态障碍，也把其他无人机发布的未来轨迹当成动态约束。实验设置的安全半径为0.45米，明显大于测得的最大跟踪误差，用空间冗余吸收控制偏差和通信延迟。最大速度、加速度与加加速度上限分别设为10米/秒、10米/秒²和20米/秒³。

控制器以100赫兹读取当前状态和参考轨迹，输出总推力与机体角速度给PX4。论文还加入一个很朴素的电池补偿：飞行时间变长后，电压下降，相同控制量产生的升力会变化；如果机器持续低于目标高度，就逐步提高推力缩放，反之降低。它没有重新辨识整套动力学，而是用垂直误差的积分修正慢变化。

视觉侧使用2600多万参数的立体匹配小型模型。四个鱼眼相机经标定和校正后组成四组虚拟双目，分别预测稠密视差，再换算成四个方向的深度图。输入分辨率为256×160，平均更新率约7赫兹；在2米距离处，论文报告平均深度误差约10厘米。

地图更新没有把每个体素简单标成“空”或“占用”，而是累计对数似然证据。一次深度观测命中某体素，就提高占用值；射线穿过的体素则降低。累计值高于1才判为占用，低于−1才判为空，中间保持未知。这样偶发深度噪声不会立刻制造实心墙，也不会一次漏检就把障碍擦掉。

还有一个很关键的多机修补：其他无人机不应被永久写进静态障碍地图。系统根据邻机当前位置建立包围盒，在点云进入占用地图前删除这些区域。否则一架无人机飞过后，地图可能留下一个“幽灵障碍”，后续规划器会绕着不存在的物体走。

四、实验结果：约2小时无碰撞，究竟说明了什么

实验都在8×8×4米的室内动作捕捉场地完成。论文分别验证两种情形：六架无人机关闭深度估计，在开阔环境中测试机间避碰；四架无人机开启机载深度估计，在设置静态障碍的环境中测试感知与避障。之所以第二组只有四架，是因为其余机器当时尚未完成鱼眼相机标定。

论文图4的移动端重排。上图为六架无人机换位轨迹，下图为Foxglove实时可视化。无人机从圆周位置向中心交汇后交换目标，对规划器的机间碰撞约束和控制抗扰动能力形成压力测试。

六机实验先做圆周换位，再持续随机巡游。每架无人机到达目标点0.3米范围内后，系统就在半径2.8米、高度1.5米的圆周上重新采样目标。论文报告，在累计约2小时飞行中，即使通信存在延迟且丢包率为0.2%，仍未记录碰撞。

这里必须把标题数字读准确。第一，论文写的是累计约2小时，不是一场连续两小时耐久飞行。第二，“无碰撞”指这些室内试验中没有记录到机间碰撞，并不等于统计意义上的永久安全保证。第三，这组六机实验没有启用视觉障碍避让，核心考察的是机间轨迹交换、规划与控制。

论文图5。左侧为四机在静态障碍间巡游的轨迹，右侧展示单机占用地图与所有无人机计划轨迹。该实验启用了机载深度估计，但全局位置仍来自外部动作捕捉。

四机障碍实验累计飞行30分钟，同样没有记录撞上障碍或撞上其他无人机。作者明确说明，这与规划和建图采用保守调参有关；如果环境更拥挤，就需要放松保守策略，同时提高深度估计精度。换句话说，系统当前选择的是“少冒险、绕远一点”，不是在极限密集环境里证明最优效率。

跟踪误差也给出了更细的边界。四机视觉场景平均误差0.075米、最大0.301米；六机场景平均0.077米、最大0.315米。两组最小机间距离分别为0.668米和0.652米。由于规划安全半径为0.45米，最大控制偏差仍处在预留余量内，但这个比较不能代替更大规模、更长时间和更多故障模式的安全统计。

依据论文图3与正文重绘的移动端数据卡。开启障碍环境实验时，深度估计占据主要图形处理资源；整套自主栈图形处理器占用约95%、中央处理器约54%。这些数字只对应论文所用硬件与配置。

计算预算是这项工作的现实瓶颈。深度网络平均耗时148毫秒，最坏246毫秒，因此约7赫兹是自由运行吞吐率，不是严格截止周期。建图与规划最坏耗时分别85.8和86.8毫秒，仍在100毫秒预算内。100赫兹控制器平均只需1.13毫秒，但最坏达到40.4毫秒，超过10毫秒周期；此时PX4保持上一控制设定值，实际影响最终反映在最大跟踪误差中。

图形处理器约95%的占用意味着几乎没有空间再并行放入更大的视觉模型。中央处理器约54%则还有一定余量。这直接影响扩展路线：如果团队想同时运行视觉里程计、目标识别和语义地图，不能只把更多网络塞进同一块机载计算模块；要么换更轻的模型和分辨率，要么重新分配计算，要么接受更低更新率。

五、与三类开源平台相比，SwarmNxt补的是哪一环

Agilicious代表高性能单机路线：它把开源硬件、敏捷控制和视觉飞行做得很扎实，证明研究级四旋翼可以同时开放机体和软件。但其原始系统基于第一代机器人操作系统，也没有把多机批量部署和集群级通信作为核心产品。SwarmNxt不是取代它的飞行性能研究，而是把问题向“多台机器如何一致运行”推进。

Crazyflie群飞框架代表轻量路线：以微型四旋翼和第二代机器人操作系统组织多机控制，文档与自动化友好，特别适合教育、算法验证和较大数量编队。不过微型平台的机载算力有限，复杂深度估计、地图和高速规划通常要依赖外部计算。SwarmNxt用更重、更贵的硬件换取机载视觉自主能力。

OmniNxt则是SwarmNxt最直接的前身。它提供紧凑机体、四路鱼眼全向视觉和英伟达机载算力，解决了“单架机器有没有眼睛和大脑”的问题；新平台在此基础上补上多机通信域、轨迹桥接、批量部署、预检、日志回收和实体集群验证。可以把两者的关系理解为：OmniNxt造出可研究的单机，SwarmNxt把多台单机组织成可反复实验的队伍。

这三类路线没有绝对胜负。想做百架编队算法，低成本微型机更合适；想研究极限机动与视觉控制，高性能单机平台更直接；想在少量实体无人机上把感知、规划、控制和工程运维一起研究，SwarmNxt的系统完整性更有价值。选择平台的第一问不该是“谁指标最高”，而是你的实验到底需要多少机载计算、多少机器、什么定位条件，以及团队能否承担装配和安全管理。

相似工作：Agilicious
https://www.science.org/doi/10.1126/scirobotics.abl6259

相似工作：Crazyflie群飞框架
https://arxiv.org/abs/2302.00716

硬件前身：OmniNxt
https://arxiv.org/abs/2403.20085

六、代码与复现：资源是真的，门槛也是真的

官方仓库在本文核验的提交4dcfc83aaab376581a5de79f8d47c440042beb51中，包含主机配置、单机设置、全机队更新、起飞前检查、关机与飞后日志回收等Ansible脚本，也包含第二代机器人操作系统启动模板、域桥配置、飞控消息配置、飞行仪表盘和日志分析工具。项目文档逐步写出了焊接长度、接口、相机安装、飞控刷写、网络与时间同步检查。

这比只放一个算法仓库更接近“能照着搭”的工程项目。比如起飞前脚本会启动或检查PX4通信代理和自主栈，确认时间同步、相机时钟与焦点；控制面板显示电池、通信延迟和节点状态；飞后脚本把各机日志集中到主机，并计算跟踪误差、计算耗时和最小机间距离。

但它绝不是下载后按一次回车就能复现论文数字。完整链路需要多台兼容的机载计算无人机、鱼眼相机、无线网络、动作捕捉系统、飞行安全空间，以及对焊接、标定、机器人操作系统、开源飞控和多机网络的操作能力。论文还使用商业优化器等依赖，实际授权和部署成本需要团队逐项确认。

仓库元数据没有识别到顶层开源许可证，根目录也没有可核验的独立许可证文件。因此可以确认源码和文档公开可访问，却不能据此推定所有文件都允许任意商用、修改或再分发。研究复现前应向项目方确认授权边界，并分别检查依赖模块的许可证。

本文没有运行实体飞行测试，也不把静态检查写成“实测可用”。能够确认的是：论文、项目文档、飞行清单、批量运维脚本、通信配置和官方真实飞行演示相互对应；无法在没有专用硬件和安全场地的条件下独立复现约2小时与30分钟飞行记录。这个边界反而很重要——无人机集群不是适合在普通电脑上做个单元测试就宣称复现的项目。

七、局限：离真正的救援蜂群还有三道坎

第一道坎是定位。系统虽然在机载端完成感知、规划与控制，但全局位置依赖外部动作捕捉，经主机分发给每架无人机。因此它不是完整的无基础设施、无中心依赖系统。论文也明确指出，当前协同视觉惯性里程计还达不到敏捷群飞所需的精度和低延迟。

第二道坎是视觉。256×160分辨率与约7赫兹更新率足以支持论文中的保守静态障碍实验，却难以稳定发现远处小物体。深度模型又几乎占满图形处理器。要进入废墟、树林或人群附近，系统需要更轻、更稳健的深度与定位方案，还要面对运动障碍、纹理缺失、强逆光和扬尘。

第三道坎是规模与时间。六机累计约2小时、四机累计30分钟是有价值的实体证据，但还不足以外推到几十架、连续数天或多种故障。无线带宽、轨迹消息密度、域桥配置和人工换电都会随规模变化。论文给出了0.2%丢包下的结果，却没有系统扫描更严重丢包、节点失联、传感器异常和单机坠落后的集群恢复。

此外，实验场地只有8×8×4米，障碍是静态的，速度均值约1.9米/秒。平台的约束上限允许更快运动，但“允许上限”不等于实验持续达到该速度。标题中的“自主无人机集群”指机载自主规划控制能力，不应被读成已经完成户外搜索救援的产品验证。

八、龙哥点评：开源最难的不是放代码，而是放出流程

龙哥对这类工作的评价通常比看一张排行榜更高。原因很现实：机器人研究最昂贵的部分，往往是把论文模块接成不会伤人、不会随机失控、出现问题还能追溯的系统。SwarmNxt把装配、配置、更新、预检、监控、飞行与日志分析连起来，减少的是每次实验都重新踩坑的组织成本。

它也展示了一个重要趋势：当算法逐渐模块化，竞争壁垒会从“有没有某个模型”转向“能否把多模块长期稳定地组织起来”。深度网络、规划器和控制器都不是本文首创，但多机通信域隔离、轨迹桥接、批量部署、安全节点和日志闭环让它们变成一个可工作的研究平台。对企业或实验室来说，这类系统工程能力常比单项指标领先几个百分点更稀缺。

不过，开放平台要真正形成社区，还需要更清楚的许可证、版本化发布、可自动执行的仿真或硬件在环测试，以及不同硬件配置的兼容矩阵。当前仓库对拥有同类设备的团队很有参考价值，对没有动作捕捉和多台无人机的读者，则更适合作为系统架构教材，而不是低门槛复现项目。

龙哥的结论是：这不是“无人机蜂群已经能进废墟救人”的终点论文，而是把真实集群实验最缺的地基铺得更完整。如果后续能用协同视觉惯性定位替代动作捕捉，把视觉算力降下来，并在更大规模、动态障碍和故障注入下持续验证，这套平台才有机会从室内研究基础设施迈向真正的现场自主系统。

龙迷三问

第一问：累计约2小时无碰撞，能否说明系统安全？
能说明在论文给定场地、参数、速度、通信条件和实验流程下，系统表现出稳定性；不能推导出普遍安全认证。安全结论还需要更多小时数、故障注入、动态障碍、不同场地和独立复现。

第二问：既然规划是去中心化的，为什么还需要主机？
每架无人机在机载端独立规划和控制，并交换计划轨迹；但全局位置来自动作捕捉系统，经主机传入。主机还承担操作和监控。因此“去中心化”准确修饰规划算法，而不是整个系统。

第三问：普通团队最值得复用什么？
未必是立刻照着买六台飞机。更可复用的是工程方法：给每个机器人隔离通信域、用声明式工具批量配置、在起飞前自动检查时间同步与关键节点、飞后统一回收日志，并用真实最大误差反推安全半径。

主要资料

官方论文：
https://arxiv.org/abs/2609.11382

官方网页全文：
https://arxiv.org/html/2609.11382v1

官方仓库：
https://github.com/lis-epfl/swarm-nxt

官方项目文档：
https://lis-epfl.github.io/swarm-nxt/

官方完整视频：
https://youtu.be/9aOr5EDLQEo

本文基于龙哥读论文数据库与论文工具进行汇总整理，并以论文初版、官方项目文档、代码仓库和官方飞行演示交叉核验。普通作者姓名未展示。本文为论文解读，不构成飞行安全、产品采购或商业授权建议；涉及实体无人机操作，请遵守场地、人员和当地法规要求。