MATLAB unable to receive messages of a custom ROS message type

Hi all,

I am trying to run a ROS node to drive a small rover using a motion capture system, which entails subscribing to ROS messages containing position information. I have successfully been able to set up a ROS network and detect the message type using rostopic list in both terminal and MATLAB, but unable to receive any information through rostopic echo in MATLAB, although it works perfectly fine on terminal. I have also previously run rosgenmsg successfully to build the message type. I have tested sending and receiving information using std_msgs, and found that MATLAB has no problem picking that up, so my instinct says it is a custom message type issue. I would also add that the suscriber I in the script lists all the subtopics of the message correctly, indicating successful build using rosgenmsg.

I do not get any error messages of any kind, just a time out of the rostopic echo function in the MATLAB command window.

Would anyone have any idea for a possible workaround for this problem?

(I am running Ubuntu 16.04 and MATLAB R2019a)

Thanks

[Cam Salzberger]

Hello Harvard,

Couple of questions that should help clarify how deep the issue goes:

1. If you try to create a publisher or subscriber in MATLAB for that custom message type, are they able to be created?
2. Can you create a blank message of the correct type with rosmessage?
3. Are you able to publish that message, and receive it on another machine that is looking for that message type (if you have any)?
4. If you create a subscriber for that message type, does it receive the messages? Are you able to create a callback that accesses data within them?

-Cam

[Harvard Humphrey]

In response to your queries I have conducted a few tests with two laptops:

1. I have successfully created both the publisher and subscriber for the message type "qualysis/Subject", and have checked the workspace, in which it lists the correct subtopics and components.
2. I have created two messages with rosmessage, one in which I have left it untouched, i.e blank, and another in which I have manually assigned the component variables.
3. I have been able to publish this manually assigned message through a MATLAB ROS subscriber, and have successfully received it on another Linux machine through the terminal window with the command "rostopic echo". I would point out I was unable to receive a message on MATLAB that was published on this other machine via terminal using "rostopic pub".
4. I was able to publish a message on MATLAB and receive it on the same machine through MATLAB using the "sub.LatestMessage" command on MATLAB. This was all on the same machine.

I hope this helps clarify the depth of the problem.

[Cam Salzberger]

Hmm, so far my understanding is that there are two times when the communication did not go through:

1. Non-MATLAB publishing custom message, and MATLAB is trying to use "rostopic echo" to view them.
2. Non-MATLAB publishing a "one-off" message using "rostopic pub", and MATLAB has a subscriber for that topic (LatestMessage property does not update).

Let me know if my understanding is incorrect.

Two possible hypothesis come to mind:

1. Something is going on with the ROS command line tools (rostopic specifically), though the two failures seem to make this unlikely.
2. Something is up with the Master itself.

Did you use the same Master when doing your tests above as you do under your normal setup? Or did you create a separate MATLAB master for that? Is your normal Master located on MATLAB or on the other machine?

One other possible thing to check is MATLAB-to-MATLAB communication using "rostopic echo". Can you run this code and let me know if anything is echoed?

rosinit
p = rospublisher('/test_topic', 'qualysis/Subject');
m = rosmessage(p);
t = timer('TimerFcn', @(~, ~) send(p, m), 'Period', 1, 'ExecutionMode','fixedRate', 'TasksToExecute', 30);
start(t)
rostopic echo /test_topic

Don't forget to stop and delete the timer once you Ctrl+C to stop the echo. Otherwise it hangs around, though I limited the number of times it runs in case you forget.

[Harvard Humphrey]

Hi Cam,

I have run the code as requested and can answer your queries:

Your understanding of my decription of the problem from earlier is correct. In all previous tests I used the same Master setup as I did for the original setup that I was running when I discovered the problem. This master is on the same machine as MATLAB, and uses Robotics Systems Toolbox (ROS) to stream data from a Qualysis motion capture system, the data of which is generated on another machine that is NOT running ROS but connected to the same network as the ROS master and MATLAB machine.

Additionally I ran a test in which I published a message of the specified topic using MATLAB and successfully received it on a different machine with terminal (this machine was acting as the Master for this particular test).

Hope this helps narrow things down.

Answer 1

[Cam Salzberger]

Hey Harvard,

Now that things have been narrowed down, hopefully I can offer some potential solutions. One of the biggest causes I've seen for communication not happening in ROS (especially one way having an issue, and the other not) is the originating node not advertising itself properly. Essentially, one of the machines is incapable resolving the address to the other machine, and so communication in that direction wasn't possible, though it could still receive incoming data. One of the other common symptoms I saw for this was that "rosnode ping <pub_name>" would time out when called from the subscriber node side.

Probably can't hurt to just try a regular "ping" as well in both directions.

The most common solution for this issue is to ensure that the "ROS_IP" environment variable is set on the originating machine (in the terminal before running the node). The value of this variable should be the computer's own IP address. Make sure that "ROS_HOSTNAME" is not set if you are using "ROS_IP", as the "ROS_HOSTNAME" will supercede it.

Another possible issue is if your machine (either machine, I suppose) has a hostnames file (which specifies how the DNS lookup can determine the IP for the target machine from a hostname), and the target machine hostname doesn't match the IP of that machine.

It's also possible that the port for the ROS master is unblocked, but the specific port that the publisher-subscriber connection is using is blocked by your firewall. That one is tougher to check safely, and usually not an issue, so I'd save checking that for last.

You can get more diagnostic information out of the native ROS tools. The aptly-named "roswtf" command is pretty useful (run from one of the machines running ROS natively). rqt_graph is also useful for visualizing the network, which may indicate issues in the form of cut off nodes or similar.

I hope that helps to get you going.

-Cam

[yu zhang]

thanks very much!!!，solved the problem succesfully!

[Yoseph Kebede]

What solved the problem? Cam suggested multiple ways out of which I have tried most. I am using Ubuntu WSL and Matlab on the same computer which I am trying to communicate to eachother. What should I do?