about lidar type

[HeXu1]

great work!
It seems to be tailored for multi-ring lidars. Is it applicable to non-repetitive scanning lidar? such as livox.

[HeXu1]

WLe_p seems world points（I don't understand why it is multiplied by config.T_B_L.inverse()）

mimosa/mimosa/src/lidar/photometric.cpp

Lines 693 to 695 in 3c3f642

	V3D WLe_p =
	config.T_B_L.inverse() * T_W_Be * config.T_B_L * Le_p.getVector3fMap().cast<double>();
	feature.Le_ps.push_back(WLe_p);

and it was used as in L frame

mimosa/mimosa/include/mimosa/lidar/photometric_factor.hpp

Line 180 in 3c3f642

const V3D p_Le_b = delta_pose_b_a_Le * a_feature.Le_ps[i];

This seems contradictory. Is there something I'm misunderstanding

[nkhedekar]

Thank you @HeXu1 ! 🙂
The photometric part is designed for multi-ring lidars only however the geometric works with other lidars too! The only constraint is that it should be a sensor_msgs/PointCloud2 message. For livox there is a open-source converter from their custom message to sensor_msgs/PointCloud2 https://github.com/koide3/livox_to_pointcloud2

For the second question - the reason this is needed is because there is a non-identity transform between the LiDAR and the Body (imu) frame. The feature.Le_ps has features in the $W_L$ frame. This is different from the world $W$ frame (i.e. $W_I$ frame) with the relation $p_{W_L} = T_{BL}^{-1} p_{W_I}$

If you look at how delta_pose_b_a_Le is calculated:

mimosa/mimosa/include/mimosa/lidar/photometric_factor.hpp

Line 150 in 3c3f642

const gtsam::Pose3 delta_pose_b_a_Le =

it goes from lidar_end frame to lidar_end frame instead of the body_end frame (delta_pose_b_a_Be)

[HeXu1]

Yes thanks a lot.
I have tried to accumulate long time livox date to use photometric factor, but it doesn't work. It seems that the quality of the intensity map after accumulation is poor. and now I understand the meaning all of the pose or points symbols.
By the way, I have tried to fuse geometric factor and pre-imu factor directly with gtsam IncrementalFixedLagSmoother. I found that the system can be successfully initialized but often diverges. It seems to be affected by large errors in geometric factors.
I know that the general solution is to provide a backend fused prior through independent geometric matching. However, independent matching is unstable in scenes with weak geometry. Therefore, I have been considering directly fusing geometric factors with pre-imu factors to enable them to complement each other. But it always diverges.
Do you have any relevant experience or suggestions? This question has been bothering me for a long time. Thank you. @nkhedekar