Gazebo 8 DepthCamera ImageData returns all gray image for config and code that worked in gazebo7

Create issue
Issue #2392 new
Andrew Somerville created an issue

In Gazebo8 Calls to DepthCamera()->ImageData() (DepthCameraSensor::ImageData) from a return an image with values that hover around 128.

Identical configuration and code using Gazebo7 returned a valid image which is the same as it would be with a normal CameraSensor.

Duplicating the camera in the sdf (one as type "camera" and one as type "depth") results in functional camera which works as a workaround to the apparently broken ImageData interface of the DepthCameraSensor.

I checked the history of rendering/ and rendering/ and didn't see any smoking guns. sensors/ and sensors/ were harder

Bug can be exercised by adding "<save enabled=1><path>./images</path></save>" below the "camera" tag of any currently working sdf sensor type="depth". Saved images will all be gray.

Comments (5)

  1. Ian Chen

    I created a simple sensor plugin to test this in gazebo8. Here're the relevant functions with calls to DepthCamera::ImageData in OnNewImageFrame:

    void DepthCameraPlugin::Load(sensors::SensorPtr _sensor,
                                  sdf::ElementPtr /*_sdf*/)
      this->parentSensor =
      this->depthCamera = this->parentSensor->DepthCamera();
      this->newImageFrameConnection = this->depthCamera->ConnectNewImageFrame(
            this, std::placeholders::_1, std::placeholders::_2,
            std::placeholders::_3, std::placeholders::_4, std::placeholders::_5));
    void DepthCameraPlugin::OnNewImageFrame(const unsigned char * _image,
                                  unsigned int _width,
                                  unsigned int _height,
                                  unsigned int _depth,
                                  const std::string &_format)
        common::Image image;
          _width, _height, common::Image::ConvertPixelFormat(_format));

    I'm seeing valid rgb image data. Maybe you're doing something different that we're not expecting?

    <save enabled=1><path>./images</path></save> does not create valid images for me but that could be a different issue.

  2. Andrew Somerville reporter

    In my case "save enabled=1" was producing images with the same gray values that I was getting in my application.

    I don't have the development environment available to do further testing in the short term, but next time there's an opportunity I'll try again.

  3. Log in to comment