Regarding a suspected bug in the cloud_callback function related to keyframe filtering in the backend about lidar-slam-detection HOT 8 CLOSED

Hello, thanks for your attention

1. We reset the 'best_score' to std::numeric_limits::max() after a keyframe is inserted to the graph, so the 'best_frame' will be updated when the next frame income. The 'best_frame' indicates the frame that well aligned to the local map between two adjacent keyframes.
2. The fitness_score is the standard metric in PCL for pointcloud registration, but it calculated by the inliers(distance within the 'max_range'), so the inlier ratio is also considered here and we use the metric = fitness_score * 0.8 + (1.0 - inlier_ratio) * 0.2 as the score of pointcloud registration.
3. if (horizon_dist <= 10.0 && p1.z < floor_height_max && p2.z < floor_height_max && fabs(p1.z - p2.z) > 0.25) this operation aims to remove the points which are far away from the ground (points from moving vehicle or points generated by abruptly motion) and makes the ground plane thinner. The preconditions is that the floor detection is enabled.

from lidar-slam-detection.

十分感谢你的回复，我依旧存在一些疑问。
1.关于你的第三点回复，你说这个操作是为了滤除远离地面的点，这我看出来了。只是我不懂这样做的目的是什么？我在代码中看到的作用是为了构建odom_local_map量用于关键帧的判断。
2.关于第一点回复，我做出以下理解，不懂对不对，希望你指正：每进来一个普通的雷达帧，他就会进行一系列的判断，判断通过他就是关键帧，并重置一些量，比如best_score重置为max，但是如果当前雷达帧无法通过判断，比如
if (dx < (keyframe_updater->keyframe_delta_trans * 2.0) && da < (keyframe_updater->keyframe_delta_angle * 2.0)) {
LOG_WARN("map update, keep finding better keyframe");
return false;
}
在这里reture false，那么他就继续等待下一帧进入进行判断，如果后面的几帧一直都不太好，那么就会拿之前的最好的一帧做为关键帧（best_frame）。这一部分代码我总觉得有点绕，抱歉我的愚钝。

from lidar-slam-detection.

你好，
1.当开启地面检测后，会在关键帧插入graph之前过滤掉这些噪点，经过我们测试，能够过滤掉部分动态障碍物产生的点云和其他一些噪点，可以使得构建的点云地图中的地面比较“薄”，有助于后期标注车道线、地面标识等
2.你的理解是正确的，在dx < (keyframe_delta_trans / 2.0) && da < (keyframe_delta_angle / 2.0) ～dx >= (keyframe_delta_trans * 3.0 / 2.0) || da >= (keyframe_delta_angle * 3.0 / 2.0)范围内搜寻好的关键帧，当must_update为true时，判断当前best_frame是否满足条件，不满足则在dx < (keyframe_updater->keyframe_delta_trans * 2.0) && da < (keyframe_updater->keyframe_delta_angle * 2.0)到达前继续搜索。
这里加了一些简单的逻辑来筛选关键帧，能够一定程度减少odometry误差导致的地图重影问题

from lidar-slam-detection.

感谢你的回复，我明白了。
我根据你的代码进行了移植，重新构建了我自己的slam工程，主要移植了fastlio和后端模块。现在已经基本能够运行，且在我自己的一些数据上有了比较好的效果。但是我最近在新的自己采集的数据上发现了些问题。

绿色这个是开了回环（后面不说默认都是关闭地面约束），另外两个一个是单纯前端fastlio的输出，一个是关闭回环，只有帧间约束。这个开了回环之后z轴就异常升高。我现在计划拉取您的镜像，利用您的工程测试一下。

此外，我想请问您一下，采用您的floam，需要点云哪些信息？目前采用的是禾赛128线lidar。我现在的点云信息有xyz、intensity、ring，需要我修改哪些文件或者配置呢？（这个问题和上面问题没关系，是另外一件事情）

from lidar-slam-detection.

感谢你的回复，我明白了。 我根据你的代码进行了移植，重新构建了我自己的slam工程，主要移植了fastlio和后端模块。现在已经基本能够运行，且在我自己的一些数据上有了比较好的效果。但是我最近在新的自己采集的数据上发现了些问题。 绿色这个是开了回环（后面不说默认都是关闭地面约束），另外两个一个是单纯前端fastlio的输出，一个是关闭回环，只有帧间约束。这个开了回环之后z轴就异常升高。我现在计划拉取您的镜像，利用您的工程测试一下。

此外，我想请问您一下，采用您的floam，需要点云哪些信息？目前采用的是禾赛128线lidar。我现在的点云信息有xyz、intensity、ring，需要我修改哪些文件或者配置呢？（这个问题和上面问题没关系，是另外一件事情）

1.开启回环后，确认下是否存在回环误检或者是两个关键帧align不好的情况，排除之后，我之前也遇到过这种问题，主要原因应该是z轴缺少约束导致的，z轴（pitch/roll)的变化对于g2o优化代价函数影响较小，在优化时为了最小化代价函数，导致z轴（pitch/roll)变化较大。如果使用场景无法开启地面约束的话，建议尝试利用IMU加速度计的重力约束，从而约束关键帧的pitch/roll，应该能够缓解这个问题

2.floam需要ring作为输入，在’points_attr‘的第二维填上每个点的ring id，应该就可以了

from lidar-slam-detection.

1.我明白了，您的意思是在g2o优化中，如果没有地面约束的话，在加入回环的时候误差变大，此时为了让整体代价函数最小，就可能会对z、roll、pitch这三个自由度产生比较大的修改，从而导致最终的地图比较混乱。目前场景有上下坡，无法开启地面约束，因为地面约束一旦开启上下坡可会被强行拉成平面。您说的建议尝试利用IMU加速度计的重力约束，这个具体该怎么做呢，我现在的slam框架并没有把imu数据传入后端模块，imu只是用于前端fastlio。您知道有利用IMU加速度计的重力约束开源的相关方案吗，我想学习一下，十分感谢您的帮助。此外您说的回环误检需要怎么排查呢？我用的是您代码原本的参数，得分条件应该是满足，此时不应该有误检，而且我可视化看了，产生回环的两帧是符合实际情况的。两个关键帧align这个我没理解，可以请您说详细点吗？需要排查哪部分代码。(补充：我拉取您的镜像进行了测试，在您的镜像工程中并不会这样，建出来的图十分完美，但是我的却有问题。我已经排查了fastlio前端，前端和原版fastlio基本一样，效果也可以，就是加入了后端不行。我可以保证后端代码与您的基本一致，所以现在问题出哪了，我已经不知道从哪里查了)
2.我是不是需要修改lidar_driver.cpp中的数据解析的代码进行适配？我现在是用的rosbag包，通过您提供的rosbag_proxy工具进行了转换。我能否不传递intensity值，在pkl中改成传递ring呢？如下面图片所示

3.延续第一点问题，从之前的evo轨迹对比图片可以看到，fastlio的前端输出和加了帧间约束的后端的输出，二者在轨迹是基本重合，也就是说帧间约束（我理解应该就是十四讲中的位姿图优化）貌似并没有啥作用？不懂是不是这么回事？如果没作用加入的意义是什么呢/
最后，大佬，不知道我们能不能有更高效点的交流方式，比如邮箱[email protected]或者其他，不方便的话也没关系。感谢您

from lidar-slam-detection.

续上面的第二点，进行了上述修改，用intensity代替ring，可以拿到ring值，且我已经打印输出，确认没问提，但是还是无法运行。使用的是禾赛128线，无imu，web中选择的是custom配置

from lidar-slam-detection.

1.我明白了，您的意思是在g2o优化中，如果没有地面约束的话，在加入回环的时候误差变大，此时为了让整体代价函数最小，就可能会对z、roll、pitch这三个自由度产生比较大的修改，从而导致最终的地图比较混乱。目前场景有上下坡，无法开启地面约束，因为地面约束一旦开启上下坡可会被强行拉成平面。您说的建议尝试利用IMU加速度计的重力约束，这个具体该怎么做呢，我现在的slam框架并没有把imu数据传入后端模块，imu只是用于前端fastlio。您知道有利用IMU加速度计的重力约束开源的相关方案吗，我想学习一下，十分感谢您的帮助。此外您说的回环误检需要怎么排查呢？我用的是您代码原本的参数，得分条件应该是满足，此时不应该有误检，而且我可视化看了，产生回环的两帧是符合实际情况的。两个关键帧align这个我没理解，可以请您说详细点吗？需要排查哪部分代码。(补充：我拉取您的镜像进行了测试，在您的镜像工程中并不会这样，建出来的图十分完美，但是我的却有问题。我已经排查了fastlio前端，前端和原版fastlio基本一样，效果也可以，就是加入了后端不行。我可以保证后端代码与您的基本一致，所以现在问题出哪了，我已经不知道从哪里查了) 2.我是不是需要修改lidar_driver.cpp中的数据解析的代码进行适配？我现在是用的rosbag包，通过您提供的rosbag_proxy工具进行了转换。我能否不传递intensity值，在pkl中改成传递ring呢？如下面图片所示

3.延续第一点问题，从之前的evo轨迹对比图片可以看到，fastlio的前端输出和加了帧间约束的后端的输出，二者在轨迹是基本重合，也就是说帧间约束（我理解应该就是十四讲中的位姿图优化）貌似并没有啥作用？不懂是不是这么回事？如果没作用加入的意义是什么呢/ 最后，大佬，不知道我们能不能有更高效点的交流方式，比如邮箱[email protected]或者其他，不方便的话也没关系。感谢您

你的问题太多了，我回复不过来，你可以加我qq, 526390906

from lidar-slam-detection.