你說「排成聖誕樹」，三十架無人機就排好了。

你對一套系統說：「在高度兩公尺、以原點為中心，排成一個聖誕樹。」

幾秒後，三十架無人機開始移動。它們互相讓路，誰也不撞誰，最終靜止在空中——一棵聖誕樹的立體輪廓，從頂點到底部，每一架都在正確的位置。

這不是科幻小說的場景。這是 Heriot-Watt 大學杜拜校區的四位研究者，在今年 2 月的 DAUS' 2026 會議上展示的系統。

但這件事為什麼困難？又是用什麼方法讓它成真的？

DAUS'：無人機研究的專業舞台

在看論文內容之前，先認識這個會議。

DAUS（International Conference on Drones and Unmanned Systems，無人機與無人系統國際會議）是一個以無人機為核心主題的學術會議，今年是第二屆，在奧地利薩爾茲堡舉行。相較於 AAMAS 或 ICRA 這類涵蓋範圍廣泛的大型會議，DAUS 的焦點更為集中：無人機的控制、感測、通訊、後處理應用，以及它們在農業、地形測繪、基礎設施巡檢等領域的落地。

這篇論文的主題——用大型語言模型（LLM）控制無人機群體——剛好站在 DAUS 的核心議題上：自主性與易用性。

問題：LLM 不懂物理

用自然語言控制無人機，這個想法本身不新。把「向前飛三公尺」翻譯成控制指令，並不難。

真正的問題出在群體和安全。

當你有三十架無人機，要讓它們同時移動到不同位置，LLM 需要為每一架都規劃一個三維座標——而且這些座標必須在物理上可行：不能飛出邊界、不能互相撞上、速度不能超過馬達上限。

LLM 本質上是文字預測系統。它沒有真實世界的物理接地（physical grounding）——它不「知道」兩架無人機在同一點同時出現意味著碰撞，也無法在推理時追蹤三十個移動物體的即時位置。讓 LLM 直接輸出控制指令，在小規模、低速的情況下或許可行，但在多機、動態、密集的場景，稍有偏差就是連鎖事故。

這篇論文的回答，不是讓 LLM 變得更「懂物理」，而是在架構上把這個責任交給別的模組。

SkySim 的三層架構：感知、規劃、執行

SkySim 建在 ROS2（Robot Operating System 2）上，使用 Gazebo Harmonic 模擬器。它的設計哲學用三個動詞就能概括：感知（Sense）→ 規劃（Plan）→ 執行（Act），三個層次嚴格分離、各司其職。

感知：即時掌握每架無人機的位置

收到自然語言命令的第一件事，不是把命令丟給 LLM，而是先訂閱 ROS2 的 /odom 話題，取得所有無人機的當前三維座標。

這個座標來自 Gazebo 的模擬真值（ground truth），用來模擬真實部署中 OptiTrack 這類動作捕捉系統所提供的精準位置資訊。感知層的輸出是一個即時的「群體拓撲快照」——每架無人機現在在哪裡。

規劃：LLM 做高層空間推理

感知完成後，系統動態組合一個 prompt，把三件事塞進去：

系統指令（無人機數量、座標系定義、高度下限 Z ≥ 0.5 公尺）
所有無人機的當前位置
使用者的自然語言命令

這個 prompt 送給 Gemini 3.5 Pro。LLM 被要求只輸出一個 Python list，格式嚴格——N 架無人機對應 N 組 [x, y, z] 座標，沒有任何多餘的文字或 markdown。系統用抽象語法樹（AST）做格式驗證；如果輸出格式錯誤或 API 超時，系統直接讓所有無人機維持當前位置，不進入未定義狀態。

關鍵在於：LLM 的任務只有一件事——把語意翻譯成座標。它不控制油門，不決定路徑，不負責防撞。它只需要回答「這架無人機應該最終停在哪裡」。

執行：APF 安全濾波器，20Hz 持續運行

LLM 給的是靜態目標點，不是飛行路徑。把無人機從現在的位置移到目標位置，是執行層的工作——而執行層的核心是**人工勢場（Artificial Potential Field，APF）**控制器。

APF 以 20Hz 的頻率持續運行，為每架無人機計算速度向量，由兩個力的疊加決定：

吸引力：把無人機往目標位置拉，增益 K=1.0 的比例控制器。
斥力：當任意兩架無人機的距離低於 0.8 公尺，立刻啟動線性斥力向量，把它們推開。斥力增益 K=2.0，確保排斥力足以壓過吸引力。

在此之上還有兩道硬性限制：任何 LLM 生成的座標如果超出虛擬圍欄（X,Y ∈ ±10 公尺，Z ∈ 0.2 到 5 公尺），直接拒絕並讓無人機懸停；最終速度指令飽和在 0.5 m/s，確保不超出 Crazyflie 2.1 的運動學限制。

選擇 APF 而非強化學習或 MPC，是刻意的工程決策。APF 是確定性演算法，計算量極低，能夠在控制迴路裡以毫秒級延遲運行——而 LLM 的推理可能需要 30 到 50 秒。兩者的時間尺度差了三個數量級。把它們嚴格分離，是讓整個系統可行的關鍵。

實驗：三十架無人機，一句話。

研究者設計了三類實驗，分別測試不同面向。

隊形生成：空間推理準確率 100%

最直接的測試：給不同規模的群體（N=3、10、30）下達隊形指令，包括：

「以原點為中心，在高度兩公尺排成一個三角形」
「以原點為中心，排成一個半徑三公尺的圓圈」
「在高度兩公尺排成 5×6 的網格」
「排成一個 3D 立方體」
「排成一棵聖誕樹」

Gemini 3.5 Pro 在所有測試的幾何圖形上，達到 100% 的空間推理成功率——每次都輸出了有效的 N 組座標，APF 控制器也在沒有碰撞的情況下引導所有無人機到達目標位置。

碰撞壓力測試：APF 守住了

兩個極端情境：

靜態危險：強制讓所有 10 架無人機收斂到同一個點。這在理論上必然引發碰撞。結果：無人機距離一度短暫跌破 0.8 公尺的 APF 啟動門檻，斥力向量立刻接管，主導了吸引力，沒有任何無人機達到物理碰撞。

動態危險：指令為「所有無人機和正對面的那架交換位置」——這讓所有軌跡在空間中心點交叉。APF 的斥力場在即時動態中把彼此繞開，所有無人機最終抵達目標位置。

速度分析顯示，整個重組過程中，峰值速度約 0.42 m/s，始終低於 0.5 m/s 的硬性限制，曲線平滑，沒有高頻震盪。

延遲分析：規模擴大，延遲只多了一半

LLM 的端到端規劃延遲，定義為從發出命令到收到解析完的座標列表為止。

群體規模	平均延遲
N = 3	~24 秒
N = 10	~34 秒
N = 30	~50 秒

群體規模從 3 擴大到 10，翻了超過三倍，延遲只增加約 45%。這個次線性的可擴展性，說明系統在把所有無人機位置塞進 prompt 時，計算成本的增長是可管理的。

不過，N=30 的延遲數據出現明顯的高離散值——有些請求超過 100 秒。這不是演算法問題，而是雲端 API 的伺服器負載和網路抖動造成的。關鍵在於：這段時間裡，APF 仍然在 20Hz 持續守著所有無人機，沒有任何一架因為「LLM 還在想」而出事。

限制：誠實的自我評估

論文對系統的侷限說得很清楚，而且這幾點侷限並不小。

雲端 API 依賴：延遲變異大，最壞情況超過 100 秒，對於需要快速反應的任務完全不適用。

無感測器雜訊：目前的定位來自 Gazebo 的完美模擬真值。真實部署中，OptiTrack 的測量誤差、GPS 偏差、封包遺失，都會讓 APF 的斥力計算失準。

LLM token 限制：N 超過 30 之後，把所有無人機的座標塞進 prompt 可能超出 context window。目前的驗證上限是 30 架。

APF 的局部最小值問題：在障礙物密集的環境裡，APF 可能讓無人機陷入「吸引力和斥力平衡」的停滯點，無法到達目標。這是反應式勢場的已知缺陷。

只有靜態隊形：SkySim 目前只支援「移動到固定點」的重組，不支援連續動態軌跡（例如「旋轉的球體」）。

這個框架說明了什麼？

SkySim 的技術選擇，反映了一個在 LLM 應用設計中愈來愈清晰的原則：信任 LLM 做它擅長的事（語意理解、空間推理），但不要讓它負責它不擅長的事（即時物理約束）。

LLM 的空間推理能力確實令人意外地強——在沒有任何針對性訓練的情況下，Gemini 3.5 Pro 對「5×6 網格」、「3D 立方體」、「聖誕樹」這些抽象描述，都能翻譯出合理的三維座標。這個能力是「泛化的」，不需要事先定義每種形狀。

但物理安全是另一回事。APF 是確定性的、快速的、可驗證的——它不猜測，它按公式算。把這兩件事放在同一個黑盒子裡（直接讓 LLM 輸出控制指令），是危險的；把它們分開，各自在自己擅長的時間尺度上運行，是這篇論文真正的貢獻所在。

未來的工作方向也清楚：把 LLM 換成部署在本地的小型語言模型（SLM）以消除 API 延遲、用 MPC 取代 APF 以解決局部最小值問題、轉移到真實硬體以面對感測器雜訊。

這些都不是短期就能做到的事。但作為一個「讓非專家也能指揮無人機群」的研究框架，SkySim 在模擬環境裡已經把這件事做到了。