前言上一篇文章從Kruchten的41視圖視角分析了RL_SAR軟件架構(gòu)。Kruchten視圖模型已經(jīng)回答「從哪幾個角度看軟件」但換電機協(xié)議會不會影響策略相關(guān)代碼這件事圖上不一定看得出。四層回答的是邏輯視圖里控制棧到底按什么切開四層補的是一條領(lǐng)域約束。換 SDK / 仿真后端應(yīng)只動 HAL。發(fā)軟、跟不住應(yīng)先查實時層的 dt 和 PD而不是先改網(wǎng)絡(luò)。換 himloco.pt應(yīng)只動決策配置與觀測清單。加「按 3 跳舞」應(yīng)只加 FSM 技能和 YAML。這些是變更影響規(guī)則Kruchten 41視圖不會自動寫出來所以有必要補四層模型分析否則 sim2real、換機型、換策略的邊界是模糊的。為什么必須分層可以把整機想成一家餐廳灶臺和鍋電機、IMU、通信協(xié)議各家都不一樣。后廚節(jié)奏幾毫秒發(fā)一次力矩、PD 跟蹤必須穩(wěn)定客人等不起。主廚拍板看姿態(tài)、推策略、決定下一步動作可以慢一點但必須看對信息。前廳點單走路、跳舞、接導(dǎo)航才是用戶真正要的服務(wù)。如果不分層換一臺機器人就要把 PD、觀測、策略、按鍵一起改一遍。分層之后換機型主要改 HAL換策略主要改感知決策的配置加一個「跳舞」技能只動業(yè)務(wù)層的狀態(tài)機。四層之間只通過窄接口說話下層上報「現(xiàn)在關(guān)節(jié)在哪、身體怎么傾斜」上層只下發(fā)「目標(biāo)位置 / 速度 / 剛度」。上層不關(guān)心這是真機還是仿真下層不關(guān)心當(dāng)前是在走路還是在跳舞。四層職責(zé)對照如下層級典型頻率核心問題在 rl_sar 中的落點業(yè)務(wù)應(yīng)用層人機交互級現(xiàn)在要走路、跳舞還是跟導(dǎo)航走fsm_*.hpp技能狀態(tài)、Control、/cmd_vel、policy/*/config.yaml感知決策層~50 Hz看見什么、決定下一步動作ComputeObservation()、InferenceRuntime、FSM、MotionLoader實時運動控制層~200 Hz如何按時、安全地把目標(biāo)變成力矩LoopFunc、RLControl()、Interpolate()、robot_joint_controllerHAL 硬件抽象層總線級怎么把各家硬件讀成同一份結(jié)構(gòu)RobotState / RobotCommand、GetState()/SetCommand()1. HAL 硬件抽象層1.1 什么是 HAL 硬件抽象層硬件抽象層Hardware Abstraction Layer它把各家機器人/電機/總線的差異擋在下面向上提供統(tǒng)一的 RobotState / RobotCommand 以及 GetState() / SetCommand() 這類接口。HAL 的目標(biāo)只有一句話上層永遠面對同一份狀態(tài)和同一份指令不要面對廠商協(xié)議。工業(yè)上常見的做法是定義統(tǒng)一數(shù)據(jù)結(jié)構(gòu)關(guān)節(jié)位置、速度、估計力矩、IMU 四元數(shù)。用適配器把廠商 SDK / 仿真器填進這份結(jié)構(gòu)。用一張關(guān)節(jié)映射表處理「訓(xùn)練時的關(guān)節(jié)順序」和「SDK 里的關(guān)節(jié)順序」不一致。沒有 HAL策略網(wǎng)絡(luò)的輸入順序會和電機編號綁死。換一臺 Go2或從仿真遷到真機策略就要重訓(xùn)或手改下標(biāo)。1.2 該層項目示例rl_sar項目的 rl_sdk.hpp 里定義了兩份核心結(jié)構(gòu)。讀上來的叫 RobotStateIMU 電機狀態(tài)寫下去的叫 RobotCommand每個關(guān)節(jié)的 q / dq / tau / kp / kd?；?RL 只聲明兩個純虛函數(shù)GetState(RobotState*)把硬件讀成統(tǒng)一狀態(tài)SetCommand(const RobotCommand*)把統(tǒng)一指令寫回硬件真正干活的是子類RL_Real真機、RL_SimGazebo、MuJoCo 仿真。上層 RobotControl() 永遠是同一句先 GetState再跑狀態(tài)機再 SetCommand。以 Unitree Go2 真機為例。GetState() 從 DDS 話題 rt/lowstate 取出 IMU 四元數(shù)、陀螺儀再按 joint_mapping 把電機 q / dq / tau_est 填進 RobotState。SetCommand() 則組裝 LowCmd_寫回 rt/lowcmd并補上 CRC。上層完全看不到 0xFE 0xEF 這種協(xié)議頭。仿真?zhèn)茸吡硪粭l路Gazebo 里沒有廠商 DDS而是 robot_msgs/MotorCommand 下發(fā)、MotorState 回讀真正把「位置目標(biāo)」變成「仿真力矩」的是 robot_joint_controller 插件。對決策層來說兩邊都是同一份 RobotState。L4W4 更「直接」自己的 UDP SDK 解析 MCU 報文。HAL 的價值在這里特別明顯——策略代碼一行都不用為 UDP 改。1.3 關(guān)節(jié)映射訓(xùn)練空間 ≠ 硬件空間Go2 的 base.yaml 里關(guān)節(jié)按 FR / FL / RR / RL 排列himloco 策略的 joint_mapping 卻是 [3, 4, 5, 0, 1, 2, 9, 10, 11, 6, 7, 8]。也就是說觀測和動作按訓(xùn)練順序排讀寫電機按 SDK 順序排。 G1 的 whole-body tracking 策略映射更長因為 29 個自由度的訓(xùn)練順序和 Unitree HG SDK 順序也不一樣。可以把它理解成「插座轉(zhuǎn)換頭」墻上的孔電機編號各家不同插頭策略輸出必須經(jīng)過 mapping 才能插上。仿真和真機還有一個容易踩坑的細(xì)節(jié)角速度坐標(biāo)系。項目在觀測里用 ang_vel_axis 區(qū)分 body 和 world——ROS1 Gazebo 是世界系ROS2 / MuJoCo / 真機是機體坐標(biāo)系。這也屬于 HAL 向決策層「翻譯物理含義」的一部分。2. 實時運動控制層2.1 實時運動控制層職責(zé)實時運動控制層的主責(zé)是在固定短周期內(nèi)把上層給的關(guān)節(jié)目標(biāo)變成持續(xù)、安全的伺服推理來不及也不能停發(fā)力。 它不管「往哪走、跳什么舞」只保證在 5 ms 節(jié)拍上給電機下發(fā)目標(biāo)位置、目標(biāo)速度等。和相鄰層的邊界上層給的是目標(biāo)本層給的是「每拍都有效的伺服指令」。本層不讀 DDS/UDP 報文格式這些是HAL做的事。這一層有三條鐵律周期確定用獨立線程按固定 dt 跑必要時綁 CPU。控制律簡單關(guān)節(jié)級 PD阻抗足夠快、足夠好懂。安全兜底力矩限幅、姿態(tài)保護、柔順下電必須能在這一層直接生效不能等神經(jīng)網(wǎng)絡(luò)想完再救。強化學(xué)習(xí)策略通常跑在 50 Hz 量級推理有開銷而電機伺服需要 200 Hz 甚至更高。中間用 decimation抽稀控制環(huán)每拍都發(fā) PD 指令策略每隔 N 拍才更新一次目標(biāo)。兩次推理之間關(guān)節(jié)仍然跟著上一拍的 q* / dq* 走。2.2 該層項目示例Go2 的 base.yaml 里dt: 0.0055 ms200 Hzdecimation: 4。啟動時拉起三條 LoopFunc 線程線程周期職責(zé)loop_controldt 5 msGetState → StateControllerFSM→ SetCommandloop_rldt × decimation 20 ms組觀測、推理、ComputeOutput結(jié)果推進并發(fā)隊列l(wèi)oop_keyboard50 ms鍵盤人機接口不進實時熱路徑策略線程和伺服線程之間用 tbb::concurrent_queue 解耦推理慢了控制環(huán)仍用上一拍目標(biāo)而不是卡住不發(fā)指令。Forward() 里對模型互斥鎖用 try_lock——正在切換策略文件時直接沿用上一拍 action避免 200 Hz 環(huán)被加載模型堵住。2.3 該層運控邏輯策略輸出的不是原始電流而是歸一化動作。ComputeOutput() 做三件事actions × action_scale 得到相對默認(rèn)姿態(tài)的增量。普通關(guān)節(jié)變成位置目標(biāo) q* default_dof_pos Δq輪足的輪子關(guān)節(jié)走速度目標(biāo)wheel_indices。軟件側(cè)預(yù)計算力矩τ K p ( q ? ? q ) ? K d q ˙ \tau K_p (q^{*} - q) - K_d \dot{q}τKp?(q??q)?Kd?q˙?再按 torque_limits 限幅。真機上Unitree 電機固件會再跑一遍阻抗τ K p ( q ? ? q ) K d ( q ˙ ? ? q ˙ ) τ f f \tau K_p(q^{*} - q) K_d(\dot{q}^{*} - \dot{q}) \tau_{\mathrm{ff}}τKp?(q??q)Kd?(q˙???q˙?)τff?。仿真里沒有電機固件就由 robot_joint_controller::UpdateFunc() 用同一條公式把 effort 寫進 Gazebo。所以仿真和真機都是這條 PD只是執(zhí)行地點不同。起身、趴下不走神經(jīng)網(wǎng)絡(luò)而走 Interpolate()在若干個 5 ms 周期里把當(dāng)前關(guān)節(jié)角線性插到 default_dof_pos剛度用 fixed_kp / fixed_kd比 RL 的 rl_kp / rl_kd 更「站得住」。這是實時層的經(jīng)典手法——大行程用插值精細(xì)運動才交給策略。被動模式更直接kp 0、kd 8、tau 0相當(dāng)于關(guān)節(jié)變阻尼器人可以按倒機器人而不會硬頂。這是實時層的安全態(tài)不經(jīng)過策略。3. 感知決策層3.1 感知決策層職責(zé)這一層回答兩件事——「現(xiàn)在是什么情況」和「下一步做什么」在傳統(tǒng)機器人里這里往往是狀態(tài)估計 規(guī)劃 WBC。強化學(xué)習(xí)部署里對應(yīng)關(guān)系變成感知把 IMU、關(guān)節(jié)、指令、歷史動作拼成策略訓(xùn)練時見過的那些向量observation。決策神經(jīng)網(wǎng)絡(luò) forward 出 action有限狀態(tài)機決定「現(xiàn)在該不該推理、該用哪份策略」。注意這里的「感知」通常不是激光建圖那種環(huán)境感知而是本體感知proprioception。視覺、導(dǎo)航可在以后掛到業(yè)務(wù)層經(jīng) cmd_vel 灌進來。觀測必須和訓(xùn)練嚴(yán)格對齊縮放ang_vel_scale、dof_pos_scale、裁剪clip_obs、歷史幀堆疊缺一項部署就會「看起來在動但不是訓(xùn)練時那樣動」。3.2 該層項目示例ComputeObservation() 按 YAML 里的 observations 列表逐項拼接。Go2 的 himloco 策略菜單是commands, ang_vel, gravity_vec, dof_pos, dof_vel, actions → 一共 45 維。觀測項物理含義人話commands期望 vx, vy, yaw再乘 commands_scale你想讓它往哪走ang_vel機體角速度身體轉(zhuǎn)得有多快gravity_vec重力在機體坐標(biāo)下的方向現(xiàn)在是不是快要歪了dof_pos相對默認(rèn)站姿的關(guān)節(jié)角腿現(xiàn)在收著還是蹬著dof_vel關(guān)節(jié)速度腿甩得有多猛actions上一拍網(wǎng)絡(luò)輸出讓策略有短期記憶himloco 還開了 6 幀歷史observations_history: [0,1,2,3,4,5]由 ObservationBuffer 環(huán)形緩存。網(wǎng)絡(luò)一次看到的不是「這一瞬間」而是最近約 0.12 秒的身體 continuity。這對抑制抖動、估計接觸很有幫助。G1 跳舞則換成另一張列表motion_command參考軌跡的關(guān)節(jié)位置速度 motion_anchor_ori_b軀干相對動作錨點的姿態(tài) 本體狀態(tài)。MotionLoader 按仿真時間軸推進 BVH/CSV 參考運動。同一套 ComputeObservation()換列表就能從「走路」變成「跟動作」。推理后端被收在 InferenceRuntime按文件后綴自動選 libtorch 或 ONNX Runtime。決策層同樣不綁定某一種推理庫。3.3 FSM決策層的「交通指揮」神經(jīng)網(wǎng)絡(luò)不會自己決定「該不該站起來」。項目用通用 FSM每個狀態(tài)實現(xiàn) Enter / Run / Exit / CheckChange。這里用Go2 四態(tài)講一下邏輯進入 RLFSMStateRLLocomotion 的 Enter() 才會 InitRL(“go2/himloco”)讀 config.yaml、加載 himloco.pt、重置觀測。Run() 里調(diào)用 RLControl()從隊列取出策略算出的 q* / dq*填進 RobotCommand 的 kp/kd。FSM 在控制環(huán)頻率下運行推理在更慢的環(huán)決策結(jié)果通過隊列灌進實時層。G1 在同一套 FSM 骨架上多掛了 Charleston、Dance102、Gangnam Style。技能結(jié)束動作播放到 100%會 RequestStateChange 回 locomotion——這是決策層對「任務(wù)做完了」的判斷不是業(yè)務(wù)層彈窗。4. 業(yè)務(wù)應(yīng)用層4.1 業(yè)務(wù)應(yīng)用層職責(zé)業(yè)務(wù)層回答產(chǎn)品問題今天這臺機器人提供哪些能力行走、舞蹈、導(dǎo)航跟隨誰來下指令手柄、鍵盤、ROS 導(dǎo)航棧換任務(wù)要不要重編底層理想情況只換配置和模型文件它允許非實時、允許和人交互但不能直接寫電機寄存器。所有業(yè)務(wù)意圖都要翻譯成「期望速度」或「切換 FSM 狀態(tài)」再交給下面三層。4.2 該層項目示例G1 的業(yè)務(wù)菜單交互業(yè)務(wù)含義決策層加載的配置數(shù)字鍵 1 / RB方向上基礎(chǔ)行走g1/robomimic/locomotion數(shù)字鍵 2Charleston 舞蹈g1/robomimic/charleston播完回行走數(shù)字鍵 3全身跟蹤舞蹈g1/whole_body_tracking/dance_102 動作 CSV數(shù)字鍵 4江南 Styleg1/whole_body_tracking/gangnam_style鍵盤 N導(dǎo)航模式開關(guān)用 /cmd_vel 覆蓋手柄速度Control 結(jié)構(gòu)里的 x / y / yaw 就是業(yè)務(wù)層的「速度點單」。手柄搖桿直接寫入開了 navigation_mode 后ROS 的 geometry_msgs/Twist/cmd_vel覆蓋這三項。于是 Nav2、鍵盤遙控、手柄可以共用同一個 locomotion 策略業(yè)務(wù)層只是換了指令來源。策略文件本身也是業(yè)務(wù)資產(chǎn)policy/機器人/技能/config.yaml 描述觀測清單、動作縮放、Kp/Kd、模型文件名。換一份 pt YAML不必改 C就能在同一臺 G1 上換技能。這是業(yè)務(wù)層和決策層之間最干凈的契約。再往上仿真啟動方式也是業(yè)務(wù)roslaunch rl_sar gazebo.launch rname:go2 或 ./rl_sim_mujoco g1 scene_29dof。用戶選的是「在哪演、演哪臺機器人」。4.3 多機型是業(yè)務(wù)層的「產(chǎn)品矩陣」README 里的支持列表A1、Go2、Go2W、G1、Lite3、L4W4、D1…看起來像硬件表從分層看其實是每種機器人注冊一個 FSMFactoryREGISTER_FSM_FACTORY啟動時按 robot_name 自動 CreateFSM。業(yè)務(wù)上「再支持一臺新機器人」的標(biāo)準(zhǔn)路徑是HAL實現(xiàn)該機型的 GetState / SetCommand實時層核對 dt、fixed_kp/kd、力矩限幅決策層補一份與訓(xùn)練對齊的 config.yaml業(yè)務(wù)層注冊 FSM 狀態(tài)至少 Passive / GetUp / Locomotion下面三層穩(wěn)定后產(chǎn)品經(jīng)理口中的「新技能」往往只發(fā)生在第 4 步。5. 把四層串成一個控制拍下面用 Go2 真機、已經(jīng)站起來、正在搖桿前進為例看 20 ms 里數(shù)據(jù)怎么走。6. 分層帶來的三條工程好處仿真和真機共用決策。 RL 基類里的觀測、推理、FSM、輸出縮放仿真與真機各寫一份 HAL 即可。訓(xùn)練–仿真–真機之間最容易弄錯的是「觀測定義」和「關(guān)節(jié)順序」它們被顯式寫在 YAML 里而不是散落在 #ifdef。故障被關(guān)在該關(guān)的層。 姿態(tài)保護、力矩限幅屬于實時層即使策略輸出離譜也可以先趴下或限幅。業(yè)務(wù)層按錯鍵最多切到 Passive不會直接改 CRC 或 UDP 緩沖區(qū)。時間尺度分開。 鍵盤 20 Hz、策略 50 Hz、伺服 200 Hz。若把推理塞進 5 ms 環(huán)模型稍一變大就會丟拍若把 PD 降到 50 Hz落地沖擊會明顯變差。四足和人形在這套分層里的差別主要是 HAL 的關(guān)節(jié)數(shù)量、實時層的增益表以及業(yè)務(wù)層掛了幾個技能狀態(tài)。G1 有 29 個自由度、能跳舞Go2 是 12 關(guān)節(jié) locomotion——對上面兩層來說都只是「另一份 YAML 和另一張 FSM 表」。分層不是為了把代碼寫得好看而是為了讓「換硬件、換頻率、換策略、換產(chǎn)品功能」四件事不要纏在一起。rl_sar 用 RobotState 這一窄接口、兩條時間環(huán)、一份可配置觀測、以及可注冊的 FSM把這件事做得很具體。把這四層看清再去讀 rl_sdk.cpp 和任意一個 rl_real_*.cpp在整體邏輯的把握上會清楚很多。