Depth buffer issues in remote access to camera


I’m using ROSBot 2.0, and I’m trying to display the images returned by the RGB camera and the depth camera. To do this, I display the return of the topics /camera/rgb/image_rect_color and /camera/depth/image_rect_raw via the ROS image_viewer node on a remote computer.
This works well by setting all camera output video formats to QVGA_30Hz resolution (limited to 320x240) via rqt_reconfigure; but I would like to get VGA_30Hz (640x480) resolution output. Unfortunately, when I try to set this resolution for the depth camera, I get multiple “Depth Frame is corrupt” errors that greatly decrease the number of images available for the depth camera.

The errors are as following :

 29878148 WARNING    Read: Depth buffer is corrupt. Size is 476240 (!= 614400)
 29965883 WARNING    Depth: Expected 21ab, got 220f
 29966066 WARNING    Depth frame is corrupt!
 29966365 WARNING    Read: Depth buffer is corrupt. Size is 4448 (!= 614400)
 30030806 VERBOSE    [FPS] IR: 0.00 Color: 30.38 Depth: 14.73 
 30113484 WARNING    Depth: Expected 2366, got 2384
 30113714 WARNING    Depth frame is corrupt!
 30114368 WARNING    Depth: Expected 23ba, got 243c
 30114585 WARNING    Read: Depth buffer is corrupt. Size is 120160 (!= 614400)
 30158761 WARNING    Depth: Expected 24cc, got 2512
 30158873 WARNING    Depth frame is corrupt!
 30159446 WARNING    Read: Depth buffer is corrupt. Size is 476240 (!= 614400)
 30199266 WARNING    Depth: Expected 25ad, got 25f1
 30199357 WARNING    Depth frame is corrupt!
 30199425 WARNING    Depth: Expected 25f6, got 25ee
 30199597 WARNING    Read: Depth buffer is corrupt. Size is 240336 (!= 614400)

Is this type of error related to the camera, or to ROS topics? Is there a 640x480 resolution without this type of error for the RGB, IR and depth cameras of this robot?



Hi XV25,

Thank you for detailed description of your issue. We will investigate it and send you response asap.

Best regards,

Hello XV25,

The issue occurs due to overflowing network capacity.
By default ROS is using uncompressed data to transfer images, this should be used only on local machine.
To view camera image on other computers, you should use compressed images.

First, install image_transport_plugins:

For Ubuntu 18.04:

sudo apt install ros-melodic-image-transport-plugins

or for Ubuntu 16.04:

sudo apt install ros-kinetic-image-transport-plugins

Then on ROSbot launch astra camera as usual:

roslaunch astra_launch astra.launch

Finally launch image_view on your computer:

rosrun image_view image_view image:=/camera/rgb/image_rect_color _image_transport:=compressed
rosrun image_view image_view image:=/camera/depth/image_rect_raw _image_transport:=compressedDepth 

The Astra camera driver is using image_transport which automatically loads all available transport plugins, that is why you do not need to modify astra.launch. On the other hand image_view is using uncompressed image by default, thus it is required to specify image transport.


Hello Łukasz,

Thank you for your response.
I tested the image_transport plugin. It has indeed greatly reduced my bandwidth usage (from 5 MB/s to roughly 450 kb/s when I display the two topics via image_view), and reduced the corrupted buffer problems.
Unfortunately, the problem still appears. I have the impression that it is not only related to a bandwidth problem: when I display the topic /camera/rgb/image_rect_color (via

rosrun image_view image_view image:=/camera/rgb/image_rect_color 

), the consumed bandwidth is then 4.5MB/s. However, I don’t have any problem of corruption on the rgb buffer. Conversely, when I display the topic /camera/depth_registered/image_raw (on which I want to work later, and displayed via the command :

rosrun image_view image_view image:=/camera/depth_registered/image_raw

), the bandwidth consumed is roughly the same, but the corruption problems of the buffer depth appear. Finally, by displaying the two topics, although the bandwidth consumed is much lower, the corrupted depth buffer issue still appears.
Here are some screenshots of the bandwidth consumption according to the topics called. Could you tell me if there is another reason for this problem, please?



Hello XV25,

I would like to verify that the problem is not caused by other “non-ROSbot” factors. Would it be possible for You to make the same test with different network connection and workstation?


Hello Łukasz,

Sorry for the delay of this response. I have not been able to test this with a different workstation, but I have been able to test it with a different network connection.
Here are the results with an optical fiber (the previous results were obtained via a VDSL connection, having less bandwidth). There is better performance for the uncompressed depth_registered/image_raw topic, and perhaps a slight improvement for the compressed depth_registered/image_raw and compressed rgb/image_rect_color combination (despite the persistence of corrupted depth buffer errors). Otherwise, the results look about the same on both connections.

I will try on another workstation and get back to you.




I did a similar ticket here in the forum:

I see the same problem also if the receiver of the camera data is inside the robot. So, no external network interface is used, only the internal loopback interface.

If you use a faster external connection (like fibre) than you have better results because the network packets are processed faster by the hardware and a packet fragmentation does not occur so often.

In my ticket, I described what I think what happens in the software of RosBot: The internal network reciever software part is not aware about the fact that network packets can be divided into several fragments and a receiver (internal or extern) must collect as much packets as needed to fulfill the read size.

I think, this is here the problem.

Could anyone of Husarion or ROSBot check that?

Best reghards,


Hi @matthias

Like I said in the post you linked. I guess it’s better to ask maintainers of ROS on how it is implemented.
The only thing I can say it that indeed ROSbot wireless connection is not the fastest for current standards. We are working on changing that in newer models.

Best regards,
Krzysztof Wojciechowski.