WiFi Use Cases and Needs

The IPC SIG is looking into improvements in ROS communication over WiFi and other lossy or low-bandwidth links. The first step is to understand requirements.

Here some motivating questions:

• In what ways do you use ROS over WiFi?

• How would you use ROS differently if WiFi communications performed better?

• What do you do now to work around WiFi limitations?

• What performance do you want or need over WiFi?

• What's most important to you (e.g., connection / reconnection behavior, message latency, delivery of small messages, delivery of large messages)?

Your needs

Post your answers here. Add your name if you'd like to be contacted about development efforts.

• (Brian Gerkey) For eyes-on teleop over WiFi (e.g., from an Android device), we need low-latency (i.e., no TCP-like backup) delivery of small messages (e.g., Twist messages).

• (Brian Gerkey) For eyes-off teleop over WiFi (e.g., from an Android device), we need successful delivery of large messages (e.g., Image messages) at as high a rate the channel will allow (probably not frame rate).

  • (Ken Conley): A more general expression is "need video delivery over wifi for human monitoring" (don't want to couple to issues of messages as I think there are better opportunities w/ investigating streaming video servers)
    • (Nick Armstrong-Crews): We also try to do point cloud/camera fusion and "augment" the reality of the real-time video feed, using ROS packages. Having video delivery exist outside of ROS makes this much harder.
  • (Bill Morris): My experience with using video for teleop suggests that one reasonable solution is to stream the video outside of ROS using gstreamer and use a ROS topic or service to provide the connection information for the video stream. Some cameras have hardware encoders and can output video streams directly so converting them into an image message and back into a video stream can cause problems. Also, the OMAP (gumstix/beagleboard/etc) embedded platform has a DSP that can be used for gstreamer acceleration
    • (Ken Conley) +1: we've experimented with this as well. IIRC, there are even packages that will convert a ROS Image topic into a gstreamer device
• (Ken Conley) For multi-robot coordination, we need to reliably trigger a service/action on another robot.

• (Bill Morris): Sending pointcloud data over WiFi was painful, sending depth images seems to work better.

  • (Nick Armstrong-Crews): Kinect over wifi is excruciating.

• (Bill Morris): The most critical use of WiFi is for status information such as battery charge level

• (Nick Armstrong-Crews): We wrote a network monitor to keep track of network health (latency, throughput capacity, signal strength). What would be really nice is a way for nodes to request some quality-of-service, and a moderator to respond to those requests and enforce the QoS "contracts."
  • (Nick Armstrong-Crews): Nodes could adapt their behavior based on what QoS they are guaranteed; e.g., the video capture could reduce frame rate or JPEG quality as the wifi signal starts to weaken (or when other chatty nodes are started).
  • (Nick Armstrong-Crews): Without this capability, we have to limit our video pipeline to the worst-case scenario (sometimes reducing framerate by 10x what is possible)... otherwise, video hogs bandwidth and we lose joystick drive control.
  • (Matthieu Herrb-LAAS): +1 being able to monitor the link quality is important if you want to have really autonomous robots, able to act when they loose communication (to plan to move back to an area where the communication is possble)

  • (Nico Hochgeschwender-BRSU): Our need for WiFi is mainly for monitoring and commanding purpose. For instance, emitting events over WiFi like status information as the notification that a task has been achieved. Those events are emitted only once (here reliability is required) and others are emitted more frequently as the battery status or the CPU load. Moreover, reliable WiFi is in particular required for conferences, workshops or RoboCup where several WiFi connections may interfere.