Liang Wang

在master分支上，单目3D已经删除了，单目3D请参考tag v1.3版本

> > D > > 那么请问现在是没有视觉的融合了吗？ main分支已经移除单目3D了

> > > 那么请问现在是没有视觉的融合了吗？ > > > > > > main分支已经移除单目3D了 > > 谢谢您的回复，我还想问问： 移除的原因是什么呢？ 1.3的版本是可以使用CPU的版本的雷达检测和单目3D融合吗？ 是否可以不编译和使用slam的模块呢？ 打扰了，谢谢回复~ 1. 单目3D检测精度不高，本来是打算替换成多相机BEV检测模型的 2. slam算法模块是c++实现的，需要编译

> > > > > 那么请问现在是没有视觉的融合了吗？ > > > > > > > > > > > > main分支已经移除单目3D了 > > > > > > > > > 谢谢您的回复，我还想问问： 移除的原因是什么呢？...

> > > > > > > 那么请问现在是没有视觉的融合了吗？ > > > > > > > > > > > > > > > > > > main分支已经移除单目3D了 > > >...

> > > > > > > > > 那么请问现在是没有视觉的融合了吗？ > > > > > > > > > > > > > > > > > > > >...

> Hi there, I found that in **mapping/fastlio/src/preprocess.cpp** [velodyne_handler] function, you set the timestamp of each point in a scan to 0? That may be a little different from offical-fastlio....

> > > Hi there, I found that in **mapping/fastlio/src/preprocess.cpp** [velodyne_handler] function, you set the timestamp of each point in a scan to 0? That may be a little different...

> 官方的fastlio代码是通过imu预测得到lidar结束时刻的先验位姿，然后通过反向传播得到基于lidar结束时刻坐标系的去畸变点云，然后通过ieskf进行位姿更新。我看您的代码，您是仍然使用imu预测得到lidar结束时刻的先验位姿，但是因为您不是使用的反向传播，且我看您上述的描述，推测您的去畸变点云是基于lidar起始时刻坐标系的，此时ieskf迭代更新的时候，先验位姿是lidar结束时刻的位姿，但是点云却是在起始时刻下，这样感觉有点怪。（ps：虽然通过ieskf的迭代，最终是能够将在lidar结束时刻的先验位姿更新到lidar起始时刻）。 lsd修改了fastlio后，imu预测的是上一帧结束时刻的位姿(其实也就是当前帧起始时刻的位姿)，你可以通过打印imu队列，可以看到每次迭代更新时，一直缓存着大约10个imu(imu为100hz)

> > > 官方的fastlio代码是通过imu预测得到lidar结束时刻的先验位姿，然后通过反向传播得到基于lidar结束时刻坐标系的去畸变点云，然后通过ieskf进行位姿更新。我看您的代码，您是仍然使用imu预测得到lidar结束时刻的先验位姿，但是因为您不是使用的反向传播，且我看您上述的描述，推测您的去畸变点云是基于lidar起始时刻坐标系的，此时ieskf迭代更新的时候，先验位姿是lidar结束时刻的位姿，但是点云却是在起始时刻下，这样感觉有点怪。（ps：虽然通过ieskf的迭代，最终是能够将在lidar结束时刻的先验位姿更新到lidar起始时刻）。 > > > > > > lsd修改了fastlio后，imu预测的是上一帧结束时刻的位姿(其实也就是当前帧起始时刻的位姿)，你可以通过打印imu队列，可以看到每次迭代更新时，一直缓存着大约10个imu(imu为100hz) > > 如果是按您说的这样，那就没啥问题了。但是我看了代码，在sync_packages()等地方没看到对应的逻辑？您方便指出一下么？ sync_packages中的lidar_mean_scantime一直是0 (每个点的时间也就是point.curvature在前面都被置0了)，所以每次调用时lidar_end_time = lidar_start_time