Fix gazebo_ros scripts signal handling and do not load the gazebo_ros_api_plugin into the gzclient #1452
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use
exec
where appropriate, such that signals send by roslaunch are received directly by thegzserver
orgzclient
processes and do not have to be forwarded by the shell explicitly.Apply the
$gzserver_pid
variable saved earlier instead of$! in the all-in-one
gazeboscript to kill the server process once the client terminates. The old version should also have been fine, because
$!is the pid of the last _background_ process. Before, variable
gzserver_pid` was unused.With the
gzclient
script thegazebo_ros_api_plugin
was also loaded into the client process. That plugin creates the/gazebo
ROS node, and hence two identical nodes are spawned. Launching the client like that broke the ROS API of Gazebo for us, including/clock
publishing, at least once the GUI would be closed.The
gzclient
script is also what is executed by the launch files in packagegazebo_ros
if argumentgui:=true
(the default). In this case the node names do not clash because roslaunch overwrites the default node name with/gazebo_gui
, but still it is probably unintended to load the plugin into the GUI at all, I assume.This patch eventually fixes #751?