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?
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.
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.
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
), 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 :
), 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?
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?
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 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.
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.
