A practical guide to robot teleoperation software integration into existing control centers, using ROS, ROS2, web dashboards, and an API first model.
Most enterprise robotics teams do not need a new control center. They already have one. It runs the dashboards, the alerting, the operator queue, the customer reports, and the integrations with the rest of the company's systems. What it does not have is the teleoperation surface that lets a human take over a robot in real time, with the latency and reliability production manipulation demands.
That is the integration problem, and it is the single most common ask we hear from systems architects evaluating a teleoperation platform: embed the engine, do not replace the control center. This post walks through how to do that with Adamo, the teleoperation engine for frontier robotics, inside an existing ROS or ROS2 stack and a web dashboard, using an API first integration model. The same evaluation checklist applies to any vendor decision, including alternatives like Formant.
Why embedding beats replacing
The control center an enterprise robotics company runs in production is rarely the bottleneck. It is the dashboards, the alerts, the data inspection layer, the operator queue, and the customer facing reporting surface. Teams that rip and replace this layer to bolt on remote robot operation lose more than they gain: six to nine months of integration work, internal change management, and a customer facing system that loses fidelity in the transition.
The right move is to keep the control center intact and embed a robot teleoperation software integration that does exactly one thing well: provide closed loop video, telemetry, and control between an operator's console and a robot, with the latency, reliability, and security a production fleet demands. That is the design problem the next sections solve.
The integration surface
A teleoperation engine has four points of contact with an enterprise robot control center.
The robot side. The engine runs on the robot, talks to the autonomy stack, captures video and telemetry, and executes control commands. This is where ROS and ROS2 integration lives.
The operator side. The engine drives an operator console with low latency video, telemetry, and control. The console embeds inside the customer's existing web dashboard rather than running as a separate application.
The data plane. Every teleoperation session generates synchronized video, telemetry, and operator action streams. These flow back into the customer's data lake, training pipeline, and audit log without the customer rebuilding the pipeline.
The control plane. The control center decides when a session starts, who is allowed in it, how it is logged, and how it ends. This is where the robot control software APIs live: session creation, operator assignment, recording handles, audit hooks.
The integration is clean if each of these four surfaces is well documented, API first, and does not assume the customer's stack looks a particular way.
The ROS and ROS2 layer
Most enterprise robotics teams run ROS2 in production today, with some legacy ROS1 robots still in the field. A teleoperation engine that requires a translation layer between its protocol and ROS becomes the brittle joint in the system. Updates to the autonomy stack break the translation. The wire format silently changes. The operator console freezes when a topic name shifts.
Adamo's engine is a single 40MB binary with zero external dependencies and native ROS and ROS2 support. It drops onto the kernels real robots ship with, including older unpatched Linux versions, and integration is measured in hours rather than months. The autonomy stack and the teleoperation engine speak the same protocol, which means topic updates do not cascade into hidden failures. The developer docs walk through the full ROS2 integration path.
The web dashboard layer
The operator side of a teleoperation session lives inside the customer's existing web dashboard. Embedding rather than replacing is the right model.
The clean integration is an iframe or web component the dashboard renders inline, with the control center owning navigation, authentication, and audit. The teleoperation engine handles only what it does best: video pipeline, control stream, and the operator interaction surface.
Adamo's web SDK is designed for this model. The console embeds inside the dashboard with a single component, picks up the customer's authentication context, and emits events the dashboard can hook into for telemetry, recording, and audit. The video and control streams flow over Adamo's transport, not the dashboard's, so the customer's web stack does not have to carry the latency budget.
The API first model
The control plane is the part most teams underestimate. A production teleoperation program needs APIs for:
Session creation, with operator assignment and authentication scoped to the customer's identity provider.
Recording handles for video, telemetry, and operator actions, with retention windows and access controls the customer can configure.
Audit events emitted for every operator action, scoped to the session and the customer site.
SLA hooks for uptime, response time, and the failure modes the customer monitors.
The right design exposes these as well documented robot control software APIs that the control center calls, not as a separate UI the customer has to integrate into. API first means the engine is a service, and the control center stays in control of the user experience.
Security and audit
Security is the second area teams underestimate at integration time. The controls a customer's safety team will demand for production are:
AES 256 encryption end to end on every stream.
SOC2 compliance for the platform and any managed operator facilities.
Audit logs that connect every operator action to a session, robot, customer site, and identity, with retention windows the customer can verify.
Documented incident processes: recordings, root cause writeups, customer notifications, insurance reporting.
Adamo ships with all of the above by default. The integration question is whether the control center can ingest the audit events and recordings as they flow, not whether the engine produces them.
Robot teleoperation software integration vs alternatives
Most teams that come to us are also evaluating Formant, which is the most common alternative in the robotics observability space.
The honest comparison: Formant is the strongest fleet observability platform on the market today, with broad ROS support and a mature dashboarding surface. If the team's primary bottleneck is fleet visibility, that is the right tool.
The reason a separate teleoperation engine is usually needed alongside it is that observability platforms tend to be built on WebRTC for the teleop layer, which puts the glass to glass latency floor around 150ms under realistic cellular conditions. That is fine for remote inspection and forgiving intervention. It is not fine for closed loop dexterous manipulation, where the latency cliff sits at 100ms. The robot teleoperation software integration in that case is two systems wired together: observability for the broad fleet view, and a teleoperation engine for the closed loop manipulation surface.
Adamo embeds cleanly alongside an observability platform. The operator console runs inside the customer dashboard. The audit events flow into the customer's data lake. The synchronized capture flows into the customer's training pipeline. Nothing rips and replaces.
A typical migration path
The teams we work with usually move in three phases:
1. Pilot. Integrate Adamo on a small subset of robots, usually 10 or fewer. Keep the existing control center intact. Validate latency, integration cost, and operator workflow in production conditions.
2. Embed. Roll the operator console into the customer dashboard as a web component, wire the audit events and synchronized capture into the customer's existing data plane, and migrate the fleet to the new transport layer one site at a time.
3. Scale. Add managed operator coverage where it makes sense, instrument the program against the metrics that matter at fleet scale, and use the synchronized training data the platform captures to compound autonomy over time.
The pilot phase is hours of integration work. The embed phase is days to weeks depending on the complexity of the dashboard. The scale phase is ongoing.
What we built Adamo for
Adamo is the teleoperation engine for frontier robotics, designed from the transport layer up to embed inside existing robot control centers. Glass to glass latency as low as 40ms, multi path bonding across LTE, 5G, and WiFi, native ROS and ROS2, NVIDIA compatibility, AES 256 encryption, SOC2 compliance, and a single 40MB binary with zero dependencies. Plus a managed operator network if the program needs 24/7 coverage at scale.
If you are evaluating a robot teleoperation software integration into an existing control center, we will run a benchmark against your stack and walk through the integration path with your systems team. Book a demo at adamohq.com.
FAQs
Should we build our own control center for teleoperation, or use a managed teleoperation service?
The right call comes down to three things: fleet size, how core teleop is to your product, and how much variance you want in operator coverage.
Below roughly 20 robots, the cost of recruiting, training, and managing teleoperator shifts in-house usually exceeds the savings — managed teleoperation services run from purpose-built control facilities tend to be the faster path. Above a few hundred robots the per-robot economics flip, and embedding teleoperation software in a dedicated in-house control center pays back quickly.
The decision isn't binary. Many teams run a hybrid: in-house operators handle daytime routine work on a self-hosted teleoperation platform, with a managed provider supplying overflow capacity for nights, weekends, and surge events. The Adamo stack is designed for this — the same software runs both modes, so robots and recordings move between in-house and managed coverage without reconfiguration.
What does our network and hardware actually need to run low-latency teleoperation in a control center?
Three places matter, in order: the robot's uplink, the control center's downlink, and the operator workstation.
At the robot, a single LTE or Wi-Fi link is rarely production-grade. Modern teleoperation software bonds multiple paths (LTE, 5G, Wi-Fi) and shifts traffic as one degrades - single-link teleop deployments are the most common cause of avoidable session drops we see.
At the control center, bandwidth is rarely the bottleneck; consistency is. A teleop session uses a handful of Mbps per camera, but jitter and packet loss matter far more than peak throughput. Dedicated symmetric fiber is ideal; shared corporate Wi-Fi is the most common cause of latency we see in control rooms.
At the workstation, most teams over-spec the GPU and under-spec the display chain. Many consumer monitors add tens of milliseconds of display latency that silently doubles the perceived round-trip - a low-latency monitor with under 10ms response time is one of the cheapest meaningful upgrades a control center can make.
How many robots can a single teleoperator supervise from a control center?
It depends on the control mode, and the ratio is the single biggest driver of teleoperation unit economics.
For continuous direct control - the operator driving the robot the entire time - the ratio is 1:1. This is reserved for high-stakes manipulation or initial deployments of new robot types.
For supervisory control, where the operator monitors several robots and only intervenes when one flags for help, one teleoperator can comfortably oversee four to eight robots, scaling higher as the autonomy stack matures and intervention frequency drops.
The number is bounded less by the teleoperation platform itself and more by intervention frequency and interface design. If a robot needs human input every ten minutes, one operator could theoretically watch sixty - but only if the platform routes alerts cleanly, queues interventions, and lets the operator switch context in a few seconds. The interface design of the teleoperation software matters as much as the underlying latency.
