Problem with Some RosPlugins due to an "/".

Report crashes, strange behaviour, or apparent bugs
Posts: 9
Joined: 06 Oct 2016, 00:39

Problem with Some RosPlugins due to an "/".

Postby sradmard » 10 Nov 2016, 19:48

I do not know whether this problem has already been discovered before, but it looks like it is not addressed in the latest version of the ROS packages, so I thought it might be useful to share.

I found a problem while using the publisher “simros_strmcmd_get_depth_sensor_data”. This RosPlugin publishes the frame_id of the header of the published PointClouad2 message in ROS with a preceding “/”. This was compatible with tf, but is not compatible with tf2 standard since there was a change in tf2, that frame_ids cannot start with an “/” anymore. Therefore, there will be a problem in ROS if we try to apply tf2 to the published data of “simros_strmcmd_get_depth_sensor_data”. I also think it is the same problem with other RosPlugins that publish a frame_id in their message, like "simros_strmcmd_get_laser_scanner_data", and you want to apply any action in ROS that involves tf2.

I faced this problem when I wanted to apply pointcloud_to_laserscan package to the pointcloud data that I was publishing via “simros_strmcmd_get_depth_sensor_data”. Here is my specific story:

Imagine that we are publishing PointCloud2 message type on a topic called “/cloud_in”. When we check for the published data on this topic in ROS using:
$ rostopic echo /cloud_in -n 1 –noarr
we see the output frame_id to be like:
frame_id: /base_scan
Then imaging that you want to apply pointcloud_to_laserscan package to convert the publishing point cloud data from “/cloud_in” topic to laser scan data and publish it on “/scan” topic. Depending on how your reference frames have been set in the v-rep model, you may need to transform the data from one reference frame to another as well. Since pointcluod_to_laserscan package provides the option for setting a “target_frame”, you can adjust the target_frame in the launch file of pointcloud_to_laserscan, for instance as follows:
target_frame: laser_frame
This allows for reference frame transformation, so that you can transform the reference frame of the publishing point cloud data to a different reference frame for the converted laser scan data. This transformation operation involves tf2, which does not accept frame_ids that start with “/”.

Solution: my solution was to modify the source code for “simros_strmcmd_get_depth_sensor_data” in the “vrep_plugin” package under programming/ros_packages and eliminate the “/” before the frame_id of publishing point cloud data from v-rep. The source file for this is ROS_server.cpp. My quick hack was to modify the line #90 in ROS_server.cpp as follows:
std::string ret = objName; //objNameToFrameId(objName)

After rebuilding the vrep_plugin package, it will update “”. The last step is to link this newly built library to the V-REP installation folder. The new library provides a frame_id without preceding “/” for “simros_strmcmd_get_depth_sensor_data” publisher.
I am sure there is a better a way to address this bug instead of hack, so that it does not interfere with other functionalities of RosPlugins. I hope this will be considered in the next v-rep release.

Good luck everyone.

Site Admin
Posts: 5614
Joined: 14 Dec 2012, 00:25

Re: Problem with Some RosPlugins due to an "/".

Postby coppelia » 11 Nov 2016, 08:50


you are perfectly right, there are some shortcomings in the old Ros Plugin. Some of them have been addressed more or less elegantly, but in the end the problem is more that the Ros Plugin does not closely duplicate the Ros API.

Since a couple of months, there is a new Ros Interface, that should be used instead, since it is much more flexible, supports all standard messages, can easily be extended, and duplicated the C++ ROS API quite closely.


Return to “Bug reports”

Who is online

Users browsing this forum: No registered users and 3 guests