Open DroneLog 開源 DJI 飛行日誌分析器:本地 DuckDB 引擎、Docker 自架,以及藏在 README 裡的 HTTPS 警告

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把一批 DJI 的 .txt 飛行記錄拖進 Open DroneLog 的視窗,幾秒鐘 DuckDB 把索引建好,左側的航線地圖畫出整段軌跡,下方一整排遙測折線圖:高度、速度、RC 遙控訊號、GPS 衛星數、電池電壓。你在電壓曲線上點到一段不自然的陡降,地圖上的航點就跟著跳到當時的位置與時間,那段飛行到底發生了什麼,一眼就對得上。這套「3D 航線回放加遙測疊層」的體驗,本來是商業雲端服務 Airdata UAV 在賣的東西,Open DroneLog 把它搬回你自己的電腦或 NAS,不收訂閱費,也不要求你把含位置與行程的日誌上傳到第三方伺服器。

對常飛大疆空拍機、或做商業航拍與測繪的人來說,飛行日誌真正值錢的地方,在電池電壓、搖桿輸入、無線電訊號、GPS 定位這些遙測欄位,它們才是排查異常、追蹤設備狀態、做飛行復盤時會反覆翻看的原料。問題在於,能好好解析這類日誌的軟體,主流幾乎都走訂閱制加上雲端上傳。Open DroneLog 反過來做:開源、AGPL-3.0 授權、本地優先,作者 Arpan Ghosh 一個人做到 GitHub 上 1449 顆星、192 個 fork。

一台 Tauri 桌面程式,背後跑的是 DuckDB

Open DroneLog 的桌面版用 Tauri v2 打造,前端是 TypeScript 加 React,後端是 Rust,跟 ElegantClipboard 一樣是 Tauri 2 加 Rust 的原生桌面路線,不是 Electron 那種包整個 Chromium 的重量級方案。分析引擎是 DuckDB,一個專為 OLAP 查詢設計的嵌入式資料庫,跑在本地處理程序裡,不需要另外架資料庫伺服器。README 對這層的說明是 DuckDB 驅動的查詢,會對大資料集做自動降採樣(automatic downsampling),所以一次拖一批日誌、檔案又大,篩選與統計還能維持在秒級回應。

格式支援上,它讀 DJI 原生的 .txt 飛行記錄、Litchi 匯出的 CSV,也讀 Airdata 匯出的 CSV,並且自動偵測單位。Dronelink、DroneDeploy 這類第三方 App 的格式也涵蓋,還可以透過 parsers.json 接自訂解析器插件,處理非主流的日誌格式。視覺化用的是 deck.gl 與 maplibre-gl 負責 3D 地理圖層、echarts 負責遙測折線圖,兩邊聯動,你在折線圖點某個時間點,地圖會跟著標到對應的航點,這種圖表與地圖對著看的設計,是做飛行復盤最省時間的地方。

部署型態有四種:Windows、macOS、Linux 的桌面安裝包,Android 版上了 Google Play,Docker 容器化的自託管 Web 版,還有一個公開的 Web demo 在 app.opendronelog.com。同一套東西,從單人桌面到團隊共用的 NAS 實例都涵蓋。

Pin

實際回放一段航程時,3D 地形檢視可以切換衛星圖與地形模型,最高能用 16 倍速把整段飛行快速跑過一遍,先抓出想細看的時間區段,再放慢逐格檢視。遙測折線圖與地圖是連動的,在電壓、衛星數、RC 訊號強度、航速、高度任一條曲線上點到可疑的瞬間,地圖會同步標到當時的航點與時間。這對找出「訊號在某個瞬間掉到只剩幾顆衛星」或「電壓在某段突然下凹」這類問題,省下大量前後對照的功夫,也是靜態截圖永遠給不了的資訊。

Pin

對手上不只一架飛機的人,電池健康追蹤是另一個會用到的核心能力。Open DroneLog 以序號把每顆電池單獨建檔,先記異常放電事件,再疊上累計循環次數與健康衰減幅度,達到自訂門檻就觸發更換預警。這層追蹤讓它不再只是單次飛行的檢視器,而開始承擔每顆電池的長期衰減履歷,長期累積下來的曲線,恰恰是 DJI 官方 App 比較不會替你做的事。對飛安來說,一顆快要衰退的電池在空中掉壓,後果遠比軟體 bug 嚴重,這層追蹤因此有實質意義;不過日誌分析畢竟是事後復盤,一顆電池是否堪飛仍應以 DJI 原廠維護指引與起飛前的實際電壓檢查為準,工具的預警門檻僅供參考,不作為飛安判斷的唯一依據。

日誌可以留在本地,但第一次解析得先跟 DJI 要一把鑰匙

「本地優先、日誌不出本地網路」是 Open DroneLog 最主打的一點,這句話在絕大多數情況下成立,但有一個精確的邊界要講清楚。DJI 的 .txt 飛行記錄檔本身是加密的,要解析內容,得用 DJI Developer API Key 來解密。 Open DroneLog 出廠時內建了作者自己申請、共享出來給所有人用的 API Key,你裝好就能直接匯入,不必先去 DJI 註冊。

代價是,共用 Key 會被限流。README 明寫:用預設 Key 時,每匯入一個新的日誌檔,可能會看到大約 5 秒的 cooling down... 訊息。為了緩解這個來回,2026 年 5 月 6 日的一次重構(commit 訊息為 Implement database caching for decryption keys)把解密鑰匙放進本地資料庫快取,同一台機型的日誌解過一次,後續就不必再向 DJI 重複請求。

換句話說,日誌檔案本身確實沒有被上傳,但「解析某一台新機型日誌的第一次」必須聯絡 DJI 的伺服器拿解密鑰匙(拿的是 Key,不是日誌)。所以這是 local-first,不是完全離線,第一次取鑰匙的那一下網路呼叫,是這套工具繞不開的環節。想徹底擺脫共用 Key 的限流,可以到 DJI Developer Technologies 申請自己的 Key 填進設定,但那等於多一次向 DJI 開發者平台註冊、交出個資的動作,作者在 README 裡半開玩笑地附註「重視隱私的話,不確定那邊填的個人資訊是否需要真實」,這個取捨留給讀者自己判斷。

想用 Docker 自架給整個團隊?先把 HTTPS 補上

桌面版自己一個人用,大致開箱即用。但 Open DroneLog 真正吸引商業航拍團隊的,是 Docker 自託管的 Web 版,把日誌統一丟到 Synology、QNAP 這類家用 NAS,或多機飛手的共用伺服器上,所有人把自己機器的日誌匯進同一個實例,統一管理、統一歸檔。資料落在 drone-data 這個 Docker volume,映射到容器內的 /data/drone-logbook,重啟、更新映像檔都不會掉,只有明確下 docker compose down -v 才會清掉。設 KEEP_UPLOADED_FILES=true 還會用 SHA256 雜湊當檔名,保留並去重原始日誌。

不過 README 裡藏了一個不容略過的安全警告,就擺在 Docker 部署段落的後面。Open DroneLog 是為本地使用設計的,不內建 TLS、不內建 HTTPS。如果你把實例直接暴露到網際網路,設定檔密碼與登入階段發放的 session token,會以明文形式透過 HTTP 傳輸。官方列出的限制相當誠實:工作階段只存在記憶體,伺服器重啟就全部失效;沒有 CSRF token,只靠同源政策與自訂的 X-Session、X-Profile 標頭;密碼用 Argon2id 雜湊,雜湊本身夠強,但沒有 TLS 時,網路上的中間人可以攔截 token。

官方的建議很明確:在容器前面加一層反向代理(Nginx、Caddy、Traefik 都行)做 TLS 終結,不要直接把 port 80 對外開,並且設定 PROFILE_CREATION_PASS 防止別人亂建設定檔。這層「自架省下訂閱費,但要自己補 HTTPS 與維運」的真相,跟 自架 AI 履歷產生器 JadeAI 遇到的成本結構是同一回事,免費的是軟體,不是營運。把 Open DroneLog 包成對外服務之前,先想清楚這層;這也是它與 OpenClaw 101 那類第三方聚合站類似的地方,README 裡其實寫著你必須先知道的資安前提。

設定檔與密碼保護是團隊部署會用到的另一層。Open DroneLog 支援多個具名設定檔,每個設定檔是隔離環境,有自己的資料庫、設定、上傳與同步資料夾,可以選擇加上密碼保護;密碼用 Argon2id 在伺服器端驗證,連續失敗 5 次會鎖定 60 秒,Web 與 Docker 模式下登入成功後發放 session token 透過自訂標頭傳遞。不想自己管伺服器的團隊,作者也在 README 指向 PikaPods 這個容器託管服務,月費不到 2 美元就能拿到一個專屬 URL 的代管實例,等於把「自架省錢」與「不想碰伺服器」兩種需求各留一條路。另外原始碼倉庫除了 GitHub,還同步鏡像到 Codeberg 並提供 Codeberg 的容器映像檔,多一份不綁單一平台的備援,對重視分散風險的團隊是加分。

與 Airdata 的差別,看的是資料落在誰的機器上

Open DroneLog 在 README 與來源介紹裡都被放在「Airdata 替代方案」的位置,但真正值得想的差異,不是一個免費、一個收費,而是同一份飛行日誌,處理完之後落在誰的機器上。Airdata UAV 這類平台的流程是:你的日誌得先進它的雲端,排隊等它分析完,才能把結果撈回來,日誌裡的 GPS 軌跡與行程資訊在這一步就經過了第三方。對休閒飛手也許無所謂,但對做工程巡檢、測繪、商業航拍的團隊,飛行軌跡等於作業現場的位置紀錄,很多團隊在合約或內部審計上根本不能把這類資料交給外部平台。

Open DroneLog 把這層顧慮直接消掉:日誌留在你的硬碟或私有 NAS 上,3D 渲染、圖表、篩選、統計、儲存都在本地完成,需要合規留存或內部稽核時,權限控制、備份、遷移都掌握在自己手裡。這個「檔案不出本地處理」的思路,與本機 PDF 塗黑工具 Secure PDF Editor 走的是同一個方向,價值都在讓敏感資料繞過雲端。遷移方面,Open DroneLog 能直接讀 Airdata 匯出的 CSV,等於幫想從訂閱制搬走的人留了一條退路。

它還沒解好的幾件事

把話講回來,Open DroneLog 不是沒有粗糙的邊角。Open DroneLog 的 GitHub Issues 裡,幾個最近的真實問題值得在裝之前先知道。編號 #210、2026 年 7 月 8 日開出的 issue 回報:升級到 DJI 韌體 01.64.0818、DJI Pilot 17.2.5.28 之後,.txt 飛行日誌找不到,這是 DJI 自己改了日誌輸出造成的相容性問題,工具端需要跟著調整,屬於這類第三方解析工具會持續遇到的維護負擔。

另外幾個還掛著的:#199 高風警告沒有被正確報出來、#205 RC 訊號強度在航線地圖上的色彩渲染會出錯、#208 有飛行日誌解析失敗的情況。功能面也有值得期待的走向,#195 已經實作完成、支援匯入 iNav、Betaflight、Ardupilot 這些開源飛控的日誌,代表它不完全綁 DJI 生態,往開源無人機社群延伸。

維護節奏也要看清楚。程式碼最後一次提交是 2026 年 5 月 12 日,最新正式版 v3.3.0 在 2026 年 5 月 1 日發布,5 月之後沒有新版本。這不代表專案停擺,issue #211 在 7 月 10 日剛把 Flatpak 打包完成閉合,#200、#195 等也在 5 月密集處理掉,但 release 的步調確實放慢了。商業團隊要長期依賴它,得接受「作者是個人開發者、更新跟著 DJI 韌體變動走」這個前提。

AGPL-3.0,以及它跟 DJI 沒有關係

授權是 AGPL-3.0,這條要特別留意。AGPL 的網路服務條款意味著:如果你把 Open DroneLog 改一改、包成對外提供的 Web 服務,衍生作品必須以同樣的授權對外開源。團隊內部自託管、自己人用,通常沒有問題;但若想把它的能力包進商業 SaaS 對外賣,就得面對 copyleft 鏈。以 ONLYOFFICE 為基礎的 WASM Office 編輯器 也面對同樣的 AGPL 誠實問題,重點在於網路服務也要回饋原始碼,不是裝了就能隨便用。

另一個容易混淆的身分問題:Open DroneLog 是獨立的第三方專案,跟大疆沒有任何官方附屬。README 開頭就以重要標示寫明,DJI、DroneLogbook、Litchi、Airdata UAV 都是各自公司的註冊商標,這個專案不受這些公司贊助、授權或背書。它解析 DJI 日誌,但不是 DJI 出的工具;要取 DJI 解密鑰匙也是透過 DJI 的開發者平台,兩邊是利用關係而非從屬關係。

還有一個 macOS 使用者會撞到的小麻煩。因為 Apple 開發者簽名一年要 99 美元,作者沒有購買,所以 macOS 下載安裝後會跳出「Open DroneLog 已損壞,無法打開」,這不是檔案真的壞了,是 Gatekeeper 對未簽名 App 的安全警告。解法是對著 App 右鍵選「打開」,或在終端機執行 xattr -cr 再把 App 拖進去放行。這條未簽名的代價,ElegantClipboard、MoePeek 這類由個人或小團隊打造的原生 macOS 工具也得一併吃下。

誰會真的用到它,誰會白裝一輪

講完技術與邊界,把它放回適合的位置。會真的用到它的人有個共同點:手上設備多、需要長期追蹤電池健康,而且出於合約或合規不能把軌跡交給雲端。商業航拍團隊、測繪與巡檢工作者,還有習慣用 Docker 在 NAS 上統一歸檔的玩家,都落在這個範圍。對這些人,電池健康追蹤、維護預警門檻、多設定檔隔離、密碼保護這套近似「機隊管理」的能力,是官方 App 給不了的。

反過來,假如你一年飛不到幾次,既不會回頭比對歷次電壓曲線,也沒有要替每架飛機建設備履歷,那麼架 Docker、管 DJI API Key、處理 macOS 未簽名這些前置工對你純粹是負擔,DJI 隨機附的飛行記錄檢視就足以應付偶發的查看需求。Open DroneLog 換來的是深度與資料主權,代價是要自己架、自己補 HTTPS、接受它是個人開發者維護的節奏。對的需求,它是 Airdata 的免費替代;不對的需求,它只是看起來很厲害的累贅。

關於 Open DroneLog 的常見問題

飛行日誌裡到底有什麼,為什麼值得留在本地?

日誌裡的 GPS 軌跡等同作業現場的位置紀錄,一旦交給第三方雲端,就等於把客戶案場的座標也一起交出去。對有保密合約的測繪或巡檢團隊,這等於踩到合約紅線,所以本地處理對他們是剛性需求,不是錦上添花。

第一次解析為什麼要連網?之後還要嗎?

DJI 的 .txt 日誌是加密的,需要 DJI Developer API Key 解密,所以第一次解析某個機型時,會向 DJI 伺服器請求鑰匙(只取 Key,不上傳日誌)。2026 年 5 月的更新把鑰匙快取進本地資料庫,同一機型後續不必再重複請求。換句話說,首次連網取鑰匙是必要的,但不是每次都要。

用 Docker 自架給團隊用,安全嗎?

預設不夠安全,需要自己補一層。Open DroneLog 的 Web 與 Docker 版不內建 TLS,密碼與 session token 會以明文透過 HTTP 傳輸,也沒有 CSRF token。官方建議在容器前面加反向代理(Nginx、Caddy、Traefik)做 HTTPS 終結,不要直接把服務暴露到公網,並設定 PROFILE_CREATION_PASS。內網自用風險較低,對外開放就一定要補這層。

它和 Airdata 比起來,主要差在哪?

核心差異是資料的歸屬。Airdata 走訂閱制加雲端上傳,日誌要先交給第三方才能分析;Open DroneLog 免費、開源,日誌留在本地分析。功能面上兩者重疊度高(3D 航線、遙測、電池健康),Airdata 在雲端協作與官方整合上更成熟,Open DroneLog 在隱私與成本上勝出,並且能直接讀 Airdata 匯出的 CSV,方便遷移。

它是 DJI 官方出的工具嗎?

不是。Open DroneLog 是獨立開發者 Arpan Ghosh 的第三方開源專案,以 AGPL-3.0 授權,README 明確聲明與 SZ DJI、DroneAnalytics、VC Technology、Airdata UAV 皆無附屬或背書關係。它解析 DJI 日誌、需要向 DJI 開發者平台取解密鑰匙,但兩邊是利用關係,而非官方從屬。

除了 DJI,它還能解析哪些機型或日誌格式?

DJI 的 .txt、Litchi CSV、Airdata CSV、Dronelink、DroneDeploy 都讀;issue #195 閉合後也吃 iNav、Betaflight、Ardupilot 這些開源飛控的日誌,所以並不是只能配大疆。冷門格式還能透過 parsers.json 自寫解析器插件,把它當成可擴充的日誌分析底座。

值不值得放進你的航拍工具箱

Open DroneLog 把一套本來要付訂閱、要上傳雲端的飛行日誌分析能力,以開源、本地優先的方式重新做了一遍,DuckDB 讓大日誌在本地也能秒級查詢,Docker 自託管讓團隊可以統一歸檔而不交出軌跡。對一個標準的商業航拍工作流來說,它的位置落在飛行結束與設備保養之間:飛完把日誌同步進 NAS,定期回頭看哪顆電池循環數偏高、哪段航程訊號異常,把每一次飛行的遙測變成可長期追溯的設備履歷。它不會取代你對 DJI 官方 App 的依賴,也不是給偶爾飛一趟的人用的;但對需要深度復盤、長期設備維護、位置資料不能外流的商業與進階玩家,它是開源陣營裡少數能把 DJI 日誌做到 3D 航線回放加電池健康追蹤的選擇。裝之前先認清幾個前提:第一次解析要跟 DJI 取解密鑰匙、自架對外要用反向代理補 HTTPS、另外它是個人開發者在維護而節奏會放慢。接受這些前提,它就值得放進工具箱;不能接受,官方 App 與 Airdata 會是更省心的路。