When using the new reset method with the emitter-receiver scheme, supervisor receiver gets two extra messages causing two additional resets. See screenshot showing the console of the regular discrete cartpole modified to use the new reset scheme.
According to the simulationReset() method documentation, the controllers need to be restarted separately. The robot controller seems to send two extra messages after the first time the done condition causes a reset.
According to Webots user guide emitter/receivers queues are flushed when calling reset. This was bugged in earlier versions of Webots (<R2020b, more here).
So far, i've found out that if robotController is forced to reset using restartController() as soon as the done condition becomes True (inside is_done() implementation), one of the two extra messages goes away.
I'm investigating further to find out where the second one comes from and when, and whether it is caused by us or it is caused by Webots.
When using the new reset method with the emitter-receiver scheme, supervisor receiver gets two extra messages causing two additional resets. See screenshot showing the console of the regular discrete cartpole modified to use the new reset scheme.
According to the
simulationReset()
method documentation, the controllers need to be restarted separately. The robot controller seems to send two extra messages after the first time the done condition causes a reset.According to Webots user guide emitter/receivers queues are flushed when calling reset. This was bugged in earlier versions of Webots (<R2020b, more here).
So far, i've found out that if robotController is forced to reset using
restartController()
as soon as the done condition becomes True (insideis_done()
implementation), one of the two extra messages goes away.I'm investigating further to find out where the second one comes from and when, and whether it is caused by us or it is caused by Webots.