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.
EDIT: If you can afford to switch, ROS 2 has lifecycle management built in.
Originally posted by achille with karma: 464 on 2020-06-12
This answer was ACCEPTED on the original site
Post score: 0
Original comments
Comment by Dragonslayer on 2020-06-12:
Thanks for your response @achille. What I meant there is mostly about obtimizing resource use. While navigating I dont need the manipulator controllers to run and more importent to use up bandwith on the serial line, and the other way arround. Also Iam looking for a way to switch between amcl and a scanmatcher for localization. For cmd_vel there is a mux node, I didnt find something like that for tf.
Comment by achille on 2020-06-14:
Right, so what I am suggesting is to only have a service be listening for each node that upon receipt of an 'enable' command, starts spinning up all the node's resources. On receipt of a shutdown request, it simply shuts down those resources. That way it only connects to resources like your serial line when it is active. You'll need some kind of manager to send these requests. A state machine like smach could help do that.
Regarding the mux for tf: I haven't seen that so I'm basically suggesting to write one yourself. See also tf-mux-or-multiple-parents
Comment by Dragonslayer on 2020-06-15:
Thanks for the leads @achille . What you are sugesting is exactly what I came up as well, good to know Iam on the right track. The master node would also be nice as a watchdog, as Ros seems unstable at times, Ros2 seems better. What I still dont get is the "service be listening...spinning up all the nodes resources", to me this sounds like what a launchfile does, specially as it would be nice to be able to "reset"(parameter change) nodes. Also are you talking about building adition service functionality into the nodes themselfs and just skip the main functionality "while(!disabled)...", kind of approach?
Regarding tf-mux I was hoping for a ready made solution but will have to write it myself then, but as I have to write a statemachine and gui anyway, this shouldnt be to bad I think. Do you think smach is worth it? In the end I really would like a c++ implementation of the statemachine. Thanks again.
Comment by achille on 2020-06-15:
If you can switch to ROS2 (all your dependent packages have a ROS2 version), then I would recommend that because of solutions for this like lifecycle management.
Indeed what I am suggesting is akin to a launch file, but a launch file doesn't allow you to do that in ROS1. To reset parameters, you can use rosparam delete and when the triggering service to enable the node comes in, you load all the params again. This service solution only works if you have control over the source code, so it wouldn't work if you're using someone else's package.
I avoid writing smach code myself since it's a pain to setup IMO. Instead I use FlexBE which autogenerates smach code. It's intended for higher level, slow-running state machines and not for low-level fast switching. You could call your ROS services (running c++ code) from the Smach state though.
Comment by Dragonslayer on 2020-06-16:
Thanks again @achille . lifecycle managment looks promissing, I have to read up in detail about it. For Ros I was eyeing on the c++ "system.XXX" functionallity (with launch files and node kills), as you mentioned correct, the state machine would be high-level and time wouldnt be a big issue. I would then have to write a node to funnel through or "fake publish" the topics as to keep the rest of the system calm. Or use the mentioned tf-mux and just put computing power behind it, just let all the nodes run, utilizing just the outputs I want. Although I really would have liked to get this at least basically working, it really might be better to go to Ros2 right away.
Comment by achille on 2020-06-16:
That decision really depends on your setup but starting in ROS2 might save you work down the line in a few years when ROS1 becomes outdated. Hope that helped answer your questions!
Comment by Dragonslayer on 2020-06-16:
Thanks for your help @achille !
Comment by achille on 2020-06-21:
SMACC, a C++ statemachine for ROS was just announced
Comment by Dragonslayer on 2020-06-21:
Thank you very much @achille !!
