Revision history [back]

There's no best practice AFAIK for force shutting down but you can ask it to shut down using a service as in this question. Rather than shutting the nodes down, I would suggest asking them to temporarily stop publishing by simply having a service that starts spinning and only allows resuming progress when another service call comes in to tell it to resume.

If the hand-off for tf has to be smooth and fast, for example for a fast-moving robot, I would construct a dedicated node that is in charge of the hand-off and ensures that the tf tree is always intact. Other nodes generating localization publish the tf information to this node and it decides what to listen to.

I'm not sure what you mean by "Separating move_base, navigation, localization and manipulation."

There's no best practice AFAIK for force shutting down ROS 1 nodes but you can ask it to shut down using a service as in this question. Rather than shutting the nodes down, I would suggest asking them to temporarily stop publishing by simply having a service that starts spinning and only allows resuming progress when another service call comes in to tell it to resume.

If the hand-off for tf has to be smooth and fast, for example for a fast-moving robot, I would construct a dedicated node that is in charge of the hand-off and ensures that the tf tree is always intact. Other nodes generating localization publish the tf information to this node and it decides what to listen to.

I'm not sure what EDIT: If you mean by "Separating move_base, navigation, localization and manipulation."can afford to switch, ROS 2 has lifecycle management built in.