Add option to specify a message type

[carlossvg]

This PR adds an option to the Performance benchmarking package to use a predefined message type instead of generic type. The motivation for this option is to allow to replicate scenarios with exactly the same message types as the original case.

[carlossvg]

@emersonknapp @adamdbrw Could you please review this PR? As explained in the description the motivation of this PR is to be able to run benchmarks using different message types instead of a generic type. The main reason would be to be able to reproduce as close as possible different scenarios.

For this reason a new option, msg_type, is introduced to specify the message type we want to use. For the moment only sensor_msgs` are included but the idea would be to provide some instructions so people can add their own message types.

A logical question is what happens now when msg_type is used with msg_size_bytes. Here there several cases:

• If msg_type is not used the message type is defaulted to the byte array message type. The behavior should be the same as before.
• If msg_type is used and there is no msg_size_bytes the message is not resized. This makes sense for fixed size messages (i.e. std_msgs::msg::Int32).
• If msg_type is and a non-zero msg_size_bytes the developer should add a function to construct and resize tat message type. In case the message type has multiple bounded/unbounded fields is not obvious how msg_size_bytes should be used. I suggest to assume we want to resize all the fields in the same proportion so the total message size is msg_size_bytes.

Additional notes:

• Currently, only benchmark_publishers support the msg_type option. A suitable error message should be added to inform the user.
• We added automotive.yaml to show a usage example.
• We created rosbag2_performance_benchmarking_msgs to remove the std_msgs dependency and to provide a place to add more message types if needed in the future (i.e. nested types).

[MichaelOrlov]

@carlossvg Thanks for the PR.
In general it looks good to me among a few nitpicks.
I would really appreciate if you will address them.

[MichaelOrlov]

@carlossvg Can you please clarify what this TODO about?

[carlossvg]

@MichaelOrlov Currently the total message size will be all the message fixed size fields (https://github.com/ros2/common_interfaces/blob/rolling/sensor_msgs/msg/Image.msg#L4-L25) + the size of the data field (which is the size parameter passed as a function argument). Ideally the total message size would be equal to size. In order to do that we would have to calculate the size of all other fields except from data and then subtract this value to the size parameter to resize data the necessary amount.

[MichaelOrlov]

Could you please add meaningful comment to the todo with the same level of details?

[MichaelOrlov]

@carlossvg Kindly ping to reiterate on this PR.

[MichaelOrlov]

Gist: https://gist.githubusercontent.com/MichaelOrlov/7374b636991bac95242b44bc7924e462/raw/192fd2e9264b5bdc3ff901c799249cc8e5de6376/ros2.repos
BUILD args: --packages-above-and-dependencies rosbag2_performance_benchmarking rosbag2_performance_benchmarking_msgs
TEST args: --packages-above rosbag2_performance_benchmarking rosbag2_performance_benchmarking_msgs
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/11344

• Linux
• Linux-aarch64
• Windows

[MichaelOrlov]

Failure in Test rosbag2 / build_and_test (pull_request) is unrelated to the changes from current PR and relates to the moved mcap packages.

  Package 'mcap_vendor' specified with --packages-up-to was not found
  Package 'rosbag2_storage_mcap' specified with --packages-up-to was not found
  Package 'rosbag2_storage_mcap_testdata' specified with --packages-up-to was not found