Comments (14)
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.
Related Issues (20)
- Size Limit on Sequence Type Members of Laser Scan Msg HOT 3
- app-colcon.meta vs colcon.meta HOT 3
- Adding a timeout parameter to rclc_support_init() HOT 3
- idf.py build failing in Ubuntu 20.04 HOT 2
- Cannot build int32_publisher_custom_transport with docker container HOT 5
- Communication between Micro-ROS Agent (@RPi 4B) and Client (@esp32-s3) is not established HOT 2
- ESP32 uROS ethernet netif bug
- vscode+espidf5.2 Could not complete HOT 3
- Issues compiling with W5500 enabled HOT 6
- idf.py menuconfig error related to xtensa-esp-elf tool HOT 6
- FreeRTOS tasks are not working HOT 2
- microxrcedds_client fails to build with -DUCLIENT_PROFILE_MULTITHREAD=ON HOT 3
- Small question regarding the microROS agent. HOT 2
- Adding a custom interface or message to esp-idf microROS HOT 2
- Action server does not create
- Problem with the build of the "int32_publisher" example on ESP32-S3 HOT 1
- How can I configure Security QoS? HOT 5
- Is it feasible to select interfaces (UART/UDP) dynamically at runtime during the initialization phase?
- Agent does not communicate with Client HOT 7
- atomic patch build failed for ESP32C3 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from micro_ros_espidf_component.