launch_ros
launch_ros copied to clipboard
Support LifecycleNode and EventHandler in frontend
Feature request
Feature description
It's useful to support LifecycleNode in frontend(xml) as well.
As for LifecycleNode itself, if we only use simple launch files as below, it can be done by just exposing like this https://github.com/kenji-miyake/launch_ros/commit/8daecd810d65ebdea6df32ab145137faa343a80d.
<launch>
<lifecycle_node pkg="lifecycle" exec="lifecycle_talker" name="lc_talker" namespace=""/>
<node pkg="lifecycle" exec="lifecycle_listener" />
<node pkg="lifecycle" exec="lifecycle_service_client" />
</launch>
However, I believe it's not enough useful because we usually would like to write state transitions as well like this.
So I think it's better to support RegisterEventHandler and EventHandlers.
Implementation considerations
I think there are at least two problems.
-
How to expose EventHandlers? Is it okay to add
parse_event_handler
andinstantiate_event_handler
as Action class does? -
How to refer Python Object from frontend? For example,
OnStateTransition
requiresLifecycleNode
object but I think it can't be given in frontend easily. Probably this is what @ivanpauno mentioned here https://answers.ros.org/question/333404/launch-composed-nodes-using-the-launch-xml-frontend/, right?
The topic of having references (i.e.: being able to identify) another action in the XML/YAML frontend is an interesting feature currently not supported. It would be useful, for example, to support event handlers.
So I guess some mechanism for finding Object from all entities.
Does anybody have any idea about this? If somebody guides me, I'll try to work on this task!
@jacobperron To provide some advice on how to move forward with this.
@kenji-miyake Certainly, what you have is a good start (kenji-miyake@8daecd8). I would accept that in a pull request on its own.
Regarding exposing events and event handlers (etc) in the front-end, I suggest we open up a separate issue in launch. I imagine it should be easy to expose the RegisterEventHandler action. Then we need a way to parse EventHandlers
, which I would guess should be fairly easy except when we need to reference other launch actions (e.g. referring to the Python objects as you mention). In these cases, maybe we could limit functionality such that launch actions must be referenced by name (ie. a string). I haven't thought about it much, but if you'd like to continue the discussion it would be great if you opened up a ticket over in launch.
Thank you! I can't make time so much recently, but I'll try to work on this task, so please wait for that. Or somebody else would like to proceed more quickly, then I'd appreciate it if they could open issues and implement a prototype.
@kenji-miyake I can work on this. What is missing in your branch? How do you think it should continue? Thanks.
@esteve What I've done is just exposing LifecycleAction to frontend. So missing things are (even though it's the same as the description of this issue):
- To expose EventHandler (that is not an action) as well.
- To improve class designs so that they can refer to Python objects by name.
- It's because we can't use raw Python objects in XML. We have to search objects by name.
@kenji-miyake Certainly, what you have is a good start (kenji-miyake/launch_ros@8daecd8). I would accept that in a pull request on its own.
@jacobperron I've created a PR based on @kenji-miyake 's work at https://github.com/ros2/launch_ros/pull/327, I'll work on the remaining tasks in separate PRs
@jacobperron I've created https://github.com/ros2/launch/issues/658 to continue the discussion there about the RegisterEventHandler action