上篇聊了安全設(shè)計功能安全和信息安全是機(jī)器人的安全底線。今天聊的話題是機(jī)器人部署出去之后怎么管很多團(tuán)隊把精力都放在開發(fā)階段產(chǎn)品一交付就眼不見心不煩。結(jié)果客戶打電話來說機(jī)器人不動了你連日志都拿不到只能派人到現(xiàn)場排查——一次出差的成本夠你做好幾套監(jiān)控系統(tǒng)了。系統(tǒng)監(jiān)控和運(yùn)維能力是機(jī)器人產(chǎn)品成熟度的重要標(biāo)志。機(jī)器人運(yùn)維和傳統(tǒng)服務(wù)器運(yùn)維有本質(zhì)區(qū)別。服務(wù)器掛在云端你可以SSH上去查日志、重啟服務(wù)。機(jī)器人在客戶現(xiàn)場的局域網(wǎng)里你大概率訪問不到。而且機(jī)器人有物理實體遠(yuǎn)程操作需要格外小心——你不能像重啟服務(wù)器一樣隨意重啟一臺正在搬運(yùn)貨物的AGV。日志系統(tǒng)——出了問題有據(jù)可查日志是排查問題的第一手材料。機(jī)器人日志系統(tǒng)的設(shè)計要考慮幾個問題日志量傳感器數(shù)據(jù)量很大不能全記、存儲限制嵌入式設(shè)備磁盤有限、檢索效率出問題時能快速定位。日志分級是基礎(chǔ)操作DEBUG、INFO、WARN、ERROR、FATAL。關(guān)鍵是每一級該記什么要有團(tuán)隊共識。我們團(tuán)隊的規(guī)范是DEBUG記算法中間結(jié)果開發(fā)時用發(fā)布時關(guān)閉INFO記狀態(tài)變化節(jié)點(diǎn)啟停、模式切換、任務(wù)開始結(jié)束WARN記異常但可恢復(fù)的情況傳感器數(shù)據(jù)延遲、定位精度下降ERROR記功能失敗路徑規(guī)劃失敗、通信中斷FATAL記系統(tǒng)級故障硬件驅(qū)動崩潰、安全系統(tǒng)觸發(fā)。ROS2的日志框架rclcpp::Logger提供了標(biāo)準(zhǔn)的日志功能但生產(chǎn)環(huán)境還需要做增強(qiáng)日志要帶時間戳和節(jié)點(diǎn)標(biāo)識方便跨節(jié)點(diǎn)排查要支持日志輪轉(zhuǎn)log rotation避免磁盤寫滿要能遠(yuǎn)程上報不能只存在本地。// ROS2日志增強(qiáng)示例 RCLCPP_INFO(this-get_logger(), Task %s started, battery: %.1f%%, map_version: %s, task_id.c_str(), battery_level, map_version.c_str()); // 關(guān)鍵信息任務(wù)ID、電量、地圖版本 // 出問題時可以快速還原當(dāng)時的運(yùn)行環(huán)境日志上報用什么方案輕量級方案是rsyslog或者Filebeat把日志文件推送到中心的Elasticsearch。ROS2生態(tài)里也有人用ros2bag錄制關(guān)鍵話題數(shù)據(jù)回傳后離線回放分析。帶寬受限時只上報結(jié)構(gòu)化日志文本關(guān)鍵指標(biāo)原始傳感器數(shù)據(jù)存在本地需要時再遠(yuǎn)程拉取。監(jiān)控與告警——知道機(jī)器人不舒服了日志是事后分析用的監(jiān)控是實時感知系統(tǒng)健康狀態(tài)用的。機(jī)器人的監(jiān)控指標(biāo)分三類硬件指標(biāo)CPU溫度、內(nèi)存使用率、電池電壓、磁盤剩余空間、軟件指標(biāo)節(jié)點(diǎn)存活狀態(tài)、話題發(fā)布頻率、消息延遲、業(yè)務(wù)指標(biāo)任務(wù)完成率、定位精度、導(dǎo)航成功率。告警規(guī)則的設(shè)計要避免兩個極端太靈敏導(dǎo)致告警風(fēng)暴運(yùn)維人員被無數(shù)誤報淹沒真正的告警反而被忽略太遲鈍導(dǎo)致問題已經(jīng)嚴(yán)重了才告警。實踐經(jīng)驗是分級告警WARNING級別推送給值班工程師的IM工具CRITICAL級別自動觸發(fā)降級策略同時電話通知負(fù)責(zé)人。# 告警規(guī)則示例Prometheus格式 groups: - name: robot_health rules: - alert: HighCPUTemperature expr: cpu_temp_celsius 80 for: 5m labels: severity: warning annotations: summary: 機(jī)器人CPU溫度過高: {{ $value }}°C - alert: NavigationFailureRate expr: nav_failure_rate 0.1 for: 10m labels: severity: critical數(shù)據(jù)采集用什么方案機(jī)器人端用輕量級的Prometheus Node Exporter采集系統(tǒng)指標(biāo)ROS2話題里加一個診斷節(jié)點(diǎn)diagnostics采集業(yè)務(wù)指標(biāo)。數(shù)據(jù)推送到云端用Grafana做可視化看板。如果機(jī)器人數(shù)量超過幾十臺建議上一個時序數(shù)據(jù)庫TDengine或InfluxDB查詢性能比直接查Prometheus好很多。OTA遠(yuǎn)程更新——不停機(jī)升級軟件機(jī)器人部署到客戶現(xiàn)場后軟件更新是不可避免的。修bug、加功能、優(yōu)化性能——都需要遠(yuǎn)程推送新版本。OTAOver-The-Air更新系統(tǒng)的設(shè)計要考慮三個核心問題怎么分發(fā)更新包、怎么保證更新不中斷服務(wù)、更新失敗了怎么回滾。更新包的分發(fā)方式取決于網(wǎng)絡(luò)環(huán)境。有公網(wǎng)連接的機(jī)器人可以直接從云端拉取更新包只在內(nèi)網(wǎng)的機(jī)器人需要通過本地網(wǎng)關(guān)或者U盤導(dǎo)入。我們團(tuán)隊做過一個方案在內(nèi)網(wǎng)部署一個本地更新服務(wù)器云端先把更新包推送到本地服務(wù)器機(jī)器人從本地服務(wù)器拉取——這樣既不需要公網(wǎng)直連機(jī)器人又利用了內(nèi)網(wǎng)的高帶寬。不中斷服務(wù)更新是最理想的狀態(tài)但對機(jī)器人來說往往不現(xiàn)實——你不能在機(jī)器人正在搬運(yùn)貨物的時候替換它的導(dǎo)航模塊。常見的做法是下載-準(zhǔn)備-確認(rèn)三步走先后臺下載更新包然后在機(jī)器人空閑時安裝安裝完成后等待管理員確認(rèn)再切換到新版本。回滾機(jī)制是OTA的生命線。每次更新前自動備份當(dāng)前版本如果新版本啟動后自檢失敗自動回滾到上一版本。更穩(wěn)妥的做法是A/B分區(qū)方案系統(tǒng)盤分成兩個分區(qū)當(dāng)前運(yùn)行的在A分區(qū)新版本安裝到B分區(qū)。啟動時通過Bootloader選擇從哪個分區(qū)啟動。A分區(qū)始終保持不變B分區(qū)出問題了直接切回A。嵌入式設(shè)備比如機(jī)器人的MCU固件用這種方案特別合適。我見過一個團(tuán)隊沒有做回滾機(jī)制一次OTA推送了一個有bug的固件二十多臺機(jī)器人集體變磚只能派人到現(xiàn)場一臺一臺用USB線刷回來。代價慘痛。遠(yuǎn)程診斷——不出差也能排查問題遠(yuǎn)程診斷的核心是讓工程師在辦公室就能還原客戶現(xiàn)場的情況。最基本的能力是遠(yuǎn)程查看日志和監(jiān)控數(shù)據(jù)——這前面已經(jīng)說了。進(jìn)階的能力是遠(yuǎn)程操控在授權(quán)的前提下遠(yuǎn)程接管機(jī)器人的控制權(quán)復(fù)現(xiàn)問題場景。最高級的能力是遠(yuǎn)程數(shù)據(jù)回放把機(jī)器人某段時間的傳感器數(shù)據(jù)錄制下來在辦公室的模擬環(huán)境里回放用仿真工具分析問題。ROS2的rosbag2錄制和回放功能天然支持這種場景。關(guān)鍵是在設(shè)計時要預(yù)留遠(yuǎn)程觸發(fā)錄制的接口——問題發(fā)生后再錄制往往來不及。我們做了一個自動錄制觸發(fā)器當(dāng)檢測到導(dǎo)航失敗率超過閾值時自動開始錄制前后各30秒的傳感器數(shù)據(jù)。這樣工程師拿到的bag文件里一定包含了問題發(fā)生的完整上下文。面試追問你們怎么處理日志存儲問題嵌入式設(shè)備上用日志輪轉(zhuǎn)保留最近三天的詳細(xì)日志和最近三十天的摘要日志。詳細(xì)日志每秒可能幾十KB摘要日志只有幾百字節(jié)。重要事件安全告警、任務(wù)失敗的日志單獨(dú)存儲不受輪轉(zhuǎn)策略影響永久保留直到手動清理。OTA更新怎么保證安全更新包用RSA-2048簽名機(jī)器人端內(nèi)置公鑰驗簽。傳輸用TLS加密。安裝前校驗包完整性SHA-256。整個過程有完整的審計日志——誰推送了什么版本、什么時候安裝、結(jié)果如何全部可追溯。你們怎么判斷一臺機(jī)器人需要運(yùn)維關(guān)注我們有一個健康度評分系統(tǒng)綜合CPU負(fù)載、內(nèi)存使用、傳感器狀態(tài)、任務(wù)成功率、通信質(zhì)量等指標(biāo)算出一個0到100的健康分。低于80分自動標(biāo)黃低于60分標(biāo)紅并推送告警。運(yùn)維人員每天看一眼看板優(yōu)先處理標(biāo)紅的機(jī)器人。運(yùn)維能力是區(qū)分Demo級產(chǎn)品和量產(chǎn)級產(chǎn)品的關(guān)鍵。很多機(jī)器人公司的產(chǎn)品能做出很炫的Demo但部署到客戶現(xiàn)場后問題頻出運(yùn)維成本居高不下。根本原因就是開發(fā)階段沒有把監(jiān)控、告警、遠(yuǎn)程更新這些能力當(dāng)作產(chǎn)品的一部分來建設(shè)。一個好的運(yùn)維系統(tǒng)能讓你的團(tuán)隊把80%的問題通過遠(yuǎn)程排查解決只有真正需要換硬件的情況才出差。這對控制成本、提高客戶滿意度、加快問題響應(yīng)速度都有巨大價值。下一篇聊項目管理基礎(chǔ)。機(jī)器人項目的復(fù)雜度決定了它不能靠一個人單干完成。選對項目管理方法、建立合理的流程是項目成功的保障。敏捷還是瀑布這個問題在機(jī)器人行業(yè)一直沒有定論。如果這篇文章對你有幫助歡迎點(diǎn)贊、在看、轉(zhuǎn)發(fā)三連。 你的支持是我持續(xù)更新的最大動力?！笝C(jī)器人軟件開發(fā)面試·從入門到精通」連載系列上一篇第334篇 安全設(shè)計——機(jī)器人軟件的功能安全和信息安全下一篇預(yù)告第336篇 項目管理基礎(chǔ)——機(jī)器人項目的敏捷/瀑布選型有任何問題歡迎評論區(qū)留言我會盡量回復(fù)。