Added motion compensation feature to rslidar_pointcloud

[lorenwel]

I have added motion compensation to the rslidar_pointcloud node. What it does is that it compensates for potential motion of the sensor between arrival of a scan package and publication of the point cloud.
This is achieved by querying the TF tree for motion of the rslidar frame relative to a given fixed frame.

We have experimentally tested that this works using a BPearl on our legged robot.
The following screenshot is taken from RViz, while our robot was walking up a single step onto a flat podium. The sensor is mounted in the front of the robot, scanning the ground.
This clearly shows that, without motion compensation, there is a serious "cut" in the point cloud, while the ground is flat with motion compensation.

This introduces a new dependency on eigen_conversions, which is installed with ROS per default.

[johuber]

Do you have any data on computational overhead or delay caused by this?

At which moving speeds do you think this becomes relevant?

[lorenwel]

Do you have any data on computational overhead or delay caused by this?

On my desktop i7 machine it has a processing time for the entire cloud of ~10ms instead of 7.5ms. Other than the processing delay, there might also be a 20ms delay from the TF query. You could remove the waiting time, but then you occasionally get a "extrapolation into the future requested" error thrown by TF.

EDIT: Actually, the processing time with motion compensation is ~8.5ms. The rest of the increase is indeed from wait times induced by the TF query.

At which moving speeds do you think this becomes relevant?

Whether this is relevant is hard to say and depends on the platform and the rotation speed of the lidar. Generally, fast rotations are usually more problematic than linear velocities because they produce large offsets at long distances.
For your machine, I would imagine that it could possibly be relevant while yawing or while going up or down curbs.