Dependencies and launch sequence

[Nico Hochgeschwender]

Hi all,

I would like to propose/extend also another feature which has been mentioned: launch sequence. Not only "Node A before Node B", but also a group of nodes before another group of nodes. This makes sense for instance in the case when one wants to launch first the hardware/driver nodes and then the processing nodes etc. Just a minor comment.

Best regards,
Nico  

[Lorenz Mösenlechner]

Hi,

I know that launch order has been proposed before. But I also believe
that this feature is not necessary and should be kept out of
roslaunch. Topics are defined to not require a specific startup order,
you can start publishing or subscribe at any time you want. For
actions and services there are functions to wait for them to come up
if necessary and latched topics can be used to make sure that a node
receives the most recent data as soon as possible.

Adding startup dependencies will not only make the whole
implementation more complex. It's also not clear to me how to handle
for instance nodes that died. Should all nodes that depend on a dead
node also be shutdown? How to handle respawn then? How to actually
know when a node completed its startup procedure? I don't think that
extending the middleware to provide sort of a live-cycle state machine
is a good option here.

I think there were good reasons for not adding startup order and we
shouldn't change that. In particular because the design of the ros
middleware already provides means for startup synchronization if
really necessary on a node implementation level. Implementing nodes to
not require any startup order is not hard, so why complicating the
whole system?

Lorenz

> --
>
>



--
Lorenz Mösenlechner | moes...@in.tum.de
Technische Universität München | Karlstraße 45
80335 München | Germany
http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910

[Dan Lazewatsky]

At times I find myself wishing that it was possible guarantee launch order, but I agree that it is probably more robust for each node to individually ensure that all its requirements are running (using things like wait_for_service()) rather than assuming roslaunch will take care of it (what about nodes that aren't started using roslaunch?). Since this has been proposed before, I think it would be good to see what use-cases people come up with, and explore what the current solution is for each one, and how that could be improved. 

For example there are a lot of services that need to be up for the manipulation pipeline, and waiting for each one is a pain. Maybe there could be a way to signal that a group of services/actions/dynamically reconfigurable parameters/etc. is ready without explicitly waiting for each one.

-Dan

--

[Christian Dornhege]

I also agree with that assessment. I think the most important point preventing this to be usable is that we really do not know when a node is started.

Given most of the use cases for this, it does not mean that the binary is running, but that some topics and services are enabled. Who knows what those are?
It would need to be specified as dependencies for a each client node.
A node might come up with part of the services that it can provide while others currently aren't available. For some nodes that might be all that is needed
for others not.

If there is some use case that can't be solved with the current methods, we can discuss what a proper solution might be.

For the "service group signals": I'm not sure if that would improve anything. I guess ideally each node should do initialization and bring up its services first before waiting for services (for example to prevent deadlocks). But after that you will have to wait for the  last client service one to be available if grouped or not. I would assume that once all services are available waiting for each individual one is fast. If that is not the case, it should be improved.

[Nico Hochgeschwender]

Hi all,

Am Dienstag, 14. August 2012 23:41:45 UTC+2 schrieb Dan Lazewatsky:

At times I find myself wishing that it was possible guarantee launch order, but I agree that it is probably more robust for each node to individually ensure that all its requirements are running (using things like wait_for_service()) rather than assuming roslaunch will take care of it (what about nodes that aren't started using roslaunch?). Since this has been proposed before, I think it would be good to see what use-cases people come up with, and explore what the current solution is for each one, and how that could be improved. 

The problem which you described is exactly the motivation for the proposal. Things like wait_for_service() are good but it becomes a bit complex when you have to wait for a couple of services. In addition, having such a dependency described in one particular place (launch file) could help to cope with the complexity. Having the dependency on a service/action level would also not require to introduce a life cycle state machine. In case there are changing requirement you still have to modify the launch file, but not a (maybe) couple of node implementations. In any case, I could imagine that the whole dependency stuff is optional anyway.

Nico

 

[Lorenz Mösenlechner]

Hi,

the problem with launch dependencies is that they are absolutely not
trivial and dependency management based on roslaunch will introduce a
lot of complexity, not only in the implementation but also for the
user. Node dependencies needed to be documented properly, the user
needed to deal with renamed or new actions or services manually etc.

Does anybody have a specific use case in mind that is hard to solve
with the current middleware implementation? I understand that it can
be a burden to wait for a lot of services or actions in user code, but
would that really become easier with launch dependencies? All services
still needed to be specified somewhere and I believe it's better to
keep them at the place they semantically belong to, the node that is
using them.

Lorenz

On Fri, Aug 17, 2012 at 2:50 PM, Nico Hochgeschwender

[Bhaskara Marthi]

On Fri, Aug 17, 2012 at 6:37 AM, Lorenz Mösenlechner <moes...@in.tum.de> wrote:
> Hi,
>

> the problem with launch dependencies is that they are absolutely not
> trivial and dependency management based on roslaunch will introduce a
> lot of complexity, not only in the implementation but also for the
> user. Node dependencies needed to be documented properly, the user
> needed to deal with renamed or new actions or services manually etc.
>
> Does anybody have a specific use case in mind that is hard to solve
> with the current middleware implementation? I understand that it can
> be a burden to wait for a lot of services or actions in user code, but
> would that really become easier with launch dependencies? All services
> still needed to be specified somewhere and I believe it's better to
> keep them at the place they semantically belong to, the node that is
> using them.
>
> Lorenz
>

I agree that this would be a complex feature and needs more use cases.
I once toyed with the idea of having a framework whereby a node could
send named 'events' to its roslaunch process (or maybe ros core) which
could then be used to condition other actions within the launch
process. But it seemed too heavyweight for existing use cases.
- b

> --
>
>



--
Bhaskara Marthi
Research Scientist
Willow Garage Inc.
650-475-2856