Microduck 是那種第一眼看上去像玩具、實際玩法很深的 25cm 級強化學習機器人。我手頭這臺從英偉達 GPU 上的仿真訓練開始最終讓它跑在 RK3566 實機上中間橫跨了強化學習算法調試、模型導出、邊緣端部署、電機驅動和一堆本該避免但繞不開的坑。這篇文章就記錄整個部署過程適合正在折騰 Microduck 的玩家、準備把強化學習策略從 PC 搬到嵌入式平臺的研究生或工程師也適合只想知道 RK3566 這類開發(fā)板到底能不能跑強化學習策略的朋友。1. 項目背景與整體方案選型1.1 Microduck 是什么25cm 尺寸帶來的設計約束Microduck 是一個開源的小型強化學習機器人項目整體尺寸只有 25cm 級別常見的說法也叫它“玩具尺寸四足”或者“桌面級足式機器人”。體積小帶來的好處是場地要求低、危險系數(shù)低可以在桌面上直接做實驗但代價也很明顯可用電池容量小電機扭矩小主控板尺寸小散熱條件差。這就直接決定了你在選主控芯片、電機驅動、通信總線的時候不能照著大型機器人的思路來。很多玩機器人的人一上來就想著用高性能工控機或者 Jetson Orin 這類平臺做端側推理但 Microduck 這種尺寸根本塞不下這么大的板子功耗也不現(xiàn)實。我最初試過用 Jetson Nano 做推理平臺結果電池掉電速度驚人而且發(fā)熱嚴重最后只能放棄。真正適合這種體積的是一塊像 RK3566 這種小尺寸、低功耗、帶一點點 NPU 算力的核心板。25cm 尺寸還有一個隱含約束結構件大多是 3D 打印的重量控制不嚴格轉動慣量分布不均勻。這意味著你在 GPU 仿真環(huán)境里練出來的策略如果不在仿真階段做好域隨機化到了實機上大概率站都站不穩(wěn)。所以這個尺寸的機器人項目反而是對“仿真到實機遷移”要求最嚴苛的一類。1.2 為什么選擇英偉達 GPU RK3566 這套組合訓練端選擇英偉達 GPU不需要太多解釋。強化學習尤其是 PPO 這類策略梯度算法動輒需要跑幾十萬到幾百萬個 step沒有 GPU 加速的 Isaac Gym 或 MuJoCo光靠 CPU 仿真訓練一個能走的四足策略可能要幾天甚至一周根本沒法迭代。用 RTX 4090 這類消費級卡配合 GPU 版仿真器能把訓練時間壓縮到幾小時這就是選英偉達 GPU 的核心原因。部署端選擇 RK3566則是從成本、功耗、算力三個維度權衡的結果。RK3566 是瑞芯微推出的一款四核 Cortex-A55 處理器帶 0.6TOPS 左右的 NPU功耗通常能做到一兩瓦左右板子也夠小非常契合 Microduck 的限制條件。很多人會糾結它算力不如樹莓派 5但實際做部署時你會發(fā)現(xiàn)強化學習策略網絡往往是一個很小的 MLP多層感知機幾百到一兩千個參數(shù)CPU 跑也只要幾毫秒NPU 反而不是重點。真正的問題是 RK3566 上的軟件生態(tài)、系統(tǒng)鏡像、外設接口是否穩(wěn)定可靠這才是我選擇它之后花大量時間踩坑的地方。所以整套鏈路用一句話總結英偉達 GPU 負責把策略訓出來RK3566 負責把策略跑起來中間通過模型導出和推理框架把兩者連接起來。1.3 完整部署鏈路概覽在動工之前我先在紙上把整條鏈路畫了一遍避免做到一半才發(fā)現(xiàn)方案不閉環(huán)。我的最終鏈路是在 PC 上用 GPU 仿真環(huán)境MuJoCo 或 Isaac Gym構建 Microduck 的四足動力學模型。用 PPO 或其變體算法訓練控制策略同時設計獎勵函數(shù)增加域隨機化。訓練完成后把 PyTorch 權重導出為 ONNX 格式。對 ONNX 模型做精簡去掉不必要的算子適配邊緣端推理框架。在 RK3566 上部署推理代碼接好電機驅動通過串口或者總線把動作指令下發(fā)到電機模塊。實機調試修正關節(jié)方向、控制頻率、延時補償?shù)葐栴}。這條鏈路本身不算復雜但每一步都有不少隱藏問題。尤其是從第 4 步到第 6 步很多做算法的人不太熟悉硬件側的操作很容易卡住。后面我會按這個順序把每個階段的實操細節(jié)拆開來講。2. 強化學習訓練階段的關鍵環(huán)節(jié)2.1 訓練環(huán)境搭建從 MuJoCo 到 Isaac Gym 的選擇我在訓練階段先用了 MuJoCo因為它的物理引擎精度高而且完全免費開源社區(qū)里也有不少四足機器人模型可以直接導入。但真正開始大規(guī)模并行采樣時我發(fā)現(xiàn) MuJoCo 的 GPU 加速能力在配置上有點繁瑣雖然它支持 GPU 批量仿真但對一個剛開始接觸這個項目的人來說還是有點門檻。后面我換了 Isaac Gym這個環(huán)境最大的優(yōu)勢是可以直接在 GPU 上大規(guī)模并行多個機器人實例一次性采樣幾千個環(huán)境訓練效率比單環(huán)境仿真高很多。Microduck 這種 25cm 小機器人在 Isaac Gym 里可以同時跑幾千個實例配合 RTX 4090 的話訓練一個能穩(wěn)定行走的 PPO 策略大概只需要一兩個小時到半天具體取決于獎勵函數(shù)設計得有多復雜。當然 Isaac Gym 也有缺點。首先它的官方支持已經逐步轉向新的 Isaac Lab 框架舊版環(huán)境安裝時和 CUDA、PyTorch 版本的兼容性問題比較多其次在 Isaac Gym 里要精確復現(xiàn) Microduck 的物理尺寸、電機特性、關節(jié)阻尼需要自己調整模型參數(shù)并不是導入一個 URDF 就萬事大吉。如果你和我一樣用的是社區(qū)里現(xiàn)成的 Microduck 模型文件一定要檢查關節(jié)角度的正負方向以及電機最大扭矩是否和實機一致。我的建議是如果你只想快速驗證控制邏輯用 MuJoCo 就夠了如果你要大量訓練、頻繁迭代策略直接上 Isaac Gym 或 Isaac Lab別猶豫。2.2 狀態(tài)空間、動作空間與獎勵設計錯誤獎勵的處理很多人第一次訓練強化學習機器人時失敗的原因不在算法而在狀態(tài)空間和動作空間定義不合理。Microduck 這種四足機器人我最開始用的狀態(tài)向量是機身線速度3 維、角速度3 維機身朝向的四元數(shù)4 維四條腿的關節(jié)角度假設每條腿 3 個電機共 12 維關節(jié)角速度12 維上一個動作12 維這樣加起來大概 46 維對于 MLP 策略網絡來說完全夠用。動作空間是 12 維的關節(jié)目標位置也就是每個電機期望轉到哪個角度具體的力矩由底層的 PID 控制器去實現(xiàn)。這里有一個很關鍵的設計思路強化學習策略不直接輸出電流或力矩而是輸出目標位置由電機驅動板自帶的 PID 閉環(huán)去跟蹤。這樣做的好處是策略在高層面做邏輯決策底層的力控制和頻率控制交給更可靠的嵌入式系統(tǒng)去處理可以避免策略在完全沒有約束的情況下輸出極端的力矩指令導致電機過載。熱詞里提到“基于強化學習的 PID 控制”其實就是這個方向的一個變體你可以讓強化學習實時調節(jié) PID 參數(shù)也可以讓強化學習輸出目標軌跡PID 去跟蹤兩種方式都有人在用。獎勵設計是訓練階段最容易踩坑的地方尤其是熱詞里提到的“強化學習遇到錯誤獎勵”。我在 Microduck 項目里遇到過兩次比較典型的錯誤獎勵問題。第一次是獎勵項數(shù)值量級失衡我把前進速度獎勵設成 1.0而朝向一致性的懲罰只有 0.01結果訓練出來的策略瘋狂亂跑即使方向偏離很大也能獲得高總獎勵。第二次是稀疏獎勵陷阱能量懲罰設置得太重策略干脆待著不動因為任何動作都會增加能量消耗不動反而能拿到更高的累計獎勵。處理錯誤獎勵的核心思路是每次只檢查單一獎勵項的貢獻而不是只看總獎勵曲線。我會在訓練時把各個獎勵分量單獨記錄成日志觀察前進速度分量是否正常上升、電能懲罰是否失控、朝向誤差是否有收斂趨勢。如果某個分量始終抖動劇烈多半就是該項的系數(shù)太高或者目標函數(shù)和策略行為之間存在沖突。實踐中比較好用的做法是先用簡單獎勵跑通比如只給前進速度獎勵和存活獎勵跑一個能走但姿勢怪異的策略再逐步加上姿態(tài)穩(wěn)定性、能耗項、關節(jié)限位懲罰。2.3 從仿真到實機的域隨機化Microduck 這類小機器人實機部署最大的敵人是仿真環(huán)境和真實物理環(huán)境的差異。我在仿真里跑得再漂亮拿到實機上一開機大多數(shù)情況是原地抽搐、翻車、甚至直接把電機堵轉。原因無外乎摩擦系數(shù)不一樣、重心位置有偏差、電機響應延遲高、關節(jié)阻尼不匹配。域隨機化是目前解決這個問題最實用、也最容易落地的手段。我的具體做法是在每一次環(huán)境重置的時候隨機化機身質量、質心偏移、腿部摩擦系數(shù)、關節(jié)阻尼、電機扭矩上限、控制延時這幾個參數(shù)隨機區(qū)間大概設置在機器人真實參數(shù)的百分之二十左右。比如 Microduck 的實際重量是 0.6kg我就在 0.5kg 到 0.7kg 之間隨機采樣。這里要特別提醒一點控制延時是一個很容易被忽略但影響巨大的隨機化參數(shù)。實機從讀取傳感器到真正驅動電機整個鏈路通常有幾十毫秒的延遲如果你的訓練環(huán)境里沒有加延時模擬策略就會對動作效果產生錯誤的時序關聯(lián)推斷。我的做法是在訓練環(huán)境的每一步里隨機插入 10 到 50 毫秒的延遲讓策略學會在不確定性下保持穩(wěn)定這樣實機部署時策略的魯棒性會好很多。2.4 GPU 訓練中的算力配置與超參數(shù)訓練超參數(shù)這一塊我直接說我在 Microduck 項目里用到的、實測有效的配置。PPO 算法actor 網絡和 critic 網絡都是兩層 MLP每層 256 個神經元激活函數(shù)用 ReLU。學習率初始為 3e-4訓練過程中逐步衰減到 3e-5。batch size 設為 2048minibatch 為 128clip 參數(shù) 0.2GAE 的 lambda 取 0.95折扣因子 gamma 取 0.99。在 Isaac Gym 里我同時跑 4096 個環(huán)境實例每個實例都是獨立的 Microduck 機器人用 RTX 4090 訓練時單次迭代差不多需要 2 到 3 秒。通常跑到 3000 到 5000 步迭代時策略已經能走出比較像樣的步態(tài)總體訓練時間大概在一到三個小時取決于你是否同時做大量的域隨機化。要注意的是訓練日志最好每 50 次迭代就記錄一次到本地避免中途崩潰丟了全部進度。3. 模型導出與邊緣端適配3.1 從 PyTorch 模型到 ONNX / RKNN 的轉換流程訓練完成后你手里的是一組 PyTorch 的權重。這時候不能直接把權重丟給 RK3566因為嵌入式端大概率不會裝完整的 PyTorch更常見的是用 ONNX Runtime 或者 RKNN 工具鏈做推理。我的第一步是把 actor 網絡單獨提取出來保存成 ONNX 格式。轉換過程沒那么玄乎核心代碼如下import torch import torch.nn as nn class Actor(nn.Module): def __init__(self, obs_dim, act_dim): super().__init__() self.net nn.Sequential( nn.Linear(obs_dim, 256), nn.ReLU(), nn.Linear(256, 256), nn.ReLU(), nn.Linear(256, act_dim), nn.Tanh() ) def forward(self, obs): return self.net(obs) actor Actor(obs_dim46, act_dim12) actor.load_state_dict(torch.load(microduck_actor.pth)) actor.eval() dummy_input torch.randn(1, 46) torch.onnx.export( actor, dummy_input, microduck_actor.onnx, input_names[obs], output_names[action], dynamic_axes{obs: {0: batch_size}, action: {0: batch_size}}, opset_version12 )這里我把輸入輸出動態(tài) batch 打開了方便在板端推理時每次只輸入一個樣本。opset_version 建議選 11 到 13 之間太高的版本有些嵌入式推理框架支持不完整。導出后用onnx.checker.check_model驗證一下整體結構再打印一遍網絡層確認沒有出現(xiàn)奇怪的算子。如果執(zhí)意要用 RK3566 的 NPU那么接下來還需要用 RKNN-Toolkit2 把 ONNX 模型轉成 RKNN 格式。這個過程我踩過一個明顯的坑rknn-toolkit2 的版本必須和開發(fā)板上運行的 RKNPU 驅動版本對齊否則轉換出來的模型在板上加載時會出現(xiàn)版本不匹配的報錯。我最后用的是 rknn-toolkit2 1.6.0 配合板端 1.6 驅動才穩(wěn)定跑起來。3.2 RK3566 硬件資源限制下的量化與算子裁剪RK3566 的 NPU 理論算力有 0.6TOPS聽起來還能用但實際上它支持的算子種類有限尤其是一些動態(tài)形狀、循環(huán)、稀疏操作很可能會出現(xiàn)轉換失敗。好在一個 MLP 策略網絡只有全連接層、ReLU、Tanh 這類基礎算子算是在 RKNN 支持的范圍內所以轉換成功率還算高。不過這里有一個非常現(xiàn)實的問題量化。RK3566 的 NPU 對浮點模型直接支持有限更常見的是轉成 INT8 定點運算。我在量化后先小范圍測試了一下理論上 INT8 量化對 MLP 這種小網絡的影響應該很小但實測下來量化后的策略在實機上偶爾會出現(xiàn)關節(jié)方向微小抖動后續(xù)排查是 tanh 輸出層的數(shù)值精度有損失導致策略輸出和原始浮點版本有輕微偏差。解決辦法是盡量保留輸出層為浮點層或者讓 actor 網絡輸出之前接一個線性層不強制走 INT8 量化。如果你和我一樣最終決定用 CPU 跑 ONNX Runtime那可以完全避開量化的問題。對于 Microduck 的運動控制頻率常用的控制循環(huán)是 50Hz 到 100Hz也就是說每 10 到 20 毫秒要跑一次推理。這個 MLP 網絡在 RK3566 的四個 A55 內核上單次推理只需要 2 到 5 毫秒CPU 完全跑得動NPU 反而不一定更穩(wěn)。由此可見“必須用 NPU”是很多人對嵌入式 AI 的誤解。在 RK3566 上部署強化學習策略最重要的評估指標是端到端延遲是否滿足控制頻率而不是硬件上有沒有 NPU。如果 CPU 能滿足實時性優(yōu)先用 CPU 推理能省去大量算子兼容性調試時間。3.3 推理框架選型ONNX Runtime CPU 還是 RKNN我在 RK3566 上對比過兩張方案ONNX RuntimeCPU和 RKNNNPU。ONNX Runtime 的優(yōu)勢是部署簡單直接安裝 prebuilt wheel 就能跑不依賴 NPU 驅動而且對 PyTorch 導出的 ONNX 模型兼容性好。缺點是占用的內存稍微多一點但 Microduck 控制程序本身很小完全沒問題。如果走 RKNN 通道最大的優(yōu)勢是 NPU 可以騰出 CPU 資源給其他任務比如運動學解算、傳感器處理等。但對于我這種小規(guī)模 MLP 網絡NPU 的加速效果并不明顯反而因為模型轉換、量化精度、驅動版本匹配這些事增加了大量時間成本。如果你只是復制我的做法我建議直接走 ONNX Runtime CPU先把整個控制系統(tǒng)跑通后面有余力再考慮優(yōu)化 NPU 推理。在板端運行 ONNX Runtime 的代碼思路也很清晰import onnxruntime as ort import numpy as np sess ort.InferenceSession(microduck_actor.onnx, providers[CPUExecutionProvider]) # 每一控制周期構造 obsshape 為 (1, 46) obs np.random.randn(46).astype(np.float32).reshape(1, 46) input_name sess.get_inputs()[0].name action sess.run(None, {input_name: obs})[0].reshape(-1) print(action)這里有個細節(jié)要注意輸入數(shù)據(jù)必須用np.float32不能是 float64否則 ONNX Runtime 會報類型不匹配。我在第一次跑的時候吃了這個虧整個程序報錯后我查了半天最后才發(fā)現(xiàn)是輸入數(shù)據(jù)格式問題。4. RK3566 實機部署與調試實錄4.1 系統(tǒng)鏡像與設備識別問題泰山派識別到 RK3566 但是是 ADB 設備硬件調試的第一步是讓 RK3566 開發(fā)板正常啟動并可以被電腦訪問。我用的是泰山派TaisanPi的 RK3566 核心板板卡本身支持 USB、串口、以太網但第一次上電時就被電腦識別成了一個 ADB 設備而不是常規(guī)的串口或者網絡設備這讓我折騰了一晚上。所謂“泰山派識別到 RK3566 但是是 ADB 設備”意思是開發(fā)板通過 USB 連接到電腦后lsusb識別到的設備 ID 指向 Android Debug Bridge而不是一個普通的 USB 以太網卡或者串口設備。出現(xiàn)這個問題的根本原因是板卡上電后進入了燒錄模式或者出廠固件自帶的 ADB 服務在跑這時候你是沒法正常進入系統(tǒng)的。很多剛入手 RK3566 的朋友都會卡在這一步。我的解決方法是這樣的首先用瑞芯微官方的 RKDevTool 燒錄工具進入 MaskROM 模式重新燒寫一個干凈的系統(tǒng)鏡像。具體操作是先按住板子上的恢復鍵再上電讓板子進入燒錄模式隨后在 RKDevTool 里燒入一個 Debian 或者 Ubuntu 的鏡像不要用出廠自帶的 Android 鏡像。燒寫成功后重新上電連接 USB 轉串口模塊登錄系統(tǒng)把 USB 設備模式改回普通 USB Device 或者直接禁用 ADB問題就解決了。如果你只是想在 Linux 系統(tǒng)里用 USB 通信記得檢查一下內核是否加載了對應的 USB gadget 驅動必要時寫一個 systemd 服務來啟動設備模式配置腳本。4.2 串口 / 外設對接與電機控制RK3566 實機跑起來之后下一步就是把控制信號發(fā)到電機。Microduck 的電機一般是 12V 的串行總線舵機比如常見的 LX-16A、ST3215 這類走半雙工 UART 通信。我在系統(tǒng)中用/dev/ttyS4串口和電機的轉換板通信波特率出廠默認是 115200注意每條指令幀的 ID 和校驗位不能寫錯通過 UART 調用電機的角度位置控制指令?？刂祁l率的選擇上我一開始跑 200Hz也就是 5ms 一發(fā)指令結果電機驅動板響應不過來串口數(shù)據(jù)大量積壓關節(jié)明顯抖動。后來調低到 100Hz單次指令間隔 10ms推理、控制、通信都能在時間片里完成機器人走起來才穩(wěn)定。這里想提醒各位千萬不要盲目追求高控制頻率總線舵機的內部 PWM 刷新頻率通常是 50 到 250Hz一串指令發(fā)得再快電機跟不上也是白搭。電機控制之外還要處理機身慣性測量單元IMU。我用的是一款常見的九軸 IMU通過 I2C 接口讀取加速度和角速度數(shù)據(jù)再把姿態(tài)四元數(shù)作為狀態(tài)輸入的一部分。IMU 數(shù)據(jù)的實時性會影響強化學習策略的輸入質量我把 IMU 讀取放在一個獨立線程里讓它以 500Hz 的頻率刷數(shù)據(jù)然后控制主線程每 10ms 取一次最新的傳感器數(shù)據(jù)。4.3 部署后效果驗證與性能調優(yōu)實機部署成功不代表著能走好。我第一次把策略部署上去后Microduck 能站起來但邁步時明顯一瘸一拐而且頻繁往一側偏。排查下來主要有三個問題一個是左右腿的關節(jié)方向在仿真和實機上不一致等于策略在給反方向指令另一個是 IMU 數(shù)據(jù)有噪聲策略輸入不穩(wěn)定第三個是控制線程和推理線程沒有做好同步導致推理輸出動作時使用的傳感器數(shù)據(jù)已經是舊數(shù)據(jù)。針對這三點我做的修正分別是在實機上逐個關節(jié)校驗電機方向寫一個簡單的腳本讓每個關節(jié)轉到目標角度確認轉向與仿真模型一致對 IMU 數(shù)據(jù)加一個輕量級的低通濾波比如一階 RC 濾波減少高頻噪聲把控制循環(huán)改成“先讀取當前傳感器數(shù)據(jù)再推理再下發(fā)指令”的嚴格順序執(zhí)行避免多線程競態(tài)。實測下來經過這些修正后 Microduck 的行走穩(wěn)定性提升明顯單次連續(xù)行走距離能穩(wěn)定保持在十米以上。當然這只是一個基本目標后續(xù)還有轉向、越障、摔倒恢復等更復雜的控制目標都需要進一步訓練和部署調試。5. 實踐中的典型問題與排查方法5.1 設備識別失敗快速排查清單RK3566 板卡設備識別問題在實際項目中出現(xiàn)的概率極高尤其當你第一次刷機或者更換系統(tǒng)鏡像的時候。我根據(jù)自己的經歷整理了一張快速排查表遇到問題可以直接照著查。現(xiàn)象可能原因解決辦法USB 連接電腦識別為 ADB 設備板卡進入燒錄模式或 Android 系統(tǒng)殘留按住恢復鍵進入 MaskROM 模式用 RKDevTool 燒錄 Linux 鏡像串口無輸出登錄串口和調試串口共用同一路 UART配置錯誤檢查系統(tǒng)/boot下的uEnv.txt或config.txt確認 console 映射的串口號系統(tǒng)啟動后 USB 無法模擬串口內核未啟用 USB gadget 驅動檢查/boot內核模塊加載配置啟用g_serial或g_ether驅動識別到 RK3566 但無法燒錄USB 線纜不適合數(shù)據(jù)傳輸換一根短的高質量 USB 數(shù)據(jù)線有些充電線不能傳數(shù)據(jù)板卡頻繁重啟電源供電不足使用 5V/3A 以上的適配器避免用電腦 USB 口直接供電設備識別問題大多數(shù)可以通過重新燒錄和檢查 USB 線纜解決真正卡住人的往往是不斷嘗試各種粗糙方案卻忽略了系統(tǒng)鏡像本身就是錯的。5.2 模型轉換失敗 / 精度下降我在從 PyTorch 導出 ONNX、再從 ONNX 轉 RKNN 的過程中遇到過的錯誤類型基本是三類算子不支持、版本不匹配、動態(tài) shape 引起的問題。算子不支持時你需要在導出端修改網絡結構把不支持的層用等價的基礎算子替換或者干脆重置為 CPU 推理。版本不匹配則是我在前面提過的rknn-toolkit2 和板端 RKNPU 驅動版本必須一致。動態(tài) shape 的問題更隱蔽很多 RKNN 模型要求 batch size 固定為 1如果你在導出時保留了動態(tài) batch轉換后可能無法加載。解決辦法是重新導出固定 batch 為 1。精度下降方面前面提過 INT8 量化后輸出層 tanh 受到一些影響。我驗證精度的方法是先在 PC 上隨機生成幾百組輸入比較 PyTorch 原模型和板端推理模型的輸出差異計算最大絕對誤差和均方根誤差。對于 MLP 策略網絡合理的誤差范圍在 0.01 到 0.05 左右如果誤差超過 0.1策略在實機上的表現(xiàn)很可能出現(xiàn)明顯退化。5.3 實機抖動、策略失效、獎勵信號異常實機抖動和策略失效是強化學習機器人部署中最讓人頭痛的問題。抖動的原因通常有幾個傳感器噪聲過大、控制頻率和電機響應不匹配、控制輸出的動作指令變化太劇烈、關節(jié)連桿存在間隙。我的處理思路是先把控制頻率固定到 100Hz然后在動作指令上增加一個低通濾波比如每次只更新目標角度的百分之三十讓關節(jié)運動更平滑。雖然這會稍微犧牲響應速度但穩(wěn)定性提升立竿見影。策略失效則要區(qū)分是實機輸入不對還是模型本身泛化能力不足。實機輸入不對通常體現(xiàn)在觀測向量的維度、順序、單位與訓練時不一致比如仿真里用的是弧度實機上讀出來的是角度制數(shù)那就需要做轉換。如果策略本身泛化能力不足則只能回頭補訓練增加更多域隨機化參數(shù)或者在實機上收集數(shù)據(jù)后做離線強化學習微調比如用 IQL離線強化學習來校正當前策略。獎勵信號異常多數(shù)是訓練階段的問題。如果你在訓練過程中發(fā)現(xiàn) total reward 在上升但在某一次迭代后驟降然后恢復得很慢很可能是某個隨機異常的仿真步進導致策略崩潰。解決方法是加載之前的備份權重減小學習率同時檢查是否有環(huán)境重置時出現(xiàn)非法狀態(tài)。獎勵曲線出現(xiàn)“先升后降”的走勢時不要急著加大獎勵系數(shù)先看各項子獎勵的貢獻變化往往能發(fā)現(xiàn)某些項在反復震蕩。6. 寫在最后Microduck 的擴展方向與個人經驗Microduck 這個項目真正跑通之后我在 PC 端訓練的效率并沒有提升多少反而是 RK3566 這個嵌入式平臺的部署經驗讓我對“強化學習機器人落地”這件事有了完全不同的理解。很多人總以為難點在算法但實際調試中傳感器對齊、關節(jié)方向、控制頻率、模型數(shù)值精度這些“瑣事”才是最耗費時間的部分。如果后續(xù)要繼續(xù)擴展我個人比較想嘗試的方向是離線強化學習比如先搜集 Microduck 在實機上自主跑動的大量數(shù)據(jù)再用 IQL 這類算法離線訓練策略這樣可以進一步縮小仿真和實機的差距。另外也可以在平臺上做更復雜的任務比如目標跟隨、避障、小斜坡越障這些都需要重新設計獎勵函數(shù)和訓練設置。最后分享一個小技巧不管是用 ONNX Runtime 還是 RKNN部署前一定要在 PC 上先做輸出一致性校驗不要直接燒到板子上再改。我一開始就是圖快模型轉完直接丟 RK3566結果各種莫名抖動后來回到 PC 上做差分測試才發(fā)現(xiàn)是量化精度的問題。多花十分鐘做校驗實機上能省出好幾個晚上的調試時間。