做AI無人機一體化平臺這件事說起來多少有點“被項目推著走”的味道。我們團隊最開始只負責某巡檢項目的圖像識別算法做著做著就發(fā)現(xiàn)客戶真正需要的從來不是單一的算法模型也不是某一套飛控配置而是一條從“無人機起飛”到“數(shù)據(jù)回傳”再到“AI分析結果落到業(yè)務工單里”的完整鏈路。于是這個AI無人機一體化平臺就從一個算法外包項目慢慢長成了覆蓋端、邊、云的整套系統(tǒng)。這個平臺的核心能力我習慣用三句話概括讓無人機帶著AI飛讓地面人員看得懂讓行業(yè)客戶用得上。它解決的典型問題是傳統(tǒng)無人機作業(yè)里“飛行歸飛行、識別歸識別、數(shù)據(jù)歸數(shù)據(jù)”的碎片化現(xiàn)狀——飛手只管飛算法組只管識別客戶拿到的卻是幾十個G的零散素材最后還得人工翻找、標注、寫報告。這套平臺把所有環(huán)節(jié)收攏成一個閉環(huán)適合電力巡檢、農(nóng)業(yè)植保、應急搜救、工程測繪這幾個方向的團隊直接參考也適合準備從單體無人機應用轉(zhuǎn)型做平臺化的開發(fā)者做架構藍圖。下面我把整個項目的架構設計思路、關鍵模塊落地細節(jié)、行業(yè)實踐結果和踩坑記錄都梳理一遍盡量把當時做技術選型和方案取舍的“為什么”也講清楚希望能幫想入這行的朋友少走幾段彎路。1. 項目定位一體化平臺到底解決什么問題1.1 碎片化作業(yè)的現(xiàn)狀與痛點先說說我們最初接觸到的真實場景。某電力巡檢團隊原有作業(yè)流程是這樣的飛手帶著無人機到桿塔附近手動起飛拍幾百張照片回來存到移動硬盤里然后交給內(nèi)業(yè)人員一張張翻看尋找絕緣子破損、銷釘缺失、異物懸掛等問題。一次大規(guī)模巡檢下來光照片整理就要兩三天漏檢率還特別高因為人眼在連續(xù)看幾百張相似圖片時注意力下降是必然的。農(nóng)業(yè)植保那邊更典型。無人機打完藥客戶想知道的是“哪塊地沒打到”“漏噴率多少”但傳統(tǒng)方案只給一份飛行軌跡記錄根本沒有作物分布、障礙物避讓、噴灑覆蓋率的量化分析。說白了行業(yè)里缺的不是無人機而是圍繞無人機的“數(shù)據(jù)到?jīng)Q策”能力。這些碎片化拆開看是四個層面的斷裂。第一是硬件斷裂無人機、載荷相機、RTK模塊是不同廠商的東西接口協(xié)議各講各的集成起來全靠飛手現(xiàn)場臨時拼。第二是算法斷裂AI識別模型往往在實驗室里跑得很好一到野外復雜光照和遮擋環(huán)境下就掉鏈子因為模型訓練數(shù)據(jù)和生產(chǎn)環(huán)境差異太大。第三是數(shù)據(jù)斷裂圖像、定位、飛行姿態(tài)、氣象信息各存各的沒有統(tǒng)一時空基準想做分析得先花大量時間做數(shù)據(jù)對齊。第四是流程斷裂識別結果停留在“發(fā)現(xiàn)”層面沒有直接轉(zhuǎn)化為工單、報告或調(diào)度指令業(yè)務閉環(huán)還得靠人工搬運。1.2 平臺邊界與核心能力定義既然要解決碎片化第一步是界定平臺的邊界。我們定下一條原則平臺不重新發(fā)明無人機也不重新發(fā)明算法而是把成熟的飛控技術、感知載荷、AI推理能力通過一套標準架構串起來做“整合”和“貫通”的生意。這個邊界很重要如果什么都自己做項目周期和成本會失控。平臺最終被定義為四個核心能力模塊機載AI感知能力、實時通信與控制能力、云端訓練與數(shù)據(jù)管理能力、行業(yè)業(yè)務應用能力。機載AI感知負責在飛機上直接完成目標檢測和避障決策解決“數(shù)據(jù)回傳依賴大帶寬”的瓶頸實時通信負責把飛機狀態(tài)和控制指令穩(wěn)定送達云端負責模型迭代和多架次數(shù)據(jù)匯總業(yè)務應用則把結果翻譯成巡檢工單、噴灑處方圖、搜救熱力圖這類客戶看得懂的產(chǎn)品。這個能力定義本質(zhì)上把一體化平臺和傳統(tǒng)“地面站軟件”區(qū)別開了。傳統(tǒng)地面站是“飛機儀表盤的遠程投影”一體化平臺則是“一個能干活的任務系統(tǒng)”——它關心的不是飛機本身而是飛機替客戶完成什么任務。這個定位直接決定了后續(xù)架構設計的重心。2. 架構設計從端到云的分層思路2.1 總體架構的三層劃分整體架構我們采用了經(jīng)典的“端-邊-云”三層劃分沒有搞花活。原因倒不是三層最先進而是它最符合無人機作業(yè)的真實物理鏈路飛機在天上地面站和控制人員在現(xiàn)場算力和數(shù)據(jù)匯聚在遠端天然就不能用一個單機系統(tǒng)把所有事情做完。端側指的是無人機本體包括飛控、動力、RTK定位模塊、可見光/多光譜相機、機載邊緣計算板。這一層的核心要求是在極端功耗和體積約束下完成感知與決策。邊側是地面指揮節(jié)點包括遙測遙控鏈路終端、便攜地面站、邊緣計算服務器負責飛行監(jiān)控、任務下發(fā)和現(xiàn)場級的數(shù)據(jù)預處理。云側是中心平臺負責多架次數(shù)據(jù)的長期存儲、AI模型訓練迭代、業(yè)務應用服務和設備全生命周期管理。三層之間不是簡單的數(shù)據(jù)上傳關系而是任務協(xié)同關系。端側做實時性要求高的感知和控制邊側做現(xiàn)場決策和人在環(huán)確認云側做全局優(yōu)化和知識沉淀。比如在電力巡檢里機載AI發(fā)現(xiàn)疑似絕緣子缺陷后會立即把裁剪后的目標切片回傳地面站地面站人員確認后再決定是否補拍云平臺只接收確認過的有效數(shù)據(jù)和全量原始影像做終檢和統(tǒng)計報表。這樣既保證了實時響應又控制了帶寬和存儲成本。2.2 關鍵技術選型與取舍理由技術選型是整個項目里爭論最多的地方。我把幾個關鍵決策和取舍邏輯列出來這些決定直接影響后續(xù)開發(fā)效率。第一個決策是機載AI推理平臺選什么方案。當時比較了高算力GPU板卡、手機級SoC和NPU加速芯片三條路線。GPU方案開發(fā)最順、生態(tài)最全但功耗和體積對無人機不友好懸停時間會縮水手機級SoC功耗低但散熱和穩(wěn)定性在大溫差環(huán)境下讓人不放心最終選擇的是帶NPU的異構SoC方案推理能效比高價格適中而且社區(qū)生態(tài)這兩年已經(jīng)比較成熟了。實測下來一個輕量目標檢測模型在端側跑YOLO級別的框架單幀推理能控制在毫秒級到幾十毫秒級完全夠用。第二個決策是通信鏈路怎么組。無人機控制要求低延遲高可靠圖像回傳要求大帶寬這兩者天生矛盾。我們沒有追求用一條鏈路解決所有問題而是采用雙鏈路方案飛控和遙測數(shù)據(jù)走窄帶寬的專用數(shù)傳鏈路保證安全性圖像和高價值數(shù)據(jù)走寬帶鏈路通常是4G/5G網(wǎng)絡或者現(xiàn)場自組網(wǎng)基站。為什么會這樣選因為專用數(shù)傳鏈路協(xié)議簡單、抗干擾強而寬帶鏈路一旦擁堵至少不會影響飛機安全這種“關鍵控制優(yōu)先”的思路在工程上是底線。第三個決策是云端采用微服務還是單體應用。考慮到平臺要同時支撐多種行業(yè)應用我們最后選了微服務架構但加了克制服務拆分粒度以業(yè)務域為單位不為拆分而拆分。比如設備管理、任務調(diào)度、模型服務、數(shù)據(jù)存儲各自獨立但登錄鑒權、權限管理等橫切能力統(tǒng)一在一個基礎服務里。這樣既照顧了多業(yè)務擴展又沒被微服務治理拖垮運維效率。表格整理一下主要選型傾向?qū)哟侮P鍵選型點首選方案備選方案取舍理由端側AI推理芯片帶NPU的異構SoCGPU板卡能耗比與算力平衡端側系統(tǒng)機載中間件輕量級機器人中間件框架裸機C程序模塊間通信解耦鏈路控制與圖像雙鏈路分離單寬帶鏈路控制優(yōu)先級保證安全地面站界面框架Web化桌面應用原生客戶端跨平臺和迭代速度云端服務架構微服務按業(yè)務域切分單體應用多行業(yè)擴展與運維平衡模型訓練推理部署端側量化云側全精度云端統(tǒng)一推理實時性與精度兼顧2.3 數(shù)據(jù)流與通信鏈路的完整閉環(huán)架構里的數(shù)據(jù)流是理解整個平臺的一把鑰匙。一回完整的作業(yè)任務數(shù)據(jù)是這樣流動的云平臺下發(fā)任務包包括航線規(guī)劃、作業(yè)區(qū)域邊界、目標識別類型列表打包后同步到地面站地面站通過數(shù)傳鏈路把航線注入飛控無人機起飛后按照航點飛行。飛行過程中機載AI感知模塊實時處理相機畫面識別結果連同時間戳、經(jīng)緯度、姿態(tài)角打包成結構化消息通過寬帶鏈路回傳。這里有一個關鍵設計端側不會回傳全部視頻流只回傳“有意義”的數(shù)據(jù)切片和對應的位置姿態(tài)上下文。比如輸電線路巡檢時機器識別到疑似銷釘缺失會裁出包含目標區(qū)域的一個局部圖像塊連同當時的GPS坐標和飛機姿態(tài)一起傳回。這樣做是因為現(xiàn)場4G/5G上行帶寬有限全量高清視頻回傳在多數(shù)野外場景根本不可行而結構化切片已經(jīng)能支撐業(yè)務決策。數(shù)據(jù)到達地面站后經(jīng)過一個數(shù)據(jù)融合組件把同一時空下的圖像、位置、姿態(tài)整理成標準化事件對象推送給現(xiàn)場操作員做確認。確認結果和人工標記會同步回云端一方面用于生成業(yè)務報告另一方面作為新樣本進入數(shù)據(jù)集為后續(xù)模型迭代做準備。云端把這些事件對象和歷史數(shù)據(jù)一起存儲、統(tǒng)計、回溯形成從“采集”到“學習”到“再采集”的閉環(huán)。這個閉環(huán)設計有一個容易被忽視的好處數(shù)據(jù)一致性。因為所有事件都帶有統(tǒng)一時空基準后續(xù)做復飛對比、歷史變化分析時不需要再做數(shù)據(jù)對齊工作直接查事件表就能把同一桿塔在不同年份的狀態(tài)變化拉出來。我們在客戶現(xiàn)場做過演示把某變電站三年的紅外和可見光巡檢數(shù)據(jù)在一張地圖上按時間軸回放客戶的直觀感受就是“終于能講故事了”。3. 核心模塊實現(xiàn)從機載AI到云平臺3.1 機載AI節(jié)點一架會思考的無人機機載AI節(jié)點是這套平臺和普通無人機最大的差異點。它不是一個算力板卡那么簡單而是一個需要和飛控深度配合的子系統(tǒng)。首先是硬件集成。我們在無人機機身內(nèi)部增加了一個隔離艙放置計算板同時考慮了三件事散熱、減震、供電。散熱方面裸板和機身壁之間加了導熱硅墊和散熱片機身上對應位置開進風口利用飛行時的迎面氣流降溫實測芯片溫度在高負載下能穩(wěn)定在七十度左右比靜態(tài)測試低不少。減震方面整個板卡裝在阻尼減震架上因為無人機電機的高頻振動會讓圖像傳感器產(chǎn)生果凍效應也會讓算力板上的存儲卡壽命大幅縮短。供電則單獨從電池經(jīng)過DC-DC模塊引出避免和舵機、圖傳搶電導致電壓跌落、AI推理偶發(fā)失敗。軟件上機載節(jié)點跑的是一個精簡的Linux系統(tǒng)核心程序分成四個進程協(xié)作圖像采集進程負責驅(qū)動相機按固定幀率抓取圖像推理進程加載量化后的模型對圖像做目標檢測融合進程把檢測結果和飛控傳來的位置姿態(tài)數(shù)據(jù)做時間同步上報進程負責把結構化結果通過通信模塊發(fā)出。這四個進程之間用輕量中間件做消息通信好處是某個進程崩潰了可以單獨重啟不會拉垮整機。為什么用進程拆分而不是單線程大循環(huán)這是從維護性角度考慮的。現(xiàn)場迭代時經(jīng)常只需要升級檢測模型如果耦合在一起每次調(diào)整都要重新編譯整套程序風險大效率低拆開后模型熱替換只需要重啟推理進程幾秒鐘就完成。我們后來還加了一個模型熱加載機制地面站可以遠程下發(fā)新模型包飛機降落后自動校驗并切換整個流程不需要拆機這對現(xiàn)場工程人員非常友好。機載端的模型優(yōu)化是另一個要點。訓練好的模型不能直接搬上飛機需要做量化、剪枝和算子適配。我們采用的量化方案是訓練后INT8量化精度損失控制在百分之二以內(nèi)推理速度卻提升了三倍多。針對機載NPU不支持的算子手寫替換成等價實現(xiàn)這部分工作最耗時建議有條件的團隊提前用模擬器做算子兼容性檢查。3.2 地面指揮端從控飛機到管任務地面站軟件我把它定位成“任務指揮官”而不是“遙控器”。早期我們把大量精力放在還原飛行儀表上高度表、姿態(tài)球、地圖軌跡做得越像傳統(tǒng)地面站越覺得順手。但客戶反饋很直接“我們不是來學開飛機的我們是來完成巡檢的?！边@句話改變了我對地面站體驗的理解。后來整個地面站界面重構為任務視角。左邊是任務面板顯示當前作業(yè)的進度、已發(fā)現(xiàn)目標數(shù)量、待確認事件隊列中間是實時地圖和視頻畫中畫地圖上飛機位置和已識別目標以標記點疊加右邊是事件列表每條事件包含縮略圖、坐標、識別類型和置信度。操作員的日常工作流就變成了“看事件、做確認、發(fā)指令”而不是“盯著姿態(tài)儀防止炸機”。這個轉(zhuǎn)變背后還有一層邏輯無人機自主飛行能力成熟后人在環(huán)的主要價值不是控制飛機而是對AI判斷做最后把關。比如搜救場景里機載AI把某個水面異常物標記為“疑似落水者”置信度中等地面操作員可以調(diào)取大圖判斷是否派飛機下降抵近查看。這種“人在關鍵決策點介入”的設計比讓人從頭到尾盯著飛機科學得多。地面站的通信管理也做了不少工程優(yōu)化。弱網(wǎng)環(huán)境下視頻碼率需要自適應調(diào)整我們用了一個簡單有效的策略以端側識別事件為優(yōu)先級無論帶寬多緊張事件切片優(yōu)先傳輸視頻流自動降碼率甚至暫停。這樣做雖然犧牲了實時觀看體驗但保證了關鍵決策數(shù)據(jù)不丟失?，F(xiàn)場測試時在山區(qū)4G信號只有一格的條件下事件上報成功率依然能維持在較高水平。3.3 云平臺數(shù)據(jù)集、模型與服務云端平臺承擔三塊工作數(shù)據(jù)資產(chǎn)沉淀、模型持續(xù)迭代、業(yè)務應用服務。數(shù)據(jù)資產(chǎn)沉淀是最樸素也最容易被低估的模塊。我們把每一次飛行的原始影像、識別事件、人工確認結果、航線信息全部入庫建立以時間、空間、任務類型為維度的檢索能力。這個庫不會立刻產(chǎn)生價值但積累到半年以上客戶做設備缺陷趨勢分析、作業(yè)質(zhì)量評估時數(shù)據(jù)就是最硬的依據(jù)。模型迭代采用“半自動飛輪”的方式。云平臺定期把新確認的樣本篩選出來經(jīng)過清洗和增強混合歷史數(shù)據(jù)重新訓練生成新版本模型通過A/B評測對比精度和誤報率通過則推送到機載端更新。這個過程在項目早期是月度節(jié)奏后來隨著數(shù)據(jù)量增加壓縮到雙周一次。跑通這個飛輪后模型的場景適應性會越來越強這是純算法項目比不了的優(yōu)勢。業(yè)務應用方面我們沒有做通用大而全的系統(tǒng)而是針對每個行業(yè)提供可配置的應用模板。電力巡檢模板包含缺陷分類、桿塔臺賬關聯(lián)、復檢任務生成農(nóng)業(yè)模板包含變量噴灑處方圖、作業(yè)面積統(tǒng)計、漏噴區(qū)域標記。這樣做的考量是行業(yè)應用的需求差異很大強行統(tǒng)一只會做出一個誰都不滿意的系統(tǒng)但底層數(shù)據(jù)和能力是統(tǒng)一的做新行業(yè)應用時只需要開發(fā)業(yè)務層的適配邏輯平臺側改動很小。4. 行業(yè)應用實踐四個場景的效果復盤4.1 電力巡檢從人工翻圖到缺陷自動分級電力巡檢是我們落地最深的場景。和某省級電力運維團隊合作時整個流程是無人機按規(guī)劃航線對指定線路通道進行自主巡檢機載AI實時識別絕緣子、銷釘、防震錘、異物等目標并判斷缺陷等級事件切片秒級回傳地面站現(xiàn)場人員確認后當天就能生成缺陷清單直接對接運維工單系統(tǒng)。效果最明顯的是效率提升。以前一個班組一天巡檢五基桿塔回來還要花兩天整理照片?，F(xiàn)在同樣班組一天可以覆蓋四十基桿塔當天出具缺陷報告。更重要的是漏檢率顯著下降機載AI不會疲勞同一類型的目標只要在訓練集里見過都會給出穩(wěn)定檢測結果。過程中也發(fā)現(xiàn)了一個有意思的問題客戶對“誤報”的容忍度和我們預想的不一樣。他們更擔心漏報因為誤報可以靠人工二次確認過濾漏報意味著缺陷可能長期無人處理風險更大。所以我們在模型訓練時有意調(diào)整了置信度閾值偏向召回率犧牲一些精確率再靠人環(huán)確認兜底。這個經(jīng)驗后來寫進了我們給所有行業(yè)客戶的默認配置里。4.2 農(nóng)業(yè)植保處方圖與變量噴灑農(nóng)業(yè)場景的特點是地塊大、環(huán)境變化快、作業(yè)窗口期短。某植保服務公司用平臺管理幾十架植保無人機最核心的需求是“知道自己到底噴得怎么樣”。我們的方案是多光譜相機采集作物長勢數(shù)據(jù)云平臺反演生成植被指數(shù)分布圖再結合地塊邊界生成變量噴灑處方圖也就是把地塊劃分成不同網(wǎng)格每個網(wǎng)格對應不同的施藥量。植保機按處方圖飛行作業(yè)噴頭流量實時調(diào)節(jié)。作業(yè)結束后平臺再根據(jù)飛行軌跡和流量記錄生成覆蓋質(zhì)量報告哪些區(qū)域重復噴、哪些區(qū)域漏噴一目了然。這套流程讓植保公司的管理方式發(fā)生了實質(zhì)變化。過去他們和農(nóng)戶結算靠“飛了多少畝”來算賬現(xiàn)在可以拿覆蓋質(zhì)量、變量施藥帶來的藥量節(jié)省數(shù)據(jù)說話。一個試點季度的統(tǒng)計里在產(chǎn)量不降的前提下部分地塊用藥量節(jié)省了將近兩成這就是數(shù)據(jù)化的說服力。4.3 應急搜救與時間賽跑的感知網(wǎng)應急搜救是平臺架構中“實時性”要求最極端的場景。某救援隊配備了兩架多旋翼無人機和一架固定翼巡檢無人機在山區(qū)水域執(zhí)行失蹤人員搜索任務。機載AI加載了人員檢測和異常物檢測模型固定翼飛機做大范圍快速掃描發(fā)現(xiàn)疑似目標后把事件上報地面站多旋翼無人機隨即前往疑點位置低空抵近偵察可見光和紅外相機同時確認。整個“發(fā)現(xiàn)-確認-抵近”的接力流程把過去搜救隊靠經(jīng)驗判斷搜索重點的做法變成了有數(shù)據(jù)支撐的網(wǎng)格化搜索。這里平臺的通信鏈路設計發(fā)揮了作用。山區(qū)公網(wǎng)覆蓋差我們部署了移動自組網(wǎng)基站飛機圖像和事件通過自組網(wǎng)回傳現(xiàn)場指揮車再通過衛(wèi)星鏈路同步后方指揮中心。雖然視頻幀率受限但事件切片和關鍵目標圖像始終優(yōu)先保障后方專家可以實時看到搜索進展給出更專業(yè)的判斷。4.4 工程測繪從點云到結構化成果工程測繪場景更看重數(shù)據(jù)的精度和后處理能力。某公路勘察項目需要用無人機生產(chǎn)高精度地形圖傳統(tǒng)流程是無人機采集影像帶回辦公室用專業(yè)軟件處理生成正射影像和數(shù)字表面模型整個過程要一兩天。平臺介入后機載AI在采集過程中同步完成初步的地物分類把植被、裸土、道路、建筑等像素級標簽實時疊加并標記出需要重點采集的區(qū)域。影像落地的同時現(xiàn)場工程師就能預覽初步分類結果決定是否需要飛第二遍補拍。云端再結合高精度RTK數(shù)據(jù)和算法推理生成帶分類信息的測繪成果整體交付周期從兩天縮短到半天。測繪行業(yè)比較特殊它對軟件生態(tài)的兼容性要求高客戶已經(jīng)有成熟的后處理軟件平臺不能替代只能做好配合。所以我們把平臺輸出的格式做了標準數(shù)據(jù)格式兼容確?？蛻裟苤苯訉爰扔熊浖^續(xù)處理這比讓客戶換工具鏈更容易被接受。5. 落地部署中的高頻問題與排查實錄5.1 現(xiàn)場問題速查表平臺從實驗室走到客戶現(xiàn)場會遇到很多在開發(fā)環(huán)境里做夢都想不到的問題。我挑幾個高頻的整理成速查表這些都是實際踩過的坑。現(xiàn)象可能原因排查思路處理辦法機載AI偶發(fā)推理超時電壓跌落導致算力降頻檢查DC-DC輸出和電池電量獨立供電并加穩(wěn)壓電容事件切片上傳失敗率高弱網(wǎng)下TCP重傳風暴查看通信模塊信號強度和隊列積壓切換UDP協(xié)議并加應用層確認模型新版本切換后誤報驟增新模型過擬合測試集對比新舊模型評測指標回滾并補充困難樣本重訓地面站地圖與機載定位偏差大RTK未固定解查看定位狀態(tài)字等待固定解后再執(zhí)行任務紅外相機與可見光畫面不同步兩路時間戳未對齊檢查時鐘同步配置統(tǒng)一以GPS時間戳對齊多云環(huán)境下拍照模糊相機參數(shù)未隨光照自適應查看曝光參數(shù)日志開啟自動曝光并加HDR模式5.2 避坑經(jīng)驗與工程心得第一個經(jīng)驗是“永遠不要把演示環(huán)境的配置當成生產(chǎn)配置”。我們第一次去客戶現(xiàn)場部署時帶的是開發(fā)板上調(diào)好的參數(shù)結果在強日照和高溫環(huán)境里機載AI節(jié)點過熱保護觸發(fā)推理速度掉到原來的四分之一。后來專門做了一輪環(huán)境適應性測試在高溫箱、低溫箱、振動臺上跑滿循環(huán)重新標定了熱管理和供電參數(shù)這個問題才根治。第二個經(jīng)驗是“數(shù)據(jù)鏈路要能降級不能硬扛”。一體化平臺最容易垮的環(huán)節(jié)就是通信。早期我們把所有數(shù)據(jù)都塞進一條鏈路結果一遇到信號波動控制指令和視頻互相搶占飛機倒是沒丟但操作員完全失明了。后來改成控制優(yōu)先、事件優(yōu)先的多優(yōu)先級調(diào)度策略問題迎刃而解。這個教訓讓我明白工程上的穩(wěn)定不是靠把單點做堅固而是靠把失敗影響控制在局部。第三個體會是關于團隊協(xié)作的。做這種跨端、邊、云的平臺項目最怕的是各模塊負責人各做各的到最后聯(lián)調(diào)時發(fā)現(xiàn)接口對不上。我們從一開始就定義了統(tǒng)一的數(shù)據(jù)交換標準包括事件結構、時間戳格式、坐標系約定每個模塊的單元測試里都包含對這些標準的校驗。寧可前期多花兩周定義標準也不要后期花兩個月聯(lián)調(diào)返工。最后再補充一點個人感受如果你也想啟動類似的一體化平臺項目別急著買設備、跑模型先花時間把“平臺要替客戶完成什么任務”這個問題想透。技術選型、架構分層、模塊設計都是圍繞這個問題展開的方向?qū)α撕竺婷恳徊蕉紩叩梅€(wěn)方向偏了再炫的技術也只是在錯誤的大道上加速。這套平臺做到現(xiàn)在我們最自豪的不是算法精度有多高、系統(tǒng)多復雜而是現(xiàn)場同事們真的愿意天天用它這比什么指標都說明問題。