Stopping containers doesn't disable motor torque

[sebtiburzio]

Stopping containers from the host (compose down or ctrl-C) does not seem to properly shutdown the hardware interface/deactivate motor torque.

Stopping from within the container (ctrl-C) does seem to deactivate the motors properly.

Probably something that can be fixed within the dynamixel_hardware interface on_deactivate() callback method.

[sebtiburzio]

I tested this by adding the on_shutdown method to the hardware interface (seb/implement_on_shutdown)) but still not working - on_shutdown only gets called when stopping from within the container still.

The issue seems to be more deeply connected with how Docker/ROS2 handle the shutdown signals, this seems relevant: https://github.com/ros2/launch/issues/666

[ciandonovan]

@sebtiburzio you are correct, Docker sends SIGTERM by default which isn't correctly handled yet so the launch process gets immediately terminated. Working on a fix here, it should work.

An easier workaround though, and what we've been using up until now, is changing the stop signal Docker uses. You can pass --stop-signal SIGINT to docker run, or add STOPSIGNAL SIGINT to your Dockerfile.

[sebtiburzio]

Thanks @ciandonovan , but unfortunately this workaround doesn't seem to be working in our case. Maybe something for us to review again once the ROS2 signal handing changes have been made.

For future reference I've tried STOPSIGNAL SIGINT in the Dockerfile and stop-signal: SIGINT in the compose file, but not seeing a difference with either.

[ciandonovan]

@sebtiburzio try force ROS2 Launch to be in "non-interactive" mode so it manually forwards the SIGINT signal to your child process with the flag --noninteractive after ros2 launch.

This is in addition to STOPSIGNAL SIGINT in the Dockerfile and/or stop-signal: SIGINT in the compose file.

[sebtiburzio]

For whatever reason, in this case launching in non-interactive mode has the effect that the motors are no longer disabled even when shutting down with Ctrl-C inside the container. I can see from the logs that SIGINT is indeed being forwarded to each of the node processes, so it appears that the particular problem occurs somewhere at the level of ros2_control, or the dynamixel_hardware interface.

Thanks again for the help @ciandonovan , I think if I can figure out the problem of SIGINT handling at the ros2_control/dynamixel_hardware level, we will be able to use the STOPSIGNAL SIGINT workaround to make sure the containers shut down properly.