Listener node cannot hear the message from the talker node about demos

[clalancette]

Two things you can try here:

1. Run ros2 doctor, which may give you some feedback about network configuration.
2. In galactic, try running both the talker and the listener using rmw_fastrtps_cpp. That is, run the commands like this:

RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run demo_nodes_cpp talker

That will tell us whether the problem you are having is generically in Galactic, or specifically in the default DDS vendor (which is CycloneDDS in Galactic).

[yang-yuke]

Thanks, Chris!

I still have some confusion with regard to your reply. In step 2, what should be the command I should run for the listener? Do you mean I should run the below 2 commands in the terminal?
1.run the talker RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run demo_nodes_cpp talker
2.run the listener RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run demo_nodes_cpp listener

Or should I run the listener with the command RMW_IMPLEMENTATION=rmw_fastrtps_cpp ros2 run demo_nodes_py listener?

[clalancette]

Either one will do. The important bit is that you are using rmw_fastrtps_cpp as the DDS vendor.

[yang-yuke]

Hello, Chris,

I use the commands you gave me. Now it works normally. Could you please elaborate on what is the reason here? Is it because the default vendor in Galactic(i.e. CycloneDDS) has some bug? What is the DDS vendor we are using with the rmw_fastrtps_cpp?

//talker terminal, print out messages normally

//listener terminal, can print out messages telling that it is receiving messages from talker now.

//run the listener py script, can also print out messages normally.

[clalancette]

I use the commands you gave me. Now it works normally. Could you please elaborate on what is the reason here? Is it because the default vendor in Galactic(i.e. CycloneDDS) has some bug?

I'm not sure what's going on here. But at least we know it has something to do with CycloneDDS. Ping @eboasson to take a look and maybe get some relevant information.

What is the DDS vendor we are using with the rmw_fastrtps_cpp?

It's using Fast-DDS instead.

[yang-yuke]

I use the commands you gave me. Now it works normally. Could you please elaborate on what is the reason here? Is it because the default vendor in Galactic(i.e. CycloneDDS) has some bug?

I'm not sure what's going on here. But at least we know it has something to do with CycloneDDS. Ping @eboasson to take a look and maybe get some relevant information.

What is the DDS vendor we are using with the rmw_fastrtps_cpp?

It's using Fast-DDS instead.

Thanks Chris for your prompt reply. I have one more question. What is the default DDS vendor used by foxy BTW? Is it the same as Galactic(i.e. Cyclone DDS)?

[clalancette]

Thanks Chris for your prompt reply. I have one more question. What is the default DDS vendor used by foxy BTW? Is it the same as Galactic(i.e. Cyclone DDS)?

No, Foxy, uses rmw_fastrtps_cpp by default.

[yang-yuke]

I

Thanks Chris for your prompt reply. I have one more question. What is the default DDS vendor used by foxy BTW? Is it the same as Galactic(i.e. Cyclone DDS)?

No, Foxy, uses rmw_fastrtps_cpp by default.

I see, thank you so much Chris!

[eboasson]

Hi @yang-yuke, I would guess it has something to the with a networking configuration, but let's make sure by looking at the debugging traces that Cyclone can write. (There are other steps one might take to narrow down the problem, but if it is something simple where the other methods also work, it can usually be found in the traces as well; and if it is something totally weird, then one usually ends up needing the the traces anyway.)

Those traces are not the easiest thing to read, not even with a document describing them (and I only have a draft anyway), but I am happy to look at them for you. Would you be willing to share the logs with me? If you're not comfortable sharing internal internal IP address in GitHub attachments, email me directly. My address is pretty easy to find from the commit log of Cyclone 🙂

To get the traces, please run it with CYCLONEDDS_URI="$CYCLONEDDS_URI,<Tr><C>trace</><Out>cdds.log.\${CYCLONEDDS_PID}</></>" in the evironment? (This is abbreviated XML that one would normally write out in full and put in the configuration file.) This should get you one file for each process, cdds.log.PID where PID is the process id.

[yang-yuke]

Hi @yang-yuke, I would guess it has something to the with a networking configuration, but let's make sure by looking at the debugging traces that Cyclone can write. (There are other steps one might take to narrow down the problem, but if it is something simple where the other methods also work, it can usually be found in the traces as well; and if it is something totally weird, then one usually ends up needing the the traces anyway.)

Those traces are not the easiest thing to read, not even with a document describing them (and I only have a draft anyway), but I am happy to look at them for you. Would you be willing to share the logs with me? If you're not comfortable sharing internal internal IP address in GitHub attachments, email me directly. My address is pretty easy to find from the commit log of Cyclone 🙂

To get the traces, please run it with CYCLONEDDS_URI="$CYCLONEDDS_URI,<Tr><C>trace</><Out>cdds.log.\${CYCLONEDDS_PID}</></>" in the evironment? (This is abbreviated XML that one would normally write out in full and put in the configuration file.) This should get you one file for each process, cdds.log.PID where PID is the process id.

Dear Mr. Erik,

I really appreciate your willingness to help me out. Can we sync up offline once? There are a lot of things I cannot make clear here. I have sent an email to you. My email address is [email protected]. Hope you receive it.

I will update the thread here once the problems are resolved.