2
$\begingroup$

Is there a standard practice for merging the pointclouds generated by several LIDARs when there is overlap?

For example, if my vehicle has two LIDARS (front and back) I'd rather fuse and deal with a single pointcloud in the perception pipeline than two. Each LIDAR pointcloud will definitely have unique sections in their FOV, but there will definitely also be overlap. The vehicle geometry can make this overlap not geometrically simple.

Is the standard practice just to add them on top of one another? What should one then do about overlap? Perhaps just accept it and move on? I think things like ICP and the like are out of the question since the interest is to have one pointcloud per time sample to use for the perception pipeline, the interest here is not for mapping.

$\endgroup$

1 Answer 1

2
$\begingroup$

Certainly merging two laser scans into a single point cloud is doable. Here's an example tool and you can easily concatenate said point clouds too.

However I'd like to suggest that you reconsider some of your assumptions in your question.

Each LIDAR pointcloud will definitely have unique sections in their FOV, but there will definitely also be overlap.

Do they really overlap? Aka they point to the same point exactly, or do they overlap only if you're assuming that they are planar. And also if they see the same object from different angles does that give you more information? Are they vertically alligned and planar? Do they have different viewing angles, different heights.

I think things like ICP and the like are out of the question since the interest is to have one pointcloud per time sample to use for the perception pipeline, the interest here is not for mapping.

ICP can be applied to any sequence of point clouds. There's no rule about when or how to update. Many implementations may be optimized for taking repeated scans from the same scanning laser sensor as that's the most common use case.

A fused cloud may be better for doing things like general obstacle avoidance. Using each scan individually for sequential ICP may be the best way to track odometry. Some algorithms can take advantage of the semantic meaning of getting one consistent laser scan, while some can benefit from having a less structured fused data source. And others may actually want the multiple feeds fed in in the raw format and they will do their own fusion.

With that said I would suggest that both it's not an either/or question but what will serve your application best. You may want to do both feeding different forms of the data to different algorithms to enable them to operate optimally.

Is the standard practice just to add them on top of one another? What should one then do about overlap?

It completely depends on how you plan to use the data. There's a whole field of study called sensor fusion which I would recommend you do some reading on and ask more specific questions when if you have them. This is too large a scope to answer here.

$\endgroup$
3
  • $\begingroup$ The application here is not at all for odometry, 100% for obstacle avoidance/situational awareness. Regarding the overlap, the vehicle has two 360 deg, 128 vert channel LIDARs mounted at the front and back, so there should 100% be overlap in the center of the vehicle as well as on either side given reasonably unobstructed environments. $\endgroup$ Jan 30, 2022 at 9:55
  • $\begingroup$ Just to be clear, I definitely want to combine them, I was curious if there was an established standard way to take two overlapping pointclouds and make one, combining real-time for a live data flow. $\endgroup$ Jan 30, 2022 at 9:56
  • $\begingroup$ There are many different ways to combine point clouds. Again it depends on your application. Those feels like an X-Y problem where you're looking for a solution to an assumption. Off you want to do pure obstacle avoidance, almost all algorithms for that will want to use the separate scans individually to compute the best estimates for the obstacles. Instead of having the data be preprocessed and merged. Data will be lost if you apply any naive prefilter such as joining scans from two separate sensors. An example is that your can't ray trace to the origin nor get the data as fast. $\endgroup$
    – Tully
    Jan 31, 2022 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.