[WIP] Support recording and replay service #1414

Barry-Xu-2018 · 2023-07-11T06:47:36Z

Related issue: ros2/ros2#1285
The design document https://github.com/ros2/rosbag2/blob/rolling/docs/design/rosbag2_record_replay_service.md

Barry-Xu-2018 · 2023-07-18T02:46:07Z

Current status @MichaelOrlov

Phase 1 (Done)
Commit: bd6e02b
Phase 2 (In progress)
- make type support helper supported for service rclcpp#2209 (Under review)
- Generic client (Depend on make type support helper supported for service rclcpp#2209)
  - Implementation has been finished. Barry-Xu-2018/rclcpp@ad8dbf5. After 2209 is merged, I will create a PR.
- Rosbag2 play request (In progress)

Barry-Xu-2018 · 2023-07-19T02:23:06Z

@MichaelOrlov @emersonknapp

I have a question on filter for mcap implementation.
Current codes as the below

rosbag2/rosbag2_storage_mcap/src/mcap_storage.cpp

Lines 524 to 543 in 744cdf0

    
             if (!storage_filter_.topics.empty()) { 
        
               options.topicFilter = [this](std::string_view topic) { 
        
                 for (const auto & match_topic : storage_filter_.topics) { 
        
                   if (match_topic == topic) { 
        
                     return true; 
        
                   } 
        
                 } 
        
                 return false; 
        
               }; 
        
             } 
        
           #ifdef ROSBAG2_STORAGE_MCAP_HAS_STORAGE_FILTER_TOPIC_REGEX 
        
             if (!storage_filter_.topics_regex.empty()) { 
        
               options.topicFilter = [this](std::string_view topic) { 
        
                 std::smatch m; 
        
                 std::string topic_string(topic); 
        
                 std::regex re(storage_filter_.topics_regex); 
        
                 return std::regex_match(topic_string, m, re); 
        
               }; 
        
             } 
        
           #endif

If --regex REGEX is set, it will override --topics TOPICS.

But sqlite implementation has the different behavior. --regex REGEX and --topics TOPICS can take effect at the same time.

rosbag2/rosbag2_storage_sqlite3/src/rosbag2_storage_sqlite3/sqlite_storage.cpp

Lines 524 to 548 in 744cdf0

    
           // add topic filter 
        
           if (!storage_filter_.topics.empty()) { 
        
             // Construct string for selected topics 
        
             std::string topic_list{""}; 
        
             for (auto & topic : storage_filter_.topics) { 
        
               topic_list += "'" + topic + "'"; 
        
               if (&topic != &storage_filter_.topics.back()) { 
        
                 topic_list += ","; 
        
               } 
        
             } 
        
             where_conditions.push_back("(topics.name IN (" + topic_list + "))"); 
        
           } 
        
           // add topic filter based on regular expression 
        
           if (!storage_filter_.topics_regex.empty()) { 
        
             // Construct string for selected topics 
        
             where_conditions.push_back("(topics.name REGEXP '" + storage_filter_.topics_regex + "')"); 
        
           } 
        
           // exclude topics based on regular expressions 
        
           if (!storage_filter_.topics_regex_to_exclude.empty()) { 
        
             // Construct string for selected topics 
        
             where_conditions.push_back( 
        
               "(topics.name NOT IN " 
        
               "(SELECT topics.name FROM topics WHERE topics.name REGEXP '" + 
        
               storage_filter_.topics_regex_to_exclude + "'))"); 
        
           }

For this PR, new filter parameters for play are added. I have to modify filter related codes.
So the question is whether the filter for mcap should be the same behavior as sqlite ? Or due to certain reasons, the mcap can only be implemented in current way.

MichaelOrlov · 2023-07-20T21:51:04Z

@Barry-Xu-2018 There are a bit of discussion about topic filters in this PR #944. It is a bit stale but some info for the context and probably other questions in this area. I need to reaiterate on it and move forward with it.

As reagrds to the MCAP behavior.
There are no special restriction for MCAP in this case and I think the behaviour should be the same as in the SQLite3.
i.e. --regex REGEX and --topics TOPICS can take effect at the same time.
Feel free to align it in your PR and I will try to "condition" topic filters in the #944.

cc: @emersonknapp

Barry-Xu-2018 · 2023-07-21T01:55:46Z

As reagrds to the MCAP behavior.
There are no special restriction for MCAP in this case and I think the behaviour should be the same as in the SQLite3.
i.e. --regex REGEX and --topics TOPICS can take effect at the same time.
Feel free to align it in your PR and I will try to "condition" topic filters in the #944.

Okay. Thank you.

Barry-Xu-2018 · 2023-08-02T06:49:00Z

@MichaelOrlov @fujitatomoya

I found a problem based on current contents of service event info.

Service and client all enable introspection

---
info:
  event_type: 0      <== request sent event from client
  stamp:
    sec: 1690882511
    nanosec: 241860458
  client_gid:
  - 1
  - 15
  - 235
  - 125
  - 113
  - 20
  - 108
  - 182
  - 0
  - 0
  - 0
  - 0
  - 0
  - 0
  - 21
  - 3
  sequence_number: 89
request:
- a: 89
  b: 3
response: []
---
---
info:
  event_type: 1      <== request received event from service
  stamp:
    sec: 1690882511
    nanosec: 242176284
  client_gid:
  - 1
  - 15
  - 235
  - 125
  - 113
  - 20
  - 108
  - 182
  - 0
  - 0
  - 0
  - 0
  - 0                                                                                                                                                                                                         
  - 0
  - 20
  - 4
  sequence_number: 89
request:
- a: 89
  b: 3
response: []
---

These 2 client gids are different. So we have no way to identify these 2 events for one request.
While there are many events are received at the same (some clients enable introspection and others disable introspection, and service enable introspection), event messages for different clients are mixed. It is impossible to distinguish request.

I have 2 solutions.

Ask user must enable introspection on client (rosbag2 only care event type is REQUEST_SENT).
Change event info struct. Add service_client_gid.
For REQUEST_RECEIVED event, client_gid is the client GID which is the same as client_gid in REQUEST_SENT event. And service_client_id saves ID as current client_id.

I'd like to hear your opinions.

MichaelOrlov · 2023-08-08T03:44:11Z

@Barry-Xu-2018 I am sorry I will be on vacation for the next two weeks and will not be able to take a look at your findings.

@fujitatomoya @emersonknapp Could you please take a look on the issue found by @Barry-Xu-2018 in the previous post?

Barry-Xu-2018 · 2023-08-16T01:08:52Z

Friendly ping @emersonknapp @fujitatomoya, do you have any idea about this issue #1414 (comment) ?

fujitatomoya · 2023-08-24T22:14:58Z

@Barry-Xu-2018 sorry to be late to get back to you.

These 2 client gids are different. So we have no way to identify these 2 events for one request.

before how to fix, how come these gids are different?

i think that gid (event_type: 0) is the client gid via rmw_get_gid_for_client, and gid (event_type: 1) points the same writer gid but that object is managed on server side, that is why this is different?

https://github.com/ros-infrastructure/rep/pull/360/files#diff-7739b7ffccd3276874ea9014c4cd07872efa4e2d60d7c31896e56929ad424455R144-R149

seems like, this is against the design. if the gid is not unique through the transaction, we cannot tell service request and response match.

Barry-Xu-2018 · 2023-08-25T06:50:22Z

@fujitatomoya

https://github.com/ros-infrastructure/rep/pull/360/files#diff-7739b7ffccd3276874ea9014c4cd07872efa4e2d60d7c31896e56929ad424455R144-R149

seems like, this is against the design. if the gid is not unique through the transaction, we cannot tell service request and response match.

Completely agree. The current implementation cannot confirm whether the sent request record and the received request record are pointing to the same request. This doesn't follow the design.

After checking code for rmw_fastrtps, I find service take request

https://github.com/ros2/rmw_fastrtps/blob/b45e73500bc0a2056fdc31197a6f94434b327d55/rmw_fastrtps_shared_cpp/src/rmw_request.cpp#L111-L117

        request.sample_identity_ = info_seq[0].sample_identity;    // Get writer_guid
        // Use response subscriber guid (on related_sample_identity) when present.
        const eprosima::fastrtps::rtps::GUID_t & reader_guid =
          info_seq[0].related_sample_identity.writer_guid();
        if (reader_guid != eprosima::fastrtps::rtps::GUID_t::unknown()) {
          request.sample_identity_.writer_guid() = reader_guid;    // writer_guid will be replace by reader guid. 
        }

Where do I report this bug ? Each rmw ?

fujitatomoya · 2023-08-25T17:07:27Z

I think that is what needs to be unique are different between service server/client message and service introspection event message.

service server/client message includes unique identification of each endpoint in the request and response header. this tells us which endpoint sends the message.
service introspection event message requires gid must be unique during transaction. which uniquely identify a single request-reponse pair. (see https://github.com/ros-infrastructure/rep/pull/360/files#diff-7739b7ffccd3276874ea9014c4cd07872efa4e2d60d7c31896e56929ad424455R144-R149)

i think that this is just unexpected behavior because request_header is overwritten and reused from rmw_take_request to rmw_send_response.

iuhilnehc-ynos

some comments based on my first review.

docs/message_definition_encoding.md

ros2bag/ros2bag/verb/burst.py

ros2bag/ros2bag/verb/play.py

rosbag2_cpp/include/rosbag2_cpp/service_utils.hpp

iuhilnehc-ynos · 2023-09-11T01:29:57Z

rosbag2_transport/include/rosbag2_transport/player.hpp

-  std::unordered_map<std::string, std::shared_ptr<PlayerPublisher>> publishers_;
+  using SharedPlayerPublisher = std::shared_ptr<PlayerPublisher>;
+  using SharedPlayerClient = std::shared_ptr<PlayerClient>;
+  std::unordered_map<


Is it possible that the name of topic and service are the same?

Yes. It is possible. I will consider how to handle this issue.

After checking implementation, for service, service event topic name is used as key.
So if topic name is the same as service event topic name, there is a problem. Not sure whether do we need to deal with this case?

rosbag2_transport/src/rosbag2_transport/player.cpp

rosbag2_cpp/src/rosbag2_cpp/service_utils.cpp

Barry-Xu-2018 · 2023-09-13T02:55:43Z

Codes are ready to be reviewed. Please help to review them.

This PR depended on below PR:

https://github.com/Barry-Xu-2018/rclcpp/tree/review/topic-generic-client-support (Depend on below PR. Not submit PR)
make type support helper supported for service rclcpp#2209 (Under review)

One issue

service introspection event does not have unique GID during transaction
This problem exists in Fastdds and Cyclonedds. But connextdds has no this problem.
This problem leads that play cannot correctly send request while recorded messages are from the situation in which service introspection and client introspection are enabled at the same time.

MichaelOrlov · 2023-09-20T07:11:07Z

@Barry-Xu-2018 Could you please rebase your branch on top of the latest rolling branch? It has some conflicts with the latest changes.

Barry-Xu-2018 · 2023-09-20T09:04:01Z

Could you please rebase your branch on top of the latest rolling branch? It has some conflicts with the latest changes.

Done. I fixed the conflicts. @MichaelOrlov

MichaelOrlov · 2023-09-21T17:39:28Z

@Barry-Xu-2018 Sorry, it seems will need to rebase and fix conflicts one more time.
We changed Player class recently to be a pimpl design.

Signed-off-by: Barry Xu <[email protected]>

Barry-Xu-2018 · 2023-09-22T05:21:47Z

@MichaelOrlov

Sorry, it seems will need to rebase and fix conflicts one more time.
We changed Player class recently to be a pimpl design.

It's ok.
I have done rebase.

ros-discourse · 2023-09-25T21:46:24Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-09-21/33733/1

MichaelOrlov · 2023-09-28T23:59:52Z

@Barry-Xu-2018 I see that the current implementation depends on rclcpp::GenericClient implemented on your https://github.com/Barry-Xu-2018/rclcpp/tree/review/topic-generic-client-support branch. But there is no active open PR associated with those branch.
Is it still WIP or have you forgotten to create a PR?

MichaelOrlov

@Barry-Xu-2018 This PR has grown and become very large with a lot of changes on the multiple layers.
First of all, I would like to say thank you for your thorough and tremendous work!
While it is thorough and addresses all aspects of this big feature – it has become difficult to manage/review it and move forward with it.
I would suggest to split it on two parts. One part could be bigger with everything among playback of the service requests. At least move changes in the rosbag2_transport::Player class to the separate follow-up PR. It turns out that playback of the service request is not trivial to implement.

I have made a first pass of the review and here is my major notes and proposals:

It seems we don’t have tests for the rosbag2_cpp::Info::read_service_info(...) and Python wrapper for information about services. It would be nice to add at least one sanity check.

I have a proposal about new parameters for topic/services exclusions:

Keep the old parameter exclude but rename it to the exclude_regex. it will be applicable to both topics and services.
Make exclude_topics and exclude_services as std::vector<std::string> i.e. space separated list of topics and services names for CLI arguments.

IMO it will be more user-friendly. We have had recently an incoming issue from one of the users when it was expected that the exclude parameter is a list of topics. Like opposite to the topics parameter.
It looks intuitively reasonable to expect it to be defined this way.

I would like to request to rename PlayerClient to the PlayerServiceClient and consider moving it to its own separate cpp and hpp files.
The PlayerClient is pretty large and independent from its parent PlayerImpl class. We already have a lot of code inside the Player class and with this inner class inside it will become more cluttered and more difficult to navigate and support.

We are doing deserialization for the same service message twice. Once in the PlayerClient::is_include_request_message(..) and the second time in the PlayerClient::async_send_request(). This is an expensive procedure.
I would like to request structural changes there.
Could you please rework is_include_request_message(..) to the get_service_request_message(serialized_message) and return smart pointer to the deserialized message? If there are no valid request message it will return a pointer to null. Then rework async_send_request(deserialized_message) to accept those smart pointer to the already deserialized message.

I also have a concern about PlayerClient::async_send_request. We can’t really make it sending request asynchronously at least with the current design. Because we need to wait for future returning from client_->async_send_request(..). Since we can't delete ros_message until the future complete. Otherwise, it will be a dangling pointer to the request_addr and memory could be reused and we have a chance to use corrupted memory during the client_->async_send_request(..). Also according to the notes in the client_->async_send_request(..) API need to call client_->remove_pending_request(future) if we wait for future and timeout happened.
As a first iteration, I would suggest to making sending client request synchronous with timeout. Then need to figure out how to design it to be asynchronous.
I have idea to create some static worker thread and wait in it for static condition variable by timeout and check for future. If another request needs to be sent we can signal to condition variable to interrupt the wait earlier than timeout, remove_pending_request(future) and then try to send the new service request.

MichaelOrlov · 2023-09-28T03:28:32Z

ros2bag/ros2bag/verb/play.py

+        if args.exclude_services:
+            play_options.services_regex_to_exclude = args.exclude_services + '/_service_event'


@Barry-Xu-2018 As far as understand the args.exclude_services is supposed to be a list of services regex separated by spaces.
Shouldn't we add space before + '/_service_event' as well?

MichaelOrlov · 2023-09-28T03:44:02Z

ros2bag/ros2bag/verb/record.py

+        # One options out of --all, --all-topics, --all-services, --services, topics or --regex
+        # must be used


Suggested change

# One options out of --all, --all-topics, --all-services, --services, topics or --regex

# must be used

# At least one options out of --all, --all-topics, --all-services, --services, topics or --regex

# must be used

MichaelOrlov · 2023-09-28T03:45:06Z

ros2bag/ros2bag/verb/record.py

+        if not self._check_necessary_argument(args):
+            return print_error('Must specify only one option out of --all, --all-topics, '
+                               '--all-services, --services, topics and --regex')


Suggested change

if not self._check_necessary_argument(args):

return print_error('Must specify only one option out of --all, --all-topics, '

'--all-services, --services, topics and --regex')

if not self._check_necessary_argument(args):

return print_error('Neet to specify one option out of --all, --all-topics, '

'--all-services, --services, topics and --regex')

MichaelOrlov · 2023-09-28T20:22:37Z

rosbag2_cpp/src/rosbag2_cpp/message_definitions/local_message_definition_source.cpp

+        Format format = definition_identifier.format() == Format::SRV ?
+          Format::MSG : definition_identifier.format();
+        DefinitionIdentifier dep(dep_name, format);


@Barry-Xu-2018 Could you please clarify why do we need to remap Format::SRV to the Format::MSG here?
It would be useful to have a comment in the source code.

MichaelOrlov · 2023-09-29T05:36:23Z

rosbag2_cpp/src/rosbag2_cpp/info.cpp

+#include "rcl/service_introspection.h"
+#include "rmw/rmw.h"
+
 #include "rcpputils/filesystem_helper.hpp"
+#include "rosbag2_cpp/service_utils.hpp"
 #include "rosbag2_storage/logging.hpp"
 #include "rosbag2_storage/metadata_io.hpp"
 #include "rosbag2_storage/storage_interfaces/read_only_interface.hpp"
 #include "rosbag2_storage/storage_factory.hpp"

+#include "service_msgs/msg/service_event_info.hpp"
+


Suggested change

#include "rcl/service_introspection.h"

#include "rmw/rmw.h"

#include "rcpputils/filesystem_helper.hpp"

#include "rosbag2_cpp/service_utils.hpp"

#include "rosbag2_storage/logging.hpp"

#include "rosbag2_storage/metadata_io.hpp"

#include "rosbag2_storage/storage_interfaces/read_only_interface.hpp"

#include "rosbag2_storage/storage_factory.hpp"

#include "service_msgs/msg/service_event_info.hpp"

include "rmw/rmw.h"

#include "rosidl_typesupport_cpp/message_type_support.hpp"

#include "rcpputils/filesystem_helper.hpp"

#include "service_msgs/msg/service_event_info.hpp"

#include "rosbag2_cpp/service_utils.hpp"

#include "rosbag2_storage/metadata_io.hpp"

#include "rosbag2_storage/storage_factory.hpp"

Better organize includes. Adds missing and remove unused.

MichaelOrlov · 2023-09-30T08:59:47Z

rosbag2_transport/src/rosbag2_transport/player.cpp

+
+void PlayerImpl::PlayerClient::async_send_request(const rclcpp::SerializedMessage & message)
+{
+  void * ros_message = new uint8_t[message_members_->size_of_];


It would be safer to use smart pointer rather than raw pointer to avoid memory leaks and better manage the liveliness of the data.

MichaelOrlov · 2023-09-30T09:06:54Z

rosbag2_transport/src/rosbag2_transport/player.cpp

+  message_members_->init_function(
+    ros_message, rosidl_runtime_cpp::MessageInitialization::ZERO);
+
+  int ret = rmw_deserialize(&message.get_rcl_serialized_message(), ts_, ros_message);


We are doing deserialization for the same message twice. Once in the is_include_request_message(..) and second time here. This is an expensive procedure.
I would like to request structural changes.
Could you please rework is_include_request_message(..) to the get_request_message and return smart pointer to the deserialized message.
Then rework async_send_request() to accept those smart pointer to the already deserialized message.

MichaelOrlov · 2023-09-30T09:27:14Z

rosbag2_transport/src/rosbag2_transport/player.cpp

+void PlayerImpl::PlayerClient::async_send_request(const rclcpp::SerializedMessage & message)
+{


I have a concern about PlayerClient::async_send_request. We can’t really make it sending request asynchronously at least with the current design. Because we need to wait for future returning from client_->async_send_request(..). Since we can't delete ros_message until the future complete. Otherwise, it will be a dangling pointer to the request_addr and memory could be reused and we have a chance to use corrupted memory during the client_->async_send_request(..). Also according to the notes in the client_→async_send_request(..) API need to call client_→remove_pending_request(future) if we waited for future and timeout happened.

MichaelOrlov · 2023-09-30T09:28:46Z

rosbag2_transport/src/rosbag2_transport/player.cpp

+    get_message_type_support_handle<service_msgs::msg::ServiceEventInfo>();
+  if (type_support_info == nullptr) {
+    throw std::runtime_error(
+            "It failed to get message type support handle of service event info !");


Suggested change

"It failed to get message type support handle of service event info !");

"Failed to get message type support handle of service event info !");

Maybe also add output to the log?

MichaelOrlov · 2023-09-30T09:29:01Z

rosbag2_transport/src/rosbag2_transport/player.cpp

+    type_support_info,
+    reinterpret_cast<void *>(&msg));
+  if (ret != RMW_RET_OK) {
+    throw std::runtime_error("It failed to deserialize message !");


Suggested change

throw std::runtime_error("It failed to deserialize message !");

throw std::runtime_error("Failed to deserialize message !");

Barry-Xu-2018 · 2023-10-08T01:18:39Z

@MichaelOrlov

I'm sorry for the late reply. I just finished a long holiday.

I see that the current implementation depends on rclcpp::GenericClient implemented on your https://github.com/Barry-Xu-2018/rclcpp/tree/review/topic-generic-client-support branch. But there is no active open PR associated with those branch.
Is it still WIP or have you forgotten to create a PR?

No. This PR is ready. But this PR depended on ros2/rclcpp#2209 which is under review. So I want to submit PR after 2209 is merged.

Barry-Xu-2018 · 2023-10-08T02:03:07Z

@MichaelOrlov

Thank you for your review.
I will start to handle your comment.

Barry-Xu-2018 · 2023-10-13T01:00:40Z

@MichaelOrlov

I created 2 PRs (#1480 and #1481) instead of this one.
And I will move your comment to these 2 PRs.
Please continue to review on these 2 PRs.

ros-discourse · 2023-10-16T22:50:44Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-10-12/34178/1

ros-discourse · 2023-11-20T23:28:05Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-11-16/34757/1

fujitatomoya · 2023-12-04T20:14:23Z

@Barry-Xu-2018 do we want to close this PR, instead we need post the review comments either on #1480 or #1481 along with the implementation?

Barry-Xu-2018 · 2023-12-05T01:17:46Z

@fujitatomoya

do we want to close this PR, instead we need post the review comments either on #1480 or #1481 along with the implementation?

I think yes. All review comments had been moved to #1480 or #1481.
I will close this ticket.

Barry-Xu-2018 · 2023-12-05T01:20:30Z

@MichaelOrlov

I will close this ticket.
In ROS2 TSC meeting, please use #1480 and #1481 instead of this ticket.

Barry-Xu-2018 requested a review from a team as a code owner July 11, 2023 06:47

Barry-Xu-2018 requested review from gbiggs and emersonknapp and removed request for a team July 11, 2023 06:47

Barry-Xu-2018 marked this pull request as draft July 11, 2023 06:48

Barry-Xu-2018 mentioned this pull request Jul 11, 2023

[Design] Add design on recording and replay service #1359

Merged

MichaelOrlov mentioned this pull request Jul 11, 2023

[service introspection] add syntactic sugar for recording services #1063

Closed

Barry-Xu-2018 force-pushed the review/topic-support-service branch from 1cb3812 to bd6e02b Compare July 11, 2023 08:07

Barry-Xu-2018 force-pushed the review/topic-support-service branch 2 times, most recently from f709616 to ba418e9 Compare August 2, 2023 04:57

This was referenced Aug 25, 2023

service introspection event does not have unique GID during transaction ros2/rmw#357

Open

add Jazzy Roadmap features by Sony Corp. ros2/ros2_documentation#3865

Merged

iuhilnehc-ynos reviewed Sep 11, 2023

View reviewed changes

Barry-Xu-2018 marked this pull request as ready for review September 12, 2023 07:47

Barry-Xu-2018 force-pushed the review/topic-support-service branch from 67678ff to 93768b5 Compare September 20, 2023 09:03

Implement service record phase 1

d9b888f

Signed-off-by: Barry Xu <[email protected]>

Barry-Xu-2018 added 7 commits September 22, 2023 11:13

Implement service record phase 2

2527eb3

Signed-off-by: Barry Xu <[email protected]>

Update test codes for burst and play

d5ee316

Signed-off-by: Barry Xu <[email protected]>

Optimize codes for more readable

b873de8

Signed-off-by: Barry Xu <[email protected]>

Address reivew comments

1d2aa1e

Signed-off-by: Barry Xu <[email protected]>

Fix test error after rebase

1601045

Signed-off-by: Barry Xu <[email protected]>

The description is consistent with --topics option

48fee06

Signed-off-by: Barry Xu <[email protected]>

Fix error from rebase action

2cea90d

Signed-off-by: Barry Xu <[email protected]>

Barry-Xu-2018 force-pushed the review/topic-support-service branch from 93768b5 to 2cea90d Compare September 22, 2023 05:17

MichaelOrlov requested changes Sep 30, 2023

View reviewed changes

This was referenced Oct 13, 2023

Implement service recording and display info about recorded services #1480

Merged

Support service 2/2 --- rosbag2 service play #1481

Merged

fujitatomoya mentioned this pull request Nov 2, 2023

make type support helper supported for service ros2/rclcpp#2209

Merged

Barry-Xu-2018 closed this Dec 5, 2023

		if args.exclude_services:
		play_options.services_regex_to_exclude = args.exclude_services + '/_service_event'

		# One options out of --all, --all-topics, --all-services, --services, topics or --regex
		# must be used

		void PlayerImpl::PlayerClient::async_send_request(const rclcpp::SerializedMessage & message)
		{

	"It failed to get message type support handle of service event info !");
	"Failed to get message type support handle of service event info !");

	throw std::runtime_error("It failed to deserialize message !");
	throw std::runtime_error("Failed to deserialize message !");

[WIP] Support recording and replay service #1414

[WIP] Support recording and replay service #1414

Conversation

Barry-Xu-2018 commented Jul 11, 2023 • edited by MichaelOrlov Loading

Barry-Xu-2018 commented Jul 18, 2023 • edited Loading

Barry-Xu-2018 commented Jul 19, 2023

MichaelOrlov commented Jul 20, 2023

Barry-Xu-2018 commented Jul 21, 2023

Barry-Xu-2018 commented Aug 2, 2023 • edited Loading

MichaelOrlov commented Aug 8, 2023

Barry-Xu-2018 commented Aug 16, 2023

fujitatomoya commented Aug 24, 2023

Barry-Xu-2018 commented Aug 25, 2023 • edited Loading

fujitatomoya commented Aug 25, 2023

iuhilnehc-ynos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Barry-Xu-2018 commented Sep 13, 2023

MichaelOrlov commented Sep 20, 2023

Barry-Xu-2018 commented Sep 20, 2023

MichaelOrlov commented Sep 21, 2023

Barry-Xu-2018 commented Sep 22, 2023

ros-discourse commented Sep 25, 2023

MichaelOrlov commented Sep 28, 2023

MichaelOrlov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Barry-Xu-2018 commented Oct 8, 2023

Barry-Xu-2018 commented Oct 8, 2023

Barry-Xu-2018 commented Oct 13, 2023

ros-discourse commented Oct 16, 2023

ros-discourse commented Nov 20, 2023

fujitatomoya commented Dec 4, 2023

Barry-Xu-2018 commented Dec 5, 2023

Barry-Xu-2018 commented Dec 5, 2023

Barry-Xu-2018 commented Jul 11, 2023 •

edited by MichaelOrlov

Loading

Barry-Xu-2018 commented Jul 18, 2023 •

edited

Loading

Barry-Xu-2018 commented Aug 2, 2023 •

edited

Loading

Barry-Xu-2018 commented Aug 25, 2023 •

edited

Loading