Parsing for SDFormat camera sensors

[jwnimmer-tri]

SDFormat has a standard way of adding cameras to a scene with the sensor element on a link. It would be wonderful if Drake could support that, at least for the basics.

[jwnimmer-tri]

Rough design proposal:

(1) The parser converts the XML specification to a geometry.render.ColorRenderCamera (or DepthRenderCamera).

(2) On the MbP body (i.e., link), the parser registers a superfluous geometry instance with the perception role (only), something like a box geom set to zero alpha. Within its perception properties, we store the above item, keyed as something like (group_name="parser", name="color_render_camera").

(3) We provide a function that takes a Diagram and adds the RgbdSensor systems. It would scan all geometries for the magic "parser" property, and when it finds any such property it would add a System. It would return the collection of sensor output ports, somehow keyed or indexed by the original SDFormat sensor names.

[jwnimmer-tri]

@SeanCurtis-TRI when you have some time, I'd appreciate any feedback on the principle of using GeometryProperties to communicate sensors from the Parser to an RgbdSensor.

The other alternative would be passing the full DiagramBuilder pointer to the Parser, so it can add entire farms of new Systems instead of just MbP elements and geometries.

[SeanCurtis-TRI]

Without pondering too long, it feels hacky. There's not actually a geometry with properties. We'd be turning geometry into a message passing service.

Generally, I'd vote for the parser being less MbP-centric if we're parsing formats that represent concepts that are more than MbP.

If we're looking for less churn on the current API, we can modify the idea of two passes (parser does its work, collecting additional data, followed by some other entity that discovers and operates on the additional data). The parser could collect all additional information in an explicit struct and the second pass can operate explicitly on that -- no discovery necessary.

[jwnimmer-tri]

At this point, I think we're happy with configuring cameras outside of SDFormat. For one, we load models from a wide variety of formats so SDFormat is nothing particularly special. But more importantly, there's a few more details about a camera than SDFormat denotes (e.g., capture offset, output delay, LCM topic, compression) so we would need to keep the yaml-based camera config in any case. We can re-open if we find the need to do this later.