Modified serial transport fails to create a session on agent side

[sunoc]

Issue template

• Hardware description: Xilinx's KRIA KV260 Vision Started Kit board
• OS: Ubuntu 22.04, Linux 5.15.0-1023-xilinx-zynqmp
• Installation type: Standalone agent in a Docker
• Version or commit hash: 40954c2

Steps to reproduce the issue

Greetings,

The agent version (as well as the client version) are significantly modified compared to the base system, in particular to accommodate the particular board our system is running on, as well as the communication system we are currently testing. Thus, the exact reproduction of the error might be difficult, however I would like to describe the behavior:

• In a created build directory, the modified agent is successfully built: cmake .. && make -j4.
• The agent is run with the following parameters: ./MicroXRCEAgent serial --dev /dev/null --verbose 6. Since the init function was modified, no dev is required for my system to run. /dev/null is passed anyway since serial requires the dev parameter.
• The init is happening successfully, and the agent is "waiting" at the logger setup in the set_verbose_level, as expected.
• A first stream of 31 bytes of data is sent from the client to the agent: 0x7E 0x00 0x00 0x18 0x00 0x80 0x00 0x00 0x00 0x00 0x01 0x10 0x00 0x58 0x52 0x43 0x45 0x01 0x00 0x01 0x0F 0x19 0x75 0x06 0xDD 0x81 0x00 0xFC 0x01 0x4B 0x88.

Expected behavior

Receiving some id from the client (0x7E, in my case), I would expect the agent to take the following steps

• create_client
• establish_session
• create_participant
• create_topic

And then, the agent should be ready to work for a ping-pong test application.

Actual behavior

In the recv_message function, it appears that framing_io_ never succeeds to read bytes, thus never letting the recv_message function go to the UXR_AGENT_LOG_MESSAGE, confirming the reception of a message.

The whole system then times out and the session creation never ever starts.

Weirdly , the very first block of data being read is always 5 bytes long, even thought the client actually sent 31 bytes.

Going deeper, it appears that in the StreamFramingProtocol.cpp, the read_framed_msg function successfully get the 0x7E value from the client, bus nothing else seems to happen from here.

I am quite stumped here. Even knowing that reproducing this setup is very difficult, any advice or clue on how this transport system behave would be much appreciated !

Thank you very much in advance.

Additional information

Modifications of the serial agent transport system

My latest modification of the serial transport are visible at my fork of this repository, on the develop branch.

Are there any other information I can provide in order to get help with my issue ?

About the custom transport system

One aspect that might be useful for me eventually is to be able to modify and run the custom transport instead of the modified version of the serial transport I am currently dealing with. However, I struggle a bit to figure out exactly how to use this.

I guess I missed some critical piece of information, but I never was able to use custom or similar as a transport for the compiled MicroXRCEAgent.

Again, any clue or advice is very welcome.

Cheers,

Vincent

[pablogs9]

Hello @sunoc I suggest you write to support@eProsima.com since this is a kind of complex use case that may require in-depth analysis.

Also, we provide other DDS solutions for communicating cores inside Kria K26 in a DDS manner with no need for XRCE-DDS.

[sunoc]

Hi @pablogs9, thank you for the rapid response!

I did contact the eProsima support directly a while ago to have some more general information for my project, however they recommended me to try and ask on the GitHub pages first. More specifically, they suggested me to write on the micro-ros discussions pages, but I sent a message here first since my current problem is specific to the XRCE Agent I'm trying to deploy. I will try and open a discussion over there about my situation, and maybe recontact eProsima directly. Thank you for the advice !

The reason I went with XRCE-DDS in the first place is because the communication we want to archive is between the A53 core of the KRIA board, running Ubuntu and ROS2, with the R5F core running FreeRTOS and micro-ros. If another solution to make the DDS communication happening between these two exists, I would be really excited to try it ! What solutions were you making reference to ?

[sunoc]

Hello, The situation described in this ticket was solved, eventually. It turns out the management of length of the received data versus the requested data length caused the Agent to fail to understand what was going on.

A basic FIFO system was implemented in the customized read function, receiving the data (rpmsg_buffer_len), giving back only the requested amount of data (buf) and keeping the rest for later.

For reference, and if it can be useful to anyone else, here is the code used to manage this that was added to our custom read function:

 if ( 0 < rpmsg_buffer_len ){
    UXR_PRINTF("Something was received", rpmsg_buffer_len);
    uint32_t copylen = ((size_t)rpmsg_buffer_len >= len) ? len  : rpmsg_buffer_len;

    /* Actually writting the data received to the buf */
    for ( int i = 0; i<(int)copylen; i++ ){
      buf[i] = rpmsg_buffer[i+rpmsg_buffer_top];
      UXR_PRINTF("data:", buf[i]);
    }

    /* Update the rpmsg buffer variables */
    rpmsg_buffer_len -= copylen;
    /* If the buffer was emptied */
    if ( 0 == rpmsg_buffer_len ){
      rpmsg_buffer_top = 0;

      /* Otherwise, we keep the start of the rest of the data
       * in the "top" variable. */
    } else {
      rpmsg_buffer_top += copylen;
    }

    /* In this case, we always return len since the whole lenght of the
     * expected data was read */
    return copylen;

      }