Adding new SDF blocks to schema at runtime

asked 2017-12-02 10:52:41 -0600

ivaughn gravatar image

I'm trying to add a new sensor type to gazebo-- in this case a Doppler Velocity Log, although the choice of sensor is functionally irrelevant. Yes, I'm aware that there are several other DVL implementations out there, but this question really isn't about adding a specific sensor type to gazebo. It's about how to overcome overly-rigid SDF parsing constraints.

There seem to be two approaches to adding a new sensor type:

1). Pick an existing sensor and write a plugin that inherits from SensorPlugin. This is what most people seem to be doing. You can specify your parameters in an SDF file inside the plugin block, and everything is peachy-- as long as there's a sensor that meets your needs. If this is what the developers were intended I would have expected more abstract sensor classes (e.g., an "Empty" you could extend to implement a full-on INS).

2). Inherit from the Sensor class and use a SystemPlugin to add your custom new sensors to SensorFactory by calling Register[YourSensor]() in Load. This works nearly-brilliantly. Except....

I'm having trouble figuring out how to add an SDF block to the SDF parser somehow (analogous to, say, the <gps> block for a GPS sensor). Any thoughts on how to do this without recompiling gazebo and the sdf library?

Its frustrating to find this robust design and solid plugin architecture only to be thwarted by an overly-rigid config file parser. This is a long-term non-student project. We have no interest in maintaining our own gazebo fork for the next decade, so solutions like "oh, just add it to the SDF schema and recompile" aren't really an option.

Thanks.

edit retag flag offensive close merge delete