Added reflectance output image for DepthCamera

[WilliamLewww]

When specified in the SDF file, the depth camera will output a reflectance image that can be viewed in the topic visualizer.

[ahcorde]

can we add a test to check the ign topic ?

[WilliamLewww]

I added a test for both enabled and disabled reflectance output.

[WilliamLewww]

Should I create a different pull request to encapsulate all the date for the other tests that are already there?

https://github.com/osrf/gazebo/blob/2e42eb91e7638da54b36dbb8fdd4ae5e3a310d6d/gazebo/sensors/DepthCameraSensor_TEST.cc#L25-L32

https://github.com/osrf/gazebo/blob/2e42eb91e7638da54b36dbb8fdd4ae5e3a310d6d/gazebo/sensors/DepthCameraSensor_TEST.cc#L196-L201

[ahcorde]

Should I create a different pull request to encapsulate all the date for the other tests that are already there?

You can do it in this PR

[ahcorde]

@Steve do you mind to take another quick look ?

[scpeters]

Steve do you mind to take another quick look ?

I assume you meant me. Sure I'll take another look

[scpeters]

should we use the Sensor::UpdateRate() instead of hard-coding to 50 Hz?

[WilliamLewww]

I noticed that the other cameras are using a hard-coded 50Hz:

https://github.com/osrf/gazebo/blob/26b69a7cff29312164558d23344eb551a96508ba/gazebo/sensors/CameraSensor.cc#L110-L112

https://github.com/osrf/gazebo/blob/26b69a7cff29312164558d23344eb551a96508ba/gazebo/sensors/WideAngleCameraSensor.cc#L146-L148

When I tried changing the 50 to this->UpdateRate(), I get a broken topic because I think the update rate has not been set and still is the value 0.000.

I could change this and initialize the update rate before advertising the topic but I am unsure if this will cause problems to the other components on the depth camera.

[scpeters]

gazebo::transport::Node::Advertise has two optional numeric parameters, first the queue size and then the rate of publishing in Hz. In these examples from CameraSensor and WideAngleCameraSensor, 50 is actually the queue size. In the ignition::transport code (that has now been removed) it was a bit more clear that SetMsgsPerSec was about the rate of publishing

I think no additional changes are needed to the queue size

[WilliamLewww]

Inverted the reflectance buffer to correct the inverted values for depth images.

[scpeters]

I've merged with gazebo11 to fix the abichecker build

[scpeters]

can you clarify what the values in this array mean physically? does 0 mean nonreflective and 1 mean reflective?

I'm asking because you inverted the data in c776173

[iche033]

oh we should not invert the data on the sensors side. We should only update the visualization code. The gui visualization inverts the data when it detects that the underlying image has a FLOAT type:
https://github.com/osrf/gazebo/blob/gazebo11/gazebo/gui/viewers/ImageFrame.cc#L157-L167

The logic there was added for visualization of depth data, i.e. black pixels means far away while white means close to camera. However, now that the reflectance image output is also in FLOAT, we don't want the inversion to be applied to the reflectance image. I think there needs to be some way on the gui side to tell reflectance images from depth images so that the correct visualization is applied.

[WilliamLewww]

To prevent the buffer from inverting, I set the reflectance message format to UNKNOWN_PIXEL_FORMAT so that the image frame would be able to detect that the message isn't a depth image. The pixel format R_FLOAT32 is hardcoded to be recognized as a depth buffer, and to maintain the pixel format while being able to distinguish depth vs. reflectance would require pixel analysis.

A cleaner solution is to add a new data member to the Image message specifying what type of image the message contains. The change could remove the hardcoded pixel format to image type mapping but will make the Image message larger. I am not too sure how disruptive this change may be so I opted for the first solution.

[chapulina]

What's the status of this PR?