nkliuhui

请问是可能哪里出了问题

不好意思哈, 今天测试了一下, 发现初值没有前天测试的时候给的好; 在粗配准阶段是激光与图像先靠近, 然后突然向反方向跳变了; 后期优化阶段拉回来一点, 但最终结果也不是太理想. 请问是和计算平台的依赖库有关吗? Eigen 3.3.7, Ubuntu 16, Ceres 2.0.0, PCL 1.7.  

我重新编译了代码, 发现还是同样的结果; 确实使用了最新的代码, 我怀疑可能是我安装环境的问题, 后续换台电脑再尝试一下哈. (在粗配准阶段, 开始时确实是朝着重合的方向收敛, 但是突然跳变了.)  

没有修改参数文件, 只修改了数据包路径

> 我也是只改了bag包的路径，然后运行程序，标定的结果也不好。我的环境是ubuntu16.04, eigen3.3.4, pcl-1.7, ceres-1.14.0。你找到问题的原因了吗? @nkliuhui 我放弃了

您好， 0. 前提假设：程序是为了实验性目的使用，触发信号发送、传感器接收等时间延迟直接忽略处理了；应用时假设短期在高性能平台上使用。 1. gps、imu和lidar之间直接赋值时间戳，三者之间的时间同步可以有效保证，硬件带来的时间差异可以忽略(相比于未同步带来的时间偏差)，特别对于低速应用的移动机器人等平台完全可以忽略影响； 2. 相机的时间戳比较不稳定，目前的程序逻辑只能保证在算力比较好的平台上短时间内达到同步的效果(会存在大约5ms的滞后--与曝光时间、相机硬件等也有关系)；我考虑了一下您提到的这个问题，工控机等算力较弱的平台，再加上ROS中间件，特别容易出问题；稳定的方法感觉加上一个下位机专门用于采集数据可能比较好，特别是可以支持中断触发的(中断判断触发信号发出，在设定固定时延内未收到相机图像，则判断跳帧等等)；具体不是搞底层的，可能是一个思路，实现不太会哈。 希望有帮助，祝好！