Feature Request: Extending rclcpp/rclpy API to Include Action Servers, Clients, and Actions

[PranavDhulipala]

Feature Request: Extending rclcpp/rclpy API to Include Action Servers, Clients, and Actions

Overview

The ROS 2 rclcpp and rclpy libraries currently offer a range of methods for interacting with topics, services, subscriptions, and publishers. However, there is a noticeable gap in the API regarding actions - particularly action servers and clients. This feature request proposes the extension of the rclcpp/rclpy API to include methods analogous to those available for topics and services, but focused on actions.

Current API Limitations

The current version of rclcpp/rclpy (Humble Hawksbill, Ubuntu 22.04, FastDDS/Fast-RTPS implementation) includes methods such as:

• get_topic_names_and_types
• get_publishers_info_by_topic
• get_publisher_names_and_types_by_node
• get_subscriptions_info_by_topic
• get_subscriber_names_and_types_by_node
• get_service_names_and_types
• get_service_names_and_types_by_node
• get_client_names_and_types_by_node

However, equivalent methods for dealing with action servers, action clients, and actions are notably absent.

Proposed Features

To address this limitation, the following methods are proposed for implementation:

• Methods to retrieve action server and action client names and types (similar to existing methods for services and topics something like get_action_names_and_types_by_node, get_action_names_and_types).
• Methods to gather detailed information about active action servers and action clients, (similar to get_subscriptions_info_by_topic or get_publishers_info_by_topic).
• Enhanced introspection capabilities for action-related entities within the ROS 2 graph.

Implementation Considerations

• Compatibility with existing ROS 2 architecture, ensuring the new features seamlessly integrate with the current ROS 2 ecosystem.
• Performance implications, especially in large-scale systems with numerous action servers and clients.
• The potential need for updates or modifications in the underlying ROS 2 communication layers, particularly DDS implementations.

Motivation and Use Cases

The lack of these features limits the ability of developers to introspect and interact with action servers and clients programmatically. In complex systems where actions play a crucial role, such as in robotics automation or complex sensor interaction, this limitation can lead to challenges in debugging, monitoring, and dynamic interaction with the ROS 2 graph.

[audrow]

Hi @PranavDhulipala, this looks like a good feature, but I'm not sure we have bandwidth at the moment.

If you have the time, it would help if you can come up with an idea of how to do this in a way that works with the existing ROS 2 action CLI.