做過多旋翼飛控開發(fā)的朋友大概率都有過這種經(jīng)歷在Gazebo里把PID參數(shù)調(diào)得漂漂亮亮飛機懸停穩(wěn)得像釘在地上信心滿滿地換到真機結(jié)果剛解鎖推油門機身就開始高頻哆嗦嚴重的時候直接原地翻跟頭。問題出在哪里SITL軟件在環(huán)仿真里PX4固件跑在x86處理器上傳感器數(shù)據(jù)由仿真器以近乎理想的方式喂進來調(diào)度時序、總線讀取、中斷優(yōu)先級統(tǒng)統(tǒng)和真實飛控無關。于是你根本分不清是控制器參數(shù)不對、傳感器噪聲太大還是電調(diào)響應跟不上。硬件在環(huán)仿真HIL就是為這個場景準備的——把真實飛控板接進仿真回路用仿真世界的傳感器數(shù)據(jù)喂給它再把它的控制輸出送回仿真世界讓整條鏈路的實時性、時序和采集噪聲暴露在正式試飛之前。這篇文章我完整梳理一遍Simulink與PX4硬件在環(huán)仿真的實現(xiàn)路徑覆蓋PX4端HITL模式配置、Simulink端動力學模型與MAVLink消息收發(fā)搭建、聯(lián)調(diào)排錯要點以及這套平臺能擴展的故障注入和自動化測試方法給正在從純仿真邁向真機驗證的開發(fā)者一條可以直接走通的路線。1. 為什么SITL出不了問題卻在真機上翻車HIL到底補上了哪一環(huán)1.1 純軟件仿真與硬件在環(huán)的本質(zhì)差異先把這個概念掰開。SITLSoftware-in-the-Loop里面PX4是作為Linux/x86原生的進程跑在電腦上的物理飛控板完全不存在。傳感器驅(qū)動、I2C/SPI總線、中斷處理都被模擬器數(shù)據(jù)替代或者干脆繞過了。這意味著飛控自身對時間的感知是理想化的——任務調(diào)度器不會因為總線等待而阻塞EKF拿到的傳感器數(shù)據(jù)沒有真實采樣過程中的時序抖動控制輸出經(jīng)過網(wǎng)絡回到仿真器時也沒有額外延遲。HITLHardware-in-the-Loop則把PX4原樣編譯進真實飛控板比如Pixhawk 4或者Holybro Pixhawk 6X。板子上的ARM處理器、任務調(diào)度器、中斷機制全部真實運行只是傳感器數(shù)據(jù)來源從真實IMU/GPS換成了MAVLink注入的仿真數(shù)據(jù)。這個區(qū)別非常關鍵你驗證的不只是控制算法還包括固件在真實硬件上的調(diào)度行為、傳感器數(shù)據(jù)被EKF接收后的實際表現(xiàn)、MAVLink鏈路的通信質(zhì)量。我見過不少開發(fā)者在SITL里完成了整套姿態(tài)控制驗證上真機后第一次起飛就碰到EKF告警、position漂移甚至電機振蕩。這些問題的根子大多不是控制律算錯了而是SITL環(huán)境下傳感器數(shù)據(jù)的理想程度遠高于真機飛控里很多針對異常數(shù)據(jù)的安全邏輯根本沒有觸發(fā)。HIL的價值就是把這些藏在時序和噪聲里的問題提前暴露出來而且不需要承擔炸機風險。1.2 在HIL閉環(huán)里Simulink到底扮演什么角色很多人第一次接觸HIL時會搞混Simulink和PX4的職責。在SimulinkPX4的硬件在環(huán)架構(gòu)里PX4是主飛控跑在真實硬件上負責姿態(tài)估計、控制解算、混控輸出。Simulink不是用來當控制器的而是扮演虛擬環(huán)境被控對象傳感器這三個角色接收PX4發(fā)出的執(zhí)行器指令解算飛行器剛體動力學再把計算出的姿態(tài)、角速度、位置、氣壓、GPS信號編碼成MAVLink消息重新喂給PX4。這個回路和真機飛行的數(shù)據(jù)流是嚴格對應的。真機上IMU和GPS提供測量PX4內(nèi)部EKF融合后得到狀態(tài)估計控制器輸出電機轉(zhuǎn)速指令在HIL里Simulink模型相當于一個可編程的物理世界PX4感覺自己在飛實際上是在飛一個數(shù)學方程描述的虛擬機體。如果你想讓Simulink做外環(huán)控制器、PX4只做底層的姿態(tài)穩(wěn)定和電機輸出那架構(gòu)上就是另一回事了——那叫控制器快速原型數(shù)據(jù)流方向和控制權限分配都不同。為了不混淆這篇文章全程假設PX4是主控Simulink是虛擬被控對象這也是HIL仿真的經(jīng)典定義。2. 三種落地路線對比直連HIL、FMU模型交換還是嵌入式代碼集成2.1 路線AMAVLink HIL消息直連最正統(tǒng)的硬件在環(huán)PX4固件原生支持HITL模式。開啟后飛控內(nèi)部的傳感器模塊不再從I2C/SPI總線讀取真實IMU而是等待MAVLink的HIL_SENSOR消息注入imu、氣壓計、GPS等uORB主題的數(shù)據(jù)源全部切到虛擬通道。PX4解算出的控制量也不會輸出到電調(diào)而是通過HIL_ACTUATOR_CONTROLS消息發(fā)回仿真器。這條路線對固件的侵入最小不需要改一行PX4代碼只需要Simulink端按照MAVLink協(xié)議編解碼消息完成執(zhí)行器指令到傳感器數(shù)據(jù)的換算。這也是我最終選定的方案因為它保留了完整的PX4原生安全邏輯、Mag校準流程和EKF故障保護機制跟你將來跑真機時使用的固件完全一致。2.2 路線BFMU導出與聯(lián)合仿真更適合算法階段驗證FMI/FMU標準最近幾年在飛控圈子越來越常見?？梢园裇imulink控制模型導出成FMU也可以把PX4的SITL固件封裝成FMU供Simulink調(diào)用。這種方式的優(yōu)點是省去手動編寫MAVLink收發(fā)邏輯Simulink和PX4通過標準接口交互變量開發(fā)速度快很多。但FMU方式有個繞不開的缺陷導出的PX4模型本質(zhì)上還是跑在x86處理器上硬件時序、中斷優(yōu)先級這些真實感全丟了。它更適合在SITL階段快速嘗試控制算法、做早期參數(shù)掃掠不適合做上真機前最后一道驗證。如果你的目標是驗證控制律本身而不是驗證飛控硬件和軟件鏈路選這條路線效率更高。我自己會在HIL之前先通過FMU把外環(huán)控制器的結(jié)構(gòu)和參數(shù)空間縮小避免一上來就在HIL環(huán)境下漫無目的地調(diào)參。2.3 路線C模型代碼生成后嵌入PX4嚴格說不是HIL但常見另一種常見做法是用Simulink設計控制器通過Embedded Coder生成C代碼然后以自定義模塊的形式集成到PX4固件中替換掉原有的控制律模塊。這種方式的最終形態(tài)是模型驅(qū)動的嵌入式開發(fā)在產(chǎn)品階段價值很大因為它把開發(fā)和部署統(tǒng)一到了同一條工具鏈上。但在HIL仿真的語境里這條路線的定位有些尷尬。代碼集成后你測試的是融合了自定義控制器的PX4在硬件上的表現(xiàn)沒法把固件原版控制器當作基準來對照排查問題時固件、模型、硬件之間的問題會互相糾纏。如果你要做HIL是為了驗證PX4整體的魯棒性建議不要選路線C如果你本來就要交付一個產(chǎn)品化控制器那路線C值得認真考慮。2.4 選型建議對比表對比維度路線AMAVLink直連HIL路線BFMU聯(lián)合仿真路線C代碼集成對PX4固件的修改無需修改無但模型非真機態(tài)需集成自定義控制器硬件時序真實性完整保留基本丟失完整保留傳感器鏈路驗證精準弱取決于集成方式開發(fā)工作量中高需碼MAVLink低高適用場景上真機前最關鍵驗證控制算法探索產(chǎn)品化控制器落地我的建議很明確如果你目標是驗證PX4與真實硬件的可靠性選A如果你還在早期摸索控制架構(gòu)選B如果你本來就要做產(chǎn)品級嵌入式控制器交付選C。3. PX4一側(cè)的HITL模式準備固件、參數(shù)和傳感器靜默3.1 固件版本與SYS_HITL參數(shù)開啟PX4官方對HITL的支持在1.13及之后的版本都比較穩(wěn)定推薦直接選當前官方主線的穩(wěn)定release版本避免用太老的1.9、1.10。固件用標準版即可不需要做任何編譯期的特殊配置HITL是一個運行時功能。開啟方法很簡單用Micro USB連上飛控和QGroundControl在參數(shù)列表里搜索 SYS_HITL把值從0改成1然后重啟飛控。QGC新版界面里右上角也有模擬模式入口選擇Hardware In The Loop后會自動引導你設置對應參數(shù)。設置完重啟后通過MAVLink Console輸入param show SYS_HITL如果輸出是1說明HITL模式已經(jīng)啟用。這時飛控會打印類似waiting for HIL sensor data的提示說明它已經(jīng)準備好接收仿真器數(shù)據(jù)。3.2 HITL模式下EKF的準備與傳感器靜默這里有個很多人忽視的細節(jié)HITL模式下真實傳感器數(shù)據(jù)源雖然被切走了但EKF的初始化和校準流程并沒有被豁免。第一次接上QGC進入HITL后我強烈建議老老實實做一遍加速度計、陀螺儀、磁力計的標準校準以及水平校準。雖然這些校準在HITL中不會真正影響傳感器讀數(shù)但它會初始化EKF里的初始偏置估計跳過這一步EKF狀態(tài)在啟動后很容易因為初始偏置異常而長時間處于不健康狀態(tài)。磁力計校準要特別小心。電腦、調(diào)試器、電源線在地面測試時都會產(chǎn)生磁場干擾如果仿真?zhèn)鞲衅髂Ｐ徒o的是一個固定磁場方向的簡單向量校準過程會變得很奇怪——讀數(shù)一直不變或者緩慢漂移。我的做法是先不啟用磁力計主導的航向估計把EKF2_AID_MASK里的磁力計輔助項先關掉只保留IMU主導的姿態(tài)估計等HIL鏈路完全穩(wěn)定后再打開磁力計項。EKF2_AID_MASK的值按PX4文檔配置即可。如果只做姿態(tài)控制可以暫時去掉GPS輔助減少對HIL_GPS消息的依賴如果要做位置控制GPS的輔助功能必須保留并且要確保HIL_GPS消息質(zhì)量足夠高。3.3 通信鏈路設計串口波特率與消息通道HIL模式下Simulink和飛控之間的數(shù)據(jù)交換鏈路是整個系統(tǒng)最容易出問題的地方。常見方案是串口直連和UDP網(wǎng)絡連接兩種。如果走串口TELEM2口是最常用的HIL串口波特率必須設成921600不能沿用默認的115200。為什么HIL_SENSOR消息大約70到80字節(jié)以250Hz發(fā)送每秒的數(shù)據(jù)量接近20KB。115200波特率的有效數(shù)據(jù)吞吐率只有約11.5KB每秒連理論值都喂不滿921600才有足夠余量。我第一次跑HIL時就因為手里只有115200的USB-TTL模塊眼睜睜看著PX4報傳感器超時換了高波特率模塊后立刻恢復正常。如果走UDP飛控需要掛一個能接入網(wǎng)絡的模塊比如通過UART連接的WiFi模塊或者直接把飛控USB連到電腦通過MAVLink over UDP轉(zhuǎn)發(fā)。UDP的好處是帶寬大、不容易因為字節(jié)粒度的阻塞丟幀而且Simulink天然支持UDP收發(fā)代碼寫起來比串口簡單。缺點是網(wǎng)絡棧本身會引入抖動同時你必須先確定防火墻沒有攔截飛控與電腦之間的UDP包——這個坑我踩過排查了半天才發(fā)現(xiàn)是Windows防火墻把MAVLink端口擋了Simulink的發(fā)送模塊壓根沒收到飛控的任何回包。4. Simulink端動力學模型與MAVLink收發(fā)實現(xiàn)4.1 模型頂層結(jié)構(gòu)從執(zhí)行器輸出到傳感器數(shù)據(jù)Simulink模型的頂層可以做得很規(guī)整核心鏈路就一條UDP/串口接收MAVLink消息解出HIL_ACTUATOR_CONTROLS里的執(zhí)行器指令送入飛行器動力學模型算完狀態(tài)后再經(jīng)過傳感器模型生成陀螺、加速度計、磁力計、氣壓、GPS數(shù)據(jù)最后通過MAVLink編碼發(fā)回PX4。我推薦用Aerospace Blockset里的6DoFQuaternion剛體動力學模塊作為機體模型。它的輸入是三軸力矩和總拉力輸出是位置、速度、姿態(tài)四元數(shù)和角速度。關鍵在于怎么把PX4輸出的HIL_ACTUATOR_CONTROLS換算成力和力矩。HIL_ACTUATOR_CONTROLS里前四個控制值分別對應橫滾、俯仰、偏航、油門取值范圍在-1到1附近。對多旋翼而言這四個值經(jīng)過PX4的混控器語義對應到執(zhí)行機構(gòu)后需要等比例映射到推力系數(shù)和力矩系數(shù)上。我通常的做法是油門通道映射到總拉力基值注意要把重力配平的靜推力考慮進去懸停時的油門通常對應約1g的重力加速度補償橫滾和俯仰通道映射到繞機體X/Y軸的力矩縮放系數(shù)參考電機的力臂長度和推力系數(shù)估算偏航通道映射到繞機體Z軸的反扭矩差。這個映射不需要一開始就特別精確因為你是閉環(huán)仿真PX4的姿態(tài)控制器會主動修正靜差。但如果模型偏得太離譜——比如把拉力方向搞反了或者把橫滾和俯仰弄混了——飛控再怎么調(diào)也無法收斂這類低級錯誤往往也是新手最容易踩的坑。4.2 必須打通的六條核心MAVLink消息HIL鏈路的核心是MAVLink消息以下是必須打通的六類消息以及我實際使用的頻率和字段要點消息名消息ID方向頻率建議關鍵字段說明HIL_SENSOR107Simulink - PX4250Hz陀螺、加速度、磁力、氣壓、空速、temperature、fields_updatedHIL_GPS113Simulink - PX450Hz經(jīng)緯度、高度、速度分量、fix_type、satellites_visibleHIL_RC_INPUTS_RAW92Simulink - PX450Hz遠程遙控通道值PWM數(shù)值解鎖時需要有效RC信號SYSTEM_TIME2Simulink - PX41Hz對齊PX4的time_boot_ms確保時間基準一致HIL_ACTUATOR_CONTROLS93PX4 - Simulink250Hz執(zhí)行機構(gòu)控制量前4個是橫滾/俯仰/偏航/油門HIL_STATE_QUATERNION115PX4 - Simulink50HzPX4內(nèi)部狀態(tài)估計回傳用于監(jiān)控和對比編解碼MAVLink最省力的方式是用現(xiàn)成的mavlink C庫通過Simulink的Legacy Code Tool包裝成S-Function調(diào)用。如果為了快速驗證也可以在MATLAB Function里手寫字節(jié)拼包但一定要小心MAVLink的CRC校驗和字節(jié)序——MAVLink 1使用X.25 CRCMAVLink 2還有額外的校驗字節(jié)一旦CRC對不上PX4會靜默丟棄不會給你任何報錯。第一次聯(lián)調(diào)時我建議先用Wireshark或者tcpdump抓包確認Simulink發(fā)出去的包確實是通過MAVLink協(xié)議編碼的合法幀。4.3 實時性討論外部模式、UDP與調(diào)度抖動Simulink模型在普通Windows/Linux系統(tǒng)上跑本質(zhì)上不是一個硬實時系統(tǒng)。Windows的定時器分辨率在默認情況下大約是15.6ms這意味著如果你直接讓Simulink以250Hz的速率發(fā)送HIL_SENSOR發(fā)送間隔會出現(xiàn)比較大的抖動。PX4的傳感器模塊對數(shù)據(jù)到達間隔有一定容忍度但如果抖動過大或者某段時間內(nèi)完全沒數(shù)據(jù)就會觸發(fā)傳感器超時。幾種緩解方案按效果排序Simulink模型使用定步長離散求解器步長建議1ms然后用Rate Transition塊把傳感器數(shù)據(jù)降采樣到250Hz發(fā)送使用UDP發(fā)送而非串口UDP自帶緩沖允許短時間內(nèi)的小抖動不丟包不要在這個場景里依賴Simulink外部模式來實時調(diào)參。外部模式本質(zhì)上是宿主機和目標機的通信鏈路它本身會增加額外的調(diào)度開銷和延遲。如果模型就是HIL的數(shù)據(jù)源外部模式會讓抖動問題雪上加霜。更好的做法是讓模型通過UDP周期輸出狀態(tài)日志用Simulink Dashboard或MATLAB Analysis離線分析如果要做嚴格的真實時HIL應該把Simulink模型生成C代碼后部署到帶實時擴展的工控機比如Speedgoat或者裝PREEMPT_RT補丁的Linux機器。我自己在非實時系統(tǒng)上跑HIL的經(jīng)驗是250Hz的HIL_SENSOR配合1ms的模型步長在普通Ubuntu 22.04主機上發(fā)送間隔的標準差可以控制在0.5ms以內(nèi)這對PX4驗證來說已經(jīng)足夠。再低頻率——比如降到200Hz——就需要調(diào)低PX4的IMU預測頻率否則EKF會因為數(shù)據(jù)稀疏而表現(xiàn)變差。5. 聯(lián)調(diào)實錄從連不上到解鎖起飛遇到的四個坎5.1 坎一PX4一直在報傳感器超時無法進入預飛行現(xiàn)象QGC面板一片紅報PREFLIGHT FAIL: SENSORMAVLink Console里連續(xù)輸出sensor missing。這次排錯花了大半天。排查鏈路是這樣的先確認SYS_HITL1并重啟沒問題然后確認Simulink確實在發(fā)HIL_SENSOR用tcpdump抓包看UDP端口能抓到107號消息但內(nèi)容是否合法不確定再檢查飛控側(cè)發(fā)現(xiàn)飛控壓根沒收到任何消息。最終定位到兩個疊加的問題。第一個是Windows防火墻攔截了同一網(wǎng)段下的UDP通信Simulink發(fā)包沒有報錯但數(shù)據(jù)根本沒離開本機網(wǎng)卡第二個是MAVLink的sysid/compid沒配對Simulink發(fā)出去的包系統(tǒng)ID是255而飛控配置里MAV_SYS_ID是1PX4對這種來源的消息直接不予理睬。經(jīng)驗聯(lián)調(diào)的第一步永遠是讓兩個端點之間有一個能互相確認消息的中間視圖。先用QGC的MAVLink Console確認飛控能收到HEARTBEAT以外的任何MAVLink消息再用抓包軟件確認Simulink發(fā)出去的消息內(nèi)容兩端對上了再談控制。5.2 坎二EKF狀態(tài)不健康解鎖被拒現(xiàn)象能連上飛控消息也在跑但QGC姿態(tài)儀表盤總有一半是紅的解鎖鍵點了沒反應或者解鎖后幾秒鐘自動跳回HOLD。查了EKF2的狀態(tài)日志發(fā)現(xiàn)加速度計和磁力計的innovation值特別大。原因是仿真器發(fā)過來的傳感器數(shù)據(jù)沒有加噪聲也沒有合理的初始偏置——EKF拿到這種過于干凈的數(shù)據(jù)反而不容易收斂因為真實世界里任何傳感器都有噪聲和偏置EKF依賴這些統(tǒng)計特性去估計狀態(tài)。解決方法是給傳感器模型加入合適的噪聲模型。我在模型里為陀螺加了約0.003度每秒每根號赫茲的白噪聲和常值偏置加速度計加了約0.05米每二次方秒的噪聲磁力計加了中等強度的白噪聲。加完噪聲后EKF立刻進入normal狀態(tài)。另外如果一直不執(zhí)行QGC的校準向?qū)Р襟EEKF在啟動后長時間停留在unhealthy狀態(tài)。即使傳感器數(shù)據(jù)來自仿真器也不要跳過這個初始化步驟。5.3 坎三時間戳不同步導致數(shù)據(jù)被丟棄現(xiàn)象MAVLink消息計數(shù)在漲狀態(tài)估計器卻一動不動日志里頻繁出現(xiàn)timestamp error。原因很隱蔽。HIL_SENSOR消息里的time_usec字段是微秒級時間戳PX4會用這個時間戳做數(shù)據(jù)時序處理。我的Simulink模型一開始直接用電腦的系統(tǒng)時間填入但這個時間和飛控上電后的time_boot_ms基準差了很遠PX4判定時間戳不連續(xù)把大多數(shù)消息當成無效數(shù)據(jù)丟掉。解決方法是Simulink端發(fā)一條SYSTEM_TIME消息給PX4把基準時間對齊。更穩(wěn)妥的做法是模型啟動時先讀取飛控返回的HEARTBEAT消息里的time_boot_ms字段以此為基準計算自己的相對時間再填入HIL_SENSOR。這樣一來Simulink和PX4的時鐘在同一個參考系下PX4不會再因為時間戳跳變丟棄數(shù)據(jù)。5.4 坎四控制頻率和模型步長的匹配現(xiàn)象解鎖成功后飛機懸停出現(xiàn)明顯的高頻抖動頻率大概十幾赫茲和電機轉(zhuǎn)速并不相同。排查后發(fā)現(xiàn)是模型步長和HIL_SENSOR發(fā)送頻率不匹配。我最初把Simulink主步長設成了5ms200Hz然后以200Hz發(fā)送HIL_SENSORPX4的IMU控制循環(huán)默認是250Hz拿到的傳感器數(shù)據(jù)更新率低于自身控制頻率EKF和控制器的相位裕度受到嚴重影響。把模型主步長降到1ms1000Hz用Rate Transition塊把HIL_SENSOR的發(fā)送頻率鎖定在250Hz后抖動基本消失。之后我又嘗試把發(fā)送頻率提到400Hz效果更平滑但串口鏈路已經(jīng)開始接近帶寬上限所以如果沒有特別需要250Hz是一個性價比最高的選擇。6. 在HIL平臺上還能做什么故障注入、測試自動化與跨領域延伸6.1 常見故障注入HIL平臺最大的優(yōu)勢是你可以隨意制造事端這是真機測試沒法做到的。實操中值得做的故障注入類型包括GPS斷鏈突然停止發(fā)送HIL_GPS消息觀察PX4從定位模式回退到姿態(tài)模式的邏輯是否正常位置估計是否漂移切換時間是否符合預期磁力計干擾在Simulink里給磁力計數(shù)據(jù)加上一個階躍性偏置模擬飛控附近突然出現(xiàn)強磁場源觀察EKF航向估計的漂移和恢復過程單電機飽和把某個執(zhí)行器輸出手動限幅模擬真實情況下電機堵轉(zhuǎn)或電調(diào)損壞看PX4的混控補償機制如何處理傳感器噪聲放大把陀螺儀白噪聲方差臨時放大5倍模擬高溫振動環(huán)境下IMU性能下降驗證姿態(tài)控制在傳感器質(zhì)量惡化時的魯棒性。每一類故障注入都應該和真機試飛的測試場景對應起來跑HIL不是圖新鮮而是為了在零風險條件下積累飛控對不同故障的響應數(shù)據(jù)。把故障注入的時機和結(jié)果記錄成時間線后續(xù)對比真機表現(xiàn)時會很有價值。6.2 從手調(diào)到自動掃參HIL環(huán)境沒有炸機風險非常適合自動化參數(shù)掃掠。我的做法是用一個MATLAB腳本驅(qū)動Simulink模型上一輪跑完后通過MAVLink PARAM_SET命令寫一組新的PID參數(shù)到PX4等EKF重新健康后再次解鎖并執(zhí)行標準試飛動作。重復這個循環(huán)就能在一個下午內(nèi)測試十幾組參數(shù)組合。要注意自動掃參時必須把起飛位置、起飛準備時間、任務動作序列完全固定否則仿真結(jié)果之間的差異無法歸因于參數(shù)變化。日志方面Simulink記錄的時間序列需要和PX4的ULog按時間戳對齊我一般用MAVLink的SYSTEM_TIME和HIL_STATE_QUATERNION作為對齊錨點兩邊時間戳完全一致時才認為該輪數(shù)據(jù)有效。Simulink的UDP收發(fā)天然適合這種自動化模式。腳本控制Simulink模型的啟動和停止通過MATLAB API讀取模型里的記錄模塊數(shù)據(jù)再結(jié)合PX4的ULog做對比分析。整個過程無需人工干預效率比手動操作QGC高一個數(shù)量級。6.3 車輛HIL、轉(zhuǎn)向臺架與Simulink生態(tài)的共性這套HIL模式Simulink模型MAVLink/總線消息注入的方法論在很多其他行業(yè)都能看到同構(gòu)實現(xiàn)。汽車轉(zhuǎn)向臺架HIL就是一個典型例子真實ECU或域控制器通過CAN總線連接到負載模擬器和轉(zhuǎn)向機器人Simulink配合CarSim或AMEsim解算整車動力學再把方向盤扭矩、車速、輪速等信息轉(zhuǎn)換成傳感器信號喂給控制器。它的架構(gòu)和PX4的HIL完全是一個套路只是MAVLink換成了CAN/以太網(wǎng)無人機動力學換成了整車模型。如果你之后從飛控轉(zhuǎn)向域控制器、VCU或者底盤HIL方法論是高度可遷移的Simulink既可以是被控對象仿真器也可以作為測試管理器負責場景編排、數(shù)據(jù)回灌和自動判據(jù)。搜到的很多關于VCU控制策略Simulink建模、CAN報文故障診斷Simulink、CANoe聯(lián)合仿真的工作本質(zhì)上都在復用這一套信號級仿真與故障注入的思想。我現(xiàn)在養(yǎng)成的習慣是任何一次在SITL里優(yōu)化過的控制器參數(shù)在提交真機試飛前都會先跑一遍HIL至少讓它完成起飛、懸停、位置控制、降落整套動作并且刻意在中間注入一兩個故障看飛控怎么處理。很多問題不是算法本身而是隱藏在鏈路里的時序和數(shù)據(jù)質(zhì)量問題只有把真實硬件挪進回路這些問題才會現(xiàn)形。這套SimulinkPX4的HIL鏈路給了我極大的安全感也希望這篇文章能幫你少走幾個我走過的彎路。