add lifecycle_msgs

[Karsten1987]

No description provided.

[mikaelarguedas]

nicktip: I think we aim for alphabetical order

[mikaelarguedas]

I don't think that you need to depend on std_msgs if you are using only primitive types (dependency can be removed from package.xml too)

[mikaelarguedas]

except nicktips looks good to me, maybe we will wait to merge it along ros2/rclcpp#265 given that it'll be the first piece of code using these messages?

[tfoote]

We commonly put the state enumerations into the msg to make sure that they're available cross platform. I know that this is a little bit lower level and the goal is for all of this to be in rcl only but even if we choose not to enumerate here, it would be great to add a comment where to look up the valid states. It might make sense to simply have a State message with the integer and the enums. It's extra overhead but improves insepction. And can be reused for publishing the state and rendering the state in the future since the data will be semantically typed.

[gbiggs]

I wonder if ease of introspection would mean that the state name should be used instead of enumeration values? I can see the efficiency value in using one-byte numbers, but I can also see the value in being able to see state names from the command line. What concerns me is that unlike the enumeration used in the implementation, these messages form an external, visible interface.

I guess this probably needs more thinking about in terms of how we'll interact with a node's life cycle state machine. If there is a command line tool to manage them, then it can provide readability through its interface, but if we're going to end up using rostopic and rosservice to do it, then the messages themselves would need to be human-readable. I think I prefer the former.

Either way, the state enumerations should probably be in the message, as @tfoote suggested.

[wjwwood]

Related to this, there was a discussion at some point about making rostopic echo in ROS 1 print out the "constant name" rather than the value. I can't find the discussion, it may have been in person, but the idea was that you could "hint" in the message description as to which fields would use the constants as values.

For example:

# Foo.msg

# hint: start constant group "states"
int STATE_ONE = 1
int STATE_TWO = 2
int STATE_THREE = 3
# hint: end constant group

int state  # hint: uses "states" constant group
int something_else

If you echo'ed that you'd get something like this:

---
state: STATE_ONE (1)
something_else: 1
---
state: STATE_TWO (2)
something_else: 2
---
state: STATE_THREE (3)
something_else: 3
---

This is done by rostopic echo introspecting the message comments to find the relationship between the values and comments. This doesn't help you when using this message programmatically, and doesn't address corner cases like groups having duplicate values, but at the time we were looking for a convention that didn't require a change to the message format. Instead we could change the message format to add the idea of typed enumerations, something like this:

# Bar.msg

enum States {
  STATE_ONE = 1,
  STATE_TWO = 2,
  STATE_THREE = 3,
}

States state
int something_else

In the end, it seems like a shame to avoid the optimization on a message type that is likely to be sent so many times in virtually all systems. My vote would be to keep the optimization and try to mitigate the introspection issues with tooling, but I can see the point of why strings for states would be compelling.

[dirk-thomas]

Should these messages maybe be closer to the other messages using in rcl (from rcl_interfaces)? I would prefer rcl to not depend on the common_interfaces repo.

[Karsten1987]

I'd left out the states names on purpose for now or two reasons:

• optimization. This also goes along with the fact that in-code I can compare my state to the actual enum value. Therefore I can still avoid using the actual state number.
• customization: Might be a minor point here, but in case users wanted to create their own states, they don't have to modify the lifecycle_msgs

[Karsten1987]

@dirk-thomas What exactly is the difference between rcl_interfaces and common_interfaces? This package contains only lifecycle_msgs, that'd be the only dependency.

[dirk-thomas]

Repositories will need to be released in a specific order. If rcl(*) uses this new package the whole repo needs to be released before. That is the reason why rcl_interfaces is in a separate repo.

[mikaelarguedas]

should constants be defined for the current_state here as they've been defined in the Transition.msg file ? or this would be unnecessarily redundant?

[gbiggs]

What about putting the constants for the default life cycle state in a separate file that gets included by both message definitions?

[Karsten1987]

closed in favor of ros2/rcl_interfaces#11