Next Client Library WG Meeting: Friday 6th December 2024 8AM PT

General
,
1

Hi,
The next meeting of the Client Library Working Group will be this Friday, 6th December 2024 at 8 AM Pacific Time.

We will be reviewing the charter proposal for the ROS 2 Client Library Working Group and continue the discussions from the previous meetings.

2

Meeting minutes

I’m setting up a shared page that will be used to collect all meeting minutes from now on.

Attendees

  • Alberto Soragna
  • Janosh Machowinski
  • Francisco Martin Rico
  • Peter Ndiba

Discussions

  • Reviewed Working group charter document: client-library-wg-charter - Google Docs

  • fix: Expose timers used by rclcpp::Waitables by jmachowinski · Pull Request #2699 · ros2/rclcpp · GitHub this PR follows up on what we discussed in the previous meeting. We need a way to grab the timers out of a waitable in order to add them to an executor.

  • fix(rcl_action): Allow to pass the timer to action during initialization by jmachowinski · Pull Request #1201 · ros2/rcl · GitHub this is a pre-requisite to the above PR. It allows the client library (rclcpp) to create a timer and pass it to the action server rather than have the action server create the timers internally in rcl (which makes it hard to access them from the executor)

    • We discussed allowing to create a rclcpp::TimerBase from a rcl_timer_t object but that’s not easy to do (we need a way to extract clock and context shared pointers from the rcl layer) and probably not the correct approach.
    • Proposal: we may want to have a policy where rcl never creates entities on its own, but they are always created via the rclcpp/rclpy layers. This ensures that they can easily be accessed.
    • Question: this PR introduces an API named rcl_action_server_init2. There are precedents for calling new APIs like this (e.g. rcl_init_timer2), is this a practice we should recommend?

  • Discussed a bug: creating clocks via their constructor, rahter than via a ROS node, will not connect them to a ROS source, so they won’t follow the ROS time. This can be a source of hard to debug problems. We still should allow to create MONOTONIC or SYSTEM clocks without a node.

  • feat: Add ClockWaiter and ClockConditionalVariable by jmachowinski · Pull Request #2691 · ros2/rclcpp · GitHub This PR fixes a bug / bad design related to the above problem.

    • This PR simplifies how “wait until” is managed for different types of clocks, even if there’s some code duplication.
    • We should deprecate the Clock::cancel_sleep_or_wait API. This was introduced in Jazzy right before the code freeze. Likely no one is using it and it’s broken.
    • How to avoid this type of issues? We could anticipate the code freeze, or we could leverage more features like the “experimental” namespace. We have to be careful to not discourage contributors or just delay the problem.
    • Question: if we break API/ABI for a class in the experimental namespace, are we affecting people that are using rclcpp but are not using this class?

  • Waitset not triggering timer when initialized in lifecycle node · Issue #2652 · ros2/rclcpp · GitHub High priority bug around waitset executors.

    • A unit-test in rclcpp capable of reproducing the problem would really help us fixing the problem

TODO work

  • Ask if we can deprecate Clock::cancel_sleep_or_wait
  • Write a unit-test for rclcpp #2652
  • Discuss experimental namespace or anticipated code freeze with ROS PMC
  • Review PRs around timers and rcl action, as they are pre-requisites for improving the timers manager.

Thank you everyone for joining!
See you on December 20 2024

1 Like