Increasing payload size for microROS publisher

[krm-int]

Describe the bug I'm trying to publish a ros_msg of type sensor_msgsmsgLaserScan from mu olimex-stm32-e407 dev. board. I'm only interested in sending the .ranges & header.stamp for now, meaning the intensities is only a pointer to 1 value.

System information:

• OS: NuttX running on Olimex-stm32-e407
• ROS 2 Dashing
• microROS Dashing branch

I'm using the micro ROS publisher example to publish the new type: (Note the ROS handling is in its own class, but i dont think that matters)

#include <sensor_msgs/msg/laser_scan.h>
... 
rv_ = rcl_publisher_init(&publisher_,
                            &node_,
                            ROSIDL_GET_MSG_TYPE_SUPPORT(sensor_msgs, msg, LaserScan),
                            "bea_lzr_scan",
                            &pub_ops);

To allocate memory for my laser_scan msg i do:

const uint8_t LASER_MSG_SIZE = 120;   //or the size im testing
...
laser_scan_msg_ = *sensor_msgs__msg__LaserScan__create(); //this happens in the initializer list
laser_scan_msg_.ranges.data = (float *)calloc(LASER_MSG_SIZE, sizeof(float));
laser_scan_msg_.ranges.capacity = LASER_MSG_SIZE;

I fill the msg with dummy data like so:

laser_scan_msg_.ranges.size = 0;
size_t i;
for (i = 0; i < laser_scan_msg_.ranges.capacity; i++) // every datapoint is 2 bytes
{
   laser_scan_msg_.ranges.data[i] =
       1.0;
   laser_scan_msg_.ranges.size++;
 }

The breakpoint of LASER_MSG_SIZE where the publisher fails is: 111 Ideally, I would like to send 400 floats of 4 bytes

During debugging I've narroved it down to to an error coming from: mcu_ws/uros/rmw_microxrcedds/rmw_microxrcedds_c/src/rmw_publish.c::49 --> mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/core/session/session.c::766 --> mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/core/session/stream/output_reliable_stream.c::49

It's something with the lenght, block_size or remaining blocks.

So my question:

Is there anywhere I can increase the allowed payload size for RMW?

[jfm92]

Hi @krm-mir, The payload size is calculated at building time, when this file is generated: https://github.com/micro-ROS/rmw-microxrcedds/blob/80a305b05dec7ff0954c91726db78418fbf07661/rmw_microxrcedds_c/src/config.h.in#L26

As you can see this is related with the RMW_UXRCE_STREAM_HISTORY, which you can modify on the CMakeFile and the RMW_UXRCE_MAX_TRANSPORT_MTU which is a value manage by Micro-XRCE-DDS and you can modify it on the next file: Micro-XRCE-DDS Config.

To clarify, the MTU on Micro-XRCE-DDS is the maximum size of data that can be sent on each packet. This value can be modified but having in mind that RMW_UXRCE_STREAM_HISTORY*RMW_UXRCE_MAX_TRANSPORT_MTU should be at least 2048.

[krm-int]

@jfm92 Thanks for the response. I've been playing around with the history and MTU and i still get memory leaks when I try to publish 200-400 floats in the Laser_scan_msg. Do you think 400 floats is simple to much for the RAM of the Olimex board? When i bumped up (history = 8, MTU = 2048) I couldn't build because of SRAM overflow - maybe an indication of to much memory usage?

[pablogs9]

Hello @krm-mir, that is right, setting a history of 8 and a MTU of 2048 will allocate static buffers of ~16 Kb, and depends on your configuration they can overflow your SRAM at linking time. For publishing it will work with a history of 1.

200 messages of aprox 4 Bytes is ~ 800 Bytes. I think that this should work, let us try a demo app with such big payload.

Are you sure that laser_scan_msg_ = *sensor_msgs__msg__LaserScan__create(); is allocationg the element? Please try the following:

sensor_msgs__msg__LaserScan laser_scan_msg_;
laser_scan_msg_.ranges.data = (float *)calloc(LASER_MSG_SIZE, sizeof(float));
laser_scan_msg_.ranges.capacity = LASER_MSG_SIZE;

[krm-int]

I still get an error when preparing the output stream (same place as in my initial comment).

A small sidetrack while debugging: Is the output stream fixed to reliable? https://github.com/micro-ROS/rmw-microxrcedds/blob/80a305b05dec7ff0954c91726db78418fbf07661/rmw_microxrcedds_c/src/rmw_publish.c#L49-L52

[pablogs9]

For now the Micro-XRCE-DDS RMW is fixed to reliable while something about rmw specific configuration API is proposed in the RCL.

You can check this branch where publishing and subscribing are done using best effort: https://github.com/micro-ROS/rmw-microxrcedds/tree/test/best_effort

Remember that this branch is experimental and far from being stable.

[krm-int]

@pablogs9 & @jfm92 I've experimented with another application, which publishes an increasing array of floats from the Olimex board. I can send an array of floats until the size = 123. Then I either get a memory leak or the app crashes:

I'm gonna put my float publisher on hold for now. Du you want to close the issue or keep it open for future discussion?

[pablogs9]

Please keep it open, we will be back to this issue soon or later.

Thank you so much for the research!

[krm-int]

Hi @pablogs9 , I've come around to running some test on this issues again. I'm still using the Olimex-stm32-e407 board but switched to microROS on FreeRTOS (dashing). My test is basically the same - keep publishing an array of float32 and increase the size of the array after every publish. I can publish until size = 122. (screenshot of ros2 topic echo command)

Since i can replicate the same error (with same result) on two different OS, could this mean that it's related to microROS or fastRTPS?

regards

[pablogs9]

@julibert can this be related to fragmentation? are the new fragmentation branches used in micro-ROS build system?

[pablogs9]

@krm-mir can you show us what is the agent output on the working and not working publications? Please use -v6 to set the max verbosity and share us the trace

[krm-int]

@pablogs9 Here the output:

[julionce]

Hi @krm-mir,

This PR in Micro XRCE-DDS Client should fix this issue. Please, update Micro CDR and Micro XRCE-DDS Client repos and rebuild your app. I hope it helps you.

[krm-int]

@julibert I've updated the repos and rebuild. I'm not sure if its related, but I run into another error: firmware/mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/core/session/stream/input_reliable_stream.c:217:11: error: 'ucdrBuffer' {aka 'struct ucdrBuffer'} has no member named 'offset' ub->offset); (https://github.com/eProsima/Micro-XRCE-DDS-Client/blob/91f234a3216cfa501e48badc09990d376b587fa5/src/c/core/session/stream/input_reliable_stream.c#L217) and firmware/mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/core/session/stream/output_reliable_stream.c:269:11: error: 'ucdrBuffer' {aka 'struct ucdrBuffer'} has no member named 'offset' ub->offset); (https://github.com/eProsima/Micro-XRCE-DDS-Client/blob/91f234a3216cfa501e48badc09990d376b587fa5/src/c/core/session/stream/output_reliable_stream.c#L269) when rebuilding.

I also tried with a fresh build of micro-ros-build --> create_firmware -> configure -> buildfirmware, and get same error.

Closing as this issue is resovled - the new one exist here

[krm-int]

@julibert I've reopened the issue after running the same tests in FreeRTOS and NuttX. Results are much better, but not near the paylaod size of eg a camera frame.

Both tests use the laser_scan msg type with only the frame_id changed to “LZR_data” and the ranges increased.

NuttX results 360floats + header.

FreeRTOS resutls 371floats + header.

[julionce]

Hi @krm-mir, could you share the Agent output again?

[krm-int]

@julibert

I believe the issue could be a segmentation fault (or something similar), since the agent doens't croak. Here are the agent outputts:

NuttX ... I can't make the NuttX debugging work atm to trace the error - sorry.

FreeRTOS

[1588682947.389365] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7C 02 00 00 80
[1588682947.389273] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 79 02 7B 02 80
[1588682947.389432] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7C 02 00 00 80
[1588682947.389736] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 7B 02 7B 02 80
[1588682947.389762] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7C 02 00 00 80
[1588682947.885782] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x15B5CC50, len: 508, data: 
0000: 81 80 7C 02 0D 01 F4 01 07 01 D8 05 01 14 00 65 A5 A5 A5 A5 A5 A5 A5 A5 09 00 00 00 4C 5A 52 5F
0020: 64 61 74 61 00 00 71 43 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5
0040: A5 A5 A5 A5 66 01 00 00 00 00 00 00 00 00 80 3F 00 00 00 40 00 00 40 40 00 00 80 40 00 00 A0 40
0060: 00 00 C0 40 00 00 E0 40 00 00 00 41 00 00 10 41 00 00 20 41 00 00 30 41 00 00 40 41 00 00 50 41
0080: 00 00 60 41 00 00 70 41 00 00 80 41 00 00 88 41 00 00 90 41 00 00 98 41 00 00 A0 41 00 00 A8 41
00A0: 00 00 B0 41 00 00 B8 41 00 00 C0 41 00 00 C8 41 00 00 D0 41 00 00 D8 41 00 00 E0 41 00 00 E8 41
00C0: 00 00 F0 41 00 00 F8 41 00 00 00 42 00 00 04 42 00 00 08 42 00 00 0C 42 00 00 10 42 00 00 14 42
...
0180: 00 00 9C 42 00 00 9E 42 00 00 A0 42 00 00 A2 42 00 00 A4 42 00 00 A6 42 00 00 A8 42 00 00 AA 42
01A0: 00 00 AC 42 00 00 AE 42 00 00 B0 42 00 00 B2 42 00 00 B4 42 00 00 B6 42 00 00 B8 42 00 00 BA 42
01C0: 00 00 BC 42 00 00 BE 42 00 00 C0 42 00 00 C2 42 00 00 C4 42 00 00 C6 42 00 00 C8 42 00 00 CA 42
01E0: 00 00 CC 42 00 00 CE 42 00 00 D0 42 00 00 D2 42 00 00 D4 42 00 00 D6 42 00 00 D8 42
[1588682947.885919] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7D 02 00 00 80
[1588682947.886064] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x15B5CC50, len: 508, data: 
0000: 81 80 7D 02 0D 01 F4 01 00 00 DA 42 00 00 DC 42 00 00 DE 42 00 00 E0 42 00 00 E2 42 00 00 E4 42
0020: 00 00 E6 42 00 00 E8 42 00 00 EA 42 00 00 EC 42 00 00 EE 42 00 00 F0 42 00 00 F2 42 00 00 F4 42
0040: 00 00 F6 42 00 00 F8 42 00 00 FA 42 00 00 FC 42 00 00 FE 42 00 00 00 43 00 00 01 43 00 00 02 43
...
01A0: 00 00 A8 43 00 80 A8 43 00 00 A9 43 00 80 A9 43 00 00 AA 43 00 80 AA 43 00 00 AB 43 00 80 AB 43
01C0: 00 00 AC 43 00 80 AC 43 00 00 AD 43 00 80 AD 43 00 00 AE 43 00 80 AE 43 00 00 AF 43 00 80 AF 43
01E0: 00 00 B0 43 00 80 B0 43 00 00 B1 43 00 80 B1 43 00 00 B2 43 00 80 B2 43 00 00 00 00
[1588682947.886198] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7E 02 00 00 80
[1588682947.886291] debug    | DataWriter.cpp     | write                    | [** <<DDS>> **]        | client_key: 0x00000006, len: 1492, data: 
0000: A5 A5 A5 A5 A5 A5 A5 A5 09 00 00 00 4C 5A 52 5F 64 61 74 61 00 00 71 43 A5 A5 A5 A5 A5 A5 A5 A5
0020: A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 66 01 00 00 00 00 00 00 00 00 80 3F
0040: 00 00 00 40 00 00 40 40 00 00 80 40 00 00 A0 40 00 00 C0 40 00 00 E0 40 00 00 00 41 00 00 10 41
...
0560: 00 00 A5 43 00 80 A5 43 00 00 A6 43 00 80 A6 43 00 00 A7 43 00 80 A7 43 00 00 A8 43 00 80 A8 43
0580: 00 00 A9 43 00 80 A9 43 00 00 AA 43 00 80 AA 43 00 00 AB 43 00 80 AB 43 00 00 AC 43 00 80 AC 43
05A0: 00 00 AD 43 00 80 AD 43 00 00 AE 43 00 80 AE 43 00 00 AF 43 00 80 AF 43 00 00 B0 43 00 80 B0 43
05C0: 00 00 B1 43 00 80 B1 43 00 00 B2 43 00 80 B2 43 00 00 00 00
[1588682947.886428] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7F 02 00 00 80
[1588682947.886581] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 7D 02 7E 02 80
[1588682947.886627] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x15B5CC50, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7F 02 00 00 80

Here I've traced the error to: /workspaces/uros_ws/firmware/mcu_ws/eProsima/Micro-XRCE-DDS-Client/src/c/core/session/stream/output_reliable_stream.c. I reckon there's some issue with the buffer?

Below is the application source code:

#include <allocators.h>

#include <rcl/rcl.h>
#include <rcl_action/rcl_action.h>
#include <rcl/error_handling.h>

#include <rmw_uros/options.h>

#include <stdio.h>
#include <unistd.h>

// application specific includes
#include <std_msgs/msg/float32.h>
#include <cmsis_os.h>

// #define USE_FLOAT_ONLY

#ifdef USE_FLOAT_ONLY
#include <custom_interfaces/msg/float_array.h>
#include <std_msgs/msg/float32_multi_array.h>
#else
#include <sensor_msgs/msg/laser_scan.h>
#endif /* USE_FLOAT_ONLY */
//application defines
#define PAYLOAD_SIZE 400 // 111 is max

void appMain(void *argument)
{
    rcl_init_options_t options = rcl_get_zero_initialized_init_options();

    rcl_init_options_init(&options, rcl_get_default_allocator());

    // Optional RMW configuration
    // rmw_init_options_t *rmw_options = rcl_init_options_get_rmw_init_options(&options);
    // RCCHECK(rmw_uros_options_set_client_key(0xBA5EBA11, rmw_options))

    rcl_context_t context = rcl_get_zero_initialized_context();
    rcl_init(0, NULL, &options, &context);

    // create node
    rcl_node_options_t node_ops = rcl_node_get_default_options();

    rcl_node_t node = rcl_get_zero_initialized_node();
    rcl_node_init(&node, "payload_node", "", &context, &node_ops);

    // create publisher
    rcl_publisher_options_t publisher_ops = rcl_publisher_get_default_options();

    // SET RELIABILITY QOS:
    publisher_ops.qos.reliability = RMW_QOS_POLICY_RELIABILITY_RELIABLE;
    // payload_publisher_ops.qos.reliability = RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT;
    rcl_publisher_t publisher = rcl_get_zero_initialized_publisher();
#ifdef USE_FLOAT_ONLY
    rosidl_message_type_support_t *type_support = ROSIDL_GET_MSG_TYPE_SUPPORT(custom_interfaces, msg, FloatArray);
#else
    rosidl_message_type_support_t *type_support = ROSIDL_GET_MSG_TYPE_SUPPORT(sensor_msgs, msg, LaserScan);
#endif /* USE_FLOAT_ONLY */
    rcl_publisher_init(&publisher,
                       &node,
                       type_support,
                       "/payload_test",
                       &publisher_ops);

// allocate space for msg
#ifdef USE_FLOAT_ONLY
    custom_interfaces__msg__FloatArray msg;
    custom_interfaces__msg__FloatArray__init(&msg);
    msg.data.capacity = PAYLOAD_SIZE;
    msg.data.size = 1;
    msg.data.data = (float *)calloc(1, sizeof(float));
    msg.data.data[0] = 0.0;
#else
    const char HEADER_ID[] = "LZR_data";
    float ranges[PAYLOAD_SIZE];
    sensor_msgs__msg__LaserScan msg;
    sensor_msgs__msg__LaserScan__init(&msg); // important!!!
    msg.header.frame_id.data = HEADER_ID;
    msg.header.frame_id.size = sizeof(HEADER_ID);
    msg.header.frame_id.capacity = sizeof(HEADER_ID);
    msg.ranges.data = (float *)calloc(PAYLOAD_SIZE, sizeof(float));
    msg.ranges.capacity = PAYLOAD_SIZE;
    msg.ranges.size = 0;
    msg.ranges.data = &ranges;
    // for (size_t i = 0; i < PAYLOAD_SIZE; i++)
    // {
    //     msg.ranges.data[i] = (float)i * 1.0 + 1.0;
    //     msg.ranges.size++;
    // }
#endif /* USE_FLOAT_ONLY */
    size_t array_size = 357;

    osDelay(5000);
    rcl_ret_t rc;
    do
    {
        rcl_ret_t rc = rcl_publish(&publisher, (const void *)&msg, NULL);

        if (rc != RCL_RET_OK)
        {
            break;
        }

        if (array_size < PAYLOAD_SIZE)
        {
#ifdef USE_FLOAT_ONLY
            free(msg.data.data);
            msg.data.data = (float *)calloc(array_size, sizeof(float));
            msg.data.size = 0;
            msg.data.capacity = array_size;
            for (size_t i = 0; i < array_size; i++)
            {
                msg.data.data[i] = (float)i;
                msg.data.size++;
            }
#else
            free(msg.ranges.data);
            msg.ranges.data = (float*)calloc(array_size, sizeof(float));
            msg.ranges.size = 0;
            msg.ranges.capacity = array_size;
            for (size_t i = 0; i < array_size; i++)
            {
                msg.ranges.data[i] = (float)i;
                msg.ranges.size++;
            }

#endif /* USE_FLOAT_ONLY */
            array_size++;
        }

            osDelay(500);
        }
        while (true);

        sensor_msgs__msg__LaserScan__fini(&msg);
        rcl_publisher_fini(&publisher, &node);
        rcl_node_fini(&node);

        vTaskDelete(NULL);
    }

Both agent-outputs just stops when the max-payload is reached - no error output. Thats why I'm guessing seg fault.

Hope it makes sense.

[julionce]

Hi @krm-mir,

I have a couple of questions:

1. What are your rmw-microxrcedds and Micro XRCE-DDS configurations? RMW_UXRCE_STREAM_HISTORY & CONFIG_UDP_TRANSPORT_MTU.
2. Do you try the same application for host? Maybe then you can debug/trance the error.

[krm-int]

1. RMW_UXRCE_MAX_HISTORY=2 CONFIG_UDP_TRANSPORT_MTU=512 (totally forgot the MTU).

Using CONFIG_UDP_TRANSPORT_MTU=1024 (History unchanged), so MTU*HISTORY >= 2048: At a LaserScan.msg containing 741 (float32) + header (total msg size is 24040bit) the agent output is:

0000: 81 00 00 00 0A 01 05 00 77 04 00 00 80
[1588752160.036618] debug    | DataWriter.cpp     | write                    | [** <<DDS>> **]        | client_key: 0x00000006, len: 3028, data: 
0000: A5 A5 A5 A5 A5 A5 A5 A5 09 00 00 00 4C 5A 52 5F 64 61 74 61 00 80 F8 43 A5 A5 A5 A5 A5 A5 A5 A5
0020: A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 A5 E6 02 00 00 00 00 00 00 00 00 80 3F
0040: 00 00 00 40 00 00 40 40 00 00 80 40 00 00 A0 40 00 00 C0 40 00 00 E0 40 00 00 00 41 00 00 10 41
0060: 00 00 20 41 00 00 30 41 00 00 40 41 00 00 50 41 00 00 60 41 00 00 70 41 00 00 80 41 00 00 88 41
0080: 00 00 90 41 00 00 98 41 00 00 A0 41 00 00 A8 41 00 00 B0 41 00 00 B8 41 00 00 C0 41 00 00 C8 41
...
0B40: 00 80 30 44 00 C0 30 44 00 00 31 44 00 40 31 44 00 80 31 44 00 C0 31 44 00 00 32 44 00 40 32 44
0B60: 00 80 32 44 00 C0 32 44 00 00 33 44 00 40 33 44 00 80 33 44 00 C0 33 44 00 00 34 44 00 40 34 44
0B80: 00 80 34 44 00 C0 34 44 00 00 35 44 00 40 35 44 00 80 35 44 00 C0 35 44 00 00 36 44 00 40 36 44
0BA0: 00 80 36 44 00 C0 36 44 00 00 37 44 00 40 37 44 00 80 37 44 00 C0 37 44 00 00 38 44 00 40 38 44
0BC0: 00 80 38 44 00 C0 38 44 00 00 39 44 00 40 39 44 00 00 00 00
[1588752160.037209] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 75 04 77 04 80
[1588752160.037245] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 78 04 00 00 80
[1588752160.037324] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 78 04 00 00 80
[1588752160.534734] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 20, data: 
0000: 81 80 78 04 03 01 04 00 01 CC 00 65 03 01 04 00 01 CD 00 53
[1588752160.535137] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0006
[1588752160.535207] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0005
[1588752160.535270] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 07 00 05 01 06 00 01 CC 00 65 00 00
[1588752160.535281] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 79 04 00 00 80
[1588752160.535300] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 08 00 05 01 06 00 01 CD 00 53 00 00
[1588752160.535429] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 78 04 78 04 80
[1588752160.535546] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 79 04 00 00 80
[1588752160.535986] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 08 00 00 00 80
[1588752160.536312] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 09 00 00 00 80
[1588752160.536624] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 12, data: 
0000: 81 80 79 04 03 01 04 00 01 CE 00 42
[1588752160.536674] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0004
[1588752160.536787] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7A 04 00 00 80
[1588752160.536799] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 09 00 05 01 06 00 01 CE 00 42 00 00
[1588752160.537437] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 0A 00 00 00 80
[1588752160.537733] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 20, data: 
0000: 81 80 7A 04 03 01 04 00 01 CF 00 35 03 01 04 00 01 D0 00 23
[1588752160.537955] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0003
[1588752160.537998] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0002
[1588752160.538053] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7B 04 00 00 80
[1588752160.538095] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 0B 00 05 01 06 00 01 D0 00 23 00 00
[1588752160.538125] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 0A 00 05 01 06 00 01 CF 00 35 00 00
[1588752160.538435] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 7A 04 7A 04 80
[1588752160.538545] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7B 04 00 00 80
[1588752160.539058] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 0A 00 00 01 80
[1588752160.539184] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 0A 00 05 01 06 00 01 CF 00 35 00 00
[1588752160.539317] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 0C 00 00 00 80
[1588752160.539329] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 12, data: 
0000: 81 80 7B 04 03 01 04 00 01 D1 00 12
[1588752160.539344] debug    | ProxyClient.cpp    | delete_object_unlock     | object deleted         | client_key: 0x172387A4, object_id: 0x0001
[1588752160.539406] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 7C 04 00 00 80
[1588752160.539416] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x172387A4, len: 14, data: 
0000: 81 80 0C 00 05 01 06 00 01 D1 00 12 00 00
[1588752160.539918] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 0C 00 00 00 80
[1588752160.540365] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x172387A4, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 0D 00 00 00 80

I'm actually way within my needs in terms of payload size - the goal was to send 400 float32 data points + header from a Laser scanner.

2. I have not tried running the payload_test app on host, as I'm aiming towards microROS on embedded only. If you want one, I'll gladly try it out.

[FranFin]

@krm-int Hi! Thank you for your interest in micro-ROS. Notice that we’ll discuss the recent contributions and developments in the next Embedded WG meeting. You’re invited to bring your micro-ROS related issue to this platform. We’ll be very happy to have you join us and discuss your questions with the community.

[pablogs9]

Probably related: https://github.com/micro-ROS/micro_ros_setup/issues/187#issuecomment-702143940

@krm-int did you achieve something regarding this issue?

[pablogs9]

Solved here: https://github.com/micro-ROS/rosidl_typesupport_microxrcedds/pull/25