RTK稳定性这块真是说到痛点了。我之前在郊区试飞，基站信号稍微被遮挡，定位就开始飘，编队直接乱成一锅粥。后来跟厂商聊过，他们现在用的其实是多源融合定位，RTK+视觉+惯导做冗余，单靠RTK谁也扛不住城市复杂环境。不过你说的“一控多机”架构我倒是有不同看法，这种集中式在千架级别确实好用，但到了万架级，中心节点的算力和通信瓶颈会不会更明显？我看国外有一些团队在尝试完全去中心化的蜂群算法，每架飞机只跟邻居通信，靠局部规则涌现整体队形，抗毁性可能更强。当然，这对机载算力和通信带宽要求也高，国内目前好像还没看到成熟落地的方案。

另外想请教一下，你说的冗余通信协议具体是指什么？是类似TDMA的时分调度，还是跳频+扩频那套？我这边实测发现，当飞机数量超过500架，2.4G频段互相干扰就很严重，厂家给的方案是改成4G专网，但延迟又上去了，表演节奏快的时候队形会迟钝。你们当时是怎么解决这个矛盾的？

协同算法这块确实是核心壁垒，你提到的“一控多机”架构，本质上把地面站的算力下沉到边缘，这个方向我赞同。但有个细节想补充——国内厂商在通信协议层面做的冗余设计，比如双频段跳频和动态时隙分配，其实比海外一些竞品更早落地。我之前拆过某海外品牌的飞控日志，他们的编队同步还在依赖主从式广播，一旦丢包就直接降级成悬停保护，这在复杂电磁环境下根本没法支持大规模编队。

另外，RTK定位的稳定性问题，现在国内头部厂商其实已经用视觉+IMU紧耦合来做辅助，不是纯靠卫星信号。我接触过一些项目，在楼宇密集或强反射场景下，纯RTK的解算收敛时间会显著增加，而视觉惯导融合能把这个从秒级压到毫秒级。不过代价是机载算力要求上去了，这也是为什么大漠大那套架构里要上边缘计算。

想问个具体的技术实现细节：你们当年做编队项目时，队形重规划的触发条件是靠预置时间窗口，还是靠实时传感器回传的异常检测？我见过两种方案，预置窗口的容错率其实不如实时检测，但后者对通信链路和算力开销压力太大，不知道现在行业里有没有更优的折中方案。

确实，协同算法才是真正的护城河。不过我一直有个疑问：像这种大规模编队，如果表演中突然有一架无人机失联或者定位漂移，系统是直接让它退出编队，还是会触发整个队形的实时重新规划？之前看国外一些开源方案好像挺怕这种突发故障的，国内厂商在这方面具体是怎么处理的？

确实，协同算法才是真正的护城河。之前看过一些海外团队的测试视频，无人机数量一多就容易出现定位漂移或通信卡顿，而国内厂商在复杂电磁环境下的表现确实稳定得多。另外我觉得“一控多机”架构对计算资源的分配挺有意思，相当于把决策权下放了一部分给边缘端，这样即使地面站临时出问题，编队也能保持基本队形，这比单纯依赖预设航线靠谱多了。

这个观察挺到点子上。国内编队表演这几年确实卷出了技术代差，不光是规模，而是底层架构的差异。你说的“一控多机”架构，我补充一点：其实更关键的是他们怎么解决通信信道复用的问题。传统方案是主从式广播，信道利用率低，延迟抖动大，到了千架级别基本就崩了。大漠大那套冗余协议，我拆过他们的公开资料，应该是用了时分加频分混合调度，配合机载端实时状态反馈来动态调整优先级，这样在复杂电磁环境下还能保证亚米级同步，确实不是堆硬件能解决的。

不过有个点想跟你探讨——你提到“自研协同控制算法”，我接触过几个厂商，发现他们虽然对外宣称自研，但实际在队形重规划这块，很多还是基于预置模板加有限状态机，实时性有，但灵活性不够。比如遇到突发气象干扰或者单机故障，真正能做到全自主动态重组编队的，目前还没看到哪家能完全跑通。你之前参与的那个项目，有没有遇到过队形切换时控制指令冲突导致抖动的问题？我这边测试过一些开源方案，用DMPC（分布式模型预测控制）来做，算力开销是个大瓶颈，不知道他们是怎么权衡的。

这个“一控多机”的架构确实有意思，我好奇的是它怎么解决单点故障？如果地面控制站出问题，机载边缘计算能自主接管完成表演吗？另外，千架级别的实时避障，数据量应该很大，他们的冗余通信协议具体是怎么平衡延迟和可靠性的？

“一控多机”架构确实是降维打击，把地面算力池化和机载边缘推理结合起来，相当于把编队控制从“指令同步”升级成了“动态博弈”。不过想请教一下，冗余通信协议这块你们当时是怎么做故障切换的？是多路径并行还是主备链路硬切换？我在做多机协同的时候，链路抖动导致的队形撕裂一直是个痛点。