Skip to content

拆兩份運安會炸機報告:兩次都不是操作人的錯

2026年8月7日 1 分鐘
TL;DR 台灣進入運安會統計的無人機重大事故只有 4 件,但那是因為門檻是「逾 25 公斤遭受實質損害」——一般玩家炸機根本不進統計。公開的兩份調查報告是同一款機、同一家製造商、同一個機關,而且兩次的可能原因都是硬體失效:一次是主旋翼伺服器電系,一次是尾旋翼變距連桿斷裂。兩次都與飛控電腦和操作人無關。

🌏 English version

先講邊界:我沒有炸過機,這篇裡的每一次墜毀都是別人的。

但這不完全是缺點。第一手炸機的樣本數是一,而公開的事故調查報告是花了一年多、拆解到齒輪與連桿層級的產物。要理解「無人機怎麼失控」,讀別人的報告的資訊密度,遠高於自己摔一台。

這篇拆兩份運安會(TTSB)的正式調查報告,加上 25 公斤以下的世界該去哪裡看。

先看那個數字:為什麼台灣只有 4 起

依運安會《台灣飛安統計報告 2015-2024》,自 2019 年 4 月將遙控無人機納入調查範圍迄 2024 年底,共發生 4 起重大飛航事故,其中 3 架載具全毀、1 架失蹤,未導致人員傷亡

四起。台灣註冊在案的無人機有數萬架。

這個數字不是說台灣的無人機很少摔,是因為「重大飛航事故」有法定門檻。依行政院公報公告、2019 年 8 月 1 日生效的「重大運輸事故之範圍」,遙控無人機部分是指自為飛航目的啟動推進系統準備移動時起、至飛航結束推進系統關閉時止發生的事故,且符合下列之一:

  1. 造成人員死亡或傷害
  2. 最大起飛重量逾二十五公斤之遙控無人機遭受實質損害
  3. 其他造成人民生命、財產重大影響,且經運安會認定有調查之必要

第 2 款是關鍵。逾 25 公斤才算。 你的空拍機在河濱公園摔成兩半,不在這個統計裡;連公務機關的中型機摔了,只要沒逾 25 公斤、沒傷到人,也不在。

所以「4 起」要這樣讀:這是台灣大型無人機失效的完整清單,不是台灣無人機炸機的清單。 而且正因為門檻高、樣本是公務機關的大型載具,這 4 起的調查深度遠超過一般炸機檢討。

制度的建立時程也值得記一下:運安會於 2019 年 4 月 24 日修正公布的《運輸事故調查法》把遙控無人機納入調查範圍,2020 年 3 月 4 日再發布《遙控無人機重大飛航事故調查作業處理規則》,規範所有人、操作人及政府相關機關的通報事項。

第一份:淡水河口,60 公尺到 4 公尺不到 3 秒

調查報告 TTSB-AOR-22-05-001,2022 年 5 月 20 日發布。

背景:2021 年 3 月 9 日,海洋委員會海巡署北部分署第一無人機區隊執行漁船翻覆案落水人員搜尋,任務時機是內政部空中勤務總隊直昇機返回松山機場加油的空檔。機型田屋科技 AXH-E230RS 無人直昇機,註冊號碼 B-AAA01408。

天氣沒有問題。中央氣象局淡水氣象站當日 0900 時觀測為風向 360 度、風速 1.9 公尺/秒、最大陣風 4.2 公尺/秒、溫度 20℃、露點 17℃、降水量 0 毫米;機組自己的飛勤前檢查紀錄是風速 2.3 公尺/秒、天氣晴。

時間軸(報告記到秒):

0851      起飛,沿近岸開始偵搜,巡航速度約 11 公尺/秒
0909:54   完成預畫航線,進入 GPS 模式
          → 地面導控站顯示該機姿態開始偏轉且無法保持高度
0910:00   操作人啟動自動返航(RTL)
          → 姿態持續偏轉,高度快速下降
0910:05   資料傳輸中止,影像回傳中斷

地面導控站收到的最後一筆資料:RTL 模式、速度 7 公尺/秒、高度 4 公尺、俯角 9.8 度、右坡度 108 度、資料傳輸 0%。

右坡度 108 度的意思是這台直昇機已經翻過去了。而受訪操作人的描述是:發現該機側滾 180 度,高度由 60 公尺到最後畫面的 4 公尺,大約不到 3 秒

排除法

  • 事故發生在自動模式,無人為操作介入 → 與操控手無關
  • 落海前電力輸出及主旋翼轉速皆正常 → 動力與傳動系統無異常
  • 飛控電腦(FCC)依姿態輸出了正確的 PWM 修正指令,左伺服器擺臂應向上推升至高點——但該機姿態並未隨之反應
  • 主旋翼組件毀損,經破壞次序分析確認係落海撞擊海面所造成,不是失控成因

也就是說:大腦下對了指令,肌肉沒有執行。 報告的措辭是該機左右滾轉控制遭遇不對稱失效,無法有效執行向右滾轉指令,而此期間俯仰及偏航姿態仍維持在飛控可控範圍內。

收斂到哪裡:主旋翼三個伺服器連結變向盤的機構無毀損、馬達運作正常,故異常原因收斂到齒輪組或電系。田屋檢測結果為右伺服器齒輪組無異常,左伺服器第一級齒輪明顯上抬且馬達略為下沉,有錯位空轉現象——但報告基於三個理由研判齒輪組失效可能性不高:拆解前未進行非破壞檢查、齒輪室內部機構限制第一級齒輪上移空間甚小、各級齒輪齒峰無異常磨損也無不正常嚙合的碎屑。

最終結論:可能原因為主旋翼左或右伺服器電系失效,致該機失控墜毀。報告也誠實記錄了驗證的極限——伺服器在事故當下有可能處於通電狀況落水,非純水環境使內部短路風險大幅提升,入水後電系組件又遭海水汙染;重新上電後曾出現非指令作動現象,最終仍無法正常進入功能作動程序完成測試。

一個容易漏掉的細節:該機累計飛行時數 121 小時 52 分,而維保作業手冊規定伺服器維護為每 150 飛時定期更換。也就是說,這台機器還沒到廠商自己訂的更換期。

第二份:都蘭沙灘,連桿斷了

第二份是註冊號碼 B-AAA01397 的事故,運安會英文摘要ETtoday 的中文報導可交叉比對。

2023 年 1 月 17 日 0939 時,海巡署東部分署一架 AXH-E230RS,飛行測試返航時墜毀於台東都蘭觀海平台旁的岸際沙灘,無人傷亡。運安會調查歷時一年多,2024 年 7 月公布,提出 3 項結論與 2 項安全改善建議。

結論:該機尾旋翼變距連桿於飛行中斷裂,導致無法控制飛行姿態;沒有證據指向飛控電腦或人為操作。

根因往上追一層:該機尾旋翼滑座組可能因舊型滑座及其他零件製造與組裝品質不良,轉動中產生摩擦阻滯,使連動的 Y 型座變形、變距連桿斷裂,最終失控墜毀。

再往上追一層——這是整份報告最有價值的一句:事故前,製造商田屋科技因生產線組裝問題已修改設計、變更滑座尺寸,但對於庫存與使用中的舊型零件未進行更換評估,構成飛航安全風險。

於是安全建議分成兩個對象:建議田屋加強設計、製造及組裝的品質管制,以及設計變更後對庫存及使用中舊型零件適用性之評估;建議民航局督導田屋加強設計、改裝作業,落實對適用檢驗基準的符合性。

兩份報告放在一起看

把兩起事故並排,共同點多到不像巧合:

B-AAA01408B-AAA01397
時間2021-03-092023-01-17
機關海巡署北部分署海巡署東部分署
機型AXH-E230RS(田屋科技)AXH-E230RS(田屋科技)
階段執行搜救任務飛行測試返航
失效部位主旋翼伺服器(電系)尾旋翼變距連桿
飛控電腦指令正確無關
操作人無關無關

三個觀察:

一、兩次都不是「技術不好」。 飛控電腦兩次都正常,操作人兩次都被明確排除。這跟一般人對炸機的直覺相反——直覺會先怪飛手。至少在這個樣本裡,失控來自機構與電系。

不過要誠實標註:樣本偏差是結構性的。25 公斤門檻篩掉了消費級與小型商用機,留下的全是公務機關的大型載具,這類載具的操作人都持專業操作證且在編制內受訓。一般玩家的失效分布長什麼樣,這 4 起回答不了。

二、失效都落在產業鏈第 2 層。 伺服器(舵機)、變距連桿、滑座、Y 型座——這些是產業地圖裡的第 2 層核心零組件,不是大家在談的第 3 層飛控與鏈路。這個對照很值得停一下:產業討論的瓶頸在第 3 層,但這兩台機器是被第 2 層的製造品質弄下來的。

三、第二起的根因是流程,不是零件。 「設計變更後未評估庫存與使用中的舊型零件」是品質管理流程的缺口,不是哪個零件不好。這種問題不會在規格表上出現,也不會在試飛時出現——它會在某一批舊料裝上某一台機器、飛了一段時間之後出現。規格表那篇講規格表有「沉默欄位」,這就是其中最沉默的一格。

25 公斤以下的世界:去讀 log

小型機的失效不進運安會統計,但也不是沒有資料——開源飛控生態把這件事公開化了

PX4 的 Flight Review 是官方的 log 分析工具,logger 模組把 uORB 主題寫成 ULog 檔上傳後即可分析,而且上傳時可以標記為公開。軟體轉職那篇提過,能從 log 讀出「這次飛行為什麼抖」比會背控制理論更有說服力——這裡把該讀什麼講具體一點。

依 PX4 官方的飛行 log 分析指引,開場的三個問題是:

  1. 如果是故障後的分析,log 有沒有記錄到墜機,還是在空中就中止了
  2. 各控制器有沒有追上它們的參考值?最簡單的方法是比較姿態的 roll/pitch 角速率與其設定點
  3. 感測資料看起來合理嗎?

而多旋翼最常見的單一問題是振動。PX4 文件講得很直白:高振動會導致感測器削頂(clipping)或失效,進而造成估測失效與飛脫(fly-away)。幾個可以直接拿來用的判準:

  • 原始加速度的 peak-to-peak 超過 2–3 m/s² 就算強振動
  • 頻譜密度圖裡,懸停或慢速飛行時 z 軸曲線碰到 x/y 軸曲線,代表振動過高
  • 預設濾波器設在 80Hz,所以 50Hz 附近的振動不會被濾掉——那正好落在載具本身的動力學頻段,是危險的
  • actuator controls 若長時間頂在最大值,代表控制器進入飽和。全油門時屬正常,但如果發生在任務途中,通常意味著這台機器對它能提供的推力而言太重了

這是第一手經驗與公開資料的分界線一個很好的例子:「怎麼判斷振動過高」是公開可學的;「這台機器裝上這組腳架之後為什麼開始抖」只有裝過的人知道。

更新:那句「去讀 log」,我自己去讀了

2026-08-09 更新。 上一節說 25 公斤以下的世界要「去讀 log」,而我當時沒有實際讀過任何一份。補上——但要先說清楚做到哪、沒做到哪。

取得方式(可重跑)review.px4.io 從我的環境連不上(proxy 回 403),所以我用的是 PX4 專案 repo 裡自己的測試 log:

pip install pyulog
curl -O https://raw.githubusercontent.com/PX4/pyulog/main/test/sample.ulg
curl -O https://raw.githubusercontent.com/PX4/pyulog/main/test/sample_log_small.ulg

一份 log 裡有什麼(用 pyulog 解出來的實際數字):

sample.ulgsample_log_small.ulg
檔案大小4.0 MB921 KB
訊息型別(topic)1570
樣本總筆數64,542
欄位總數300
記錄時長181.5 秒
開機參數快照493 個
飛控自己輸出的文字訊息43

那 70 個 topic 包含 vehicle_gps_positionsensor_barosensor_magvehicle_imuestimator_innovationsestimator_innovation_test_ratiosactuator_outputsinput_rcbattery_statuswind_estimatevehicle_land_detected⋯⋯EKF 的創新量和它的檢定比都在裡面,也就是GPS 干擾那篇拆過的那組判斷依據,會被逐筆記下來。

sample.ulg 的四則文字訊息全部一樣:

t=158.22s [ERROR] [sensors] no barometer found on /dev/baro0 (2)
t=162.07s [ERROR] [sensors] no barometer found on /dev/baro0 (2)
t=171.62s [ERROR] [sensors] no barometer found on /dev/baro0 (2)
t=176.41s [ERROR] [sensors] no barometer found on /dev/baro0 (2)

這就是重點。 一台 25 公斤以下的機體不會有調查報告,但它在運轉的時候,把幾萬筆資料、一份完整參數快照,以及它自己抱怨感測器不見了的那四行,全部寫進了同一個檔案。運安會的兩份報告是幾十頁的敘述;一份 921 KB 的 log 有 70 個 topic。證據的不對稱是反過來的:大機有報告沒 log 公開,小機沒報告但 log 在飛手自己手上。

這次做到哪、沒做到哪(重要):這三份都是 PX4 的測試檔,nav_state 全程為 0、vehicle_local_position.z 最高只到 −1.18 公尺——它們是地面或短暫離地的測試,不是一次真實飛行,更不是一次炸機。所以上面證明的是「log 記了什麼」,不是「log 怎麼還原一次事故」。後者仍然要一份真實的炸機 log,而公開的炸機 log 庫(review.px4.io)從這個環境連不上。這一格因此只補了一半,而且我知道另一半卡在哪。

一段查不出答案的數字

寫這篇時撞到一個我解釋不了的東西,列出來當作誠實的註腳。

運安會歷年統計報告記載的無人機註冊架數是:

時間累計註冊架數
2021 年底75,240
2022 年底40,134
2024 年底38,683(機關法人 10,176、自然人 28,507)

一年之內少了三萬五千架。

合理的推論是統計口徑從「累計註冊」變成「現行有效」:《遙控無人機管理規則》第 10 條明訂「註冊號碼之有效期限為二年,所有人得於期限屆滿前三十日內⋯⋯申請延展」,而管理規則自 2020 年 3 月 31 日施行,首波註冊潮正好在 2022 年到期。若大量所有人沒有辦延展,數字就會這樣掉。

這是推論,不是結論。運安會報告沒有說明統計口徑,我也沒有找到民航局對這個落差的說明。在找到之前,這裡只放數列和法條,不放因果。

三個判斷

  1. 統計數字要先看門檻定義。 「台灣只有 4 起無人機重大事故」是真的,但它的定義是「逾 25 公斤且遭受實質損害」。任何拿這個數字談無人機安全性的說法,都跳過了定義。
  2. 公開事故報告的資訊密度極高。 一份調查報告花一年多、拆到齒輪齒峰有沒有碎屑,這種深度個人炸一百台也做不到。想理解失效模式,這是成本最低的路。
  3. 失效常常不在你盯著的那一層。 產業討論集中在飛控與鏈路(第 3 層),但這兩起是伺服器電系與連桿斷裂(第 2 層),而其中一起的真正根因是設計變更後沒清庫存舊料——一個管理流程問題。

參考資料

事故調查(一手)

法規

Log 分析

站內