What is the ROS way to start/pause/shutdown nodes from within other nodes?

asked 2020-05-22 17:40:46 -0500

Dragonslayer
574 ●18 ●78 ●33

Iam looking for the best practice model to control nodes start/pause/shutdown with c++.

Use-cases:

Separating move_base, navigation, localization and manipulation.
Switching between localization nodes to achieve higher precision.

It seems that tf would be the biggest problem, as map -> odom -> base_link would get interrupted bringing all related nodes down as well.

edit retag flag offensive close merge delete

Comments

I know is not exactly a correct (due to the fact you specified c++) but a workaround could be to do a small rospy node with an action callback which subscribes to an action which allows to do the "node management" allowing to start, pause and shutdown the system. Then, from any other cpp node, sending information with this action, you should be available to control the nodes.

I'm just proposing this approach because is the one I am using and I am satisfied with the results, but seeing that you are trying to do that in order to optimise resource management, i do not know if it will be the perfect approach for you.

Solrac3589 ( 2020-06-17 01:45:46 -0500 )edit

Thanks for the reply @solrac . If its an "easy fix" I can go with python. Do you have it on github, or do you know someone elses code where this was actually implemented, so I could get a clue how to change the sourcecode of the nodes to work with this? At the moment Iam looking at the "system()" functionallity to "automate" console functionallity.

Dragonslayer ( 2020-06-17 08:50:36 -0500 )edit

I'm afraid all the code I am working with is owned by an enterprise and private, but if I am not wrong, this could be an example http://wiki.ros.org/roslaunch/API%20U...

Solrac3589 ( 2020-06-18 00:32:53 -0500 )edit

Thanks for the info. I also found out that ros api actually has a shutdown function for the nodes. For some reason I thought that only a master kill will shutdown a node, but of course ctrl-c works on single nodes as well, dont know where this missunderstanding came from. I also found this "node manager" link text ,wich should have lots of helpful code on its github page. Thanks again.

Dragonslayer ( 2020-06-18 10:35:03 -0500 )edit

add a comment

answered 2020-06-12 00:55:59 -0500

achille
464 ●13 ●34 ●25 http://achille.fyi

updated 2020-06-16 12:07:53 -0500

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.

edit flag offensive delete link

Comments

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.

Dragonslayer ( 2020-06-12 08:56:09 -0500 )edit

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

achille ( 2020-06-14 16:04:43 -0500 )edit

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 ...(more)

Dragonslayer ( 2020-06-15 08:21:32 -0500 )edit

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 ...(more)

achille ( 2020-06-15 12:23:07 -0500 )edit

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.

Dragonslayer ( 2020-06-16 09:53:26 -0500 )edit

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!

achille ( 2020-06-16 12:10:51 -0500 )edit

Thanks for your help @achille !

Dragonslayer ( 2020-06-16 15:38:27 -0500 )edit

SMACC, a C++ statemachine for ROS was just announced

achille ( 2020-06-21 17:52:01 -0500 )edit

see more comments

What is the ROS way to start/pause/shutdown nodes from within other nodes?

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

What is the ROS way to start/pause/shutdown nodes from within other nodes? edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

What is the ROS way to start/pause/shutdown nodes from within other nodes?