简介：这是一份面向机器人导航、飞行控制及移动设备等场景的IMU传感器标定工具包，适合需要提升惯性测量单元精度的开发者与工程师。压缩包共235个文件，包含txt说明文档、C++源程序（h/cpp）、yaml与launch配置文件、sample示例及辅助数据处理脚本，整体大小4.32MB，目录按code_utils与imu_utils两大模块组织，便于检索核心算法与配套工具。资源覆盖加速度计、陀螺仪等传感器的偏差、尺度因子、非正交性误差校正，提供Allan方差分析及自动标定流程，并修复了代码中的错误引用，提升运行稳定性。已有431人学习下载，用户可据此快速搭建标定环境，根据硬件需求定制参数配置，有效缩短传感器集成与调试周期。 做机器人定位、做自动驾驶传感器融合，或者说但凡碰过VINS、LOAM、LIO-SAM 这类框架的人，应该都体会过这种困惑：IMU 的出厂参数手册写得很漂亮，噪声密度、零偏稳定性都有标称值，可真跑起来，融合出来的轨迹还是会飘。我最早被这个问题狠狠坑过是在一套激光惯性导航方案上，LiDAR 和 IMU 看起来都正常工作，定位就是莫名奇妙地漂，排查了很久才发现问题根本不在算法，而是 IMU 的标定参数完全不准确。从那时候起，我开始认真研究 imu 标定这件事，imu-utils 也成了我用下来最顺手的工具之一。
imu-utils 是由香港科技大学沈劭劼团队开源的一套 IMU 内参标定工具，核心思路是基于 Allan 方差法，对静止状态下采集的 IMU 数据做统计分析，从而得到陀螺仪和加速度计的噪声密度、随机游走系数、零偏稳定性等关键参数。在 VIO、LiDAR-IMU 融合这类方案里，它几乎是“标配”级别的存在。无论你是在折腾无人机、机器人底盘，还是做车载组合导航，只要手里有一颗 IMU，想把它用好、想知道它的真实底细，这套工具都值得花一下午时间跑一遍。下面我会从原理、安装、实操、坑点几个方面完整拆一遍，最后再聊聊 ROS2 时代怎么接着用。
1. IMU 为什么必须从零标定：误差来源与标定目标
1.1 IMU 误差都藏在哪：确定性误差与随机误差
IMU 的误差不能笼统地说成“漂移”，它实际上由好几类性质完全不同的分量叠加而成。理解这一点，你才能真正看懂 imu-utils 输出的是什么，以及为什么它解决不了所有标定问题。
第一类是确定性误差，包括零偏、尺度因子和安装误差。零偏就是当 IMU 严格静止时，陀螺和加速度计的输出并不是理论上的 0 或重力加速度，而是一个固定偏置。尺度因子是指输入角速度或加速度与输出值之间存在一个比例偏差，比如真实角速度是 100°/s，输出却是 98°/s。安装误差则指三轴加速度计或者陀螺的三个轴并不是严格正交的，存在微小的轴间耦合。这三类误差的特点是相对固定，但会受温度影响而缓慢变化。
第二类是随机误差，也就是你无法用一个固定值去补偿的部分。常见的有白噪声，也就是高频的随机抖动；有角速率随机游走，也就是噪声随时间积分后的慢速漂移；还有零偏不稳定性，即零偏本身会在某个范围内随机波动。这类误差的可怕之处在于，它会通过积分不断累积，最终让姿态、位置解算严重发散。刚接触 IMU 的朋友最容易犯的错，就是以为把零偏减掉就万事大吉了，结果发现剩下的随机漂移照样让速度积分飞掉，这就是没搞清随机误差的统计特性。
那这些误差怎么治？确定性误差里的零偏，可以在静止时直接取均值估计；而尺度因子和安装误差，通常需要转台或者高精度的多位置旋转来标定，imu-utils 主要解决的是随机误差的统计特征，以及静态零偏的估计。转台那种大设备不是人人都有，但随机误差的统计参数用纯软件方法就能算出来，这也是 imu-utils 能成为社区标配的根本原因。
1.2 imu-utils 到底在标什么：Allan 方差与关键参数
Allan 方差是 1966 年 David Allan 提出的频域分析方法，最早的用途是研究原子钟的频率稳定性，后来被广泛用于惯性器件。它的思路不复杂，但非常巧妙：对一段静止采集的 IMU 数据，按照不同的积分时间长度，把数据切成一段一段的小块，然后在每个积分时间尺度下计算相邻块均值之差的方差。
你可以把 Allan 方差想象成一把能调节刻度的尺子。短刻度量出来的是高频噪声的激烈程度，长刻度量出来的是慢速漂移的长期趋势。把各个时间尺度下算出的方差值画到双对数坐标里，会得到一条有多个转折段的曲线。不同斜率对应的段，翻译出来就是不同类型误差的来源。
imu-utils 会把这条曲线自动拟合出来，并输出几个参数。最常用的是 noise_density，也就是噪声密度，对应角度随机游走或速度随机游走；还有 random_walk，也就是偏置随机游走，反映零偏随时间漂移的速度；另外是 bias_stability，零偏稳定性，表示零偏在一段时间内波动的下限。
注意：Allan 方差分析假设输入数据是静态的、平稳的。也就是说，标定时 IMU 必须完全静止，任何微小的震动、晃动都会污染数据，导致拟合出的参数偏大甚至曲线无法收敛。这一点怎么强调都不为过。
理解了这些，你就知道 imu-utils 能解决什么问题了：它给你的是 IMU 随机误差的统计模型参数，以及静态零偏。这些参数会直接进入 VINS-Fusion、LIO-SAM 等系统的噪声协方差设置里，从底层决定了你的融合算法能跑多稳。
2. imu-utils 安装全流程：环境、依赖与踩坑点
2.1 为什么要选 imu-utils 而不是其他工具
市面上做 IMU 标定的开源工具有好几款，我陆续试过一些。有的依赖很重，需要配合专用的采集板卡；有的主要面向商用级 IMU，对 MEMS 芯片支持得不好；还有的虽然能出结果，但文档缺失，参数怎么用全靠猜。imu-utils 在这么多工具里能脱颖而出，主要是三个原因。
第一，它轻量。整个工具就两个 ROS 功能包，依赖很少，不需要特殊的硬件设备，只要有一颗能输出原始数据的 IMU 和一个能录 rosbag 的 ROS 环境就能跑。第二，它的方法足够严谨。基于标准 Allan 方差分析，输出参数和非线性优化能直接对接，社区里大量开源项目都采用了它的输出格式。第三，它被验证的次数太多了。港科大这个团队在 VIO 和 LiDAR 惯导领域深耕多年，imu-utils 是他们内部一直在用的标定工具，后来开源出来的。我见过的绝大多数 VINS 教程、LIO 方案，在参数配置环节都会提到 imu-utils，这份信任感是在大量实战中积累出来的。
当然它也有局限。前面说过，它没法标定尺度因子和安装误差，那类误差需要转台或者至少是六面位置法。另外它依赖 ROS1，在纯 ROS2 环境里会有适配问题，这个我后面专门讲。
2.2 code_utils 与 imu_utils 编译顺序与依赖避坑
安装 imu-utils 之前，你自己要评估一下手里是哪个 ROS 版本。大多数教程默认 Ubuntu 16.04 + Kinetic 或者 Ubuntu 18.04 + Melodic，这两种环境我都在实际项目里配过。imu-utils 官方仓库里有两个子项目，一个是 code_utils，一个是 imu_utils，编译时有严格的先后顺序：必须先编译 code_utils，再编译 imu_utils，因为后者依赖前者的某些工具函数。
编译流程是这样的：先把 code_utils 放进 catkin_ws/src，然后在 catkin_ws 根目录执行 catkin_make，这里不能一次性把两个包都编译，否则因为依赖声明不完整，你会看到找不到头文件之类的报错。code_utils 编译通过后，再把 imu_utils 放进去，重新 catkin_make 即可。
提示：在 Ubuntu 18.04 + Melodic 环境下，code_utils 的 CMakeLists.txt 里如果不指定 C++14，编译时经常会报一堆奇怪错误。建议在 CMakeLists.txt 里加上 set(CMAKE_CXX_STANDARD 14)，然后再删掉 build 目录重新编译。
另外还有两个常见的坑。第一个是找不到 Sophus 库或者 Eigen 版本太老，这种问题一般用 sudo apt install libeigen3-dev 装上最新版就好，Sophus 如果报错，检查一下 include 路径是否显式包含。第二个坑和 Python 版本有关，某些新版本 Ubuntu 上，catkin_make 用的 Python 从 2 切到 3，可能导致编译脚本报错，这时建议干脆用 catkin build，在 src 目录下执行 catkin_init_workspace，然后 catkin build code_utils，再 catkin build imu_utils，分步编译，报错信息会更清晰。
我在第一次编译时，就是在 code_utils 上卡了很久，来回折腾了快一个小时，最后发现就是 C++ 标准版本问题。后来我把这个经验写进了团队的搭建文档里，后面再有人配环境基本是十分钟搞定。如果你不想踩这些坑，记住一条核心原则：分清依赖，分开编译，报错先看是不是标准版本问题。
3. 数据采集与标定实操：从 rosbag 到参数输出
3.1 采集数据：静止不动，别急着录 bag
标定数据的质量直接决定标定结果，这一步的重要性远超很多人的认知。你是不是觉得“静止”就是把 IMU 放桌上录个三五分钟？那结果多半是废的。我用实际经历告诉你，Allan 方差分析需要足够长时间的数据才能覆盖低频段的误差特征，通常建议采集 1 到 2 小时，至少不能少于 1 小时。采集时间太短，频率低端的长期漂移特征根本没有被激励出来，拟合出的 bias_stability 会偏离真实值。
采集时的环境要求也需要注意。IMU 要放在一个稳固的平台上，最好是大理石台面或者加了减震垫的三脚架底座上，避免附近有人走动、电梯运行这类低频震动干扰。采样频率尽量调到 IMU 支持的最高值，常见 MEMS 传感器能到 200Hz 或以上，高采样率可以给 Allan 方差分析提供更充足的高频信息。供电也要稳定，最好用稳压电源或者充满电的电池，供电毛刺会直接变成噪声，污染采集数据。
温度是另一个容易被忽略的变量。MEMS 惯导的零偏随温度变化很明显，所以采集时环境温度要尽量稳定，避免空调直吹、阳光直射。如果有条件，把 IMU 上电后先静置 10 到 20 分钟，让芯片自身的温度稳定下来再开始录制，这能显著减小温漂带来的误差。实测下来，同样的 IMU，冷启动直接录和预热后录，标定出的 bias_stability 可以差出一个数量级。
录制时直接用 rosbag record 即可，指定 IMU 的话题名，比如：
rosbag record /imu/data -O imu_static.bag录制期间不要去碰它，不要来回走动，录完了检查一下 bag 里的话题频率是否正常。我习惯录完顺手用 rostopic hz 看一眼，确认数据没有掉帧，再开始跑标定，省得反复折腾。
3.2 运行标定流程：launch 文件与参数配置
录好 bag 后就可以跑 imu-utils 了。imu_utils 包里通常会带一个示例 launch 文件，你需要编辑它，指定 bag 的路径和 IMU 话题名。基本的 launch 配置长这样：
<launch> <node pkg="imu_utils" type="imu_an" name="imu_an" output="screen"> <param name="imu_topic" type="string" value="/imu/data"/> <param name="imu_name" type="string" value="my_imu"/> <param name="data_saved_path" type="string" value="$(find imu_utils)/data/"/> <param name="max_time_min" type="double" value="120"/> <param name="min_time_min" type="double" value="10"/> <param name="cluster_size" type="int" value="10"/> </node> </launch>这些参数里，imu_topic 要和你 bag 里的话题名完全一致，否则节点会一直等待数据；imu_name 是输出文件的命名前缀，建议用 IMU 型号加日期，方便后面管理；max_time_min 表示最多处理多少分钟数据，一般设成和 bag 时长一致或略长；min_time_min 表示至少要处理多少分钟，建议不小于 30。cluster_size 是 Allan 方差分析时的分簇大小，保持默认即可。
运行方式也很直接：
roslaunch imu_utils imu_utils.launch然后另开一个终端，把录好的 bag 播放出来：
rosbag play imu_static.bag节点收到数据后会持续处理，并在终端打印计算进度。处理完成后，会在 data_saved_path 指向的目录下生成一组文件，包括 imu.yaml 和一系列数据文件。整个运行过程我实测下来很快，即使录了 2 小时数据，处理时间也就几十秒到几分钟，Allan 方差的计算本质上是对数据做统计分簇和方差运算，计算量不大。
3.3 标定结果拆解：如何把 yaml 参数用到工程里
标定完成后最关键的环节就是读结果。imu-utils 生成的 yaml 文件结构大致是这样的：
gyr: noise_density: 0.001234 random_walk: 0.000056 bias_stability: 0.000789 acc: noise_density: 0.002345 random_walk: 0.000123 bias_stability: 0.001234这些值单位通常是 rad/s/√Hz、rad/s²/√Hz 等，具体要看算法内部转换。在 VINS-Fusion 中，这些参数会映射到噪声协方差和随机游走协方差里，从而影响优化器对 IMU 的信任程度。你可能会发现标定出的 noise_density 比 IMU 数据手册上的标称值大，这很正常，因为实际安装环境和供电条件比厂家测试环境更复杂。使用标定值而不是手册值，融合效果通常会更稳定。
注意：不同的系统对这几个参数的定义和单位不完全一致，移植到 VINS-Fusion、LIO-SAM 或自己的状态估计器时，要仔细看源码里的协方差设置，不能盲目把 imu-utils 输出值直接塞进去而不做单位换算。
从工程实践来说，标定完最好做一次验证。最直接的方式是把 IMU 固定住静止几分钟，用标定出的零偏补偿后看积分角度漂移是否明显减小；更全面一点，把它接进你常用的 VIO 或 LiDAR-IMU 融合框架，在同一段数据集上对比标定前后的轨迹漂移程度。我每次标定完都会在同一个录好的测试包里跑一遍 VINS-Fusion，用轨迹误差来确认标定确实有效果，而不是只看参数是否合理。
4. 常见问题排查与项目经验实录
4.1 编译与运行期高频报错
编译阶段最容易碰到的问题我在安装部分已经提了一些，这里把完整的排查表整理出来，方便你直接对号入座。
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 编译 code_utils 报找不到 sophus 头文件 | include 路径缺失 | 在 CMakeLists.txt 中显式 include Sophus 路径 |
| 编译报 Python 脚本错误 | Python2/3 环境混乱 | 使用 catkin build 代替 catkin_make |
| 编译报 Eigen/Ceres 版本不兼容 | 系统库版本过旧 | 升级 libeigen3-dev，重编 Ceres |
| launch 后节点等待数据不动 | IMU topic 名与 bag 不一致 | 用 rostopic list 和 rosbag info 核对 |
| 运行完成后没有生成 yaml | 数据时长不足或 bag 播放中断 | 延长数据时长，确保 bag 完整播放 |
运行期我最常遇到的坑是 topic 名不一致。很多人录制 bag 时用默认话题名，而 launch 里写的是另一套，节点自然一直收不到数据。还有一种是 bag 播放速度太快，数据还没处理完就播完了，建议用 rosbag play -r 1.0 正常速度播放，如果处理不过来看节点日志，适当调慢播放速度也可以。
4.2 标定结果不理想怎么办
如果你发现标定出的噪声参数明显异常偏大，或者 Allan 方差曲线在长时端不收敛，先别急着怀疑工具，多半是数据质量出问题。我遇到过的几种典型情况：一是数据采集时间太短，曲线短时端和高长时端信息不足；二是数据里有震动污染，比如把 IMU 放在正在运行的机器上录；三是供电不稳定，曲线整体毛刺很多，难以收敛。
处理办法也很朴素：检查环境，重新采集。一般把 IMU 放到稳固平台上、加长采集时间到 1.5 小时以上、确保供电干净，都能得到明显改善。还有一个小技巧：录制数据时在旁边放一个静止的参考标记，比如地面贴个标签，便于事后确认采集过程中 IMU 没有被碰过。另外，如果你用的 IMU 温漂比较大，建议把标定流程设计成“预热→采集→再采集”，对比两次结果是否一致，如果差异大，说明温度还在漂移，需要等更长时间再录。
4.3 与 LiDAR-IMU 联合标定的衔接思路
很多朋友做 LiDAR-IMU 融合时会遇到两个层面的问题：IMU 自身的内参和 LiDAR 与 IMU 之间的外参。imu-utils 解决的是第一个层面，也就是内参标定；第二个层面，即 LiDAR 到 IMU 的旋转和平移外参，需要另用工具。
现在社区里常见的做法是先用 imu-utils 把 IMU 的噪声参数和零偏标定好，再用 lidar_align 这类工具，采集一个包含丰富几何特征的环境数据，让 LiDAR 点云和 IMU 轨迹进行联合优化，估计出外参。如果你用的是一些较新的 LIO 框架，比如 FAST-LIO、LIO-SAM，它们有的内置了外参初值优化，但前提是 IMU 内参必须先靠谱，否则整个优化会被带偏。我的经验是，内参标定不要省，每次换 IMU 硬件、改安装方式时都要重新做一遍，这步看似耗时，实际上是在给后面的所有工作打基础。
5. ROS2 时代的 IMU 消息与标定流程适配
5.1 ROS2 的 sensor_msgs/Imu 消息格式要点
随着越来越多的项目迁到 ROS2，你会逐渐遇到一个现实问题：imu-utils 是基于 ROS1 写的，还是依赖 roscpp 和 rosbag，直接搬进 ROS2 工程里会有一堆接口不兼容。在讨论替代方案之前，先搞清楚 ROS2 中 IMU 消息本身的变化。
ROS2 的 IMU 消息类型是 sensor_msgs/msg/Imu，核心字段和 ROS1 基本一致：header 里包含时间戳和 frame_id，angular_velocity 是角速度，linear_acceleration 是线加速度，orientation 是姿态四元数，后面还跟着三个协方差数组。看起来变化不大，但实际规范更严格了。ROS2 里 frame_id 必须明确设置，时间戳必须使用 ROS2 的时钟来源，而且在多传感器融合时，必须保证 IMU 的协方差矩阵赋值合理。很多从 ROS1 迁移的代码，常常会在时间戳同步上出问题，导致标定或融合时数据对不齐。
如果你只是想在 ROS2 环境里直接标定 IMU，有几个思路。社区里已经有人做了 allan_variance_ros2 这类将 Allan 方差分析移植到 ROS2 的包，你可以去尝试。如果你的标定数据是用 ROS2 bag 录的，也可以先用 ros2 bag play 和 ros1_bridge 把数据桥接回 ROS1 环境，继续用 imu-utils 标定。这个方法虽然有点绕，但胜在成熟稳定，不改变你现有的标定流程。
5.2 imu-utils 在 ROS2 场景下的替代方案与折中做法
说实话，我自己的习惯是暂时不完全放弃 ROS1 标定流程。工具链的成熟度比“新”更重要，imu-utils 经过了大量项目验证，输出格式稳定可靠，而 ROS2 下的 Allan 方差工具还相对年轻，用之前要花时间验证可信度。所以在实际工程里，我会把标定环节独立出来，用一个小型 ROS1 环境专门录制和处理数据，标定结果以 yaml 文件格式输出，再作为静态参数传给 ROS2 系统。这样既保证了标定质量，又避免干扰主项目的 ROS2 工程结构。
如果你必须完全在 ROS2 下完成标定，折中做法是这样的：先用 imu-utils 标定，但把数据采集和参数解析做成一个独立命令行工具，不依赖 rosbag，而是直接读取原始二进制或 CSV 数据。这样你可以把录好的数据导入 ROS1 环境标定，也可以给每个新 IMU 快速出一套参数。我在几个嵌入式项目里就是这么干的，把标定参数做成配置表，每次换传感器就查一下对应的 yaml，效率很高。
最后再分享一点个人体会：IMU 标定这件事，乍看只是个不起眼的预处理步骤，但它在整个传感器融合链路里起的作用，和你给相机做内参标定一样关键。很多人把时间花在调优化器权重、调后处理参数上，却忽略了 IMU 的“底子”根本没打好。最初我也不理解为啥相同型号的两颗 IMU，标定结果会有差异，后来做多了才发现，芯片本身的制造离散性、焊接温度、安装应力都会影响参数，而这正是为什么每次更换硬件后都必须重新标定，不能偷懒沿用旧参数。希望这篇流程梳理能帮你少走一些弯路，毕竟这些坑我都是一个个踩过来的。
本文还有配套的精品资源，点击获取
