New Supervisor API functions to handle robots states

[ygoumaz]

Currently, the wb_supervisor_node_restart_controller function is used to restart a robot controller from a supervisor. By changing the value of the respective controller field, a robot can somehow be restarted and apply a different behavior.

Unfortunately, or fortunately, depending on the case, this combination of operations does not simulate a real shutdown and restart of the robot. Indeed, if the robot motors have an active speed command, when the controller is restarted these motors are not stopped.

This issue aims at proposing one or more new functions for the supervisor API. The following functions could be useful to users:

• wb_supervisor_shutdown_robot: This function would shut down the robot completely. The motors would be completely disabled. A NAO-like robot that would be standing would fall to the ground. The controller would be terminated.
• wb_supervisor_start_robot: This function would allow to restart the robot in the case where it is turned off, that is to say to put it in the same state as at the beginning of a starting simulation and restart its controller.
• wb_supervisor_restart_robot: This function would allow to execute wb_supervisor_shutdown_robot and wb_supervisor_start_robot successively.
• wb_supervisor_reset_robot: This function would be almost equivalent to wb_supervisor_restart_robot. The difference would be in the motor commands that are left to the robot between shutdown and restart of the controller. For this function, a default motor command (non-zero for humanoid robots for example) would always be executed to prevent the robot from collapsing.

These functions are very similar to the existing wb_supervisor_node_restart_controller command but bring the possibility to completely reset currently applied commands and sensors before the restart and also more flexibility for the user in managing the robot state.

Feel free to suggest other API functions or challenge the usefulness of the one proposed here.

[omichel]

I believe that only API functions that should be implemented are:

• wb_supervisor_shutdown_robot.
• wb_supervisor_start_robot.
  The wb_supervisor_reset_robot might simply a convenience function to call wb_supervisor_shutdown_robot and wb_supervisor_start_robot in the same time step, so that a humanoid robot could not collapse in between.
  The wb_supervisor_restart_robot can be achieved by calling wb_supervisor_shutdown_robot, wb_robot_step and wb_supervisor_start_robot, so that a humanoid robot could collapse while it's off during the time step. As such it shouldn't be implemented as an API function.