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