design
design copied to clipboard
ros2
Define external life cycle management interface
The previous version of the document only gave an ambiguous description of the external interface used to manage a node's life cycle. This pull request describes the interface in detail, including topic names, and message and service definitions.
Some high level feedback for now:
- Do we need a specific service for every requested transition? Having a single service which takes an argument would make the API more flexible (since it would work for any state machine defined).
- Currently ROS 2 does neither have the concept of a namespace nor latching. While we hope to support something similar in the future it might be problematic to refer to those terms in the design doc for now.
Regarding the Travis error: every sentence in the markdown files should start on a new line. Hopefully if you update the patch the ugly error should go away.
I'd like to propose to rename create and destroy into init and deinit respectively. I am having trouble with the word create, since we don't have a factory which creates nodes and we encourage users to inherit from a generic base class. That being said, a create function is more like a constructor and a destroy is a destructor which never really gets called externally.
Concretely speaking, this would result in an non-op constructor, getting called when a user instantiates a new node. The respective init function, then, which is responsible for enabling all pub/sub etc, can get triggered externally.
I don't feel that renaming them to init and deinit is correct. These two functions are more intended to be provided by a container system that has a factory to create and destroy nodes on demand, rather than by the nodes themselves. This is why they are not included in the node's external interface specification. If a managed node is created by a user in their own main(), then there will be no create and destroy calls.
If I clarify the document to make this clear, would that be satisfactory?
If I clarify the document to make this clear, would that be satisfactory?
+1; that would be a useful improvement.
Overall, this document looks good to me.
Maybe I just missed it, but where and how does the management interface return the current state?
The current state is broadcast on a topic, and is also accessible via a service.
I clarified that create and destroy are functions of a container system, but I think the document could do with more detail on what a container is and what interface it should provide. However, that needs more discussion about what, if anything, we want to do with containers.