sensor_msgs/Range with ros_gz

[EGAlberts]

Is there support for the sensor_msgs/Range type as there appears to be in Gazebo classic?

I am trying to migrate the following sensor from classic:

 <plugin name="${name}_gazebo_ros_range" filename="libgazebo_ros_ray_sensor.so">
           #<ros>
            <namespace></namespace>
            <remapping>~/out:=${ros_topic}</remapping>
          </ros>
          <output_type>sensor_msgs/Range</output_type>
          <radiation_type>${radiation}</radiation_type>
          <frame_name>${name}_link</frame_name>
</plugin>

As you can see it outputs to sensor_msgs/Range rather than LaserScan, while I believe the use of gpu_lidar as a sensor type as is the new convention creates a corresponding LaserScan gz msg which cannot be converted to Range.

If there is no established way to do so, I can resubmit this issue as a feature request, or attempt to add this myself as a custom sensor.

[azeey]

I don't know of an established way to do this. If it's just a matter of converting LaserScan messages to Range, how about creating a ros_gz bridge for gz.msgs.LaserScan<->sensor_msgs/Range?

[EGAlberts]

Thanks for the reply, it seems the conversion was done here: https://github.com/ros-simulation/gazebo_ros_pkgs/blob/a1954425c3e0045e8591b6516f31edd77c96e7c8/gazebo_ros/include/gazebo_ros/conversions/sensor_msgs.hpp#L291 before, which I suppose can be integrated into the bridge. My only doubt is how to allow the xml element which prior were unique to this usage of the plugin (Like radiation type). Can it somehow be added as a child element of a gpu_lidar sensor without raising errors and then read in? Or should this be specified as an entry in the bridge? I am only asking if there is some established convention, in the mean time I will explore the implications of potential solutions.

[EGAlberts]

To answer my own question. The only way to include the radiation_type would see the creation of a new gazebo message corresponding to Range which is then converted to Range. This is because the bridge only receives a copy of the gazebo msg which typed LaserScan which does not have a radiation type. I think the more realistic solution is to convert from LaserScan and give the radiation type field a default dummy value, which users should then be wary of. I will create a pull request for my suggested solution of converting LaserScans to Range messages based on the snippet linked in my previous reply.

[azeey]

This is really more of a workaround until we get a Sonar sensor (gazebosim/gz-sensors#19), so I think it would be okay to use a dummy value for radiation type. I only ask that we document this in the README.