MATLAB Answers

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

12 views (last 30 days)
  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
$ 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");
laserSub = ros2subscriber(detectNode,"/scan");
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");
odomSub = ros2subscriber(detectNodeOdom,"/odom");
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.
Cam Salzberger
Cam Salzberger on 15 Mar 2021
Thanks for letting me know. I'll look into what is going on with it, but this is probably a good workaround for now.

Sign in to comment.

Accepted Answer

Cam Salzberger
Cam Salzberger on 11 Mar 2021
Edited: Cam Salzberger on 12 Mar 2021
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.
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 Salzberger
Cam Salzberger on 12 Mar 2021
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.

Sign in to comment.

More Answers (0)




Community Treasure Hunt

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

Start Hunting!

Translated by