Catalog of known robots as targets for offline compilation

[davidjsherman]

Node descriptions for known robots are kept in two places in targets: the dummy node, which is a target by itself, and the simulated robots in the Playground.

In order to compile an Aesl program, it is necessary to have a node description. Currently the only way to obtain node descriptions is to have a running robot. However, there is a use case for offline compiling a bytecode for a known robot architecture. It would be useful to be able to build a catalogue of node descriptions.

If there were a logical way to refactor the code, with all targets (dummy or simulated) grouped into a common library, this catalog could be constructed statically.

Alternatively, it would be acceptable to instantiate a VM for each kind of known robot, and query each VM for its node description. In this case the catalog would be built by calling all of the robot factories in a structure similar to the robotTypes map from playground.cpp#L430. Note that the logic in Playground is a little bit complicated, since robot factories extend Enki robots.

[davidjsherman]

Is there a use case for adding the dummy node to Playground?

[stephanemagnenat]

I agree that it might be interesting to have a static way of retrieving a node description for testing.

Two comments:

• The factory in Playground is complicated, not only because of the extension of Enki robots, but also because robots might have one or more VM, and therefore there is a need for an indirection between robots and VM.
• Note that when creating a robot you need more than the description, as for example in Playground there is a context that is necessary for the robot to interact with the viewer, report messages to the environment, receive inputs, etc. That is not necessary for exposing the description itself though.