Revision history [back]

A gigabit link provides at most a throughput of 125 MB/s. At most, as it is the theoretical limit of the transport. More often than not it won't get there.

I'm not sure what the datarate of the points topic of a realsense is, but if you'd get 6 to 12 Hz, it's probably on the order of 10 to 15MB/sec, which seems like it could be correct.

Running 2 cameras without any compression will not make things any faster.

If with "network overhead" you meant the fact that you're transferring the data over a network (ie: just that fact), then it's indeed true that this will place a bottleneck in your system.

Traditionally though, the term "overhead" is used to mean "additional traffic not directly used to transmit the payload itself" (so: headers, signalling, etc). I'm not sure that would be the main cause of the reduced data rates here. My first though would be you're simply saturating the available bandwidth.

Perhaps try a rostopic bw /camera1/depth/color/points on your master and post those results here.

A gigabit link provides at most a throughput of 125 MB/s. At most, as it is the theoretical limit of the transport. More often than not it won't get there.

I'm not sure what the datarate of the points topic of a realsense is, but if you'd get 6 to 12 Hz, it's probably on the order of 10 to 15MB/sec, which seems like it could be correct.

Running 2 cameras without any compression will not make things any faster.

If with "network overhead" you meant the fact that you're transferring the data over a network (ie: just that fact), then it's indeed true that this will place a bottleneck in your system.

Traditionally though, the term "overhead" is used to mean "additional traffic not directly used to transmit the payload itself" (so: headers, signalling, etc). I'm not sure that would be the main cause of the reduced data rates here. My first though would be you're simply saturating the available bandwidth.

Perhaps try a rostopic bw /camera1/depth/color/points on your master and post those results here.

A gigabit link provides at most a throughput of 125 MB/s. At most, as it is the theoretical limit of the transport. More often than not it won't get there.

I'm not sure what the datarate of the points topic of a realsense is, but if you'd get 6 to 12 Hz, it's probably on the order of 10 to 15MB/sec, which seems like it could be correct.

Running 2 cameras without any compression will not make things any faster.

If with "network overhead" you meant the fact that you're transferring the data over a network (ie: just that fact), then it's indeed true that this will place a bottleneck in your system.

Traditionally though, the term "overhead" is used to mean "additional traffic not directly used to transmit the payload itself" (so: headers, signalling, etc). I'm not sure that would be the main cause of the reduced data rates here. My first though would be you're simply saturating the available bandwidth.

Perhaps try a rostopic bw /camera1/depth/color/points on your master and post those results here.

what is the best setup for interfacing 6 realsense cams in ros?

I'm not convinced your problem is with ROS necessarily: saturating a specific link with traffic will become a problem in many (all?) cases, no matter which communication infrastructure you use. How the saturation is dealt with, that would seem to be specific to whatever you're using.

Edit: something to look into may be compressed_depth_image_transport. It trades spending CPU time for network bandwidth. Instead of sending over entire pointclouds, you would use depth images, compress and then decompress them.

For PointCloud2 there has been some discussion (such as Compressed PointCloud2? on ROS Discourse), and some people have implemented custom solutions (such as paplhjak/point_cloud_transport mentioned in ros-perception/perception_pcl#152).

You could see whether using those helps with the bandwidth problem.

A gigabit link provides at most a throughput of 125 MB/s. At most, as it is the theoretical limit of the transport. More often than not it won't get there.

I'm not sure what the datarate of the points topic of a realsense is, but if you'd get 6 to 12 Hz, it's probably on the order of 10 to 15MB/sec, which seems like it could be correct.

Running 2 cameras without any compression will not make things any faster.

If with "network overhead" you meant the fact that you're transferring the data over a network (ie: just that fact), then it's indeed true that this will place a bottleneck in your system.

Traditionally though, the term "overhead" is used to mean "additional traffic not directly used to transmit the payload itself" (so: headers, signalling, etc). I'm not sure that would be the main cause of the reduced data rates here. My first though would be you're simply saturating the available bandwidth.

Perhaps try a rostopic bw /camera1/depth/color/points on your master and post those results here.

what is the best setup for interfacing 6 realsense cams in ros?

I'm not convinced your problem is with ROS necessarily: saturating a specific link with traffic will become a problem in many (all?) cases, no matter which communication infrastructure you use. How the saturation is dealt with, that would seem to be specific to whatever you're using.

Edit: something to look into may be compressed_depth_image_transport. It trades spending CPU time for network bandwidth. Instead of sending over entire pointclouds, you would use depth images, compress and then decompress them.

For PointCloud2 there has been some discussion (such as Compressed PointCloud2? on ROS Discourse), and some people have implemented custom solutions (such as paplhjak/point_cloud_transport mentioned in ros-perception/perception_pcl#152).

You could see whether using those helps with the bandwidth problem.