search

micro-ROS / micro-ROS-demos

Sample code using rclc and rclcpp implementations.
Apache License 2.0
84 stars 24 forks source link

Problem with ping-pong demo - topic does not echo/list after running the node #78

Closed migsdigs closed 12 months ago

migsdigs commented 12 months ago

Issue template

Hey! I have issues running the Ping Pong example from https://micro.ros.org/docs/tutorials/core/first_application_linux/. After running the agent I am unable to see the ping or pong topic listed. As a result, ros2 topic echo /microROS/ping produces:

WARNING: topic [/microROS/ping] does not appear to be published yet
Could not determine the type for the passed topic

I would very much appreciate if someone can help me resolve this error.

Setup

Steps to reproduce the issue

Following the Tutorial on https://micro.ros.org/docs/tutorials/core/first_application_linux/:

Installing the micro-ROS build system

# Source the ROS 2 installation
source /opt/ros/$ROS_DISTRO/setup.bash

# Create a workspace and download the micro-ROS tools
mkdir microros_ws
cd microros_ws
git clone -b $ROS_DISTRO https://github.com/micro-ROS/micro_ros_setup.git src/micro_ros_setup

# Update dependencies using rosdep
sudo apt update && rosdep update
rosdep install --from-paths src --ignore-src -y

# Install pip
sudo apt-get install python3-pip

# Build micro-ROS tools and source them
colcon build
source install/local_setup.bash

Creating the firmware workspace:

# Create firmware step
ros2 run micro_ros_setup create_firmware_ws.sh host

Building the firmware

# Build step
ros2 run micro_ros_setup build_firmware.sh
source install/local_setup.bash

Creating the micro-ROS Agent packages:

# Download micro-ROS-Agent packages
ros2 run micro_ros_setup create_agent_ws.sh

Building the agent packages:

# Build step
ros2 run micro_ros_setup build_agent.sh
source install/local_setup.bash

Running the micro-ROS app:

# Run a micro-ROS agent
ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888

In a different terminal, running the ping-pong node:

source /opt/ros/$ROS_DISTRO/setup.bash
source install/local_setup.bash

# Use RMW Micro XRCE-DDS implementation
export RMW_IMPLEMENTATION=rmw_microxrcedds

# Run a micro-ROS node
ros2 run micro_ros_demos_rclc ping_pong

This proceeds to create a timer with a period of 2000 ms.

Testing the micro-ROS app (problem)

source /opt/ros/$ROS_DISTRO/setup.bash

# Subscribe to micro-ROS ping topic
ros2 topic echo /microROS/ping

Expected behavior

user@user:~$ ros2 topic echo /microROS/ping
stamp:
  sec: 20
  nanosec: 867000000
frame_id: '1344887256_1085377743'
---
stamp:
  sec: 25
  nanosec: 942000000
frame_id: '730417256_1085377743'
---

Actual behavior

suer@user~/microros_ws$ ros2 topic echo /microROS/ping
WARNING: topic [/microROS/ping] does not appear to be published yet
Could not determine the type for the passed topic

Additional information

When checking the active ros2 topics I have this output:

user@user:~/microros_ws$ ros2 topic list
/parameter_events
/rosout

Your help would be incredibly appreciated please.

Thank you very much.

pablogs9 commented 12 months ago

Is it possible for you to share the micro-ROS Agent log with the flag -v6 set?

migsdigs commented 12 months ago

Is it possible for you to share the micro-ROS Agent log with the flag -v6 set?

By this do you mean what appears in the terminal after running ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 -v6 while running ros2 run micro_ros_demos_rclc ping_pong?

Thank you for your quick reply.

pablogs9 commented 12 months ago

By this do you mean what appears in the terminal after running ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 -v6 while running ros2 run micro_ros_demos_rclc ping_pong?

yes

migsdigs commented 12 months ago 
 ros2 run micro_ros_agent micro_ros_agent udp4 --port 8888 -v6
[1695212353.797570] info     | UDPv4AgentLinux.cpp | init                     | running...             | port: 8888
[1695212353.797960] info     | Root.cpp           | set_verbose_level        | logger setup           | verbose_level: 6
[1695212438.424341] 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 79 93 AC 16 81 00 FC 01
[1695212438.424553] info     | Root.cpp           | create_client            | create                 | client_key: 0x7993AC16, session_id: 0x81
[1695212438.424640] info     | SessionManager.hpp | establish_session        | session established    | client_key: 0x7993AC16, address: 127.0.0.1:64142
[1695212438.424764] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 19, data:
0000: 81 00 00 00 04 01 0B 00 00 00 58 52 43 45 01 00 01 0F 00
[1695212438.425050] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 44, data:
0000: 81 80 00 00 01 07 24 00 00 0A 00 01 01 03 00 00 16 00 00 00 00 01 00 00 0E 00 00 00 70 69 6E 67
0020: 70 6F 6E 67 5F 6E 6F 64 65 00 00 00
[1695212438.442756] info     | ProxyClient.cpp    | create_participant       | participant created    | client_key: 0x7993AC16, participant_id: 0x000(1)
[1695212438.442924] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 14, data:
0000: 81 80 00 00 05 01 06 00 00 0A 00 01 00 00
[1695212438.442970] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1695212438.443086] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 01 00 00 00 80
[1695212438.445028] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 80, data:
0000: 81 80 01 00 01 07 47 00 00 0B 00 02 02 03 00 00 39 00 00 00 11 00 00 00 72 74 2F 6D 69 63 72 6F
0020: 52 4F 53 2F 70 69 6E 67 00 00 01 25 1D 00 00 00 73 74 64 5F 6D 73 67 73 3A 3A 6D 73 67 3A 3A 64
0040: 64 73 5F 3A 3A 48 65 61 64 65 72 5F 00 00 01 00
[1695212438.445198] info     | ProxyClient.cpp    | create_topic             | topic created          | client_key: 0x7993AC16, topic_id: 0x000(2), participant_id: 0x000(1)
[1695212438.445324] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 14, data:
0000: 81 80 01 00 05 01 06 00 00 0B 00 02 00 00
[1695212438.445387] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1695212438.445399] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 02 00 00 00 80
[1695212438.445550] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 24, data:
0000: 81 80 02 00 01 07 10 00 00 0C 00 03 03 03 00 00 02 00 00 00 00 00 00 01
[1695212438.445647] info     | ProxyClient.cpp    | create_publisher         | publisher created      | client_key: 0x7993AC16, publisher_id: 0x000(3), participant_id: 0x000(1)
[1695212438.445775] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 14, data:
0000: 81 80 02 00 05 01 06 00 00 0C 00 03 00 00
[1695212438.445830] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1695212438.445886] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 03 00 00 00 80
[1695212438.445942] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 36, data:
0000: 81 80 03 00 01 07 1C 00 00 0D 00 05 05 03 00 00 0E 00 00 00 00 02 01 52 03 00 01 00 0A 00 00 00
0020: 00 00 00 03
[1695212438.446353] info     | ProxyClient.cpp    | create_datawriter        | datawriter created     | client_key: 0x7993AC16, datawriter_id: 0x000(5), publisher_id: 0x000(3)
[1695212438.446463] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 14, data:
0000: 81 80 03 00 05 01 06 00 00 0D 00 05 00 00
[1695212438.446502] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 04 00 00 00 80
[1695212438.446522] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 04 00 00 00 80
[1695212438.446644] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x7993AC16, len: 80, data:
0000: 81 80 04 00 01 07 47 00 00 0E 00 12 02 03 00 00 39 00 00 00 11 00 00 00 72 74 2F 6D 69 63 72 6F
0020: 52 4F 53 2F 70 6F 6E 67 00 00 01 00 1D 00 00 00 73 74 64 5F 6D 73 67 73 3A 3A 6D 73 67 3A 3A 64
0040: 64 73 5F 3A 3A 48 65 61 64 65 72 5F 00 00 01 00

Is this fine? If not, I can attach an image.

pablogs9 commented 12 months ago

Yes, this is fine.

Your micro-ROS client (the ping pong application) is creating first entities correctly, at least up to this line: https://github.com/micro-ROS/micro-ROS-demos/blob/70f3cbf27ce12dc9e57e5095b4233553e207d866/rclc/ping_pong/main.c#L89

Could you debug (or at least printf-debug) if the client code is going beyond this line?

migsdigs commented 12 months ago

Sure, I will do that and give feedback. I copied more of the logs in the attached text file. I thought the previous logs were sufficient, but I see that it logged some more. Apologies for that, I think it is more appropriate in a txt file than flooring the issue. Thanks again ping_pong_logs.txt

pablogs9 commented 12 months ago

Ok, this complete logs shows that DDS communication is happening, just check those incoming (==>> DDS <<==) and outcoming (<<DDS>>) DDS messages:

[1695212631.084205] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x5706AC8C, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 16 00 00 00 80
[1695212631.084283] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x5706AC8C, len: 46, data:
0000: 81 01 07 00 09 01 26 00 00 14 00 06 57 E4 0A 65 31 27 FB 04 16 00 00 00 31 31 33 32 37 36 35 30
0020: 38 39 5F 32 30 37 35 33 37 34 39 30 30 00
[1695212633.083380] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x5706AC8C, len: 48, data:
0000: 81 80 16 00 07 01 25 00 00 21 00 05 59 E4 0A 65 30 2A F7 04 15 00 00 00 38 35 37 39 32 38 32 31
0020: 30 5F 32 30 37 35 33 37 34 39 30 30 00 00 00 00
[1695212633.083597] debug    | DataWriter.cpp     | write                    | [** <<DDS>> **]        | client_key: 0x00000000, len: 33, data:
0000: 59 E4 0A 65 30 2A F7 04 15 00 00 00 38 35 37 39 32 38 32 31 30 5F 32 30 37 35 33 37 34 39 30 30
0020: 00
[1695212633.083653] debug    | DataReader.cpp     | read_fn                  | [==>> DDS <<==]        | client_key: 0x00000000, len: 33, data:
0000: 59 E4 0A 65 30 2A F7 04 15 00 00 00 38 35 37 39 32 38 32 31 30 5F 32 30 37 35 33 37 34 39 30 30
0020: 00
[1695212633.083763] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x5706AC8C, len: 13, data:
0000: 81 00 00 00 0A 01 05 00 17 00 00 00 80
[1695212633.083827] debug    | UDPv4AgentLinux.cpp | send_message             | [** <<UDP>> **]        | client_key: 0x5706AC8C, len: 45, data:
0000: 81 01 08 00 09 01 25 00 00 14 00 06 59 E4 0A 65 30 2A F7 04 15 00 00 00 38 35 37 39 32 38 32 31
0020: 30 5F 32 30 37 35 33 37 34 39 30 30 00
[1695212635.083357] debug    | UDPv4AgentLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0x5706AC8C, len: 48, data:
0000: 81 80 17 00 07 01 26 00 00 22 00 05 5B E4 0A 65 44 9D F5 04 16 00 00 00 31 31 31 35 38 35 37 35
0020: 33 32 5F 32 30 37 35 33 37 34 39 30 30 00 00 00
[1695212635.083548] debug    | DataWriter.cpp     | write                    | [** <<DDS>> **]        | client_key: 0x00000000, len: 34, data:

That means that your micro-ROS ping pong application is working properly and publising to DDS.

So lets check the ROS 2 CLI command. When you are calling

source /opt/ros/$ROS_DISTRO/setup.bash

# Subscribe to micro-ROS ping topic
ros2 topic echo /microROS/ping
migsdigs commented 12 months ago

Alright. When I call

source /opt/ros/$ROS_DISTRO/setup.bash

# Subscribe to micro-ROS ping topic
ros2 topic echo /microROS/ping

As you have above, we get

WARNING: topic [/microROS/ping] does not appear to be published yet
Could not determine the type for the passed topic

When I echo the $ROS_DOMAIN_ID (I think this is what you meant when you said ROS_DOMAIN?) in this terminal it returns 1. I set this in bashrc when I was installing ROS2. Could this be a source of problem?

I am running in the same machine.

The output of ros2 topic list is:

/parameter_events
/rosout
pablogs9 commented 12 months ago

That is the problem! Your micro-ROS nodes are publishing in the Domain 0, just set export ROS_DOMAIN_ID=0 in the terminal before doing the ros2 topic echo /microROS/ping

pablogs9 commented 12 months ago

BTW if you need to change the domain ID of the micro-ROS nodes, just take a look here:

https://github.com/micro-ROS/micro-ROS-demos/blob/70f3cbf27ce12dc9e57e5095b4233553e207d866/rclc/configuration_example/configured_publisher/main.c#L49-L50

migsdigs commented 12 months ago

Unfortunately it still does not list or echo the topic. I tried first by setting export ROS_DOMAIN_ID=0 in the terminal before ros2 topic echo /microROS/ping. Then I tried setting the ROS_DOMAIN_ID to 0 in the bashrc and re-ran everything. Still did not work.

Could it be anything to do with anything else set in bash during the installation? ROS_LOCAL_HOST, etc... ?

pablogs9 commented 12 months ago

Try to make it a clean environment, this is a very typical configuration problem. When 2 ROS 2 instances have different Domain ID, they won't even discover each other.

As far as your micro-ROS code is working properly, this must be the problem.

Could it be anything to do with anything else set in bash during the installation? ROS_LOCAL_HOST, etc... ?

Make sure that you are not overriding ROS 2 configuration (Domain ID, Local host only)...

migsdigs commented 12 months ago

Try to make it a clean environment, this is a very typical configuration problem. When 2 ROS 2 instances have different Domain ID, they won't even discover each other.

As far as your micro-ROS code is working properly, this must be the problem.

Could it be anything to do with anything else set in bash during the installation? ROS_LOCAL_HOST, etc... ?

Make sure that you are not overriding ROS 2 configuration (Domain ID, Local host only)...

To clarify. Keep Domain ID as 0 and Local host only as 1? It is nice to know the micro-ROS is working. I can get a fresh install/config of ROS going and then see where that leads me. Thanks :)

pablogs9 commented 12 months ago

I'm not sure about Local host only = 1... try to disable it.

You can use a ROS 2 docker to ensure a clean install, for example running: docker run -it --rm ros:iron and launching your topic echo there

pablogs9 commented 12 months ago

Definitely, disable the ROS_LOCALHOST_ONLY env var. There is "bug" in Fast DDS that fails to communicate when one side has the variable enabled and the other disabled: https://github.com/eProsima/Fast-DDS/pull/3733

By default the micro-ROS Agent does not take the ROS 2 env variables, so the situation can be this.

My recommendation: make sure that disabling ROS_LOCALHOST_ONLY makes your tests work and then once the Fast DDS PR is merged, an update will fix the situation.

migsdigs commented 12 months ago

Definitely, disable the ROS_LOCALHOST_ONLY env var. There is "bug" in Fast DDS that fails to communicate when one side has the variable enabled and the other disabled: eProsima/Fast-DDS#3733

By default the micro-ROS Agent does not take the ROS 2 env variables, so the situation can be this.

My recommendation: make sure that disabling ROS_LOCALHOST_ONLY makes your tests work and then once the Fast DDS PR is merged, an update will fix the situation.

You were correct! A clean environment did the trick. I just avoided any of the additional configuration and setting of optional environment variables during the installation.

Muchisimas gracias Pablo, aprecio mucho tu ayuda :)

pablogs9 commented 12 months ago

Nice to hear that. Let us know if you have any other problem!