You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nowadays, all filters applied to the map point cloud in the post step are in the sensor's frame. Although the coordinate frame does not matter for some filters, there are cases when it could be beneficial to add support for different frames:
Bounding box filter - often used to remove points in a close neighbourhood of the sensor, such as reflections from the platform the sensor is attached to. However, it could also be applied to remove parts of the environment and in that case we need a fixed frame to apply it in.
Voxel-based filters - a moving origin causes the individual voxels to move as well, giving a different result than with a fixed voxel origin
I imagine that there could be a frame parameter for each filter in the yaml config file, with default values being the sensor frame for the input filters and the map frame for the map post filters. Other frames could be loaded from another config file, even though I don't see any point in using different frames than the two mentioned.
As for the implementation, the mapper currently relies on libpointmatcher when it comes to loading the yaml files. This would need to be replaced by something that first loads the filter's frame and then passes the description of the filter itself to libpointmatcher. The resulting yaml structure could look something like this:
Nowadays, all filters applied to the map point cloud in the post step are in the sensor's frame. Although the coordinate frame does not matter for some filters, there are cases when it could be beneficial to add support for different frames:
I imagine that there could be a
frame
parameter for each filter in the yaml config file, with default values being the sensor frame for the input filters and the map frame for the map post filters. Other frames could be loaded from another config file, even though I don't see any point in using different frames than the two mentioned.As for the implementation, the mapper currently relies on libpointmatcher when it comes to loading the yaml files. This would need to be replaced by something that first loads the filter's frame and then passes the description of the filter itself to libpointmatcher. The resulting yaml structure could look something like this:
The text was updated successfully, but these errors were encountered: