I’m a robotics engineer turned product builder. After years in R&D and recently interviewing around 30 robotics teams, I noticed a pattern that honestly surprised me:
Even teams with mature deployments are still relying on fragile, “temporary” setups for remote debugging.
You may recognize some of these:
The Classics:frp + rosbridge, usually fine… until the moment you really need it.
The Painful: SSH X11 forwarding for RViz (enjoy those multi-second frame drops).
The Network Hell: Strict customer firewalls, unpredictable industrial WiFi, or 4G/5G uplinks that work only when the robot is facing north on a Thursday.
The Modern Mesh: Tailscale / ZeroTier: great connectivity, but no robotics-specific QoS, telemetry semantics, or tooling.
Enterprise platforms (Formant, Freedom, etc.) are powerful but often expensive or too heavy for simple debugging needs. Meanwhile, open-source solutions feel fragmented.
My Hypothesis: We don’t need another heavy “platform.” We need a simple, reliable, UNIX-style pipe that just works.
I’m exploring a “stupidly simple” API focused purely on transport (low latency, resilient under packet loss). But before I commit to the architecture, I want to validate my assumptions with you.
What’s in it for you?
The Data: I’ll compile the responses into an open “2025 ROS Remote Access Landscape Report” and share it here.
The Access: I’m looking for beta testers — 10 random participants will receive lifetime free access to the managed API tier at launch.
PS: After you fill out the form, drop a quick reply below (e.g., “Done” or your biggest pain point). It helps keep this thread visible so we can get more community data!
– which is why we’ve developed Transitive, an open-source framework for creating (and publishing) fleet management modules. We already have some modules for the needs you describe above:
Terminal: web terminal over webrtc, which, like Tailscale, is capable of 'hole punching" and hence doesn’t require a VPN.
ROS Tool: an alternative to rosbridge that avoids the need for a direct connection and also caches data in the cloud, so that you can always see the last (albeit possibly stale) data from your robots, also when they are offline.
Work in progress:
Remote RViz: we are working on a way to “screen share” RViz from the robot to the web using webrtc. This is way more efficient than streaming pointclouds (even with Cloudini), and still avoids the need for ssh, X11 forwarding, and associated issues you mentioned.
Please reach out if you are interested in collaborating instead of starting something new from scratch.
Thanks a lot for sharing this. I looked into Transitive a while back and really liked the terminal module’s hole-punching approach. Clean solution.
My goal here is slightly different: instead of building a fleet platform or a full remote-ops framework, but a very minimal “pipe” layer that robotics teams can drop in when they just need:
• A low-latency, firewall-friendly data path
• Lightweight downsampled topic streaming for debugging
• Automatic recording for short sessions
Basically a “debug-mode transport” rather than a platform.
That’s why I am talking to teams– to validate whether a super small ROS-agnostic pipe solves 80% of the remote-debugging pain without the overhead.
That said, I love the direction you are taking with Remote RViz. There’s definitely room for future interoperability (e.g., an agent that speaks both APIs).
I’d be very interested in comparing notes on pain points we’re seeing across users. Feel free to DM me.
We developed MQTTSync to solve this but I think it might not be as light as you want it to be because it still requires an MQTT broker. I’d argue, though, that the best way to make friends with firewalls is to only make outbound HTTPs requests and if you accept that as a requirement, MQTT is hard to beat. So I think it checks your first two boxes. MQTTSync just adds the convenience of data-sync on top of that, instead of just message passing.
If you want automatic recording, I’ve lately heard good things about NATS (≠ NATs!) with its built-in Jetstream for this purpose.
Thanks for the detailed breakdown- super helpful.
We actually evaluated MQTT pretty early, and technically I agree with you: outbound HTTPS + MQTT is probably the most firewall-friendly combo out there. The sticking point for beta testers was the operational overhead of running a broker– they want a single binary agent that doesn’t touch their existing ROS graph. That’s the trade-off we’re optimizing for: zero-config over flexibility.
If MQTTSync is open-source, I am happy to link to it in docs for teams who need full state sync vs. just debug sessions.
My current focus now is getting the teleop latency down on 4G/5G. Once having stable numbers, I’ll share a full benchmark comparison.
– which is why we’ve developed Transitive, an open-source framework for creating (and publishing) fleet management modules. We already have some modules for the needs you describe above: