Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Design] Add design on recording and replay action #1928

Open
wants to merge 4 commits into
base: rolling
Choose a base branch
from
+139 −0
Open

[Design] Add design on recording and replay action #1928

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
ea9bd92
[Design] Add design on recording and replay action
Barry-Xu-2018 Feb 28, 2025
d8246df
Fix a typo
Barry-Xu-2018 Mar 7, 2025
f989395
Address some of review comments
Barry-Xu-2018 Mar 12, 2025
52f39c7
Update to avoid display issue
Barry-Xu-2018 Mar 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
136 changes: 136 additions & 0 deletions docs/design/rosbag2_record_replay_action.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,136 @@
# Rosbag2 record and replay action

## Context

This design describes how to implement this feature based on current architecture and how to extend current command parameter.

## How to record action message

The implementation of the action uses three services and two topics. For the services, when service introspection is enabled, rosbag2 can record service data through the service event topic (refer to [rosbag2_record_replay_service.md](./rosbag2_record_replay_service.md)). So all data related to the action can be recorded.


## Which topics should be focused on for an action

- goal service

[NameSpace/]ActionName/_action/send_goal (Service Event Topic: [NameSpace/]ActionName/_action/send_goal/_service_event)

- result service

[NameSpace/]ActionName/_action/get_result (Service Event Topic: [NameSpace/]ActionName/_action/get_result/_service_event)

- cancel service

[NameSpace/]ActionName/_action/cancel_goal (Service Event Topic: [NameSpace/]ActionName/_action/cancel_goal/_service_event)

- status topic

[NameSpace/]ActionName/_action/status

- feedback topic

[NameSpace/]ActionName/_action/feedback

For an action, five related topics will be recorded.

### Expand the 'record' command

Newly added arguments:

| Argument Name | Description |
| :-- | :-- |
| --actions ActionName [ActionName ...] | Space-delimited list of actions to record. |
| --all-actions | Record all actions via service event topics and hidden action topics. |
| --exclude-actions ActionName [ActionName ...] | Space-delimited list of actions not being recorded. Works on top of --all, --all-actions, --actions or --regex. |

Updated arguments:

| Argument Name | Description |
| :-- | :-- |
| -a, --all | Record all topics, services and **actions** (Exclude hidden topic). |
| -e REGEX, --regex REGEX | Record only topics, services and **actions** containing provided regular expression. Note: --all, --all-topics, --all-services or **--all-actions** will override --regex. |
| --exclude-regex EXCLUDE_REGEX | Exclude topics, services and actions containing provided regular expression. Works on top of --all, --all-topics, --all-services, **--all-actions**, --topics, --services, **--actions** or --regex. |

### Change output of 'Info' command

Add action part.

Without `-v` or `--verbose` parameter, info command shows as below example.
```
Files: <bag_name>.mcap
Bag size: 39.9 KiB
Storage id: mcap
ROS Distro: rolling
Duration: 4.835s
Start: Mar 18 2024 16:42:14.323 (1710805334.323)
End: Mar 18 2024 16:42:19.159 (1710805339.159)
Messages: 39
Topic information: Topic: /events/write_split | Type: rosbag2_interfaces/msg/WriteSplitEvent | Count: 0 | Serialization Format: cdr
Topic: /parameter_events | Type: rcl_interfaces/msg/ParameterEvent | Count: 0 | Serialization Format: cdr
Topic: /rosout | Type: rcl_interfaces/msg/Log | Count: 39 | Serialization Format: cdr
Service: 1
Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Event Count: 42 | Serialization Format: cdr
Action: 2
Action information:
Action: /fibonacci | Type: action_tutorials_interfaces/action/Fibonacci | Topics: 2 | Services: 3 | Serialization Format: cdr
Topic: feedback | Count: 1
Topic: status | Count: 10
Service: send_goal | Event Count: 20
Service: cancel_goal | Event Count: 2
Service: get_result | Event Count: 9
Action: /other | Type: other_action_interfaces/action/Other | Topics: 2 | Services: 3 | Serialization Format: cdr
Topic: feedback | Count: 2
Topic: status | Count: 20
Service: send_goal | Event Count: 40
Service: cancel_goal | Event Count: 4
Service: get_result | Event Count: 9
```

With `-v` or `--verbose` parameter, info command shows as below example.
```
Files: <bag_name>.mcap
Bag size: 39.9 KiB
Storage id: mcap
ROS Distro: rolling
Duration: 4.835s
Start: Mar 18 2024 16:42:14.323 (1710805334.323)
End: Mar 18 2024 16:42:19.159 (1710805339.159)
Messages: 39
Topic information: Topic: /events/write_split | Type: rosbag2_interfaces/msg/WriteSplitEvent | Count: 0 | Serialization Format: cdr
Topic: /parameter_events | Type: rcl_interfaces/msg/ParameterEvent | Count: 0 | Serialization Format: cdr
Topic: /rosout | Type: rcl_interfaces/msg/Log | Count: 39 | Serialization Format: cdr
Service: 1
Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Request Count: 20 | Response Count: 22 | Serialization Format: cdr
Action: 2
Action information:
Action: /fibonacci | Type: action_tutorials_interfaces/action/Fibonacci | Topics: 2 | Services: 3 | Serialization Format: cdr
Topic: feedback | Count: 1
Topic: status | Count: 10
Service: send_goal | Request Count: 10 | Response Count: 10
Service: cancel_goal | Request Count: 1 | Response Count: 1
Service: get_result | Request Count: 5 | Response Count: 4
Action: /other | Type: other_action_interfaces/action/Other | Topics: 2 | Services: 3 | Serialization Format: cdr
Topic: feedback | Count: 2
Topic: status | Count: 20
Service: send_goal | Request Count: 20 | Response Count: 20
Service: cancel_goal | Request Count: 2 | Response Count: 2
Service: get_result | Request Count: 5 | Response Count: 4
```

### Expand the 'play' command

Newly added arguments:

| Argument Name | Description |
| :-- | :-- |
| --actions action [action ...] | Space-delimited list of actions to play. |
| --exclude-actions action [action ...] | Space-delimited list of actions not to play. |
| --send-action-goal | Send recorded action goal instead of recorded service events and action internal topics. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reverse the logic for the --send-action-goal parameter and send by default the real action's service requests instead of the recorded service events. As far as I understand, this would be a desired behavior in most cases.

Suggested change
| --send-action-goal | Send recorded action goal instead of recorded service events and action internal topics. |
| --send-action-events | Send recorded action service events instead of real action's service calls. |

I also found that --send-action-goal is unclear about what it really means and difficult to explain in the comments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would reverse the logic for the --send-action-goal parameter and send by default the real action's service requests instead of the recorded service events. As far as I understand, this would be a desired behavior in most cases.

There is currently a parameter for play service request. If we reverse the logic for the --send-action-goal parameter, users will notice that the logic for services and actions is different.

  --publish-service-requests
                        Publish recorded service requests instead of recorded service events

I also found that --send-action-goal is unclear about what it really means and difficult to explain in the comments.

How about the following description?
Send recorded action goal. If this command parameter is not set, replay the send_goal service event, get_result service event, cancel_service event, feedback topic, and status topic in the recorded order. You can use ros2 action echo to view it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm, i do not remember exactly how we get to decide this default behavior...
probably user needs to explicitly specify the send the actual request to the service because service server needs to be running in ROS 2 network. compared to the topic playback, this is kinda different expectation for user. the same logic goes to the action playback, the action server needs to be running when user specifies.

@Barry-Xu-2018 --send-action-goal sounds like only sending the goal request, but it just replays all the data stored in rosbag database right? including result request and cancel request.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The naming is hard!
Now I am questioning myself if do really need one more extra parameter --send-action-goal?
It seems that --publish-service-requests is doing exactly what --send-action-goal is supposed to do.
i.e. transform action service events to the real service requests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fujitatomoya

--send-action-goal sounds like only sending the goal request, but it just replays all the data stored in rosbag database right? including result request and cancel request.

Based on my idea, if the '--send-action-goal' is set, rosbag2 will replay the action goal requests in the order they were recorded. User need to launch action server.
When this option is not set, it will replay all recorded action data (in addition to the send_goal event, it also includes the timing of cancel_goal and get_result, as well as feedback and status data. Users can view this through ros2 action echo).

@MichaelOrlov

It seems that --publish-service-requests is doing exactly what --send-action-goal is supposed to do.
i.e. transform action service events to the real service requests.

Yes. The essence of these two parameters is the same: whether to replay request or event messages. I used the new parameter '--send-action-goal' with another consideration in mind, which is to separately control the playback for services and actions. For example, service data is replayed with event messages, while action data can replay goal requests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am inclined to take one option with --publish-service-requests including actions, but i will leave this to you and @MichaelOrlov


Updated arguments:

| Argument Name | Description |
| :-- | :-- |
| -e REGEX, --regex REGEX | Play only topics, services and **actions** matches with regular expression. |
| -x EXCLUDE_REGEX, --exclude-regex EXCLUDE_REGEX | regular expressions to exclude topics, services and **actions** from replay. |
| --service-requests-source {service_introspection,client_introspection} | Determine the source of the service requests to be replayed. This option only makes sense if the "--publish-service-requests" or **"--send-action-goal"** option is set. By default, the service requests replaying from recorded service introspection message. |
Loading