search

turtlebot / turtlebot4

Turtlebot4 common packages.
Apache License 2.0
100 stars 45 forks source link

Rasperry Pi - Base communication: Wi-Fi network/USB network #16

Closed alexswerner closed 2 years ago

alexswerner commented 2 years ago

After starting the robot I observe constant traffic from the base to the raspberry pi on the Wi-Fi network. As recommended the PI is on a 5 Ghz Wi-Fi and the base on 2.4Ghz. Why is this traffic not using the internal network (usb0)? This thought is motivated that in a classroom full of robots Wi-Fi bandwidth could really be scarce. What is the use of multipathd in the PI? How does export CYCLONEDDS_URI='<CycloneDDS><Domain><General><NetworkInterfaceAddress>wlo1</></></></>' play into this?

Any clarification is helpful.

roni-kreinin commented 2 years ago

The Create3 and RPI are both configured to use wlan0 and usb0 for transmitting ROS data. The usb0 interface is mostly there to allow communication between the two when there is no WiFi signal. In general we want data to be sent over WiFi so that a remote PC can also access it. If the base is not sending tf data over WiFi for example, we would not be able to see the transform from base_link to odom on a remote PC since the RPI does not republish those messages. This would cause applications like rviz to not work properly.

The bandwidth used by the Create 3 for sending its data is fairly minimal when compared to the RPLIDAR and OAK-D sensor data, so I don't think it will cause significant issues.

Setting the NetworkInterfaceAddress in CycloneDDS simply tells CycloneDDS which interface to use for ROS communication. If it is not set, CycloneDDS will try to pick one on its own, but it does not always pick the right one.

alexswerner commented 2 years ago

Just having another look at this. After power up the communication between base and raspberry pi create a traffic of 500kbit/s and 300packets/second. For our application with 15 robots this would mean 4500packets/second which is, in an extremely rough estimation, a quarter of the maximum throughput of the Wi-Fi network. Is there any way to optimize this part? I remember you mentioned that there is a way to disable diagnostic messages. Or am I mixing things up?

Concerning the applications in our course, streaming sensor data is curcial. However, any application which streams the camera images across Wi-Fi is likely not scalable to many robots. I measured 46Mbit/s and 4200packets/s when subscribing to /color/preview/image at full rate. This is less a problem for us as this is not the main objective of the course. The bandwidth of the Lidar data (/scan) is more sane with 430kbit/s and 80packets/s. That is further motivation to reduce the base-rpi traffic as it is the same magnitude. Subscribing to /tf seems to create minimal traffic.

alexswerner commented 2 years ago

Due to recent experiments with 15 turtlebot4 I think the Wi-Fi traffic in idle is indeed considerable. It was fluctuating between 0.5Mbit/s and 4Mbit/s (for all robots) - which is lower than anticipated, but still. A solution can hopefully be found through #26