Following the previous week’s post and the discussion the thesis advisor, it was clear that the priority was to correct the delay in the point-cloud representation described in the last blog post, in order to advance to the next stage of the thesis roadmap.
After a fruitless attempt to correctly identify the problem with the previously implemented accumulation node, a new approach was taken. The node was rebuilt to make use of the ‘laser_assembler’ package present in the ROS environment, this new method works similarly to the old one but with benefit that the aggregated point cloud is directly created from the provided raw laser data, thus eliminating the additional conversion step present in the old node. Similarly to the old one there is a buffer_size parameter that can be used to determine the number of scans to aggregate to the point cloud. This node then publishes the resulting point-cloud in a ROS service to which the node then subscribes to. However the laser_assembler package only takes one laser as an input so two instances of the node have to be running to accommodate for the two laser scans that are to be used, and so an additional step is required to merge the point-clouds from each laser into a single point-cloud. The result is a reconstruction (white) that happens in real-time with almost no delay from the data transmission of the laser scan (pink).
Having the perceived roadway point-cloud is the first step to the road edge detection objective. The next step is to apply some pre-processing to the could, namely some down-sampling techniques, since there are to many points and often many of them are irrelevant and otherwise can seriously hinder processing speed and accuracy further down the line. To remove these extra points some algorithms were tested. Firstly a Voxel Filter was applied to reduce the number of points but still maintaining with relative accuracy the underlying surface geometry, this allowed to reduce the number of points but most of the outlier points were still present.
To eliminate these outliers and to focus on the highest density areas a RadiousOutlierRemoval tool was applied to the filtered point cloud. This algorithm searches each point in the cloud for the number of neighbours within a given radius and based on that criteria keeps or discards the point. Since these 3 parameters (Leaf size for the Voxel filter, Radius and Neighbours for the outlier removal) needed to be adjusted to find the optimal values for each, a GUI tool was developed to dynamically change these values as the Rviz visualization was occurring.
After some testing a somewhat clean point-cloud was obtained and it should now almost ready to apply an algorithm to determine the road edge. The images bellow represent the results and some of them are coloured based on height.
However, because of the filtering process the road reconstruction happens close to the sensor, about 12 m from it. This rises from the fact that the first laser scan hits the ground at approximately 8m and the second at approximately 20m and so they only overlap in the last 8m from the car. Since the filters favour the denser areas of the cloud the points further away tend to be eliminated, this could present a problem further down the line when this data is to be used. Considering that this occurs because there is too much space in between laser scans, the most obvious solution is to move the laser upper in the vehicle and pointing at more of an incline towards the road, which is a measure that needs to be discussed since it would change a lot of the previously developed work.