Robot state should be consistent on load

[stephanemagnenat]

When a new bytecode is loaded, the robot state should be defined and consistent. In particular, IR communication should be disabled.

[riedo]

also, similarly to what is wished in issue #10, i think system sounds and led behaviour should be reinitialized to the startup behavior.

[stephanemagnenat]

Indeed, in particular any incoming mic event should be cleared. That would solve this problem in VPL, in which the sound will continuously play after the first load, until the next robot reset:

[mbonani]

I don't find where to call this function in code to be clean....

[retornaz]

you can't. Aseba bytecode load is stateless at the protocol level.

[stephanemagnenat]

@retornaz we could add a hook in vm.c:745 in AsebaVMDebugMessage on ASEBA_MESSAGE_RESET.

[retornaz]

Yes, in that case a simple memset on vmvariables (with special care for the very specific one like nodeID etc ...) should also be done so that you start with the same value that with a fresh thymio.

BTW, the "when" bytecode should be reseted too.

[stephanemagnenat]

Thanks for these two important points! Do you think the memset should be part of the VM or part of the platform code?

I will change the "when" bit tomorrow.

For now I have added a hook in commit aseba-community/aseba@bb7b10b8133b9fc59ad452542203608772c82f56

[retornaz]

It must be in the platform code. For instance the marxbot/handbot VM should never be managed this way as some critical motor control must never be written to 0 in a such way.

BTW, in the platform code you should basically memset on most of the variables and reset some to the predefined value (fwversion, id, productid and maybe some others I don't remember).

[stephanemagnenat]

Clearing the when bit is implement in commit aseba-community/aseba@38ba0a3

[mbonani]

implement in commit fa2cb60

[mbonani]

in last firmware please close (I cannot???)