Support for custom sensors

General
1

Hi, I’ve just faced the need to implement a custom sensor in Gazebo 9. I’ve found out it’s pretty difficult to do so, because AFAIK there is no real plugin-like mechanism for sensors.

So I thought about writing the sensor as a separate shared library and then preloading the library and calling its RegisterCustomSensor() function and extending SystemPaths accordingly from a “preloader” plugin. What I found out slightly disappointed me - I’ve found that the only suitable plugin type for this kind of work is a system plugin, which is much worse for interoperability than a world/model plugin would be.

The problem is, model plugins load after sensors, so this would not help. And world plugins load only after the first world step, if I haven’t misread the source code. So this leaves only system plugins.

Putting up with the system plugin approach, I’ve written https://github.com/peci1/gazebo_custom_sensor_preloader . This ROS package uses a pluginlib-like mechanism to find all custom sensors and preloads them at simulator startup, so that users can freely use them in their SDF files as if they were a part of Gazebo core.

What do you think about this approach? Have I missed something? Wouldn’t it be nice to add official support for plugin-like sensors the same way model plugins are supported? And what about ignition gazebo, does it solve this problem better?

And a side question: are there any unexpected consequences if I specify my sensor type as sensors::RAY? I’ve just seen it’s put in a different data structure than the other sensors, but I don’t know why there is this separate data structure in the first place :slight_smile:

1 Like
2

I’ve found out it’s pretty difficult to do so, because AFAIK there is no real plugin-like mechanism for sensors

Great work! Is this still the case? I am not sure when this was introduced:
AddingaSensorPlugin

3

That is a bit different case. Sensor plugins as known and existing in Gazebo so far are plugins that process data from the already provided sensors.

Custom sensor preloader allows you to implement completely new sensors. The only limitation is the SDF syntax, so you have to do a bit of workaround to pass settings to the custom sensor.

4

That sounds like a bug. Sensor plugins, just like any other plugin, are allowed to have arbitrary elements inside of them to allow custom plugin configuration (SDFormat Specification). Until recently, there was a bug in the spec that just showed an element without description there, but this has been fixed.

Are those elements ignored by ignition gazebo?

5

I believe @peci1 is referring to the fact that only a fixed set of sensor types are accepted by SDF within //sensor/@type, and only those can be configured though //sensor/[sensor_name] (i.e. //sensor/altimeter).

I know the original post is about Gazebo Classic, but as reference, I’ll link a series of PRs that are introducing custom sensors to Ignition Gazebo. They make use of SDF custom element and attributes, introduced in libSDFormat 9, like this (note ignition:type and ignition:odometer):

        <sensor name="the_odometer" type="custom" ignition:type="odometer">
          <always_on>1</always_on>
          <update_rate>30</update_rate>
          <topic>odom</topic>
          <ignition:odometer>
            <noise type="gaussian">
              <mean>0.2</mean>
              <stddev>0.1</stddev>
            </noise>
          </ignition:odometer>
        </sensor>

PRs:

Feedback is welcome :grinning_face_with_smiling_eyes: This is planned to go into the Fortress release.