[HardwareSim] Configuration to enable/disable LCM (to support three use cases)

[RussTedrake]

I would like to try replacing my manipulation station workflows using the hardware sim schemas / loaders. Ideally I would like to parse the same yaml file three times:

1. stand-alone simulation. This is what hardware_sim.cc / hardware_sim.py is doing now. That's great! (It replaces my existing examples/manipulation_station/mock_station_simulation.cc.
2. to create the equivalent of ManipulationStation for in-process simulation. I don't want any LCM here; instead I want to Export the driver input and output ports so that the diagram can be used as a component in another diagram.
3. to create the equivalent of ManipulationStationHardwareInterface. Rather than load the plant and the drivers directly, I want to create a diagram which implements the complement. E.g. hardware_sim subscribes to IIWA_COMMAND, in this workflow I want the interface to be a diagram that publishes the IIWA_COMMAND directly from an input port.

Use case (2) should be able to reuse most of the same ApplyDriverConfig methods that we use in (1), but currently ApplyDriverConfig always adds the lcm publishers and subscribers. I could go through and them, but it would be better to be able to opt-out in my calls to ApplyDriverConfig, and (ideally) export the ports instead.

Use case (3) probably involves a different, but closely coupled Apply_?_Config code path. It would be nice to consider this in the design as well.

[RussTedrake]

I've worked around this locally -- you can see the draft here. But I do think that this workflow is something that is worth supporting upstream, and my version is not yet able to use e.g. the logic in Drake for making the controller_plant.

[jwnimmer-tri]

Item (3) is basically RobotHub from Anzu. See anzu/robot_bridge/hub/hub_builder_config.h and nearby.

[RussTedrake]

I took a look, and I agree. Although I find it more elegant to have the same config file be able to support all three cases?

I've got a narrow version working at the link I shared above, but would love to promote the HardwareInterface / HubBuilder idea to Drake.

[jwnimmer-tri]

For (2), I think the best path will be to refactor build_iiwa_control.cc to add the control cabinet simulation as a separate System (currently named SimIiwaDriver as a placeholder), and connect the LCM I/O to those system ports. Then, we can offer a flag (or something) to not connect the LCM. The nice cabinet sim System will remain, which you can export the ports from.

The WIP branch is here with SimIiwaDriver here.

Here's a picture of hardware_sim running with the new refactoring (with LCM still enabled).

[RussTedrake]

This is great! Thank you.

See the ManipulationStation ports here. A few lessons from that work-flow:

• I think we should prefix the model instance name on the SimIiwaDriver ports.
• I think it's valuable to add the "cheat" ports, at least when not in LCM mode. Probably adding them always is fine, since they won't be evaluated.

It's not obvious to me that this refactor is needed to make the lcm flag work, but it seems very reasonable to me.

[jwnimmer-tri]

I think we should prefix the model instance name on the SimIiwaDriver ports.

This could happen when the ports are exported out of the outer builder. Within any one SimIiwaDriver system, an unprefixed port name is sufficient. The SimIiwaDriver itself is named per the model instance. This is consistent with e.g. IiwaStatusReceiver whose port names are just position_measured not {model_name}_position_measured.

For reference, in robot hub, we use {model_name}.{port_name} when exporting, i.e., a dot instead of underscore. I think it improves clarity (and makes it easier to mechanically parse) when the model name vs port name use a different separator (.) than the separator for words within a port name (_).

When I next post a refreshed image, I'll use a left arm and vs right arm as a better example.

I think it's valuable to add the "cheat" ports, at least when not in LCM mode. Probably adding them always is fine, since they won't be evaluated.

The (C++) manipulation station doesn't have any per-model-instance cheat ports, does it? Any per-plant cheat ports would be exported out of the plant, not out of the per-model-instance sim driver.

[RussTedrake]

Makes sense.

The (C++) manipulation station doesn't have any per-model-instance cheat ports, does it? Any per-plant cheat ports would be exported out of the plant, not out of the per-model-instance sim driver.

That's correct. I hadn't thought through the implications of the sim driver being per-model-instance.

I'm fine with {model_name}.{port_name}. It would be good to rip that bandaid off before the fall terms starts, if possible to do it this week. Perhaps I should make that change in my hardware station draft right now?

[jwnimmer-tri]

It's not obvious to me that this refactor is needed to make the lcm flag work, but it seems very reasonable to me.

The subdiagram allows us to give semantic names to intermediate signals, so we can have "torque commanded" instead of "adder output". That should provide the lever we'll need to mechanically export the cabinet sim ports in use case (2), without relying on species-specific logic.

Perhaps I should make that change in my hardware station draft right now?

Probably a good idea, assuming you buy the premise.

The other thing we worked on some with robot hub was to make sure the port names were consistent across species. I suggest keeping an eye out for any unwanted variance there, as well.

[RussTedrake]

Re: naming intermediate signals. Makes sense. Thanks.

Re: "_" -> "." Sounds good. Will make the change in my course repo now.

The more I've thought about it, the more I feel certain that I'd like to use the same scenario file for all three workflows. Do you agree on that premise?