evo轨迹评估实战：解析时间戳未对齐的根源与修复方案
1. 时间戳未对齐的典型报错现象
第一次用evo评估VINS-Mono在Euroc数据集上的轨迹时，看到终端弹出红色报错"found no matching timestamps between reference..."，我整个人都是懵的。明明轨迹文件和数据集的ground truth都存在，为什么就是匹配不上？后来发现这是SLAM开发者使用evo工具时十有八九会遇到的经典问题。
具体报错信息通常长这样：
found no matching timestamps between reference and /home/user/traj.txt with max. time diff 0.01 (s) and time offset 0.0 (s)这个报错的本质是evo在对比两条轨迹时，找不到时间戳能对应上的数据点。就像试图用两个不同时区的时钟对表，永远差着几个小时。我后来测试发现，VINS-Mono、ORB-SLAM2、LIO-SAM等主流框架的原始输出，80%都会遇到这个问题。
根本原因在于时间戳单位的"时区差"——有些SLAM系统用秒为单位记录时间（如1.234567秒），有些则用纳秒（1234567000纳秒）。而Euroc等数据集的标准格式要求秒为单位。这就好比一个用12小时制，一个用24小时制，直接比较当然会出错。
2. 时间戳差异的源码级分析
2.1 ORB-SLAM2的时间戳处理
在ORB-SLAM2的System.cc文件中，找到保存轨迹的SaveTrajectoryTUM函数。关键问题出在这行代码：
f << setprecision(6) << (*lT) << " " << ... // 直接输出时间戳值这里*lT是double类型的时间值，单位是秒。比如图像时间戳是1403715273.362149，直接输出就是小数点形式。但Euroc数据集需要的是纳秒级整数时间戳，所以需要乘以1e9：
f << setprecision(6) << 1e9*(*lT) << " " << ... // 转换为纳秒2.2 VINS-Mono的特殊情况
VINS-Mono的处理更复杂些，因为它的可视化模块（visualization.cpp）和位姿图模块（pose_graph.cpp）都会输出轨迹。我遇到过更诡异的情况：明明修改了visualization.cpp里的时间戳格式，评估时还是报错。后来发现是pose_graph线程在后台偷偷输出了另一套时间戳。
关键修改点在两个地方：
// visualization.cpp foutC << header.stamp.toSec() << " "; // 修改前是toSec()*1e9 // pose_graph.cpp (建议直接注释掉相关输出) // ofstream loop_path_file(VINS_RESULT_PATH, ios::app);3. 一劳永逸的修复方案
3.1 针对ORB-SLAM2的修改
- 打开ORB-SLAM2/src/System.cc文件
- 搜索SaveTrajectoryTUM函数
- 找到时间戳输出行，修改为：
f << setprecision(6) << 1e9*(*lT) << " " << setprecision(9) << twc.at<float>(0) << " " << twc.at<float>(1) << " " << twc.at<float>(2) << " " << q[0] << " " << q[1] << " " << q[2] << " " << q[3] << endl;- 重新编译项目
3.2 针对VINS-Mono的完整方案
- 修改visualization.cpp：
ofstream foutC(VINS_RESULT_PATH, ios::app); foutC.setf(ios::fixed, ios::floatfield); foutC.precision(6); // 注意这里改成6位小数 foutC << header.stamp.toSec() << " "; // 移除*1e9 foutC << estimator.Ps[WINDOW_SIZE].x() << " " << estimator.Ps[WINDOW_SIZE].y() << " " << estimator.Ps[WINDOW_SIZE].z() << " " << tmp_Q.x() << " " << tmp_Q.y() << " " << tmp_Q.z() << " " << tmp_Q.w() << endl;- 处理pose_graph干扰：
// 在pose_graph.cpp中找到以下两处并注释掉： // ofstream loop_path_file(VINS_RESULT_PATH, ios::app); // ... (所有相关输出代码)4. 预防性编程规范建议
经过多次踩坑后，我总结了一套避免时间戳问题的开发规范：
- 统一时间戳单位：团队内部强制规定使用秒为单位，精度保持6位小数
- 输出前显式转换：在保存轨迹的代码处添加注释说明时间单位
// 时间戳单位：秒，精度6位小数 fout << fixed << setprecision(6) << timestamp << " ";- 隔离测试模块：单独测试轨迹输出功能，用文本编辑器检查前几行数据
- 版本控制备注：在Git提交时特别注明时间戳格式变更
git commit -m "[Fix] Change timestamp unit from ns to sec in trajectory output"实际项目中，我还准备了一个检查脚本verify_timestamp.py，在评估前自动检测时间戳格式：
import numpy as np def check_timestamp(file): ts = np.loadtxt(file, usecols=[0]) if np.all(ts > 1e18): # 纳秒判断 print("WARNING: Timestamps seem in nanoseconds!")