Announcing the sensor_filters package

Hi, I would like to announce the sensor_filters package (both Melodic and Noetic release are pending in the next sync of these distros).

It evolved on the base of laser_filters but provides an orthogonal filters interface for all sensor_msgs message types, not just for LaserScan.

The package provides simple nodes and nodelets that more or less just configure and spin a filters::FilterQueue, subscribe to an input topic and publish the result. I know it’s easy to write such node(let)s, but this package is a convenience in case you do not have special needs for the filter queue. I was actually quite surprised there wasn’t any convenience package providing this functionality except for LaserScan…

If you do not know about the filters framework, it is a C++-only super-efficient way to postprocess sensor data. It uses no inter-process communication and no (de)serialization - all filters are loaded as dynamic libraries and a reference to the sensor data is passed to each filter, which may alter it, and then sent to the next filter.

Example configuration for filtering a LaserScan topic:

filter.yaml

output_queue_size: 1
scan_filter_chain:
  - name: intensity
    type: laser_filters/LaserScanIntensityFilter
    params:
      lower_threshold: 8000
      upper_threshold: 100000
      invert: false
      filter_override_range: true
      filter_override_intensity: false
  - name: shadows
    type: laser_filters/ScanShadowsFilter
    params:
      min_angle: 10
      max_angle: 170
      neighbors: 20
      window: 0

filter.launch

<launch>
    <node pkg="sensor_filters" type="laserscan_filter_chain" output="screen" name="laser_filter">
        <remap from="~input" to="base_scan" />
        <remap from="~output" to="base_scan_filtered" />
        <rosparam command="load" file="$(dirname)/filter.yaml" />
    </node>
</launch>

Any comments welcome!

11 Likes

This looks super useful! Can you be more specific about what kind of filters work out of the box and what sensors are supported? Are the filters just your basic averaging / low pass / DC offset / high pass filters, or can you do more sophisticated things with the data? Do you have a roadmap to add more features? Any plans for a ROS 2 release?

From what I understand about the package any filter CAN be implemented in this package with the benefit of the

no inter-process communication and no (de)serialization

Really simple and useful package.

This package does not bring any new filters, it is just an environment that can run them.

The mean/median/increment filters from the filters package cannot be used as they work on primitive types (float, double) and not on messages.

Most scan-to-scan filters from the laser_filters package should be usable. The laser_filters scan_to_scan_node uses a tf::Subscriber to subscribe to the messages which means the filters can rely on transforms being available without waiting. But as I looked through, many of the filters do wait anyways. If the filters wait for their transforms, they can be right away used with sensor_filters.

I know it’s a pity there aren’t many filters that could be tried and used right away. Releasing this package was the first step to actually allow more filter implementations to appear. Yes, there was the filters framework, but as there was no simple way to run the filter chains, I think developers just chose other implementations (e.g. nodelets).

I haven’t yet jumped on ROS 2, so I will not provide a ROS 2 version. However, contributions are welcome!

2 Likes

I’ve now added sensor_filters/ChangeHeader/$MESSAGE_TYPE filters to sensor_filters package. These filters are able to change the header of sensor messages - they support both absolute and relative changes (i.e. prefixing/suffixing the frame_id, or adding a constant to stamp).

2 Likes