Thymio in Playground: native function to load a bytecode

[MobsyaBot]

Issue by davidjsherman Friday Sep 02, 2016 at 16:39 GMT Originally opened as https://github.com/aseba-community/aseba/issues/550

---

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.

[MobsyaBot]

Comment by stephanemagnenat Wednesday Dec 21, 2016 at 12:13 GMT

---

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.

[MobsyaBot]

Comment by stephanemagnenat Tuesday Mar 21, 2017 at 17:01 GMT

---

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.

[MobsyaBot]

Comment by davidjsherman Tuesday Mar 21, 2017 at 17:12 GMT

---

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.

[MobsyaBot]

Comment by stephanemagnenat Tuesday Mar 21, 2017 at 20:52 GMT

---

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.

[MobsyaBot]

Comment by mbonani Tuesday Apr 25, 2017 at 15:08 GMT

---

@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

[MobsyaBot]

Comment by stephanemagnenat Friday May 05, 2017 at 12:16 GMT

---

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.

[MobsyaBot]

Comment by stephanemagnenat Friday May 05, 2017 at 14:25 GMT

---

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