Recommendation to manage multiple lifecycle nodes

asked 2020-01-16 13:50:11 -0600

ignacio
68 ●5 ●10 ●13

I imagine a scenario in which there are states, such as standby, hovering, and landing, and each one of these states corresponds to a certain set of active LifecycleNodes. Let's say A, B, and C for standby; D, E, and A for hovering and F, G, and H for landing. It is important to guarantee that in each state the respective nodes will be correctly set and as fast as possible. It may also be necessary to reload parameters.

Questions:

Any recommendations on how to do that and deal with possible state transition failures? Are there plans to create a ROS2 native node/tool to manage multiple lifecycle nodes and perform that sort of task?

edit retag flag offensive close merge delete

Comments

What good timing, I just posted a ticket trying to suss out some of the same topics: https://github.com/ros-planning/navig.... I think we're in early days of lifecycle nodes (and even just people understanding them enough to use them) and there's a lot of room for improvement. I would like to hear the answer to your question as well from folks that might be more directly involved in that sort of thing, but I think it would also be valuable in this question to add what types of things you might want in this tool to help build design requirements (or be involved building yourself :-) ).

stevemacenski ( 2020-01-16 14:03:01 -0600 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-01-16 15:22:45 -0600

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2020-01-16 15:27:56 -0600

Your description reminds me of what the system_modes package created by Bosch was created for.

It essentially almost recursively applies the lifecycle management concept and allows you to configure the mode of a system (your states) through a relatively high-level interface, controlling all required nodes and their individual life-cycles for you.

See the system_modes_examples package for a nice example of how this all works and what it can do.

An alternative could be using behaviour trees, but those would not have support for the domain concepts directly (but would be capable of managing this sort of thing).

Some (related) links:

Lifecycle and System Modes in the Micro-ROS documentation
Lifecycle and System ModesSoftware Release Y1, Deliverable 4.8 of the Ofera project

edit flag offensive delete link

Comments

That is very useful. Thank you very much! This package seems to change the node state accordingly. I still have one concern regarding state transition failure, though. Is it possible to try to change from inactive to active and it just doesn't change. I ask that because I couldn't find any control that guarantees that my node will change its state.

ignacio ( 2020-01-27 15:11:49 -0600 )edit

I would advise you to ask the authors/maintainers of that package. I'm not one of them.

gvdhoorn ( 2020-01-28 03:27:46 -0600 )edit

Could you help me to do that? I don't know how to reach them. Should I ask as a form of Issue on Github?

ignacio ( 2020-01-28 10:14:20 -0600 )edit

Yes. Post an issue on their tracker.

gvdhoorn ( 2020-01-28 11:42:04 -0600 )edit

If a node does not switch from inactive to active, then the mode monitor of the system modes package will detect this discrepancy between target state and actual state. The provided mode inference mechanism allows to query this state even from another application node (e.g., inside some task execution state machine or behavior tree). Furthermore, we are currently working on a simple rules mechanism to define recovery behaviors for such cases.

ralph-lange ( 2020-01-29 11:04:08 -0600 )edit

Please find another example for the use of the system modes concept (besides the integrated example in the system modes repo) at https://github.com/MROS-RobMoSys-ITP/.... This demo shows the runtime reconfiguration of the whole Navigation2 stack using system modes. As a teaser, you may watch the video at https://youtu.be/PTyfaGybxl8

ralph-lange ( 2020-01-29 11:08:03 -0600 )edit

add a comment

answered 2020-02-12 09:48:34 -0600

Arne Nordmann
28 ●3 ●4 ●7

As mentioned by gvdhoorn and ralph, system modes might be of help for you. They provide a hierarchy abstraction (systems of systems of nodes) and a mode-manager that manages state and mode of these entire (sub-)systems. See system_modes package and its examples.

We also intend to provide rules to deal with the case that a node or system is not in its intended state/mode. I just created an issue with our first basic thoughts on that.

Love to hear your thoughts and feedback!

edit flag offensive delete link

Comments

Thank you for all your comments and responses! We are currently trying to integrate the boost state chart to our action server, which will trigger all system-modes client calls. For now, the system_modes package is doing great.

We will definitely keep this thread open giving feedback! Would you rather receive them on these open issues or here (ros.answers)?

ignacio ( 2020-02-12 11:44:03 -0600 )edit

As ROS Answers is a Q&A site which works best with a 1-to-1 ratio of questions-to-answers, I would suggest you accept the answer provided to you and move any discussion or further feedback to a more appropriate place.

gvdhoorn ( 2020-02-12 11:56:28 -0600 )edit

add a comment

Recommendation to manage multiple lifecycle nodes

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Recommendation to manage multiple lifecycle nodes edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Recommendation to manage multiple lifecycle nodes