Thymio in Playground: native function to load a bytecode

[davidjsherman]

See aseba-community/aseba-target-thymio2#17, suggesting a new native function _bytecode.load(n) that resets the VM and loads a bytecode numbered n into memory. This function could first be implemented in the simulator.

The playground XML file must be extended to include an element containing numbered, BASE64-encoded bytecodes.

The existing thymio2, e-puck, etc. elements could by extended to specify an initial bytecode to run. Otherwise bytecode 0, if it exists, could be assumed for every target node.

This functionality could be used to simulate the initial menu behavior of the physical Thymio-II, providing an even more realistic experience.

[stephanemagnenat]

I think that it would be great that Thymio in 1.6 comes with the default behaviours like the real robot, so I assign this issue to 1.6.

[stephanemagnenat]

Is loading a bytecode really the best way to proceed, or could we load an aesl file instead? This would potentially allow to load the source code of multiple robots, if this is desired.

Alternatively we could also directly attach a source code to a robot in playground scene, or even unify the AESL file format with playground scene formats.

[davidjsherman]

For the physical robot, it should be a byte code, since it should be relatively easy to add a native function based on the existing firmware code for reading the SD card.

For the simulator, you are right that an aesl file is more useful. I would suggest including it as a subnode of the XML playground description: it makes sense to have the complete description in one file, and will be simpler to edit.

If some day the simulator acquires a virtual SD reader, then I would expect that it have one SD card for each robot. So that card would logically contain byte codes such as vmcode.abo.

[stephanemagnenat]

I would suggest including it as a subnode of the XML playground description: it makes sense to have the complete description in one file, and will be simpler to edit.

I agree, I'm also considering adding the <event> and the <constant> tags to playground description, so that different robots in a scene can share these.

I am also considering whether the source code of each robot should not be in a separate file, in case we want several robots with the same code (to do some collective experiments for example). Maybe there could be two possibilities, for example the attribute sourceFile to specify an external file, and the text within a robot to specify a text file containing the source for this robot.

If some day the simulator acquires a virtual SD reader,

Issue #513 proposes that, I've enhanced the discussion there.

[mbonani]

@I was thinking about issue https://github.com/aseba-community/aseba-target-thymio2/issues/17 about loading different bytecode from SD cards. For me the first problem comes from we haven't an equivalent of all behavior in asebacode. So I try to do one and it is near to be complete: all-behavior.zip

For sure I drop some part, like the IR-communication, Remote controle and calibrations (double touch button). I put all behavior except the attentive one using the microphone (the program memory is full, and I already use some tricks... it could be improved) It is mainly working with the real robot, but not with the simulated one. It block at initialisation making the big filling loop of a vector.

Also using last build of the simulator it was difficult for me (it is perhaps related to the pick and move bevavior) to use the button of the simulated robot, I will make more test and open an issue if needed

[stephanemagnenat]

The provided code all-behavior.zip mostly works with latest Enki and Aseba master branches. There are some minor bugs (such as the visual indication being on the wrong side for line following), and it seems that the thresholds and weights for distance sensors could be tuned further.

[stephanemagnenat]

Issue #624 created to deal with loading AESL files in Playground, de-assigning this issue, which is about loading binary code, from 1.6.