Habitat IPC configuration

[tslominski]

@nunoo

Take this piece of configuration as an example:

agent_type: ${monty.class:tbp.monty.simulators. habitat_ipc.server. MultiSensorAgent}
env_init_func: ${monty.class:tbp.monty.simulators. habitat_ipc.client .environment.HabitatEnvironment}

It is crucial that no one tries to instantiate MultiSensorAgent in Monty, that only the simulator (the server) does that.

I think we’re thinking similar. Although, in the future state, I’d expect it to be something like

experiment:
  ...
  runtime:
    ...
    monty:
      ...
      environment:
        _target_: ${monty.class:tbp.monty.environments.HabitatEnvironment}
        ...
    environment:
      _target_: ${monty.class:tbp.monty.simulators.HabitatSimulator}
      ...

Monty would only receive the monty: ... portion of configuration to instantiate. Similarly, Environment would only receive the environment: ... (monty sibling one) portion of configuration to instantiate.

In my translation above, habitat_ipc.server part of the tree ends up being the simulator (there’s a separate discussion that on the environment side, environment and simulator are pretty much the same). The habitat_ipc.client part of the tree ends up being the HabitatEnvironment which is basically the interface to the enviroment (local or remote).

I think the general shape is like the above, although the details will probably look different once we get to that point.

@nunoo

I believe that before migrating, it may be necessary to encode this design constraint explicitly in the current code base (e.g. start moving some tests to separate packages).

Yes, this aligns with our intentions as well. Namespace things correctly before extracting them. That’s part of our plan for extracting experimental framing, for example.