Receive data from ros2 /scan topic does not work, while it is possible for /odom and /cmd_vel topic

  1. A Simulink model according to the tutorial here was created. The Virtual Machine provided by Matlab for Dashing and Gazebo (where the ROS bridge is used for ROS2 interaction) was used to successfully extract the Turtlebot3 /scan and /odom topics from the Gazebo simulation to build a 2D map.
2. The same Simulink model was used with a real Turtlebot3 with Ubuntu 18.04.3 preinstalled server as sbc operating system. Strangely, the /odom data is available,
but no /scan data can be measured (all scan.signal.values are 0).
3. The behavior from 2. can be confirmed with a Gazebo simulation with a fresh installation on a host PC with
  • Ubuntu 18.04 LTS
  • Dashing Diademata for ROS2
  • Matlab 2020b
The following test were executed with the described setting from 3. For easier testing basic ROS2 Matlab commands were used.
Preparation of further investigations
Gazebo und keyboard teleoperation were started:
$ ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py
$ ros2 run turtlebot3_teleop teleop_keyboard
Connection between Matlab and Ubuntu host is working:
>> ros2 topic list -t
Topic MessageType
_______________________ _________________________________
{'/camera/camera_info'} {'sensor_msgs/CameraInfo' }
{'/camera/image_raw' } {'sensor_msgs/Image' }
{'/clock' } {'rosgraph_msgs/Clock' }
{'/cmd_vel' } {'geometry_msgs/Twist' }
{'/imu' } {'sensor_msgs/Imu' }
{'/joint_states' } {'sensor_msgs/JointState' }
{'/odom' } {'nav_msgs/Odometry' }
{'/parameter_events' } {'rcl_interfaces/ParameterEvent'}
{'/robot_description' } {'std_msgs/String' }
{'/rosout' } {'rcl_interfaces/Log' }
{'/scan' } {'sensor_msgs/LaserScan' }
{'/tf' } {'tf2_msgs/TFMessage' }
{'/tf_static' } {'tf2_msgs/TFMessage' }
Error message
To get the laser scan data the following commands are used:
detectNode = ros2node("/tb3_scan");
pause(2)
laserSub = ros2subscriber(detectNode,"/scan");
pause(2)
scanData = receive(laserSub,10);
which leads to the error message
Error using ros2subscriber/receive (line 458)
Subscriber did not receive any messages and timed out.
On the Ubuntu host,
$ ros2 topic echo scan
outputs the laser scan data to the gnome-terminal: the data seems to be available.
Further tests
  1. Test with /odom:
detectNodeOdom = ros2node("/tb3_odom");
pause(2)
odomSub = ros2subscriber(detectNodeOdom,"/odom");
pause(2)
odomData = receive(odomSub,10);
No error message, odomData is available in the workspace.
2. Test with /cmd_vel provides same result as with /odom under 1. (data available in workspace).
3. The command
>> ros2 msg list
shows no messages.
The same command shows loads of messages in the gnome-terminal.
Any help is appreciated.

5 Comments

The lack of messages showing from "ros2 msg list" is odd, to say the least. That command doesn't even use the network, it just checks available message definitions.
Can you check if you have an environment variable defined in MATLAB that may be throwing things off slightly?
getenv('AMENT_PREFIX_PATH')
It may also be worth restarting MATLAB and seeing if the problem persists. Some parts of the message list get cached within a session (to improve performance). If that cache got corrupted somehow, that could be giving you that result.
-Cam
A restart did not change the problem.
The command
getenv('AMENT_PREFIX_PATH')
provides the output
/home/rosadmin1/colcon_ws/install/turtlebot3_simulations:/home/rosadmin1/colcon_ws/install/turtlebot3_gazebo:/home/rosadmin1/colcon_ws/install/turtlebot3:/home/rosadmin1/colcon_ws/install/turtlebot3_teleop:/home/rosadmin1/colcon_ws/install/turtlebot3_bringup:/home/rosadmin1/colcon_ws/install/turtlebot3_node:/home/rosadmin1/colcon_ws/install/turtlebot3_navigation2:/home/rosadmin1/colcon_ws/install/turtlebot3_fake_node:/home/rosadmin1/colcon_ws/install/turtlebot3_example:/home/rosadmin1/colcon_ws/install/turtlebot3_description:/home/rosadmin1/colcon_ws/install/turtlebot3_cartographer:/opt/ros/dashing'
Those directories are my ROS workspace for the turtlebot3 (real robot, gazebo, navigation,...) for ROS Dashing on Ubuntu 18.04 LTS from the dashing-devel branch of the following git repositories:
Hmm, just to rule it out as a possible issue, can you try restarting MATLAB (or start a new session) and running this before anything else:
setenv('AMENT_PREFIX_PATH','')
ros2('msg', 'list')
-Cam
That's it: now the message list is displayed in Matlab.
Thanks for letting me know. I'll look into what is going on with it, but this is probably a good workaround for now.
-Cam

Sign in to comment.

 Accepted Answer

Hello Bernd,
There are two main culprits that I always look at first when there is difficulty communicating in ROS 2, but there is information about the topic, indicating some level of communication:
Quality of Service Setting Compatibility
There are certain combinations of QoS settings between publisher and subscriber that can result in them being unable to communicate. See explainations here and here. You can check the settings that the publisher and subscriber use by checking their properties (in MATLAB) or how it is created (outside of MATLAB).
Ensure that the settings are compatible according to the table in the first link.
Subnet/Extended-network
Check the IP addresses of the computers on both ends of the network. If they are in the same "subnet", then they should be able to communicate freely. Typically this means that the first three sequences in the IP addresses need to be the same, but the definition of the subnet may vary depending on your network mask.
If the computers are not in the same subnet, you need to extend your network. MATLAB uses the Fast-RTPS DDS back-end for ROS 2, so it needs a DEFAULT_FASTRTPS_PROFILES.xml file in the current directory to extend the network. This has to be done in a reciprocal manner, though, so the other machine needs the same file pointing to the MATLAB computer's IP. If the other machine also uses Fast-RTPS on the back-end (the default for Dashing), then the same file should suffice if it lists both IP addresses. I don't have experience with talking across different DDS implementations, but I assume there is a similar way to extend the network for other back-ends.
See here for an example profiles XML file. Make sure the domain ID is set correctly in the file. Any nodes will need to be deleted and recreated for changes to the profiles file to take effect.
Complete Lack of Communication
Just for completeness, I wanted to link to other fixes for issues when communication is not occurring at all. It's not necessarily applicable here, since the topic is visible from MATLAB though.
-Cam

4 Comments

Hello Cam,
your QoS hint was crucial: ask an expert and he points into the right direction :) .
In Matlab, I changed "Reliability" from "reliable" to "besteffort" to avoid conflicts (as you mentioned can be found in the tables here) and everything works fine. My code looks now like this
detectNode = ros2node("/tb3_scan");
pause(2)
laserSub = ros2subscriber(detectNode,"/scan","Reliability","besteffort")
scanData = receive(laserSub,10);
In Simulink, the standard setting of the ROS2 subscriber block for "Reliability" is "reliable". I changed this to "besteffort": Everything works fine now.
/odom seems to publish with "reliable", /scan with "besteffort", i. e. "reliable" does not work for the /scan subscriber. This causes oftentimes problems, see e. g. c) below, but is part of the learning process.
Tanks a lot, Cam! I did not expect to have to dive into ROS2 pecularities for such a "simple" example.
Bernd
Further comments:
a) Subnet issues could not be the reason since I worked on a single machine to exclude this option (see my setting under 3.).
b) Sadly, the command
ros2 topic info /scan --verbose
was introduced in Foxy Fitzroy. There is no --verbose in ROS Dashing Diademata.
c) Some recent changes were made with regard to standard QoS reliability settings of Gazebo plugins in ROS Foxy Fitzroy (best-effort subscription, reliable publication).
Oops, that's what I get for not confirming my advice on my Dashing VM. Sorry about the "verbose" suggestion.
The default MATLAB/Simulink uses for QoS is based on the default QoS profile for publishers and subscribers. However, the "sensor profile" that is recommended to use for extremely frequent data and/or large data (e.g. point clouds or images) uses besteffort, since it's usually not as important that every message is received. It's good to pick the QoS settings that fit your application.
-Cam
Hi,
I have a linux device on my network. The subnet of my PC and the linux device are the same. I set the domain ID of both to 5. When I create a node in either of them I can detect it in another. Likewise, I can do the same for topics. I have a basic publisher and subscriber, which work perfectly fine, when run in the linux device. When I run the publisher on the linux machine; although Matlab in my PC can detect both the publisher node and the topic, the Matlab "receive" function always timeout and does not recieve any messages. I trully appreciate if you can suggest something.
By the way I am running linux 18.04 with ROS2 Dashing. I tested this on both Matlab 2020b and 2021b with no luck.
Here is my Matlab Code:
clear all
clc
setenv("ROS_DOMAIN_ID","5");
ros2 topic list
topicList=ros2("topic","list");
if(sum(contains(topicList, "test_publisher_topic")))
SubscriberNode=ros2node("/matlab_subscriber", 5);
msgSub=ros2subscriber(SubscriberNode, "/test_publisher_topic" ,"std_msgs/String");
while(1)
Message=receive(msgSub, 5);
disp(Message)
end
else
disp('hossein_topic not present!')
end
ERROR Code:
Error using ros2subscriber/receive (line 458)
Subscriber did not receive any messages and timed out.
Thanks
Hossein
It would probably be better to open a new question for this, Hossein.

Sign in to comment.

More Answers (0)

Categories

Products

Release

R2020b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!