[ros-users] Multiple init/start/shutdown cycles without restart

Tully Foote tfoote at willowgarage.com
Fri Jan 7 22:38:24 UTC 2011


Hi Dirk,

On Fri, Jan 7, 2011 at 12:03 PM, Dirk Thomas <dthomas at sim.tu-darmstadt.de>wrote:

>  > I'm not sure if you need to un-init to stop and start ROS (for example,
> to contact multiple masters, etc). The ros::init() function only processes
> command line arguments.
>  >
>  > There's some example code in wgtest_status_indicator that runs a
> persistent node that can reacquire the ROS Master, and start and stop ROS.
>  >
>  >
> https://code.ros.org/svn/wg-ros-pkg/stacks/wg_hardware_test/trunk/wgtest_status_indicator/src/nodes
>
> @Kevin: actually i want to be able to restart the ROS node. This may
> include
> different command line arguments, mappings, whatever. Therefore the cycle
> should
> cover all aspect including the initialization.
>
>
> > Out of curiosity, what's your use case?
>
> @Blaise: good question, difficult answer :-)
> Currently it is more a prototype and testing than a real world application.
> I build a ROS node (or a ROS Nodeletmanager) in a shared library. This
> library
> is then loaded and run from an other binary. This binary should be capable
> of
> restarting the ROS node with e.g. modified command line arguments if
> needed.
> If the library is rebuild the binary must unload/reload the modified lib.
> But
> if only command line arguments are changed it should keep the current lib
> loaded and just perform a second cycle.
> I will post more details of the use case when i am some steps further...
>
>
I'm not sure that restructuring the roscpp node to be reinitted regularly is
actually the best way to do this.   Since you're not actually passing new
command line arguments, it doesn't make much sense to simulate the
arguments.  In the default nodelet manager there is examples of how to
replicated everything the command line parsing does w/o recalling
ros::init.

Using the arguments to NodeHandle constructor, as nodelets do,  instead of
recalling ros::init does not set the default NodeHandle constructor which
means that you cannot use that.  However if you are planning to write
libraries which are expected to use seperate remappings than other parts of
the same process it is much cleaner to pass that library a NodeHandle at
construction, and the library will then base all it's communications off of
the namespace embedded in the NodeHandle passed to it.

Stopping and restarting the entire roscpp infrastructure is also dangerous
to do if you might have other ROS based libraries elsewhere in the process
that you could side effect. And you can only have one ROS node per process,
which if the entire node is built into the library it is mutually exclusive
with any other library which wants to use ROS.

If you could explain your use case more fully we might be able to suggest an
approach which would be easier to implement.  We've done several libraries
with the approach I suggested above, for example classes in the tf library
are all use this design pattern for portability.
http://www.ros.org/doc/api/tf/html/c++/classtf_1_1TransformListener.html#a40d8462819c4e5280e8553080c4bd908


Tully

PS For clarity when we refer to ROS Nodes, that actually refers to the
executable.  http://www.ros.org/wiki/Nodes

Currently i am dealing with multiple issues:
>
> - after the first cycle of init(), start() and shutdown() i can't perform a
>   uninit() and therefore no second init(), etc. cycle
>
> - when unloading the library containing the ROS node (which uses log4cxx)
> my
>   application crashes with a segfault due to some internals of log4cxx
>
> - likely more to come...
>
> Dirk
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110107/0d9872a3/attachment-0003.html>


More information about the ros-users mailing list