ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

depth_image_raw impossibly slow across machines (wireless)

asked 2023-03-04 11:16:25 -0500

MarkyMark2012 gravatar image

updated 2023-03-07 07:38:06 -0500

gvdhoorn gravatar image

Hi,

I've spun up realsense2_camera. Depth messages are being produced on the robot's PC without issue. I'm looking to see that output on a remote machine (I've tried both VM and non VM) - for now in RVIZ (later used to drive rtabmap). All other, scan, map, sensor data is fine but depth_image_raw and any other image data is impossibly slow. For example:

rostopic hz /camera/depth/image_rect_raw

yields:

On robot:

average rate: 29.975
min: 0.023s max: 0.044s std dev: 0.00097s window: 19608

On Remote PC

average rate: 0.031
min: 22.248s max: 47.057s std dev: 7.42743s window: 20

Additional Details:

rostopic echo -n1 --noarr /camera/depth/image_rect_raw

header:
seq: 421
stamp:
secs: 1678046085
nsecs: 714776278
frame_id: "camera_depth_optical_frame"
height: 480
width: 848
encoding: "16UC1"
is_bigendian: 0
step: 1696
data: "<array type: uint8, length: 814080>"
---

rostopic type /camera/depth/image_rect_raw
sensor_msgs/Image

So far I've checked the router, WiFi, Network bandwidth and all are fine/well within parameters.

If anyone has any suggestions WRT what else I can check I'd most appreciate it.

Thanks

Mark

edit retag flag offensive close merge delete

Comments

So far I've checked the router, WiFi, Network bandwidth and all are fine/well within parameters.

that's a good starting point, but without sharing what you found and what conclusions you've drawn based on that data, board members here are only going to be able to guess.

I would suggest to add at least the output of rostopic type /camera/depth/image_rect_raw and rostopic echo -n1 --noarr /camera/depth/image_rect_raw to your post.

Any image*raw topic at any reasonable resolution will result in significant bandwidth usage, which is a common cause for slow message rates.

Additionally, since you mention "WiFi": large messages over a regular TCPROS transport over a (very) lossy link may require retransmits of multiple packets (note: not messages). Over time those can add up to a significant delaying factor.

gvdhoorn gravatar image gvdhoorn  ( 2023-03-05 07:24:51 -0500 )edit

Thanks - I've updated the question with additional info. Checked other various WiFi stats - no dropped packets (noted: re: packets vs messages) . rostopic bw /camera/depth/image_rect_raw shows about 24.5MB/s

WiFi Link is capable (iwconfig) 72.2MB/s

Nothing else on the LAN (Dedicated WiFi router atm for the sake of trouble shooting). I would expect there to be a drop in performance across the network but this seems to just drop off a cliff.

MarkyMark2012 gravatar image MarkyMark2012  ( 2023-03-05 14:05:59 -0500 )edit

WiFi Link is capable (iwconfig) 72.2MB/s

please share the output of iwconfig verbatim. If you're looking at the rate field: that's instantaneous, max, theoretical bw configuration. Not actual transfer rate. Sustained, perfect (ie: zero lost pkts) transfer at the data rates you are using is not something I'm accustomed to over a wireless link.

I would also check Mb/s vs MB/s. There's a factor 8 difference there (with overhead: about 10x actually), and 72 Mb/s could make sense to me: it's one of the typical wireless datarates supported by cards.

As a diagnostic step: if you can, try using a wired connection and see whether the same delays and bw issues appear.

Also: you could try using iperf to benchmark actual available bw on your wireless link.

I would expect there to be a drop in performance across the network ...

(more)
gvdhoorn gravatar image gvdhoorn  ( 2023-03-06 01:34:39 -0500 )edit

Just run iperf in both directions from Robot to PC and back over 60 secs combined average about 34.3Mbits/sec.

iwconfig output:

 wlx74da38733b6f  IEEE 802.11  ESSID:"NeonStar2"
 Mode:Managed  Frequency:2.422 GHz  Access Point: 00:1D:AA:5E:85:A8
 Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
 Retry short limit:7   RTS thr=2347 B   Fragment thr:off
 Power Management:off
 Link Quality=70/70  Signal level=-33 dBm
 Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
 Tx excessive retries:0  Invalid misc:0  Missed beacon:0

I'll give hardwire a go in a day or 3

MarkyMark2012 gravatar image MarkyMark2012  ( 2023-03-07 04:57:18 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2023-03-07 05:00:49 -0500

gvdhoorn gravatar image

updated 2023-03-07 07:34:33 -0500

Just run iperf in both directions from Robot to PC and back over 60 secs combined average about 34.3Mbits/sec.

iwconfig output:

 wlx74da38733b6f  IEEE 802.11  ESSID:"NeonStar2"
 Mode:Managed  Frequency:2.422 GHz  Access Point: 00:1D:AA:5E:85:A8
 Bit Rate=72.2 Mb/s   Tx-Power=20 dBm
 Retry short limit:7   RTS thr=2347 B   Fragment thr:off
 Power Management:off
 Link Quality=70/70  Signal level=-33 dBm
 Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
 Tx excessive retries:0  Invalid misc:0  Missed beacon:0

So that's indeed all megabit/sec, not megabyte/sec.

Maximum theoretical bw between your two hosts over wireless would then be about 7 MB/sec, which is about 10x lower than what you stated earlier, and over 3x less than what would be needed to transmit just the depth images (at 24.5 MB/sec), if everything worked perfectly.

Your iperf results suggest the actual attainable bw is less than half the max, at 34 mbit/sec, or just about 3.5 MB/sec (that could make sense for a half-duplex medium). That would reduce available bw for depth images by another factor of 2.

Still not claiming it's just bw that's the issue here, but it's likely a big factor.

What brand/model wireless nic and router do you have? You could check whether it's capable of wider channels to increase available bw.

edit flag offensive delete link more

Comments

Btw: it's not something often done, but as depth images are basically just that, images, you can use image_transport and compress them. Using a lossless compression plugin should still result in decent compression while not affecting image quality (and ultimately, depth quality).

Something to consider perhaps.

gvdhoorn gravatar image gvdhoorn  ( 2023-03-07 05:09:26 -0500 )edit

Thanks for that. Next port of call I think I'll get a new WiFi adapter. Possibly look at the compression to.

The WiFi adapter is an Edimax dongle - I forget which one. Router is Vigor - can't remember the model off hand.

Will have a look at something along the lines of:

https://www.amazon.co.uk/FIDECO-WiFi-...

MarkyMark2012 gravatar image MarkyMark2012  ( 2023-03-07 07:32:03 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2023-03-04 11:16:25 -0500

Seen: 85 times

Last updated: Mar 07 '23