WebRTC gets robotics teams to a demo fast. It also breaks the moment the robot leaves the lab. If you are running WebRTC today, the question is not whether you will outgrow it but when, and what the next six months of engineering will be spent on while you do.
Why Every Robot Teleoperation Team Eventually Outgrows WebRTC
Article from | Adamo
Almost every teleoperation project we see starts the same way. Someone on the team finds the WebRTC docs, gets a webcam feed running between two laptops, wires it to a robot, and demos a remote drive in the office.
But when the robot leaves the building, the pilot reveals that almost nothing about the office demo transferred to the real network. The site runs on a different cellular carrier, the operator is on a poor WiFi connection, and the latency that read 80ms in the lab now reads 220 whenever the network hiccups. The robot stops responding for half a second right as the operator is lining up a grasp, and the question that surfaces in the post mortem is one we hear constantly: do we keep patching WebRTC, or replace the networking stack underneath it?
The pattern is consistent enough that we can almost set a clock to it. WebRTC gets a robotics team to a working demo faster than anything else on the market, and it also fails the moment that demo has to become a deployment. The mismatch is not a bug but a design choice baked into the protocol, which means you cannot patch your way around the choices the protocol was designed around in the first place.
Why WebRTC is the default starting point
Before getting into the failure modes, it is worth giving WebRTC its due. The reasons teams reach for it are genuinely good ones:
-
It is free and open source, with mature implementations in every language a robotics team is likely to use and permissive licensing.
-
It works in browsers, which means an operator interface can run on a Chrome tab on any laptop with no install, accelerating early demos significantly.
-
NAT traversal is solved. ICE, STUN, and TURN handle the firewall and address translation problems that would otherwise eat weeks of engineering.
-
Codec negotiation works. Both ends figure out what they can encode and decode without manual configuration.
-
The community is enormous, with Stack Overflow answers for almost everything and major browser vendors keeping the protocol moving forward.
For a small team building its first remote control demo, the calculus is obvious, because you can be live by lunch. We are not arguing against WebRTC for prototypes, where it is the right tool. The argument is about what happens when you try to take that prototype to production.
Where the constraints fight back
Robot teleoperation has four constraints that fight WebRTC’s design choices, each surfacing at a different point in the lifecycle.
Cellular networks behave nothing like WiFi
Most teleop deployments route at least part of the path over a cellular link, often with the robot on a private 5G slice and the operator on a mobile or home connection. WebRTC was tuned for the public internet, where packet loss usually signals congestion and the right response is to back off the send rate.
Cellular networks behave nothing like that. Packet loss on LTE and 5G is often a brief radio event such as a handover between cells or interference from another device, and the right response is to keep sending rather than back off. WebRTC’s congestion control treats those events as signals to throttle the stream, which throttles operator visibility at exactly the wrong moment in a way the operator has no way to correct.
Latency under 40ms requires a different jitter strategy
The threshold for usable manipulation teleop sits around 100ms of glass to glass latency, below which an operator can complete a closed loop grasp and above which they tend to overcorrect and oscillate until the task fails. Adamo runs as low as 40ms because the floor is also the ceiling: every millisecond you spend on something avoidable is a millisecond you lose to something unavoidable like network transit or display refresh.
WebRTC’s jitter buffer typically sits at 50 to 100ms, which is a reasonable tradeoff for a video call where smooth playback matters more than responsiveness, but for teleop that buffer alone consumes most of the budget. You can tune it down, but you trade smoothness for responsiveness in the process, and most teams discover the tradeoff in front of a customer rather than a whiteboard.
ROS does not speak WebRTC
The autonomy stack on almost every robot we work with runs on ROS or ROS2. WebRTC has no native concept of a ROS topic, so teams build a translation layer that packs ROS messages into data channels and unpacks them on the other side, with the timing and reliability problems that translation introduces.
This is one of the patches that gets fragile fast, because anything that shifts on the ROS side breaks the translation layer in ways that are hard to diagnose. The failure mode is silent: the channel still appears connected, while the messages quietly stop flowing or arrive out of order.
Data capture is an afterthought
The most valuable thing a teleoperation session produces is not the recovery itself but the data that comes with it: synchronized video, telemetry, sensor streams, and the operator action stream that together become a training trajectory for the next autonomy round. WebRTC was not designed to record any of this, because the streams are encoded for delivery rather than storage, and recording them faithfully across cameras and the action stream becomes a separate engineering project in its own right.
Teams retrofitting recording onto a WebRTC pipeline almost always end up with gaps, because frames lost during congestion are not recoverable and timestamps drift across streams that were never meant to be synchronized at rest. Operator inputs land in one log and video in another, and reconciling them after the fact becomes its own data engineering problem, leaving holes in the sessions that were most expensive to capture.
What the measured impact looks like
The version of this story we hear most often goes something like this:
“We spent two engineers for nine months patching our WebRTC stack. We got the latency down from 240ms to about 150ms. Recording is partial. We still cannot reliably drive the robot from a customer site on cellular.”
The numbers vary by team and network, but the shape is always the same. The patches consume engineering capacity that should be going into the robot, the autonomy, and the operator experience, producing a stack that works in the conditions it was tested in and breaks at the next customer. Even after months of patching, the latency floor sits well above what manipulation needs to feel responsive.
What to evaluate when you outgrow it
When a team finally moves off WebRTC, the question shifts from “how do we patch this” to “what should the replacement actually do.” Here is the checklist we suggest, drawn from questions our own customers brought us before switching:
-
Measured glass to glass latency under realistic network conditions. Not a marketing number on a perfect link. Ask for benchmarks on cellular, on degraded WiFi, and across continents.
-
Behavior under packet loss. Video should degrade gracefully while control keeps responding, rather than the channel freezing entirely.
-
Native ROS and ROS2 integration. The platform should speak the language your robot already speaks, because translation layers are a tax you pay forever.
-
Multi path support. Bonding across LTE, 5G, and WiFi at the transport layer is fundamentally different from failover, and removes the single point of failure that any single network path creates.
-
Synchronized data capture. The platform should record video, telemetry, and operator actions on a shared clock, ready to feed straight into training.
-
Integration cost. Hours rather than months, with a single binary and zero external dependencies as the standard worth holding any vendor to.
-
Security and compliance. AES 256 encryption on every stream, SOC2 compliance, and biometric access for any managed facilities.
-
Operational model. Software only is one option and a managed operator network is another, and the platform should support whichever you need, ideally both.
If a vendor cannot answer those questions with specifics, the honest answer to “should we keep patching WebRTC” might be yes for another quarter, because at least you control the patches.
What we built
Adamo exists because the answer to every one of those questions was no when we asked them of the open standards, so we rebuilt the networking stack from the ground up, designed specifically for robotics:
-
Glass to glass latency as low as 40ms through a global relay network, 180% faster than typical WebRTC stacks and up to 10x faster under poor network conditions.
-
Multi path bonding across LTE, 5G, and WiFi at the transport layer, with packets racing across every available path and the receiver using whichever copy arrives first.
-
Control first architecture. Control commands ride on dedicated high priority streams that never queue behind video, so when the channel narrows, video bitrate adapts while the robot keeps responding.
-
Native ROS and ROS2 support, with no translation layer required, and NVIDIA compatibility out of the box.
-
A 40MB binary with zero external dependencies that runs on the old unpatched Linux kernels real robots actually use, with AES 256 encryption end to end and SOC2 compliance.
-
Synchronized data capture built in. Video, telemetry, sensor streams, and operator actions captured on a shared clock and ready to feed back into the next training run.
On top of the software, our managed operator service runs from purpose built facilities with redundant ISPs, backup power, and biometric access, staffed by operators vetted on psychometric and performance screens, on 24/7 coverage scaled to your fleet.
The lifecycle is predictable. The replacement does not have to be.
If you are running WebRTC in production today, the question is not whether you will outgrow it but when, and what the next six months of engineering will be spent on while you do. The teams that move fastest are the ones that stop treating teleoperation as a side project and start treating it as the infrastructure layer it really is.
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Featured Product
