DDS error while node creation about micro_ros_espidf_component HOT 14 CLOSED

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

from micro_ros_espidf_component.

How are you opening the micro-ROS Agent?

from micro_ros_espidf_component.

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

from micro_ros_espidf_component.

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  

from micro_ros_espidf_component.

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.

from micro_ros_espidf_component.

what output provides the agent if -v6 is used?

from micro_ros_espidf_component.

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

from micro_ros_espidf_component.

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.

from micro_ros_espidf_component.

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

from micro_ros_espidf_component.

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?

from micro_ros_espidf_component.

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.

from micro_ros_espidf_component.

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?

from micro_ros_espidf_component.

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  ```

from micro_ros_espidf_component.

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!

from micro_ros_espidf_component.