Action Introspection and Record/Play Support

[fujitatomoya]

Feature request

This is a meta issue to track the related developments for action introspection and record/replay rosbag2.

Feature description

There are 2 major features need to be developed.

Action Introspection

Based on Service Introspection and Topic visibility, we can build Action Introspection to monitor the action communication from the outside. The primary motivation is to enable user to validate the actions are operating as expected at runtime.

as user experience, it should print all specified action data. e.g ros2 action echo /fibonnaci prints status and feedback topic message data, and send, cancel and result service communication.

ros2 bag record/play <actions>

This is an additional feature that can leverage this Action Introspection.
In recording, this feature will be really useful to validate the stored action data especially during development phase and debugging purpose.
In playback, action client bag data can be played to action server for the development, besides it is also allowed to see the goal result via ros2 action echo.

Implementation considerations

The following lists most of development items with corresponding repositories, more details need to be described in REP to beak down the tasks.

• Action topics and services deduction and code generation

technically actions are based on topics and services, those types are created from .action file.
topics are just fine, services are extended with ServiceEventInfo.msg.
So we can expect we do not need add more message or service types for supporting .action.

for the service activity in the action, we might as well the service_event messages need to be generated accordingly.
see more details for ros2/rosidl#700, i am not sure if this code generation is taking place for action as well with the current implementation. if not, we need to extend this code generation for action support.

• Action introspection configuration support for rclcpp and rclpy

introspection should be disabled by default not to affect the performance of action server or clients. This configuration is enabled by user application explicitly on each action server or client, then introspection services and topics are exposed. (similar with ros2/rcl#997)

• ros2 action echo <action> support for https://github.com/ros2/ros2cli

based on the specified action type, it can deduce the corresponding services and topic to be printed.
printing messages are categorized into feedback, status, goal request, cancel and result so that user can understand what is going on with this action communication.

• type support helper functions for rclcpp

similar with ros2/rclcpp#2209 to look up for the corresponding type support handlers based on the action type.

• GenericActionClient for rclcpp

similar with ros2/rclcpp#2358 to add GenericActionClient class for the playback from the rosbag2. this is required since rosbag2 needs to be able to resolve the action type dynamically from the action bag data.

• ros2 bag record/play with action.

Currently topics and services are stored in a single record since that handles a single message type, and playback relies on to replay the message from the bag file. To support action in the data base, we need to consider database data structure since a single action type has multiple topic types and services types.
record deduces the corresponding topic and services types internally to start the subscription and store the data into the database.
play uses GenericActionClient to look up the action type, and then behaves as ActionClient to send the requests from the bag data.

[fujitatomoya]

CC: @Barry-Xu-2018