Release rclc for Galactic

[JanStaschulat]

Galactic branch for ROS 2 was created: https://discourse.ros.org/t/galactic-api-and-feature-freeze-in-rolling/19795

TODO:

• create new branch for Galactic
• new CI job for Rolling
• update CI jobs (Rolling stays the same)
• new bloom release for Galactic
• update codecov badge in README.md

@norro, @ralph-lange @pablogs9 ,@BrettRD

Which PR shall me merge for the Galactic release?

currently open PRs for Rolling:

• Add parameter server functionality: Add parameter server [fix CI] #88
• Quality declaration statement Quality Declaration Statement for Rolling (master branch) #74
• Add Subscription with context pointer add Subscription with context pointer #73 (closed)
• Provide lifecycle services in the rclc lifecycle nodes Provide lifecycle services in the rclc lifecycle nodes #51

[BrettRD]

Leave #73 out; It doesn't change any existing API, and I'd like to backport as far as Foxy.
I also need to resubmit the PR because rclc_executor_remove_subscription needs to be a separate PR.

[pablogs9]

I would like to have parameter server functionality in Galactic. When are we going to release @JanStaschulat?

[JanStaschulat]

Galactic is going to be released on May 23 (Galactic release plan).

So I propose, one week before, May 14th to create a Galactic branch.

I apologize for this late notice. It's the first time we synchornize with a new ROS 2 release. Next time, we should align our timeline with the one from ROS 2 development.

[ralph-lange]

That's still in time. No worries. To be on the safe side regarding the Release Candidate on May 17th, I propose to do the bloom already on May 11th or 12th because the PR to rosdistro may take several days.

[ralph-lange]

I would like to have parameter server functionality in Galactic. When are we going to release @JanStaschulat?

Yes, having parameters server functionality in Galactic would be really great!

[JanStaschulat]

Timeline:

• 05.05.2021 rclc repo: Function freeze and creation of Galactic branch
• 17.05.2021 ROS 2 Galactic: Release Candidate packages are built. Updated releases of ROS Desktop 2 packages available.
• 23.05.2021 ROS 2 Galactic: Announcement of Galactic release
• 27.05.2021 rclc repo: Created bloom release for Galactic (PR to rosdistro: rclc: 2.0.1-1 in 'galactic/distribution.yaml' [bloom] ros/rosdistro#29702)

[JanStaschulat]

@pablogs9 Do you think this is enough time for you to merge the parameter PR until 5.5.2021?

[pablogs9]

@JanStaschulat I'm not sure because we are having a lot of problems with message memory initiation because of rosidl runtimes and generators that use malloc and free instead of rcutils_get_default_allocator... Check ros2/rosidl#584.

The point is that we are going to need to have a kind of conditional compilation depending on ROS2 or micro-ROS. But I'm thinking that maybe we can merge a basic (dynamic memory) version that freezes our parameter API and then makes changes internally taking care of API/ABI changes.

Let me work a little bit more on this and I will reach you with a solution.

[JanStaschulat]

okay, no problem. If the API/ABI is the same, we can update the parameter support later on.

[norro]

I would like to have the lifecycle services in galactic as they make lifecycle nodes so much more useful #51.

@pablogs9, @JanStaschulat Do you think we should/have to unstringify micro-ros lifecycle messages for the release (see @pablogs9's comment here )? This would probably involve changes in the agent, i.e. translation of micro-ros lifecycle messages without strings to vanilla ROS 2 lifecycle messages.

[pablogs9]

From the parameters, we have found that memory management in rosidl_runtime_c and rosidl_generator_c are not really prepared for micro-ROS because they rely on malloc directly.

IMO the first step is to modify these two packages to use ROS 2 allocators (ros2/rosidl#584) instead of raw dynamic memory functions. With these allocators, in micro-ROS, we will be able to customize the dynamic memory calls. But, in any case, dynamic memory operations should take place after the configuration step.

The point is that those rosidl_runtime_c and rosidl_generator_c are integrated in the FastDDS typesupport (here), so:

• that's means that FastDDS typesupport relies on dynamic memory.
• we cannot create high-level packages that init messages in static memory because when running on top of FastDDS middleware dynamic memory operations will cause crashes on that static memory.
• we cannot create micro-ROS high-level packages that rely on operation-time dynamic memory because this will harm realtimeness.

Regarding unstringify micro-ROS packages, personally, I don't like it, because it forces users to launch or configure multiple things on the agent side. I would prefer to offer reduced functionality on the client side that works as expected without any other configuration step.

So, in summary:

• Once Use RCUtils allocators in rosidl_generator_c rosidl#584 is merged and backported to foxy we will be able to control the dynamic memory operations in micro-ROS
• We should init strings in configuration steps using rosidl_runtime_c and rosidl_generator_c and ensure that have a default size: not only initting them, but assigning a certain amount of memory.
• When dealing with Micro XRCE typesupport these strings will not be reallocated in any case.
• When dealing with FastDDS typesupport there will be dynamic memory operations at runtime.

[JanStaschulat]

I created a branch for "Galactic".
https://github.com/ros2/rclc/tree/galactic
You may continue the development on the open pull requests. After merging to the master branch, please also create a PR to backport it to "Galactic".

[JanStaschulat]

Created new bloom release for Galactic (tag: 2.0.1): ros/rosdistro#29702