Data connections using UDP?

[icefoxen]

Hi all,

I'm using Foxglove+rosbridge to visualize info from autonomous drones and it works great. However, having a drone flying around means the radio downlink is often quite flaky... Flying behind a tree or at long distances with wind blowing my antenna around a little can result in it going from having megabits of bandwidth down to nothing and back fairly quickly. This isn't much of a problem for QGroundControl because it uses UDP for communication with the drone, so data drops are ignored: you get lag for a few seconds, and then it picks right up the instant signal gets back. Bad for analytic data, but perfect for on-the-fly (literally) telemetry. I've tried using better radios, but really that just shoves the problem elsewhere.

The problem is when I want to stream video or pointclouds down from the drone using Foxglove. I've been using the Websocket data connection, which works great when the radio signal is reliable, but because it goes over TCP it gets very laggy when the connection quality is poor. A few seconds of bad radio signal will make TCP put a lot of work into trying to resend old data, eventually timing out and giving up, possibly re-establishing a connection, etc. I don't need this since all the data is recorded on the drone as well, I just want the most up-to-date feed it can give me with minimal lag for situational awareness.

Sooooo this was a long saga for a simple question: does anyone know of an option that lets Foxglove Studio shove its data over some UDP-based protocol rather than TCP-based Websocket or ROS? If not, is there enough interest in this that it might be worth me starting to write a plugin or something to try to accomplish this?

Cheers!

[jtbandes]

The native ROS 2 connection, supported by the desktop app, uses DDS over UDP. However, we have found that the ROS native connections are much harder to set up correctly and more painful for our users than the rosbridge WebSocket connection.

We are very interested in working on this problem, because it is quite common for mobile robots to have unreliable network connections, and even in more reliable networks, issues like head-of-line blocking can cause degraded performance in the presence of many parallel streams with large data (such as images and point clouds). Ideally, we would be able to provide a bridge protocol that works over UDP, and on top of that an equivalent of rosbridge, and/or libraries for integrating with custom robotics stacks (like our WebSocket-based protocol). One major barrier to this is that we'd like to offer the same seamless connections from the web app, and web browsers cannot easily make UDP connections. The only currently available solution is WebRTC, but WebRTC is notoriously complex and difficult to work with. We are also watching the WebTransport project closely to see if it would be suitable to build our connection on top of.

[karanchahal]

that would be awesome, have you considered using HTML 3, the push functionality that it offers can be compelling