DDS error while node creation

[shic15]

• Hardware description: ESP32
• RTOS: freeRTOS
• Installation type: micro_ros_espidf_component
• Version or commit hash: foxy
• ESP-IDF version - V4.2

Steps to reproduce the issue

• Follow the same steps as provided in the readme file of the micro_ros_espidf_component repo.
• Configure the system static IP and network credentials in menuconfig
• Build the int32_publisher example for ESP32
• After flashing the code and starting the micro ros agent in another terminal, monitor the ESP32

Expected behavior

Ideally, after flashing the code ESP32, it should create a node and start publishing the msg via the micro ros agent.

Actual behavior

In ESP32 monitoring terminal :

It shows Failed status on line 52: 1. Aborting.
Which refer to the line below in main.c file
RCCHECK(rclc_node_init_default(&node, "esp32_int32_publisher", "", &support));

In micro-ros-agent terminal :

The micro ros client got connected to the server using UDP over wifi but there is DDS error which I assume is due to the error while creating the node.
A verbosity level 5 was giving this output :

[1623178488.148211] info     | SessionManager.hpp | establish_session        | session re-established | client_key: 0x1757513824, address: 192.168.1.32:16326
[1623178488.148315] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x68C18860, len: 19
[1623178488.148334] debug    | ProxyClient.cpp    | create_participant       | DDS error              | client_key: 0x68C18860, participant_id: 0x000(1)
[1623178488.148415] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x68C18860, len: 14
[1623178488.148442] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x68C18860, len: 13
[1623178488.152428] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x68C18860, len: 13
[1623178488.152627] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x68C18860, len: 13
[1623178488.152893] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x68C18860, len: 13
[1623178488.153022] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x68C18860, len: 13
[1623178488.171194] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x68C18860, len: 13

Additional information

I tried and tested most of the micro ros ESP IDF component examples when first used it, like a month back.
But currently after updating the repo, it is building successfully but while running the code on ESP32 I'm facing these errors.

I did try to debug it myself, looking deeper into function definitions(thanks to vs code), but I hit a roadblock there as I was unable to enable micro ros logging messages.

To enable the log, I redefined #define RCUTILS_LOG_MIN_SEVERITY RCUTILS_LOG_MIN_SEVERITY_WARN and changed the ESP verbosity but that didn't affect the micro ros logging.

Is someone else getting the same issue? any help would be really appreciated.

Thanks

[pablogs9]

How are you opening the micro-ROS Agent?

[shic15]

I'm using the micro ros agent snap package currently.

[pablogs9]

Can you try with:

docker run -it --rm --net=host -v /dev/shm:/dev/shm -v /dev:/dev --privileged  microros/micro-ros-agent:foxy udp --port 8888 -v6  

[shic15]

Exact same error, It is connected to the agent but there is an error while creating the node in ESP32. I think the problem is related to ESP32 firmware, instead of micro ros agent.

[pablogs9]

what output provides the agent if -v6 is used?

[shic15]

docker run -it --rm --net=host -v /dev/shm/dev/shm -v /dev/dev --privileged  microros/micro-ros-agent:foxy udp4 --port 8888 -v6              1 ✘ ▓▒░
[1623230572.583587] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1623230572.584364] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6
[1623230590.572175] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x00000000, len: 24, data: 
0000: 80 00 00 00 00 01 10 00 58 52 43 45 01 00 01 0F 39 95 71 49 81 00 FC 01
[1623230590.572549] info     | Root.cpp           | create_client            | create                 | client_key: 0x39957149, session_id: 0x81
[1623230590.572697] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x966095177, address: 192.168.1.32:25850
[1623230590.574616] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 19, data: 
0000: 81 00 00 00 04 01 0B 00 00 00 58 52 43 45 01 00 01 0F 00
[1623230590.599940] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x39957149, len: 52, data: 
0000: 81 80 00 00 01 05 2C 00 00 0A 00 01 01 03 00 00 1E 00 00 00 00 01 00 00 16 00 00 00 65 73 70 33
0020: 32 5F 69 6E 74 33 32 5F 70 75 62 6C 69 73 68 65 72 00 00 00
[1623230590.600061] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1623230590.600402] debug    | ProxyClient.cpp    | create_participant       | DDS error              | client_key: 0x39957149, participant_id: 0x000(1)
[1623230590.600781] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 14, data: 
0000: 81 80 00 00 05 01 06 00 00 0A 00 01 80 00
[1623230590.600871] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1623230590.600945] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1623230590.605302] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1623230590.605471] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 00 00 00 00 80
[1623230590.605744] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1623230590.605846] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1623230590.623288] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x39957149, len: 13, data: 
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80

[pablogs9]

Try to rebuild all the project and clean the micro-ROS component environment, I just have tested the int32_publisher example and it works as expected.

[pablogs9]

Also, try to get the newest docker with: docker pull microros/micro-ros-agent:foxy

[shic15]

Damn, with this it started working, without needing to rebuild.

Also, try to get the newest docker with: docker pull microros/micro-ros-agent:foxy

One last thing, I can't seem to find the node or topics with the ros2 node/topic list command. I thought the -v parameter in the docker command should reflect the changes.

So, is the snap package of the micro ros agent broken(or not updated)?
Also, is there some way to see micro ros logging messages?

[pablogs9]

micro-ROS agent snap package is not working properly due to snap+ROS2 plugin problems. The recommended option is to use dockerized version.

In general, micro-ROS does not have an internal logging system in order to keep it as small as possible. It is in our roadmap to implement it, but it is not currently available.

Regarding your question, please paste the output of the agent and tell us how and where are you using the ros2 topic list command.

[BrettRD]

This is not isolated.

I just picked up microros again today and I'm having the same issue (microros foxy latest, idf v4.3, udp transport)

node init is broken against current micro-xrce-dds-agent (snap 2021-04-05), and broken against micro-ros-agent:foxy under docker from a few months ago

Current docker micro-ros-agent:foxy allows the micro-ros application to function normally, but no topics or nodes are visible on the host. (using --net=host)

I have an application built with 96a37cd that still works perfectly using snap micro-xrce-dds-agent, but has the same non-visible topic problems with docker, so I think the docker micro-ros-agent:foxy issue is related but orthogonal.

I'm running ros2 topic list on the same host as the agent using exports from /opt/ros/foxy... (ubuntu binary)

is there any way to access the error messages like these from rclc?

[pablogs9]

In fact, micro-ROS Agent in snap is not updated and not using the binary entity creation mode that's why it is impossible to create nodes using a modern version of the micro-ROS client and the outdated micro-ROS Agent from the snap package. Dockerized micro-ROS agent is the recommended option.

Regarding the communication between the micro-ROS Agent and the ros2 topic ... CLI, usually this is not a micro-ROS-related problem but a ROS 2 middleware problem. Normally docker does not share shared memory transports so it is important to use -v /dev/shm:/dev/shm when launching the agent like in:

docker run -it --rm --net=host -v /dev/shm:/dev/shm -v /dev:/dev --privileged  microros/micro-ros-agent:foxy udp --port 8888 -v6  ```

[BrettRD]

I am able to see the topics with the shared memory.
I have to shell into the docker container, stop ros2 daemon to force a cache flush, list the topics in the container, stop daemon on the host, then list topics on the host.

The host still can't echo the topics, but it can see active subscribers (ros2 topic echo in the container).

The stated issue is resolved with the docker pull, I'll take the agent topic visibility problem elsewhere

edit: building the agent from source and running it directly on the host is giving me less trouble, still needed a daemon reset, but the topics aren't vanishing again

[shic15]

edit: building the agent from source and running it directly on the host is giving me less trouble, still needed a daemon reset, but the topics aren't vanishing again

Yup, out of options even I tried building from source, and it is working just fine. But the topic visibility issue seems to occur irregularly. Which I think can be solved by restarting the daemon whenever it arises as stated by @BrettRD.

Thanks for the help!