Mapping server transport dynamic cloud downsampling

[acschang]

This PR includes a new node to decimate team cloud data by adjusting leaf node size in the PCL library filters. Data is incrementally decimated to prevent submitted clouds having over 600,000 points to exceed the protobuf limits of Ignition transport resulting in the pointcloud being truncated. The original size of the pointcloud prior to decimation is passed to the mapping server.

The node is added to the common launch file for mapping server relays and the relevant PCL dependencies are added to the requisite Dockerfiles.

[iche033]

docker image built fine. I tested republishing point clouds from one of the robots to the /cloud topic and verified that the point clouds are downsampled in the cloud_throttled_downsampled topic

[rsawtell]

To clarify, this can potentially change the size of pointclouds (eg lidar scans etc.) received by solutions in a fully dynamic way such that anything that expects a specific formatting of the pointcloud would break (ie: assuming an rgbd sensor always has 640x480 resolution) and that this happens when all the scans over all robots on a team exceeds a threshold?

[acschang]

To clarify, this can potentially change the size of pointclouds (eg lidar scans etc.) received by solutions in a fully dynamic way such that anything that expects a specific formatting of the pointcloud would break (ie: assuming an rgbd sensor always has 640x480 resolution) and that this happens when all the scans over all robots on a team exceeds a threshold?

This is accurate however the deployment of this node will only affect cloud data sent from teams to the mapping server so this will not affect the functionality of your solutions in any manner. This node will affect the density of pointclouds sent to the mapping server as to stay below the 64MB transport limit.

More information on the mapping server is available on the wiki.