Every teleoperation vendor promises low latency. Far fewer can answer the question that actually predicts your integration timeline: does the platform think the way your robot already thinks?
TL;DR: Adamo is built on a publish and subscribe model, the same pub/sub pattern that robotics teams already use every day in ROS. Publishers broadcast data to named topics, subscribers tune in to the topics they care about, and neither side ever needs to know about the other. That one architectural choice is why components can be added, removed, or restarted without breaking anything else, and it is why Adamo integrates in days rather than quarters. When you evaluate a teleop provider, developer ease of use is not a soft criterion. It is the difference between a platform your engineers build on and a platform your engineers fight.
Robotics teams evaluating a teleoperation platform tend to start with the numbers: latency, bandwidth, uptime. Those numbers matter, and we have written at length about where the milliseconds go and why WebRTC fails teleoperation. But there is a second question that decides how much of your engineering quarter a platform consumes, and it rarely appears on a spec sheet: how does the platform actually move data, and does that model match the way your robot software is already built? The answer comes down to architecture, and the architecture that wins in robotics is pub/sub.
What pub/sub actually means
Adamo is built on a publish and subscribe model, usually shortened to pub/sub, and the idea is simple. Any part of the system that produces information, called a publisher, broadcasts it to a named channel called a topic. A camera publishes to a camera topic, a motor controller listens on a motor_commands topic, telemetry flows on its own topic alongside them. Any part of the system that wants that information, called a subscriber, just tunes in to the topic it cares about.
It works like a radio station. The station broadcasts on a frequency without knowing or caring who is listening, and anyone interested simply tunes in. The publisher and the subscriber never have to know about each other directly. They only have to agree on the topic name. That single point of agreement, a shared name rather than a shared wire, is what everything else in this post flows from.
The alternative is a tangle
To see why the model matters, look at what teams get without it. The usual alternative is wiring every component directly to every other component that needs its data, each one holding its own private connection. This is the point to point pattern, or its close cousin, a request and response setup where parts have to ask each other directly for what they need.
In a simple system that is fine. But a robot is not a simple system. It has cameras, motors, sensors, telemetry, logging, and control, all producing and consuming data at once, and if you connect them all directly you get a tangle where everything depends on everything else. If one component restarts or changes its address, every component connected to it breaks and has to be rewired. Adding a new sensor means touching every part that might want its data. The wiring diagram grows faster than the robot does, and the system becomes fragile exactly where robots cannot afford to be fragile: in the field, mid task, when a single dropped connection can cascade through the whole stack.
Decoupling is what keeps a robot resilient
Pub/sub removes the tangle by decoupling senders from receivers. They share a topic, not a wired connection, so nothing in the system depends on anyone else's address or timing. Components can be added, removed, or restarted freely without breaking anything else. A new sensor just publishes a new topic, and whoever cares subscribes. A crashed process comes back up, resubscribes, and rejoins the flow as if nothing happened.
This is not an abstract elegance argument. It is the difference between a fleet where one flaky camera takes down an operator session and a fleet where it degrades one video tile while everything else keeps flowing. Modularity and resilience are the same property viewed from two angles, and pub/sub delivers both from a single design decision.
There is one more reason this matters, and it is about your team rather than your robot. Pub/sub is how robotics engineers already think. The Robot Operating System, ROS, the framework most modern robots are built on, works exactly this way, with nodes publishing and subscribing to topics. A teleoperation platform built on the same model feels native from the first day of integration. Your engineers are not learning a new mental model or translating between two incompatible ones. They are pointing existing topics at a transport that already speaks their language.
Ease of use is the hidden line item in every teleop contract
This is where architecture turns into money. When a teleoperation platform's data model matches your robot's data model, integration is a mapping exercise. When it does not, integration is a translation layer your team has to design, build, test, and maintain forever. That translation layer never appears in the vendor's pricing, but it shows up in yours, as the quarter of engineering time spent bending robot data into a shape the transport will accept, and as every future feature that has to pass through the adapter you now own.
WebRTC based platforms are the clearest example. WebRTC hands you audio, video, and a single data channel, so control commands, telemetry, logging, and heartbeat all get crammed into one pipe and tagged by hand so the far end can tell them apart. We covered the operational consequences in why WebRTC fails teleoperation, but the developer consequence is just as costly: your team spends its time working against the transport instead of with it. Ask any engineer who has maintained one of those adapters what it cost, and then ask why the platform made it necessary in the first place.
So when you evaluate a teleop provider, put developer experience on the scorecard next to latency. Ask what the data model is and whether it maps onto ROS topics without an adapter. Ask what a minimal integration looks like in hours, not in a statement of work. Ask how many dependencies the client pulls in and what happens to the rest of the system when one component restarts. A vendor with good answers has built a platform. A vendor without them has built a demo that your engineers will be paying off for a year.
Why Adamo feels native to build with
We built the Adamo teleoperation platform on pub/sub from the ground up because it is the native shape of robot software, not a pattern we bolted on afterward. Your battery is a topic, your control is a topic, your video is a topic, and each one flows on its own terms with its own priority instead of sharing a single channel. Because that is the same model ROS uses, Adamo drops into an existing robot stack rather than demanding the stack reshape itself, and the integration footprint reflects it: a single binary around 40MB with zero external dependencies, running natively on ROS, ROS2, and the NVIDIA hardware most modern robots already ship with.
The same architecture that makes Adamo easy to build with is what makes it fast and resilient in production, with glass to glass latency as low as 40ms and components that restart and rejoin without ceremony. Ease of use and reliability are not separate features. They are the same pub/sub decision paying off twice. If you are working through a full vendor evaluation, our guide to choosing a teleoperation platform covers the rest of the checklist, and the FAQ answers the most common questions in one place.
The teleoperation platform you pick becomes the layer every robot you ship talks through, so pick the one that speaks robotics already. See it in production at adamohq.com.
FAQs
What is a pub/sub framework in robotics?
A pub/sub framework is a messaging pattern where components that produce data, called publishers, broadcast it to named channels called topics, and components that need data, called subscribers, tune in to those topics. The two sides never connect directly and only agree on topic names, which keeps a complex robot modular and resilient. It is the same pattern the Robot Operating System uses, which is why platforms built on pub/sub, like Adamo, feel native to robotics teams from day one.
Why does pub/sub beat point to point connections for robots?
Point to point wiring means every component holds direct connections to every other component that needs its data, so one restart or address change breaks everything attached to it, and adding a component means touching all the others. Pub/sub decouples senders from receivers through shared topics, so components can be added, removed, or restarted freely without breaking anything else. For a robot with cameras, motors, sensors, telemetry, and control all running at once, that decoupling is the difference between a resilient system and a fragile one.
How does developer ease of use affect the cost of a teleoperation platform?
When a platform's data model does not match the robot's, the engineering team has to build and maintain a translation layer between the two, which typically consumes a quarter or more of integration time and adds permanent maintenance cost that never appears on the vendor's invoice. A platform whose model matches robot software natively, the way Adamo's pub/sub maps onto ROS topics, turns integration into a mapping exercise measured in days, with a single 40MB binary and zero external dependencies.
