Hi there DPEng.
I’m not sure exactly what you are referring to when you say “merge”, so I’ll try to elaborate on a few possible interpretations that range from simple to complex.
I’ll start with the simplest first. The Sweep Visualizer desktop application has a small feature we call the “scan history” which draws a brief history of previous scans overtop the current scan. This allows the user to see a brief temporal window of scans all at once. However the scan data is not intelligently combined here, but instead the visualizer simply draws multiple scans overtop one another. Still it can be useful if scan data is relatively sparse in the area you are investigating. It is worth noting that the visualizer draws scans in the coordinate frame of the sensor itself. That is to say, the visualizer draws scans as if the sensor’s position is fixed in space. This is because the visualizer has no current means of knowing the sensor’s world position. Therefore, the utility of the visualizer’s “scan history” feature has diminishing returns when viewing data from a moving sensor (on a mobile robot for example). In the future we may add support for sensor position data, such that the scans can be drawn according to the known position of the sensor.
The next interpretation of “merging” scan data is to simply combine multiple scans together into 1 scan structure. This won’t do much in the way of processing or improving the data, but it might be helpful if you’re goal is to simultaneously view a larger quantity of scans than the “scan history” feature will allow. Again, the sensor position would be assumed fixed, and you could simply merge the individual readings of multiple scans into a single scan. Functionally, the result would be scan that appeared to be taken from a sensor with a higher sample rate.
Concatenation, Filtering, Smoothing
The next interpretation of “merging” scan data is a form of concatenation. That is the task of combining multiple scans of the same location in order to make one improved scan. This can help to improve sparse sections in the data, remove outliers, remove noise, and average out imperfections in the individual scans. This process would still assume that the scans are taken by a stationary sensor. There exist many techniques for filtering, smoothing and performing regressions on spatial data. Additionally, given that the Sweep is taking 2D scans, you could leverage many techniques developed for image processing in the computer vision and machine learning communities. If you’re looking looking to get started with data processing, I’d recommend you import the data into an environment that provides a host of pre-made statistical and machine learning tools such as Matlab, R or certain Python packages. That way, applying common data processing techniques becomes a trivial task, which will help you prototype a processing strategy that works best for your data.
Moving up the chain of complexity, the next interpretation of “merging” would be to merge scans taken from different locations or orientations. More generally this is called “scan matching”, where one attempts to calculate the most likely pose of one point cloud relative to another. Without knowing the position of the sensor, this problem generally involves finding a pose that minimizes the difference between data points in the two clouds. Many different methods exist for matching scans. The oldest and simplest methods use variations of the Iterative Closest Point algorithm, which can be optimized in a myriad of ways. Some implementations have been developed specifically for real-time matching with scanning LiDAR. Although other arguably superior techniques exist, ICP (Iterative Closest Point) will likely be the simplest and most well documented technique to implement yourself.
Map Generation & SLAM
Moving beyond basic scan matching and towards map generation, you will begin to approach the large realm of “SLAM” or “Simultaneous Localization and Mapping”. This is an enormous field of developing research for mobile robotics. Most techniques rely on the fusion of data from multiple sensors, especially odometry and GPS data. Many methods will also be iterative in nature, meaning that the interpretation of data is relative to the data that came before it. This can cause issues when there are hiccups in the data, or even from large movements that occur too quickly. Therefore, certain applications will require the inclusion of techniques for loop closure and the avoidance of drift. Again, this is a large field with many differing approaches. Certain approaches will be well suited to some applications and poorly suited to others.
This has all been to say, that the complexity of “merging” scans differs quite a bit depending on what you’re looking to accomplish. Currently the Sweep does not have any form of included position data. Therefore, any techniques performed without the inclusion of data from additional sensors will have to rely on inference of pose from the data itself. These problems can be complicated, but luckily the Sweep sensor data is fairly simple. And because the amount of data is relatively small, you can likely get away with running un-optimized techniques in real-time, in order to make up for the lack of position data. For example, Hector SLAM is a form of odometry-less SLAM that can function using only range data. There exists an implementation in ROS that could likely be adapted to work with the Sweep sensor.
It may also be useful to look into existing libraries or projects for processing and working with point cloud data. For example, the PCL project is open source and provides implemented algorithms for processing point clouds.
Currently at Scanse we are focusing on the assembly and shipping of devices, but as things progress we’ll be shifting some focus back to software. We intend to develop and provide Sweep libraries for our users to leverage common processing techniques in any of their projects via a user-friendly API. Additionally we’ll be investigating the topic of scan matching and map building, and hopefully develop a solution that best suites the Sweep device. Looking to the future of Scanse products, we may consider providing accessories or DIY project documentation for integrating position data into the mix. This would open up the doors to a lot more software techniques. Because this is all further down the roadmap we’d like to prioritize the export of data into various formats such that users can import sensor data into whatever program they like.