1. 项目定位这套模拟器到底在模拟什么半实物仿真这四个字在飞控研发和航空试验圈子里不算新词。但把半实物仿真、实时仿真、运动飞行模拟器三件事压进同一个项目里做出一套既能给飞控算法做闭环验证、又能给飞行员提供真实运动感受的设备这件事依然是很多团队容易踩坑的地方。我这次要分享的就是自己在搭建这样一套系统时的完整思路、选型逻辑和实际操作记录。先说清楚这套东西是什么。简单讲就是把真实的飞行控制计算机飞控板、舵机、驾驶舱操纵机构这些硬件和以飞行器数学模型为核心的软件模型放进同一个闭环里实时运行。飞机本体用数学模型替代但飞控、作动器、传感器接口、甚至运动平台都是实物。这样一来你在实验室里就能让真实的飞控去“驾驶”一架虚拟飞机感受它飞上天、失速、盘旋、撞上风切变之后的表现而不需要真的放飞一架飞机。它能解决的核心问题很直接空域和场地的限制不存在了测试的可重复性和故障注入能力都大幅提升。你可以让同一套飞控在这个闭环里跑一百次同样的机动也可以在极限迎角、传感器失效、舵面卡死这些离线仿真里容易建模、却很难真实发生的故障条件下观察硬件飞控的真实响应。适合谁看如果你是飞控工程师、半实物仿真平台的搭建者、实验室里带学生做飞行模拟课题的老师或者想验证自己开源飞控算法但没有条件外场试飞的人这篇文章应该能帮你省下至少一个月的摸索时间。1.1 “半实物”到底“半”在哪里“半实物仿真”这个名字经常让人误解以为系统只有一半是完整的。实际上它不是“残缺的一半”而是“实物与虚拟模型各占一半”的组合仿真英文叫硬件在环Hardware-in-the-LoopHIL。在我这个项目里实物侧包括飞行控制计算机、舵机及其驱动、操纵杆与脚踏、六自由度运动平台、座舱显示设备。模型侧包括飞机六自由度运动方程、气动力与力矩模型、发动机模型、起落架模型、大气与风场模型、传感器模型。两侧通过IO接口和实时通讯协议连成一个小时不碎的闭环。为什么“半实物”有价值因为纯数学仿真里飞控硬件本身是被等效的控制律在Matlab里跑得通不代表烧进真实单片机里跑得对。真实的芯片会有传感器噪声、ADC量化误差、指令刷新周期、中断延迟、通信丢包这些东西在纯仿真里你用传递函数和噪声源模拟很难完全还原。半实物仿真把飞控硬件放进回路等于让控制律和它的“肉体”一起检验。另一层原因是安全。外场试飞有坠机风险有些边界状态根本不敢真正去飞。半实物仿真里你尽管给一个持续失速的指令让飞控自己判断怎么改出哪怕模型跑到倒飞都没事模型反正不会真的摔。1.2 为什么“实时”两个字不能随便喊实时仿真和普通仿真最大的区别不在速度在确定性。普通离线仿真同样一个飞行过程电脑感兴趣跑三分钟就算完它今天算出一个结果明天再算步长可能被优化器自适应地调大调小。这对分析单次飞行曲线没有影响。但半实物仿真不行因为一端的飞控是真实时间运行的它按自己的时钟接收传感器数据、输出控制信号。模型侧必须在固定步长内完成计算并输出结果比如主仿真周期1毫秒那么每一毫秒都要算完当前帧迟了哪怕一微秒飞控就会觉得传感器数据“卡了”控制动作就会异常。我用一个生活类比解释离线仿真就像录乐队排练你录音的时候可以单独补录某一段反正最后剪到一起就行实时仿真就像现场演出每个乐手都必须跟着同一个节拍器走鼓手如果晚半拍整个队就散了。所以“实时”在工程上判定标准不是“算得快”而是“每个节拍都准点完成”。我们在项目里定的硬指标是飞行力学主回路步长1毫秒洗出滤波与运动平台指令回路步长2毫秒传感器仿真信号更新周期10毫秒总链路延迟从飞行员操作到运动平台动作控制在100毫秒以内。这几个数字不是拍脑袋定的后面会具体解释为什么。1.3 运动飞行模拟器在回路里的真实角色如果只是一台飞控验证台不需要运动平台。但要做成“运动飞行模拟器”平台就不是摆设了。运动平台在闭环里的价值是给飞行员提供真实的惯性力感。人坐在模拟器里身体的感受主要来自前庭系统和本体感觉。一个横滚动作如果只有视景发生旋转而身体没有跟着倾斜大脑马上会产生冲突轻则感觉“假”重则几十秒后就晕。加装六自由度运动平台后飞行的俯仰、滚转、偏航和过载变化可以通过平台的位移和姿态变化来模拟让飞行员产生接近真实的运动感知。它同时也是一个测试载体。通过平台产生的不同频率、幅值运动可以评价半实物仿真系统中飞控的鲁棒性比如模拟机体在一定频率下的振动、模态耦合观察飞控反馈是否出现异常振荡。这一层对工程机型的验证很有价值。2. 系统架构与关键器件选型五层闭环怎么搭整套系统我习惯分成五层来理解人机层、运动层、物理层、实时层、模型层。这五层不是简单的几个盒子摞在一起它们之间的信号走向决定了整个系统的质量。2.1 五层架构一层都不少层级典型设备核心职责人机层驾驶舱座椅、操纵杆、油门台、仪表屏、视景显示器接收飞行员操作呈现视觉反馈运动层六自由度Stewart平台、运动控制器、伺服电机执行洗出滤波指令产生运动感觉物理层真实飞控计算机、舵机、信号调理板卡运行真实飞控算法驱动真实作动器实时层实时目标机带IO板卡运行飞机模型、传感器模型、洗出滤波算法模型层PC端Matlab/Simulink开发环境建模、编译、参数监控、曲线分析信号的实际走向是这样的飞行员推动操纵杆杆位移通过模拟量或CAN总线进入物理层的飞控计算机飞控按控制律算出舵机指令驱动真实舵机这个舵机位置又会反馈到实时层实时层中的飞机模型根据舵面偏转、当前飞行状态计算下一时刻的飞机运动再把更新的空速、姿态、位置等信号送回飞控计算机形成飞行闭环。与此同时实时层把飞机的过载和姿态变化送给洗出滤波算法转成平台运动指令经运动控制器输出到伺服电机飞机位置姿态则通过UDP或者共享内存发送给视景渲染引擎生成座舱外景象。飞行员眼睛看到、身体感受到、操作能引起响应整个回路才闭合。在实际搭建时这五层里最容易被忽略的是物理层和实时层之间的信号调理。许多人买了飞控和目标机接上就以为能通结果因为电平不匹配、地线电位差、接口速率不一致导致信号乱跳。这个问题我会在后面的实操和排查部分详细说。2.2 实时目标机的选型经验实时目标机是整个系统的计算核心不能把它当作一台普通的工控机来用。关键差异在于操作系统对任务调度的确定性。我们最早考虑过三个方案Speedgoat、NI PXI、以及基于Simulink Real-Time加普通工控机的自组方案。Speedgoat和NI PXI成熟稳定支持同一套Simulink模型直接部署IO板卡种类多缺点就是贵一套下来动辄几十万。对于预算有限的实验室或初创团队自组方案是更现实的选择。我最终用了Simulink Real-Time协议跑在一台Intel i7处理器、16GB内存的工业PC上配了两块PCIe模拟量采集卡、一块CAN总线卡和一张千兆网卡。Simulink Real-Time的优势是模型从Matlab/Simulink编译下载后直接运行在独立实时内核实时性可靠IO驱动也自带。为了稳定我把电脑的板载无线网卡和蓝牙都拆了BIOS里关闭超线程和节能模式网络中断固定到单独一个CPU核避免Windows后台任务干扰实时循环。这里给一个选型的个人结论如果你团队里有人熟悉Linux实时内核可以自研基于Xenomai或Preempt-RT的方案但开发周期长如果只求快速出结果直接Simulink Real-Time加一台可靠工控机性价比最高。IO数量不大时NI的USB多功能采集卡也能应急但不建议用于长期正式试验。2.3 六自由度运动平台怎么选参数运动平台的选型是另一个容易走弯路的地方。平台不是“行程越大越好”而是必须和你要模拟的飞机动态范围匹配。六自由度运动平台绝大多数采用Stewart并联结构六根电动缸支持动平台实现三个平动和三个转动。并联机构刚度大、承载能力强特别适合周期性高速运动。我们项目里需要的负载包括一名飞行员座椅、驾驶舱结构以及部分线束合计约300公斤。平台主要参数我们是这样定的垂直行程±300毫米、纵向和侧向行程±250毫米滚转和俯仰角度极限±25度、偏航极限±30度最大加速度约0.8倍重力加速度。为什么需要0.8g因为模拟飞机起飞滑跑加速和急滚转时身体感受到的侧向过载如果少于0.3g基本没有体感达到0.8g会让肌肉和张感觉明显动作但又不会触碰到平台行程边界。选型时一个很容易犯的错误是只关注“速度”而忽略“加速度”。运动模拟中真正让人晕的不是某个稳定速度而是加速度突变。平台电机加速响应如果跟不上洗出滤波输出的高频分量整个运动感觉就会发钝、发假。所以在电机额定参数上我刻意选了峰值加速度裕量较高的伺服电机舍弃了一部分最大速度指标实际效果明显更好。3. 核心细节解析模型、接口与洗出滤波算法硬件架构定完之后真正决定这套系统能不能用的是模型精度、接口映射和洗出滤波三个核心环节。它们分别对应物理上的“飞机飞得真不真”“信号传得准不准”“人坐着像不像坐飞机”。3.1 飞行动力学模型的实时化处理飞机模型是整个仿真回路里最重的软件模块。我这次模拟的是一架小型固定翼无人机改的有人驾驶验证平台气动数据来自CFD和风洞实验的合并结果。模型本身不算复杂但“实时化”处理有不少讲究。标准的六自由度刚体方程并不难写包含力方程、力矩方程、以及基于四元数的姿态运动学。为了满足1毫秒步长我们做了三点处理。第一气动力的计算做了预处理。把随马赫数和迎角变化的气动系数表提前生成运行时用二维查表和线性插值而不是在每一步都重新计算复杂的多项式表达式这样可以把计算时间压缩到原来的一半以下。第二积分算法统一采用固定步长四阶Runge-Kutta。变步长求解器在离线仿真里很好用但在实时环境里会造成步长不确定导致每一步计算耗时差异很大飞控侧很难适配。固定步长1毫秒下RK4对这样一架亚声速飞机来说精度完全够短周期振荡频率和长周期模态都能正确复现。第三姿态表示使用四元数作为主状态只在需要输出到视景或运动平台时才转成欧拉角。这样避免了俯仰角接近正负90度时的奇异问题也避免了欧拉角微分方程在高机动状态下的数值漂移。四元数也有它的麻烦就是每几步需要做一次归一化否则长时间运行会积累误差我是每100个周期强制归一化一次。这部分的经验是实时化并不等于把离线模型“照搬”到实时机而是要重新梳理计算顺序把重计算和轻计算错开把固定开销和平滑开销做区分给每一个步骤建立一个“每秒触发一次”的离线任务专门做查表预生成和参数重算。3.2 从飞控实物到实时机的接口映射接口映射是半实物仿真项目里工作量最大、也最枯燥的部分。飞控要正常工作它必须按时收到它认为“真实”的传感器数据比如三轴角速率、三轴线加速度、空速、气压高度、位置坐标等同时它输出的舵机PWM信号或总线控制指令也要被实时机完整接收并转换成模型中的舵面偏转角度。我这次用的飞控是某开源飞控平台的工程板支持对待测的HIL模式。HIL模式下飞控不再读取板上物理IMU而是通过串口或CAN接收来自实时机的传感器仿真数据。这样飞控芯片里的控制律、传感器融合算法、故障检测逻辑全都在真实硬件上运行只是数据来源变成了仿真模型。接口映射表是必须白纸黑字写清楚的文档每一项都要有通道名、信号类型、更新周期、量程、字节序、增益和偏置。比如信号方向信号内容接口类型更新周期实时机 → 飞控三轴角速率CAN0x201帧10ms实时机 → 飞控三轴线加速度CAN0x202帧10ms实时机 → 飞控气压高度CAN0x205帧20ms飞控 → 实时机舵机PWM指令四路PWM输入采集10ms飞控 → 实时机飞控状态/模式串口RS422100ms有一个我踩过的坑是字节序。CAN帧里的数据有Intel小端和Motorola大端两种排列飞控和采集卡如果不一致就会出现“油门一推高度反而往下掉”的诡异现象。排查这种问题别靠猜直接做一个回环测试实时机发一帧已知数值的指令飞控原样返回采集结果比对字节排列就能定位。3.3 洗出滤波算法如何用一个不动的平台“骗”过身体运动平台的行程是有限的但飞机可以持续飞行、持续加速平台的物理行程不可能跟真飞机一样无限延伸。洗出滤波算法就是来解决这个矛盾的它把飞机模型输出的无限行程运动翻译成平台在自己有限行程内能模拟的运动。人对自己身体的运动感知主要来自前庭系统。半规管对旋转角速度敏感耳石器对线加速度敏感。前庭系统有一个特点对低频、持续不变的线加速度感知会逐渐减弱但对角速度和姿态倾斜变化很敏感。洗出滤波利用了这一点用平台的空间位置变化去模拟短促的高频运动用平台慢慢倾斜让重力在身体坐标系里产生一个“分量”来模拟持续的低频线加速度。这就是经典的倾斜协调原理。我们这一版用的是经典洗出滤波三个通道高通滤波通道处理线加速度把飞机模型计算出的纵向、侧向、垂向线加速度中低于阈值的持续分量滤掉只保留高频的、能给身体带来真实冲击感的加速度变化。高通滤波器的截止频率取大概0.8到1.2Hz。高通滤波通道处理角速度让平台的旋转运动快速响应飞机的俯仰、滚转和偏航角速度但超过平台行程的部分会被滤除。角速度高通截止频率取0.5到0.8Hz。低通滤波通道是倾斜协调把滤下来的持续线加速度转化成平台的目标倾斜角度。低通截止频率取0.3到0.5Hz并设置了倾斜速率限制通常每秒不超过15度。如果这个速率限制设得太高飞行员会明显感到平台在“滑走”产生一种与实际飞机不符的奇怪错觉如果设太低则加速感建立得太慢虚拟感觉像鸭子过河。这三个通道的输出合起来再经过平台运动学反解计算出六根电动缸各自的目标长度。最后还要加一个限幅器确保平台任何时刻都不会触碰到机械行程边界。我特别提醒一点洗出滤波的参数不是原理写完就能固定的必须在平台上让真人感受来回调。4. 实操过程四步联调一套可用的运动飞行模拟器下面完整记录我们当时的搭建和联调过程。这部分多数内容来自实际操作现场照着做基本不会走偏。4.1 第一步把实时仿真子系统跑起来实时子系统是整个项目最先动工的部分。先用Simulink搭飞机模型和传感器模型然后把模型用Simulink Real-Time编译生成可在目标机上独立运行的可执行文件。我这里建议使用一个简单的双机架构开发机装Matlab负责编辑模型和查看曲线目标机装实时运行环境只运行编译后的模型不接受任何开发操作。第一次下载模型后不要直接连飞控而是先做开环测试。给飞机模型一个固定的升降舵阶跃看俯仰角速度、迎角、法向过载的响应是否和离线仿真一致。我当时就发现实时机上输出曲线的采样率比离线低导致曲线看起来“抖”其实是示波器模块本身的采样设置问题不是模型问题改查采样保持时间后就正常了。还要检查实时循环实际执行时间。在Simulink Real-Time里直接运行时间监控工具能看到每个仿真步长的执行时间统计。飞行模型加洗出滤波后在1毫秒步长下的平均执行时间大约0.4毫秒最大执行时间不应超过0.9毫秒。如果接近1毫秒先把计算热点优化掉再接其他子系统。4.2 第二步接入飞控实物并打通I/O实时子系统稳定后开始接入真实飞控。先不接舵机用仿真环境里的“舵机模型”代替真实舵机保证飞控输出的PWM信号能通过采集卡转换后进入飞行力学模型。这一步主要是验证信号通路飞控输出的每一路PWM与仿真模型里的舵面映射是否一一对应、极性是否正确。映射验证有一个经典做法让飞控处于手动模式给一个固定的副翼杆量观察实时模型里副翼偏转角和滚转力矩方向是否与操纵一致。方向错了应该立刻会发现滚转角反向增大的现象。这时候别慌大概率不是接线错而是PWM映射表的符号取反在模型中把该通道增益设为负值即可。之后接入真实舵机。注意舵机供电要和信号参考地严格隔离我的仿真机与舵机电源共地导致过一次CAN总线波特率跑飞的故障后来在电源输入侧加了隔离DCDC模块故障消除。4.3 第三步整定洗出滤波并驱动运动平台IO打通后运动平台可以接进回路。先不要让模型真实飞行而是让飞机模型固定在一个悬停或者直线平飞状态手动输入一段已知的加速度波形比如5秒内从0加速到0.5g。观察平台移动是否跟随加速度波形是否存在明显迟滞。然后输入几个典型的飞行动作快速拉起、突然滚转、持续盘旋。观察平台在行程边界附近的表现。如果闻到伺服电机过载报警或看到平台位置接近限位优先调整洗出高通滤波器的截止频率而不是直接减小输入增益。真人测试是必不可少的环节。我当时找了两个熟悉飞行感觉的同事一个坐进座舱一个在旁边记录主观打分。我们反复对比了三组参数高通截止频率分别是0.6Hz、1.0Hz和1.4Hz。结论是1.0Hz那组在“感知真实”和“避免虚假运动”之间最平衡1.4Hz虽然高通动作更猛但会频繁触发平台的限幅和保护整体反而感觉不自然。4.4 第四步接入视景完成人机闭环人机层的最后一块是视景。我们采用的是FlightGear作为渲染引擎它与模型实时机之间用UDP协议通信每秒发送30帧飞机位置、姿态、空速、高度数据。视景机放在另一个普通PC上不做任何实时计算只负责渲染。关键同步点在时间对齐。真实SIM和视景机各有自己的系统时钟如果不做对齐飞机已经滚转10度了视景里还保持上一帧的姿态飞行员会看见“延迟的世界”非常容易晕。解决方案是UDP数据包里包含模型时间戳视景机收到后不是直接显示而是根据当前本地时间与时间戳差值做插值预测补偿50毫秒以内的网络抖动。全部接通后的联调是在自动飞行模式做的。我们给飞控设定一组航点飞控自己控制飞机完成起飞后的平飞转弯。飞行员在驾驶舱观察视景同时感受平台的转向倾斜和速度变化。我们实测的总链路延迟约85毫秒其中运动平台延迟约占30毫秒处于可接受范围。整套系统在这个阶段才真正具备“半实物”的样子。5. 常见问题与排查技巧实录这一节是从项目试运行到正式交付期间踩过的坑很多问题不是看手册能发现的记下来给后来人当参考。5.1 实时任务超时导致飞控“断片”现象是飞控在连续运行几分钟后突然报传感器丢失几毫秒后恢复但每次恢复后都会有一次明显的舵面抖动。排查时发现not实时机的操作系统日志里有一个“overrun”计数在持续增长。原因有两点一是模型里有一处气动系数查表的边界条件在某个特殊迎角范围会触发复杂的线性插值分支计算量比正常路径大二是实时内核所在CPU被板载显卡的中断频繁打断。解决办法是在模型中把该查表改为强制x2插值并固定插值步长将显卡中断屏蔽掉主循环最大执行时间立即降下来。经验是实时系统对环境干扰极其敏感任何非模型计算都可能破坏节拍所以“关掉不必要的中断”这一步必须做扎实。5.2 运动平台在特定频率下的共振运动平台加载后在做某些小幅高频机动时出现明显的嗡嗡声和抖动频率大概在7Hz附近。断开平台直接看洗出滤波输出发现7Hz附近确实有能量峰。我通过平台扫频测试确认这是机械结构的模态频率。解决方向是加一个陷波滤波器专门把7Hz附近的增益压下去保留其他频段。但要注意陷波器会引入相位滞后加在反馈路径上可能引起不稳定所以加在洗出滤波输出端、运动控制器之前并同时做一次相位补偿。这类问题最怕“一刀切”简单加低通滤波把所有高频都滤掉平台是安静了但运动模拟的体感会明显变钝飞行员觉得像坐了艘橡皮艇毫无飞行感。5.3 CAN总线数据错位和偶发跳变联调时遇到过一次很头疼的情况飞控收到的空速数据偶尔会跳变成超大值短时又恢复。检查CAN总线波形没有发现电平异常但偶尔出现CRC校验错的帧。最终定位是CAN总线终端电阻松动。我把节点数量增加后忘了在总线两端各接一个120欧姆终端电阻导致信号反射特定速率下的数据出错。补齐电阻后问题彻底消失。另一个相关经验是CAN总线布线应该采用屏蔽双绞线不与舵机的功率线走同一线槽否则大电流变化会通过电磁耦合“打”在CAN线上。5.4 洗出滤波参数不当导致飞行员产生“爬坡错觉”有一次测试持续平飞加速平台会缓慢地抬头让飞行员觉得自己在一个青云坡上爬但视景里明明平飞。这个感觉正是倾斜协调的副作用为了用重力分量模拟持续前向加速度平台必须缓慢后仰如果抬头速率做得太快前庭系统就会检测到清晰的姿态变化产生“爬坡”错觉。我们把倾斜协调的低通截止频率从0.6Hz降到0.4Hz倾斜速率限制从每秒18度降到每秒8度后飞行员的主观评分从“明显不自然”变成了“基本可接受”。硬要追求完全无错觉很困难关键是让视景和运动相互印证眼睛看到平飞身体慢慢感受到轻微后仰加速感大脑就会选择相信眼睛主观感受会好很多。5.5 问题速查表现象可能原因快速处理实时任务频报超时模型热点计算过重、中断干扰优化模型、关闭非必要中断、核对执行时间平台7Hz共振机械模态被激励加陷波滤波器、降低该频段能量CAN数据偶发跳变终端电阻缺失、线槽干扰补120欧终端电阻、强弱电分离布线持续过载下驾驶有爬坡感倾斜协调参数过激降低低通截止频率、限制倾斜速率视景运动明显落后于平台网络时间未对齐加时间戳、视景侧插值预测飞控收到的传感器噪声大信号调理或接地问题检查参考地、加隔离电源最后分享一点个人体会这套系统从搭框架到完整能够使用前后差不多四个月。回头看的最大感受是硬件买回来只是开始真正占用时间的相机是模型实时化、接口对齐、洗出滤波整定和故障排查每一步都比想象中更有讲究。运动飞行模拟器最神奇的地方在于它把飞行这样一个充满危险、不确定性的物理过程压缩在一个实验室里却还能让坐在里面的人真实地手心出汗。如果只让我说一个落地技巧那一定是联调前花两天做一个“信号快照记录器”把操纵指令、飞控输出、模型状态、洗出滤波输入、平台反馈这几个关键信号统一打上时间戳录成同步文件。没有这个基础出了问题你就只能猜而猜是调试里最贵的浪费时间。装上这个东西之后后面所有故障定位基本都靠它效率提升非常明显。