Robot factory

[davidjsherman]

Enki knows about different kinds of robots but does not provide a way for a client program to discover them. Since every VM must provide a node description, there is already a mechanism for reflection, so in some cases isn't strictly necessary to know the concrete robot classes in advance. A client program could be linked with different versions of Enki that provide different sets of robots.

Aseba Playground provides a complicate mechanism for doing this, with glue for Aseba and Dashel, in playground.cpp. It might be cleaner to handle this in Enki.

[stephanemagnenat]

One design issue is that Enki does not know about VM or Aseba, just about robots. In Aseba, robots might have one or more VM (for example the marXbot). That is the reason of the complexity of the glue code in Playground. Enki aims at being a lightweight simulator, a flexible library to build on in third-party applications. Note that there is an ongoing (but currently frozen) refactoring effort in the ecs-refactor branch that will bring Enki to an entity-component-relationship design, making even less interesting to have a robot factory as robots could be assembled at runtime by putting together bodies, sensors and actuators.