Loadable agents recap and future

[basicNew]

@stonier @clalancette below I'm summarizing what we talk yesterday (Daniel, I had a chat with Chris after we spoke) and a couple of thoughts on the loadable agents concept (please feel free to add/remove stuff here as you see it fits). My intention is to have this mainly as food for thought and discuss it on our Thursday meeting.

Historical context

• When the loadable agents idea was born, the python bindings were not yet started on delphyne. Also, drake had an initial python binding implementation for some core classes, but there was not much activity around them.
• Even though it was not an explicit constraint, delphyne was seen mostly as an applicaiton executable (vs. a library or framework).
• There was a future requirement that agents could be added and removed dynamically from a simulation to make it performant (e.g. if we have a big city, why use resources to simulate a pedestrian that is 10 blocks away of our car).

Considering that, having dynamic loadable agents was the reasonable thing to do, as it would allow us to fulfill those requirements. On top of that the agent developer would be able to just use drake as a library to write the agent-as-a-plugin and later instruct the backend to load it.

Current situation

• Drake's python bindings have move forward a lot in the past months and we have also been able to create bindings for our delphyne classes (which make use of Drake ones too). Currently, all of our demo examples are scripted in python and, while I haven't tested it yet, I'm 99% sure it should be possible to create an agent that is entirely programmed in python.
• We have started to see delphyne more as a simulation playground (more closely related to the concept of a framework) rather than as an application that can be configured.

The original question that came up was "do we actually need loadable agents?" and I think that part of the answer to that comes from another question: Do we want to provide an interactive simulation application or a framework? If the former, I think having agents as plugins makes total sense, as it allows to configure the app from the outside. If the latter, then maybe agents as plugins are not required, as the agent programmer can just import both drake and delphyne backend libraries and write a program that instantiates its custom agents and kicks off the simulation.

Pros and cons

• Delphyne as a application

  • Pro: Only exposing a subset of the functionality to the outside world, so less work on maintaining / versioning a public-facing API.
  • Pro: Code is done to a great extent and integration with python would end up being rather simple.
  • Cons: Complex plugin implementation + some casting magic to make it work.
  • Cons: As is now, agent plugins can only be written in C++ (we could however work this out to allow python agents too. However, I wouldn't go this way, as we would end up having to support both an application and a framework).

• Delphyne as a framework

  • Pro: More flexibility to the agent writer. Still need to check this, but most likely the agent programmer could code in either python or C++.
  • Pro: We would remove the dynamic agent-loading machinery and generic parameters.
  • Cons: We should start versioning APIs, checking for backwards compatibility, etc, etc.
  • Cons: As is now, we should throw away a non-trivial amount of code and write new one to support this approach.

[stonier]

Pro: More flexibility to the agent writer. Still need to check this, but most likely the agent programmer could code in either python or C++.

How would you write an agent in python? You'd still have to pass a c++ agent to the simulation. Perhaps you're thinking of python-bound c++ blocks that can be composed and configured in python to create an agent that gets passed to the simulation?

[basicNew]

I'm thinking of creating the subclass in python, instantiating it and then calling AddAgent with the object itself. This would require a lot of pre-existing python bindings to many drake classes and some changes in the simulation runner, but I'm almost certain it should be doable.

[stonier]

That would be some nice wizardry.

[stonier]

#417 has a working proof of concept for the trajectory agent. I like it, it's much simpler machinery than the loadable plugins. Please raise any objections if you have them today otherwise I'll push for that PR to go in as a first part of a series of two or three PR's to convert the agent loading logic over.

[basicNew]

Please raise any objections if you have them today otherwise I'll push for that PR to go in as a first part of a series of two or three PR's to convert the agent loading logic over.

@stonier my concerns are not on the approach itself, but more on the side of how much we are stretching Milestone 2. As we are right now both python bindings and loadable agents are working and, after your "has-a" PR, they reuse the Drake's code for the cars. So, if we could focus on the remaining low-hanging fruit, maybe in a week or two from now we could be closing it. How do you feel about reviewing this in our sync tomorrow?

[stonier]

From the sync yesterday:

Finalising how we load agents was probably the primary goal for M2 so I can focus on actually building agents immediately in M3. I don't plan for this to push out M2 any further - #417 gets us very close, the remainder of the work will come in on the weekend.

The list in #378 is final, looking forward to nailing the necessary parts of that next week!