After reconnecting to the agent, data cannot be received normally for a period of time

[chrisjaxy]

Issue template

• Hardware description: STM32F103
• RTOS: freertos
• Installation type: micro_ros_setup
• Version or commit hash: foxy

Steps to reproduce the issue

We created a subscriber on stm32f103, and created a publisher on another machine to publish the same topic at a frequency of 50hz. When stm32f103 successfully reconnects to the agent, it cannot subscribe to this topic for a certain period of time.
After debugging, it was found that the problem appeared in the function "uxr_create_session_retries" of the file "session.c". After calling the function "uxr_reset_stream_storage", calling "wait_session_status" to receive data may cause "uxr_reset_stream_storage" to become invalid and cause problems.
We try to call "uxr_reset_stream_storage" again after calling "wait_session_status" to avoid the problem, but I don't know if this modification is feasible. I want to ask your suggestions?

bool uxr_create_session_retries(
        uxrSession* session,
        size_t retries)
{
    uxr_reset_stream_storage(&session->streams);

    uint8_t create_session_buffer[CREATE_SESSION_MAX_MSG_SIZE];
    ucdrBuffer ub;
    ucdr_init_buffer_origin_offset(&ub, create_session_buffer, CREATE_SESSION_MAX_MSG_SIZE, 0u, uxr_session_header_offset(
                &session->info));

    uxr_buffer_create_session(&session->info, &ub, (uint16_t)(session->comm->mtu - INTERNAL_RELIABLE_BUFFER_OFFSET));
    uxr_stamp_create_session_header(&session->info, ub.init);

    bool received = wait_session_status(session, create_session_buffer, ucdr_buffer_length(&ub), (size_t) retries);
    bool created = received && UXR_STATUS_OK == session->info.last_requested_status;
    
    printf("uxr_reset_stream_storage again\r\n");
    uxr_reset_stream_storage(&session->streams);

    return created;
}

Expected behavior

When we reconnect the agent successfully, the MCU can subscribe and respond to data normally.

Actual behavior

Additional information

[pablogs9]

Can you share your application code? How are you reimplementing the reconnection?

[chrisjaxy]

We refer to the reconnection code in https://github.com/micro-ROS/micro_ros_arduino/blob/galactic/examples/micro-ros_reconnection_example/micro-ros_reconnection_example.ino. Call "destroy_entities" via a trigger signal, and then reconnect via "create_entities". In addition, our other test of reconnection is to reset the MCU, so that it will directly connect through "create_entities".

[pablogs9]

, it cannot subscribe to this topic for a certain period of time.

Does this mean that the micro-ROS node finally reconnects? Or it never receives a subscription again?

[chrisjaxy]

, it cannot subscribe to this topic for a certain period of time.

Does this mean that the micro-ROS node finally reconnects? Or it never receives a subscription again?

The micro ROS node finally successfully reconnected. but it can not receives a subscription until the "uxr_receive_best_effort_message" function, seq_num catches up to stream->last_handled

[chrisjaxy]

, it cannot subscribe to this topic for a certain period of time.

Does this mean that the micro-ROS node finally reconnects? Or it never receives a subscription again?

The micro ROS node finally successfully reconnected. but it can not receives a subscription until the "uxr_receive_best_effort_message" function, seq_num catches up to stream->last_handled

We found in the function "uxr_create_session_retries", after calling the function "uxr_reset_stream_storage", calling "wait_session_status" to receive data may cause "uxr_reset_stream_storage" to become invalid, it means the "stream->last_handled" was changed because of the mcu can still receive subscribed topics at 50hz.

[pablogs9]

Which are the values of RMW_UXRCE_ENTITY_CREATION_DESTROY_TIMEOUT RMW_UXRCE_ENTITY_CREATION_TIMEOUT and RMW_UXRCE_ENTITY_DESTROY_TIMEOUT in your colcon.meta?

[chrisjaxy]

Which are the values of RMW_UXRCE_ENTITY_CREATION_DESTROY_TIMEOUT RMW_UXRCE_ENTITY_CREATION_TIMEOUT and RMW_UXRCE_ENTITY_DESTROY_TIMEOUT in your colcon.meta?

1000

[pablogs9]

Does it have the same behaviour if you set RMW_UXRCE_ENTITY_DESTROY_TIMEOUT to 0 in the colcon.meta?

[chrisjaxy]

Does it have the same behaviour if you set RMW_UXRCE_ENTITY_DESTROY_TIMEOUT to 0 in the colcon.meta?

No, we creat a static library, RMW_UXRCE_ENTITY_CREATION_DESTROY_TIMEOUT this value is the default 1000.This is our colcon.meta

{
    "names": {
        "tracetools": {
            "cmake-args": [
                "-DTRACETOOLS_DISABLED=ON",
                "-DTRACETOOLS_STATUS_CHECKING_TOOL=OFF"
            ]
        },
        "rosidl_typesupport": {
            "cmake-args": [
                "-DROSIDL_TYPESUPPORT_SINGLE_TYPESUPPORT=ON"
            ]
        },
        "rcl": {
            "cmake-args": [
                "-DBUILD_TESTING=OFF",
                "-DRCL_COMMAND_LINE_ENABLED=OFF",
                "-DRCL_LOGGING_ENABLED=OFF"
            ]
        }, 
        "rcutils": {
            "cmake-args": [
                "-DENABLE_TESTING=OFF",
                "-DRCUTILS_NO_FILESYSTEM=ON",
                "-DRCUTILS_NO_THREAD_SUPPORT=ON",
                "-DRCUTILS_NO_64_ATOMIC=ON",
                "-DRCUTILS_AVOID_DYNAMIC_ALLOCATION=ON"
            ]
        },
        "microxrcedds_client": {
            "cmake-args": [
                "-DUCLIENT_PIC=OFF",
                "-DUCLIENT_PROFILE_UDP=OFF",
                "-DUCLIENT_PROFILE_TCP=OFF",
                "-DUCLIENT_PROFILE_DISCOVERY=OFF",
                "-DUCLIENT_PROFILE_SERIAL=OFF",
                "-UCLIENT_PROFILE_STREAM_FRAMING=ON",
                "-DUCLIENT_PROFILE_MULTITHREAD=ON",
                "-DUCLIENT_PROFILE_CUSTOM_TRANSPORT=ON"
            ]
        },
        "rmw_microxrcedds": {
            "cmake-args": [
                "-DRMW_UXRCE_MAX_NODES=1",
                "-DRMW_UXRCE_MAX_PUBLISHERS=8",
                "-DRMW_UXRCE_MAX_SUBSCRIPTIONS=6",
                "-DRMW_UXRCE_MAX_SERVICES=12",
                "-DRMW_UXRCE_MAX_CLIENTS=0",
                "-DRMW_UXRCE_MAX_HISTORY=2",
                "-DRMW_UXRCE_TRANSPORT=custom"
            ]
        }
    }
}

[pablogs9]

Could you try to set the value to 0 and rebuild the library and check if the issue is solved?

[chrisjaxy]

Could you try to set the value to 0 and rebuild the library and check if the issue is solved?

We set the value to 0, but it still doesn't work. "stream->last_handled" will still be changed in the "wait_session_status" function, we still need to call the "uxr_reset_stream_storage" function again.

[chrisjaxy]

Could you try to set the value to 0 and rebuild the library and check if the issue is solved?

We set the value to 0, but it still doesn't work. "stream->last_handled" will still be changed in the "wait_session_status" function, we still need to call the "uxr_create_session_retries" function again.

Is it reasonable to call the "uxr_reset_stream_storage" function again after the "wait_session_status" function?

[pablogs9]

According to the documentation:

• uxr_create_session_retries should be called with a "A uxrSesssion structure previously initialized.". Link
• when a session is inited with uxr_init_session() streams are set to 0. So should not have anything in the stream storage when creating the session.

[chrisjaxy]

According to the documentation:

• uxr_create_session_retries should be called with a "A uxrSesssion structure previously initialized.". Link
• when a session is inited with uxr_init_session() streams are set to 0. So should not have anything in the stream storage when creating the session.

I see that in the rmw_init function, uxr_init_session is called first, streams are set to 0, and then the uxr_create_session_retries function is called. In the uxr_create_session_retries function, streams are set to other values because the continuously sent topic or other data is monitored in the wait_session_status function. I think there should be a way to solve this situation.

[pablogs9]

Working on it