Refactor example and message packages

[wjwwood]

We should split up the examples to be rclc or rclcpp specific.

AC:

• Split userland into rclc_examples and rclcpp_examples
• Refactor simple_msgs
  • Have a meeting to decide on the types here (perhaps get rid of Int32 for example)
  • Make a common_msgs repository and move messages out of this examples repository.

[wjwwood]

I think we should do this before moving on the the demos, and before we get a bunch of new outstanding branches. I think it will also speed up our build by removing some unused messages. So I've updated proposal:

New repository common_interfaces with packages:

builtin_interfaces (was builtin_msgs)

• Time.msg
• Duration.msg

std_interfaces (was simple_msgs)

• Drop these messages:
  • AllBuiltinTypes.msg
  • AllDynamicArrayTypes.msg
  • AllPrimitiveConstants.msg
  • AllPrimitiveTypes.msg
  • AllStaticArrayTypes.msg
  • Imu.msg (should probably be moved to a sensor_interfaces)
  • Imu32.msg
  • Intraprocess.msg (some version of this should be moved to rcl_interfaces)
  • Nested.msg
  • Quaternion.msg (should probably be moved to a geometry_interfaces)
  • Quaternion32.msg
• Potentially drop these messages (depends on our decision):
  • Int32.msg
  • String.msg
  • Uint32.msg
  • Vector3Float.msg
  • Vector3Int.msg
• If these "base type messages" are not dropped, bring them up to parity with ROS 1's std_msgs.
• Add/keep messages from ROS 1's std_msgs and std_srvs:
  • ColorRGBA.msg
  • Empty.msg
  • Header.msg
  • MultiArrayDimension.msg (maybe drop?)
  • MultiArrayLayout.msg (maybe drop?)
  • Empty.srv
  • Trigger.srv

example_interfaces (was userland_msgs; could be moved to it's own repository, but not strictly necessary)

• AddTwoInts.srv

Optionally we could "sync" more of the ROS 1 msg/src packages to the ROS 2 common_interfaces repository.

Changes to the examples repository:

• Remove the builtin_msgs, simple_msgs, and userland_msgs packages.
• Rename/split userland into rclcpp_examples and rclc_examples (rclc as needed).
• Remove unused or outdated examples like the intra-process example and the Imu examples.
• Remove examples that have been superseded by tests like the publisher and subscriber examples.
• Try to keep the examples "simple" and straight forward. Use demo packages and automated tests to exercise the system.
• Add packages for the demos as they are needed.

@tfoote @esteve @jacquelinekay @dirk-thomas for comments.

[wjwwood]

I'm going to go ahead and start preparing some of the changes that I think will be least controversial.

[wjwwood]

This brings up the issue of can we have std_interfaces/Empty the msg and srv? @dirk-thomas did the changes you made to namespacing allow for this?

[dirk-thomas]

Yes, messages and services have different namespaces now - test_communication already includes an Empty message as well as an Empty service.

Regarding the renaming of std_interfaces / simple_msgs and "importing" messages from ROS 1 I would recommend to wait until we have resolved the questions related to the ROS 1 bridge.

builtin_msgs is kind of a "magic" name since it requires special handling in some rmw implementations. I would consider to put it in a separate repo. If the package will never include services do we still want to rename it?

[wjwwood]

Yes, messages and services have different namespaces now - test_communication already includes an Empty message as well as an Empty service.

Cool, it should probably pull that from std_interfaces after we do this.

Regarding the renaming of std_interfaces / simple_msgs and "importing" messages from ROS 1 I would recommend to wait until we have resolved the questions related to the ROS 1 bridge.

Why's that? I thought we had decided to go with the _interfaces convention (we've already renamed many packages in line with this strategy like ament and rclcpp). I'm open to other suggestions, but regardless to how the ROS 1 bridge is built I thought it was desirable to not collide with the ROS 1 message packages by name.

As for importing ROS 1 messages, I was just bring it in line with the ROS 1 std_msgs and std_srvs packages. That and anything more is optional.

builtin_msgs is kind of a "magic" name since it requires special handling in some rmw implementations. I would consider to put it in a separate repo. If the package will never include services do we still want to rename it?

But the rmw implementations don't depend on it, so I don't see a technical reason to put it in a different repository. Maybe instead it should be included with the rcl_interfaces repository, since that's the convergence of generated code and using it with a middleware, which is where the builtin_msgs's magic comes in. I think consistently using the _interfaces suffix would be better than using it in some places and _msgs in other places, so I'd prefer to rename it if we decide to use the suffix.

[wjwwood]

Another idea is to just merge builtin_msgs into std_interfaces and do conditional "magic" based on package name and message name, rather than just package name. I don't think the "magic" messages will grow beyond time and duration, but I guess I could be wrong about that.

[dirk-thomas]

To summarize the new structure - please correct it if I got some of it wrong:

• common_interfaces (repo)
  • builtin_interfaces
  • import from ROS 1 with renaming as necessary:
    • std_msgs
    • std_srvs
    • all packages from common_msgs
• examples (repo)
  • example_interfaces
  • rclc_examples
  • rclcpp_examples