半实物仿真测试在惯性组合导航中的工程实践与关键问题

1. 为什么半实物仿真测试在惯性组合导航里是绕不开的一环

做惯性组合导航的人，大多经历过这样的场景：算法仿真里精度跑得漂漂亮亮，位置误差曲线圆润得像教科书截图，可一旦把程序烧进真实的导航计算机，接上真实的惯性测量单元，立刻原形毕露——对准时间变长、组合滤波器发散、GNSS信号一切断就找不回北向姿态。问题往往不在导航算法本身，而在你根本没有在一个“真实器件会犯错、接口会抖动、时序会错位”的环境里验证过系统。这就是我坚持在惯性组合导航项目里引入半实物仿真测试的原因：让被测系统直接连真硬件、上转台、收真实射频卫星信号，把软件算法和物理世界放在同一个闭环里跑。

所谓半实物仿真，指的是“空气动力学、车辆运动轨迹、卫星星座这些可以用数学模型代替；但惯性器件、导航计算机、GNSS接收机这些必须用真家伙”的测试方式。和纯数学仿真相比，它多了一个关键的“不理想层”：MEMS陀螺有零偏不稳和白噪声，加速度计有标度因数误差，GNSS接收机会丢帧、会出现多路径，而这些恰恰是组合导航算法真正要面对的东西。和外场路测相比，半实物仿真的优势是场景可控、可重复：同样一条带急弯、加减速、卫星遮挡的航迹，今天跑三遍、明天再跑三遍，结果可以横向对比，且不受天气、场地和交通影响。

这套测试体系特别适合以下几种人：

• 正在做捷联惯导解算和组合滤波器的算法工程师，需要知道算法在真实器件数据上是否收敛；
• 负责把导航模块集成到飞行器或车辆上的嵌入式工程师，需要验证接口时序、数据同步和容错机制；
• 做产品出厂检验和验收测试的测试人员，需要用可复现的仿真场景给系统打分。

我见过太多“算法仿真很优秀、外场试飞翻车”的项目，根源几乎都在中间这片真实器件与仿真环境交界的灰色地带。半实物仿真测试就是专为这片灰色地带设计的，它解决的核心问题不是“算法对不对”，而是“这套软硬组合在一起还能不能保持题目里承诺的精度和可靠性”。

2. 仿真台架怎么搭：转台、GNSS模拟器与实时仿真机的最小组合

半实物仿真测试不是拿一台电脑接上惯导模块就行。一个能真实反映惯性组合导航工作状态的台架，至少包含四个部分：三轴转台、GNSS信号模拟器、实时仿真机、以及负责同步和监控的配套系统。下面按我在实际项目里的搭建经验拆开说。

2.1 三轴转台：姿态激励的来源

惯性组合导航的被测对象是惯性器件，而惯性器件的核心输出是角速度和比力。角速度从哪来？从真实的转动来。所以在半实物仿真台架里，三轴转台是物理姿态激励的唯一来源。

常用转台分内、中、外三个框，分别模拟载体绕自身三个正交轴的转动。选型时重点看两个参数：角位置精度和角速率稳定度。一般测试惯性导航系统，角位置精度至少要达到角分级，也就是优于0.01°；角速率稳定度则决定了低速条件下陀螺标定和零偏测试能不能做。比如你要模拟一个无人机慢转弯，转台以0.5°/s的角速度转动，如果转台自身速率波动达到0.01°/s，那叠加在陀螺输出上的误差就已经可能超过被测器件本身的噪声水平，测试结果就没有意义了。

安装被测件时还要注意一件事：转台三个框的旋转轴必须与被测惯性导航系统的三个敏感轴对齐。实际操作中，会有工装夹具保证这一点，但夹具本身存在加工公差，所以系统联调前要做一次“轴系对齐验证”，方法是在转台单轴转动时观察对应陀螺输出的交轴耦合量，耦合量超过预期就要修正安装角或者做软件补偿。这个细节常被忽略，却直接影响后面所有姿态误差的评估。

2.2 GNSS信号模拟器：卫星导航的可控输入

GNSS信号模拟器的作用是生成射频信号，让真实的GNSS接收机以为自己在某个特定的位置、以特定的速度运动。它要做两件事：一是根据用户设置的航迹解算出卫星星座到接收机的距离变化和多普勒频移；二是把基带信号调制到对应的射频频点上，输出给被测的接收机。

在惯性组合导航半实物仿真里，GNSS模拟器输出的航迹并不是随意设置的，它必须与转台的运动相互吻合。比如模拟器设置载体正在向东以10m/s匀速运动，同时转台却静止不动，那组合导航系统接收到的信息就是自相矛盾的：惯导说“我没动”，卫星说“你在向东跑”。这种情况下系统当然会发散，但发散的原因并不是算法问题，而是测试场景设计错误。

所以台架系统里通常还有一个航迹生成与协调软件，统一管理“载体位置/速度/姿态”这一组真值，然后把位置和速度送给GNSS模拟器，把姿态和角速度送给转台。这种协调是半实物仿真台架的灵魂。高端的台架会将转台和GNSS模拟器通过实时仿真机联动，低成本的方案也可以预先录制时间戳同步的航迹，分别加载到两个设备上，但后者对时钟一致性要求更高，后面第4章我会专门讲时间同步这个坑。

2.3 实时仿真机与监控系统

实时仿真机承担两个任务：运行运动学模型生成载体轨迹，以及作为整个台架的时序中枢。运动学模型可以很简单——直线、转弯、加减速都可以用刚体运动方程描述；也可以很复杂——加入车辆悬架特性、飞机阵风扰动、舰船波浪运动。选实时仿真机时不需要追求性能最强，关键是它的实时调度周期要小于导航解算周期，通常要做到1ms以下，否则整个闭环就会引入额外延迟。

监控系统的作用是记录测试过程中的所有数据：惯性器件原始输出、GNSS接收机输出的PVT信息、组合导航系统的解算结果、转台实际角位置、模拟器的真值航迹。这些数据必须带统一的时间戳，并且要保证日志记录本身不会干扰实时环路的运行。我在台架上使用的方法是独立的监控工控机通过局域网接收各设备主动上报的周期报文，并且让监控记录不影响实时仿真的进程调度。这套数据采集能力在后面做误差分析时至关重要，没有可靠的日志，半实物仿真测试的价值就大打折扣。

2.4 一个最小可行配置的参考

这套最小配置基本能满足大多数惯性组合导航产品的半实物仿真测试需求。如果你的项目只涉及单轴运动或者只需要做算法验证，也可以先不配GNSS模拟器，只用转台加卫星信号模拟器，但那样就测不到“组合”的效果，只能算惯导测试。

3. 一套完整可复跑的测试流程：从对准标定到失锁重收拢

台架搭好之后，真正考验功力的就是测试流程设计。流程设计得好不好，直接决定你测出来的数据是“能说明问题”还是“只能说明系统没炸”。我把在项目里沉淀下来的一套流程写在这里，每个阶段都加了场景设置思路和需要观察的指标，可以直接拿去做测试大纲。

3.1 联调前检查：先花一小时排除低级问题

设备上电之后不要立刻跑场景，先做三件事：转台回零并核对零位；GNSS模拟器输出一个静止航迹，确认接收机能正常定位定速；确认实时仿真机与转台、模拟器的通信报文正常往返。这个阶段最常见的问题是设备间的网络端口冲突和坐标基准不一致。我习惯在联调记录里专门留一页，把每台设备的坐标系定义、单位、参考椭球都写清楚，遇到异常时先检查这一页，能节省大量排查时间。

同步性也要在联调时做一次粗检：给转台发一个阶跃角速度指令，同时让GNSS模拟器输出对应的转弯航迹，观察组合导航系统的输出是否在同一个控制周期内响应。如果观察到明显的阶梯式滞后，先别急着调算法，回头检查同步设置。

3.2 静基座对准与零速测试

测试的第一步永远是静态对准。被测系统安装在转台上，转台锁定零位，GNSS模拟器输出静止航迹，保持几分钟。这一步可以验证几个基础能力：

• 初始对准是否能在规定时间内完成，航向角能否收敛；
• 静止条件下惯导的速度漂移是否在指标范围内；
• 零速更新（ZUPT）是否生效，位置误差曲线是否呈“锯齿状”被周期性修正。

静态测试的数据是后续所有测试的基线。如果静态下速度漂移就已经超差，那就没有必要进行动态测试，先回到底层排查惯性器件和导航解算的问题。

3.3 基准运动：让系统先跟上一个“听话”的航迹

基准运动测试的目的是验证组合导航系统在常规运动下的基本跟踪能力。我通常设置这样一组航迹：

这组航迹跑完，系统应该能保持厘米级的水平位置误差和亚角分级姿态误差。如果在这个阶段出现误差超差，问题大概率出在杆臂补偿或者坐标转换上，而不是更深层的算法问题。

3.4 典型机动激励：把系统逼到“不舒服”的区间

基准运动验证的是正常能力，典型机动激励验证的是系统的边界。这里要针对被测产品的应用场景设计动作：对无人机，我建议加入持续30秒的30°/s快速转弯；对车载系统，加入蛇形变道和急刹车减速；对舰载设备，加入周期性的横摇和纵摇。机动激励的目的是让陀螺和加速度计工作在大动态范围下，检查组合滤波器是否有足够的可观测性来约束误差增长，同时暴露转台速率波动对组合解算的影响。

我在做车载项目时会特别加入一个“长时间停车-快速起步”的段子：系统在静止状态下失锁GPS 60秒，再重新接收卫星信号并立即起步，观察位置和航向是否能够在几十秒内重新收拢。这个场景对城市隧道和高架桥下的导航有非常直接的参考价值。

3.5 卫星信号中断与恢复：组合导航真正的看家本领

GNSS信号中断是惯性组合导航项目必须覆盖的场景，也是半实物仿真对比外场测试最有优势的地方。外场测试很难在同一个位置重复模拟同一段遮挡，但GNSS模拟器可以在航迹的任意点设置信号开始中断、中断持续时长、中断期间是否保留部分卫星星座，甚至模拟多路径干扰。

我的标准做法是在匀速和转弯航迹中各插入一次60秒的卫星中断：

• 中断前至少保证30秒的良好定位，让组合滤波器充分收敛；
• 中断期观察纯惯性推算的位置漂移和姿态漂移；
• 信号恢复后记录重收敛时间，即位置误差回到中断前水平所需的秒数。

这个测试能直接暴露组合导航系统的“底气”——惯导质量越好，中断期的位置漂移越平滑；组合滤波器设计越好，恢复后的收敛越迅速。如果系统在60秒中断后重收敛时间超过30秒，就要检讨滤波器对速度观测和位置观测的处理逻辑了。

3.6 测试流程的复跑与轮次安排

半实物仿真测试的价值在于可重复。同一套场景，我在一个轮次中至少完整跑三遍，每遍之间不做任何参数修改，只重启系统让初始状态重置。三次结果的差异反映了系统的重复性和随机噪声水平。如果三次结果相差很大，先检查是不是转台状态没有完全复位，再检查GNSS模拟器是否每次都从同样的初始历元开始播发。这种问题往往在真实环境中极难复现，但在半实物仿真台架上只要按规范操作，很快就能定位。

4. 时间同步：半实物仿真里最容易翻车的地方

如果要我评选半实物仿真测试中最容易翻车、翻车后又最难排查的问题，时间同步绝对排第一。惯性导航解算周期快则200Hz慢则50Hz，GNSS接收机输出频率通常是10Hz或20Hz，转台的控制周期可能是1kHz，而GNSS模拟器产生的卫星信号又有基于脉冲秒（PPS）的时间基准。这四个时间基准如果不在同一个坐标系下对齐，组合导航系统收到的所有数据都会“各说各话”。

4.1 三种典型的时间不同步来源

第一种是设备本地时钟漂移。每台设备内部都有一个晶振，晶振的频率精度大约为10⁻⁵到10⁻⁶量级，看起来不高，但累计几十分钟就能造成几毫秒的偏差。对转台和仿真机来说，几毫秒的偏差可能只是造成了角度滞后一点；对组合导航算法来说，观测量和预测量的时间不匹配，在滤波器里会被当成观测噪声，甚至直接导致滤波发散。

第二种是接口延迟不确定。GNSS接收机从捕获信号到输出PVT帧，中间有接收机内部处理延迟；导航计算机通过串口接收GNSS数据，又有一个串口缓冲延迟。这些延迟在系统联调时不仔细测量，常被忽略，却在动态测试中表现为速度和位置观测始终落后于惯导推算。

第三种是仿真场景事件与数据采集的错位。例如GNSS模拟器设置航迹从t=10s开始加速，但转台要到t=10s+300ms才开始响应指令，中间这300ms里惯性器件觉得载体没动，卫星信号却说载体在加速。这种错位会让组合系统产生每秒几厘米到几十厘米的虚假速度误差。

4.2 同步方案怎么做：PPS、时间戳与调度优先级

好的同步方案不是只靠一种机制，而是三层配合。

第一层是外部脉冲同步：用同一个时钟源输出PPS脉冲给GNSS模拟器、转台控制器和被测导航系统，让所有设备对“秒”有统一的认识。GNSS模拟器在PPS上升沿对齐卫星信号发射时间，转台控制器在PPS边沿重置它的控制时间基准，被测系统的采样时钟也同步锁到这个PPS上。这是最基础的一层。

第二层是数据时间戳对齐：所有参与闭环的设备在发送数据时，在报文中标记数据对应的有效时间点，而不是发送时刻。采集端根据时间戳把惯导数据、GNSS数据和真值数据对齐到同一个插值网格上再记录，这样日志里的每一条数据都能准确知道“它代表的是哪个时刻的物理状态”。

第三层是实时系统调度：实时仿真机在调度运动模型计算时，要为转台指令输出、GNSS航迹更新和监控报文记录分别设置不同的任务优先级。硬实时时段内只允许关键任务抢占，监控和日志写入放到低优先级。这一点经常被低估——调度抖动会导致转台指令的到达时间忽早忽晚，在角速度数据上表现为额外噪声。

4.3 时间不同步影响的量化估算

为了说服项目组重视时间同步，我做过一组简单的定量估算。假设载体以20m/s匀速运动，GNSS位置观测滞后50ms，那么位置观测量就会相对真值滞后1m。在一个卡尔曼滤波器里，如果把滞后量当成真实位置误差，滤波器就会尝试修正一个并不存在的误差，产生虚假的速度修正量。又比如转台在30°/s角速度下转动，指令延迟20ms，姿态角度滞后0.6°，这在捷联姿态更新里产生的误差足以淹没陀螺本身的零偏水平。所以，在高速运动和高角速度机动场景里，几毫秒的同步偏差就能毁掉一次测试的有效性。

4.4 检查时间同步是否达标的方法

联调阶段我建议做一次“静态步进”测试：转台以5°间隔阶梯转动，每步停留5秒，同步记录转台反馈角、惯导解算角和GNSS模拟器航迹真值角，离线用互相关分析三者之间的延迟。理想情况是三者的相关峰值应该出现在零延迟附近。如果惯导解算角相对转台反馈角有明显的固定延迟，优先检查导航解算的采样时间戳和转台报文时间戳；如果GNSS模拟器航迹真值的速度特征相对惯导数据延迟明显，优先排查接收机输出延迟和串口缓存。

这个检查方法不需要额外设备，只要在测试流程里加入一小段阶梯运动，就能把时间同步的“健康状态”量出来，是我极力推荐每个项目都做的常规项。

5. 误差补偿不能靠运气：杆臂效应、安装误差与坐标转换

半实物仿真测试里很多人只盯着导航解算结果，却忽略了一个事实：台架物理结构本身会给测试数据注入额外的系统误差。杆臂效应、安装误差和坐标转换是三个最常见的来源，它们对精度的影响可能比算法调参还要大，而且全是可以通过前期的标定和补偿消除掉的。

5.1 杆臂效应：为什么位置天线和IMU不能当成同一个点

惯性测量单元测量的是它所在位置的比力和角速度，GNSS接收机天线测量的是天线相位中心的位置和速度，这两个点在物理上不重合。车载系统里，惯导放在后备箱，GNSS天线装在车顶，二者之间的空间距离就是杆臂。当载体有角运动时，天线相位中心和一个固定参考点的线速度不同，惯性导航推算出的速度与GNSS测出的速度之间会有一个由角速度和杆臂叉乘产生的差异，这就是杆臂效应。

半实物仿真台架同样存在杆臂问题：被测件安装在转台台面上，转台台面中心才是真值参考点，而GNSS模拟器输出的位置到底对应转台上的哪一个几何点，往往不是默认就一致的。如果模拟器把天线相位中心设在台面中心，而实际天线的安装位置偏离台面中心几厘米，在转台转动时就会产生虚假的速度误差。

补偿方法很简单：把杆臂向量标定出来，在GNSS观测进入滤波器之前做速度/位置修正。设载体角速度为ω，杆臂向量为r，则天线相对参考点的线速度修正量为v = ω × r。把这一项算清楚，动态机动测试的成绩通常能立刻提升一个量级。

5.2 安装误差：转台轴与被测轴不一定真平行

我前面提过转台轴系与被测惯导轴系要对齐，但工程上“对齐”永远是相对的。夹具加工误差、重复装夹误差、惯性器件封装本身的安装偏差，都会让被测件的敏感轴与转台轴之间存在一个小角度。在静态测试里这个角度可能表现为陀螺的常值偏置，在剧烈机动里则表现为交轴耦合误差。

要标定安装误差角，最直接的方法是分别让转台绕X、Y、Z三个轴做已知速率转动，同时记录陀螺的三个轴输出。理想情况下，绕X轴转动时只有X陀螺有输出，但实际会有Y和Z方向的微小耦合，耦合系数就是安装误差角的正弦值。得到这个矩阵后，可以在数据处理阶段把陀螺组合输出投影到转台轴系下，也可以在工装上做物理修正。我通常选择软件修正，因为每次装夹的误差角不同，物理修正一次只能适配一种装夹状态。

5.3 坐标转换：一个度变成弧度的教训

坐标转换是测试中最容易出错、出错后又最隐蔽的地方。GNSS模拟器输出的是经纬高和ENU速度，转台的角位置反馈是度数，惯性导航解算内部用的是弧度，组合滤波器的状态量可能是ECEF框架下的位置误差和速度误差。任何一处单位或参考坐标系的混用，都会产生系统性的伪误差。

我见过一个真实的错误：某次测试里，发现组合导航系统在匀速直线航迹下的位置误差呈现周期性波动，波动的周期恰好等于载体经度变化需要的时长。查到最后，是GNSS模拟器配置文件里把高度单位误设成了英尺，而导航解算按米处理，导致位置观测真值在以一个缓慢的规律逐渐偏置。这种问题在纯软件仿真里几乎不会遇到，因为数据格式由同一套代码生成；但在半实物仿真台架上，不同设备之间的单位差异是常态。

所以我在每次测试前都会强制做一次坐标核对。具体做法是：让转台回到零位，GNSS模拟器输出一个精确的静止点，此时载体位置已知、姿态已知，检查组合导航系统的初始对准结果和位置输出是否和理论值一致。这个“静态坐标冒烟测试”虽然简单，却是拦下后面一系列数据错误的最有效手段。

6. 实测排查记录：三个让我反复挠头的故障

半实物仿真台架最大的价值之一，就是让那些在外场看不见摸不着的故障变得可复现、可定位。下面三个故障是我在项目中真实遇到过的（细节已做脱敏处理），每个都花了不少时间，写出来给大家做个参考。

6.1 故障一：GNSS模拟器接入后速度跳变，定位却正常

现象是组合导航系统输出定位误差很小，位置曲线很平滑，但速度输出每隔几秒就出现一次1m/s级别的跳变，然后又缓慢回到零附近。位置正常、速度异常，这个组合很反直觉。我第一反应是GNSS接收机配置有问题，但看接收机原始输出的速度和定位，一切正常。

排查思路是逐级隔离。先把GNSS观测在滤波器入口处打点记录，确认进入滤波器的速度观测量是否跳变；再把组合滤波器的量测更新暂时关闭，只保留惯导推算，跳变消失，说明问题出在GNSS速度观测进入滤波器之后的融合环节。回到原始数据再细看，跳变发生的时刻正好对应到GNSS模拟器航迹文件里一段带角度突变的转弯处，模拟器生成的载体速度在转弯瞬间有一个不自然的阶跃，而接收机输出的位置在平滑算法里被过滤掉了，速度却没有被平滑掉。

解决方法是修正航迹生成器：转弯段用更高阶的曲线连接，并把相邻航迹点之间的速度增量限幅在物理可实现范围内。这个问题也提醒我，GNSS模拟器配置的航迹文件不能只看位置连起来顺不顺，速度连续性同样重要。

6.2 故障二：转台低速转动时，零偏漂移被当成真实运动

在做一组低速测试时，转台以0.2°/s缓慢转动，组合导航输出的航向角却能稳定地、平滑地跟踪转台变化，看起来一切正常。但切换到高精度陀螺器件后，同样的低速工况下航向误差增大到原来的几倍，怎么调都压不下来。

排查中发现，转台低速转动时的实际速率波动很大，瞬时角速度在0.05°/s到0.35°/s之间波动。对这个量级的波动，高精度陀螺能分辨出来，却会被当成真实角运动参与姿态更新；而之前的低精度器件噪声太大，反而把转台速率波动“抹平”了。在组合滤波器里，这种波动又会被当作姿态真值的合理变化，没有形成有效的残差去触发异常检测。

解决方法是把测试细分为“转台速率稳定度允许的角速度下限”与“被测器件分辨率上限”两个区间，只在这两个区间交叉的范围内做测试评估。低速工况的测试结果要附上转台实际速率波动的曲线作为参考，否则很容易把转台本身的品质问题误判为算法误差。

6.3 故障三：离线数据回放正常，实时闭环保不住

这个故障最折磨人：同样的航迹，用录下来的原始数据离线回放，组合导航系统跑得挺好；但只要在台架上做实时闭环测试，系统就会发散，位置误差一路飙升。既然数据一样，那问题只能出在“实时”这两个字上。

我先怀疑时间同步，重新检查了PPS连接和报文时间戳，没有发现异常。后来对比了离线回放和实时闭环两个场景的日志，发现实时闭环时进入组合滤波器的GNSS数据帧的“年龄”更大——从接收机输出到滤波器实际使用，中间隔了多个周期。原来台架上的数据采集线程把GNSS报文先写入缓存再转发给导航解算任务，缓存阻塞带来的延迟在离线回放时不存在。

修正方法是把GNSS接收机的数据链路改为直连导航解算任务，不经由缓存转发，同时利用数据帧发文中的时间戳做等待-对齐处理。这个问题让我认识到：半实物仿真测试不只是“接上设备跑数据”，整个数据通路的数据流设计，本身就是被测系统的一部分。

6.4 从三个故障里总结的排查方法

这三个案例有一个共同点：都是在“数据看似正常、系统却给出错误反馈”的时候，通过拆开中间环节、检查数据流的每个细节才找到根因。我的习惯是给台架的每个数据通路做一个“数据健康报告”，包括报文频率、延迟、丢帧率、时间戳连续性，每次测试前跑一遍，发现问题先修数据通路再跑场景。

7. 测试结果怎么读：比位置误差更值得看的东西

半实物仿真测试跑完之后，大家的注意力往往都放在最终位置误差上——“百米距离漂了几米”成了项目汇报的焦点。但从工程角度讲，位置误差只是结果指标，它没法告诉你系统到底哪里好、哪里差。我在评估一次测试时，会从下面几个维度逐项看。

7.1 从误差序列里区分系统误差与随机误差

把位置误差画成时间曲线，第一眼看的是整体趋势，但更重要的是把误差分解成常值偏置和随机波动两部分。常值偏置通常对应标定残余误差、杆臂补偿误差、坐标转换偏差，这类问题一旦找到就是定量的；随机波动对应陀螺噪声、加速度计噪声、GNSS观测噪声的放大结果，反映的是滤波器的噪声抑制能力。

分解方法很简单：将误差序列去趋势化，剩余部分的均方根就是随机误差，趋势项则用多项式拟合或滑动平均提取。在报告中我会同时给出这两个数，它们比单一的位置误差RMS更能说明问题。

7.2 按阶段切分：对准期、纯惯性期、组合期分开看

一次完整测试中，系统通常经历“对准-组合导航-GNSS中断-恢复”多个阶段，不同阶段的误差含义完全不同。对准期的误差反映的是初始对准算法的收敛速度和精度；纯惯性期的误差反映的是惯性器件的积分漂移；组合期的误差反映的是滤波器的观测融合能力；GNSS中断和恢复期的误差则反映系统的容错和重收敛能力。

我把测试过程按这些阶段切成时间段，分别计算误差指标，做成一张汇总表：

这张表比一个孤零零的“一米误差”有说服力得多，测试数据也能直接指导下一轮算法调试的优先级。

7.3 用一段小工具脚本把日志变成统计报表

测试日志的量通常很大，靠Excel手工统计效率太低。我常用一段Python脚本对录制的日志做快速统计，逻辑很简单：读取航迹真值和导航解算结果，按时间戳对齐，分别计算各阶段误差统计量并导出汇总表。代码不复杂，但节省的时间很可观。

import pandas as pd import numpy as np # 读取日志文件，包含time, ref_pos_x, nav_pos_x, ref_vel_x, nav_vel_x, ref_yaw, nav_yaw等列 df = pd.read_csv("hil_log.csv") # 计算位置误差和速度误差 df["pos_err"] = np.sqrt((df["ref_pos_x"] - df["nav_pos_x"])**2 + (df["ref_pos_y"] - df["nav_pos_y"])**2) df["vel_err"] = np.sqrt((df["ref_vel_x"] - df["nav_vel_x"])**2 + (df["ref_vel_y"] - df["nav_vel_y"])**2) # 按测试阶段切分（示例：0-60秒为对准期，60-120秒为组合期） periods = { "initial_alignment": (0, 60), "integrated_nav": (60, 120), "gnss_outage": (120, 180), } for name, (t0, t1) in periods.items(): seg = df[(df["time"] >= t0) & (df["time"] < t1)] if len(seg) == 0: continue print(f"{name}: pos_err_rms={seg['pos_err'].mean():.3f}, " f"pos_err_max={seg['pos_err'].max():.3f}, " f"vel_err_rms={seg['vel_err'].mean():.3f}")

脚本输出的数据不只是给自己看的，也是给算法同事做迭代对照用的。我会把每一轮测试生成的统计表和原始日志存档，文件名上标注日期和场景编号，这样下次调完参数想对比是否有提升，直接调出上一轮数据跑同一个统计脚本就行。

7.4 谨慎看待“精度最优”结论

最后一点是测试伦理问题。半实物仿真台架能模拟的场景再真实，也依然存在模型误差和物理设备自身的误差。转台不是绝对刚体，GNSS模拟器也不能完全复现真实环境中的多路径效应，所以测试数据应该被解读为“系统在该仿真场景下的表现”，而不是产品在所有真实场景下的保证。

我通常会在测试报告里专门列一栏“本次测试的边界条件”，包括转台速率稳定度、GNSS模拟器信号功率设置、航迹动态范围，让所有看到报告的人清楚结果是在什么条件下得出的。数据好不好看是次要的，边界条件讲不清楚，再漂亮的误差曲线对产品交付都没有参考价值。

做了这么多轮半实物仿真测试，我个人最深的一个体会是：半实物仿真测试的真正产出不是一组好看的指标，而是让你对系统里每一个误差来源、每一个数据通路、每一次异常现象都有据可查。测试中遇到难以复现的故障时，别急着改算法，先从台架本身和数据处理链路里找原因——很多时候，问题就藏在“真值”和“测量值”中间那截不起眼的连线里。