Problem with Some RosPlugins due to an "/".
Posted: 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 “libv_repExtRos.so”. 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.
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 “libv_repExtRos.so”. 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.