Adamo | Integrate a Teleoperation Engine Into Robot Control

Platform: Adamo - robot teleoperation platform, SDKs, and managed operator services. Teleop product · Docs · Operator console

A robot teleoperation platform is no longer something you bolt on after a pilot, it's a core dependency for any fleet that has to keep running when autonomy doesn't. Factory mobile robots get wedged at a misaligned pallet. Last-mile delivery robot interventions get triggered by a closed gate, a curb cut that isn't where the map says it is, or a pedestrian who won't move. A human operator has to take control, fix the situation, and hand it back, without the robot timing out, the operator getting motion sick, or the fleet behind them backing up.

This post is a short, practical guide for teams who already have working autonomy and a control stack they trust, and now need to decide which engine to plug in, how to integrate it, and what to budget for the latency tail.

What causes latency issues in industrial robot teleoperation platforms?

Latency in industrial teleoperation is rarely a single number, it's the sum of a glass-to-glass chain, and every link can spike independently under load. The dominant causes, in order of how often we see them ruin a deployment:

• Browser-tuned video stacks. Stock WebRTC implementations target conversational video. They add jitter buffers "to be safe," choose codec profiles that favor visual quality over keyframe cadence, and recover from loss with retransmits that arrive too late to matter. A 100 ms median can balloon to 400 ms under 10% loss.
• Reliable transports for real-time control. If joystick commands ride on the same reliable channel as telemetry, a single packet loss head-of-lines every subsequent command. The operator's last input arrives after the robot has already hit something. Real-time control belongs on a drop-on-congestion, best-effort, express path, the latest command, not a queue of stale ones.
• One global relay. A single region in us-east-1 adds 100–200 ms for any robot or operator outside North America. Most platforms quietly do this and report only the lucky-path median.
• Keyframe bursts. Keyframes are 10–50× larger than P-frames. Dumped into the QUIC send buffer at once, they cause burst-induced queuing delay, the primary cause of latency balloons under cellular and weak wifi. The fix is application-level send pacing (a token bucket between encoder and writes).
• Loss-only congestion detection. Throughput-based adaptation reacts after loss has already happened. By then the buffer is full and the operator is seeing a stutter. Delay-based detection (queuing-region heuristics, RTT trend) catches congestion before loss.
• Hardware encoding mismatches. Software H.264 on a Jetson costs you 40–80 ms vs. NVENC. Stereo VR will not tolerate this.
• Clock drift. If you're measuring G2G against an unsynchronized operator clock, your dashboard is lying to you. Sync both ends to the relay.

If a vendor can't tell you what they do for each of these, assume they don't do anything.

What are the top low-latency teleoperation solutions for robotics teams?

The current generation of serious low-latency teleoperation solutions share three properties: a QUIC-based transport with datagram fast paths, an SFU-style relay mesh with per-subscriber congestion control, and a control plane that's semantically distinct from the video plane. The credible options today fall into three buckets:

1. Full-stack platforms - transport, operator UI, recording, fleet view, and managed operators in one package. This is where Adamo Teleop sits.
2. Engine-only SDKs - you get the transport and the SDK; the operator UI, recording, and fleet view are your problem. Workable if you already have a sophisticated ops team.
3. DIY on WebRTC - fine for demos and small pilots. Breaks at fleet scale, for reasons covered in the previous section.

For most teams, full-stack wins on time-to-production and total cost. Engine-only makes sense if you have a specialized operator console you can't compromise on.

What teleoperation engine works best for large robot fleets?

At fleet scale, hundreds to thousands of robots, operators across regions, 24/7 intervention coverage - the engine has to do four things the small-fleet engines don't:

• Multi-region relay mesh. Robots and operators are routed to the nearest relay automatically. Cross-region traffic only happens when it has to. Adamo runs relays in six regions today (sjc, ewr, lhr, fra, bom, waw) on a Vultr footprint, plus a 32-region MoQ relay footprint we're rolling out for the next-generation transport.
• Per-subscriber adaptive bitrate. A single bad-network operator should not degrade the stream for everyone else. The relay needs an SFU-style allocator that maintains a STABLE / DEFICIENT state machine per subscriber and signals bitrate ceilings back to the publisher.
• Recording and replay as a first-class system, not a feature. Adamo ships adamo-record and adamo-replay services backed by InfluxDB, with frame-level seeking and Kafka-style stream processing (KStream, KTable, windowed joins) for downstream analysis and training-data extraction.
• A control plane the fleet team can reason about. Adamo publishes gamepad inputs as sensor_msgs/msg/Joy on /joy, VR poses as PoseStamped on /head_pose and /controller/{left,right}, and exposes a control_publisher() SDK call that's pre-configured for real-time semantics. No protocol bridge to write, no priority class to remember.

Adamo is the engine we build, so we're biased; what we can say with less bias is that an engine for large robot fleets that doesn't have all four of the above is going to cost you a year of platform work to retrofit. (See how Adamo Teleop handles fleet-scale)

Which teleoperation platform is best for factory mobile robots?

Factory mobile robots - AMRs, forklifts, tuggers, line-side material movers have a specific failure mode that distinguishes them from outdoor or last-mile fleets:

• High intervention density, low per-intervention duration. A wedged AMR needs 30 seconds of human steering, not 30 minutes of careful tele-driving.
• Stable network, predictable layout. Indoor wifi is generally good, but coverage holes near loading docks and cold storage are real.
• Tight integration with the WMS, MES, or fleet manager. Interventions need to be auditable and tied to a task ID.
• Stereo or multi-camera views. Operators need depth perception to align with pallet pockets and conveyor handoffs.

A platform for factory mobile robots should optimize for time-to-handoff, not just stream quality. Adamo Teleop's operator console at operate.adamohq.com shows the fleet as a live grid with video already playing, so the operator clicks into a robot and is driving in under two seconds. Gamepad works out of the box; stereo VR is available for the precision tasks; sessions are recorded automatically for audit.

For teams running factory mobile robots specifically, the criterion that matters most is the one nobody benchmarks publicly: p99 time from intervention request to operator-in-control. If that's not under five seconds, the rest of the latency budget doesn't matter.

How do manufacturers embed teleoperation engines into existing robot control centers?

Most robotics manufacturers already have a control center, a NOC, a fleet dashboard, a ROS-based supervisor, and the integration question is how to add teleop without rewriting any of it. The pattern that works, and the one Adamo is built around, is the following:

1. Install the agent on the robot. One command: curl -sL https://install.adamohq.com | sh. This drops the adamo binary on the robot (Jetson Orin, x86, ARM64).
2. Declare cameras and enable control relay in a YAML config.No new control loop to write — gamepad and VR inputs arrive as standard ROS topics that your existing controller already subscribes to.

   robot_name: "warehouse-04"
   video_tracks:
     - name: "main"
       source_type: "v4l2"
       v4l2_device: "/dev/video0"
       encoder: "auto"
       bitrate: 4000
       fps: 30
   control:
     enabled: true

3. Embed the operator UI, or use the hosted one. The hosted console at operate.adamohq.com is the fast path. For manufacturers who need teleop inside their own control center, the @adamo/react package gives you <VideoStream> and useSession() to drop into an existing React app, and the Tauri build at install.adamohq.com gives you a native QUIC client where browser performance isn't enough.
4. Programmatic control where you need it. For supervisory autonomy, custom input devices (GELLO arms, force-feedback rigs), or fleet-level scripted interventions, the SDK exposes control_publisher()with the right defaults baked in:

   import adamo
   from adamo import JointState
   
   session = adamo.connect(api_key="ak_...")
   with session.control_publisher("warehouse-04", "joint_states") as pub:
       js = JointState(names=JOINT_NAMES, positions=read_joints())
       pub.put(js.to_json())

5. Wire recording into your audit and training pipeline. adamo-record writes to InfluxDB; adamo-data exposes session queries, video index, and joins for downstream consumption. Interventions become labeled training data without extra work.

The whole integration is typically a one-engineer, one-week job for a single robot model. Scaling it across a fleet is configuration, not code.

A note on managed teleoperation services

Integration is one decision; staffing is another. Many teams running factory mobile robots or last-mile delivery fleets need 24/7 intervention coverage in regions where they don't have an ops team. Adamo offers managed teleoperation services, working in the same Adamo console your engineers see. The integration doesn't change; what changes is who sits in the chair when the robot calls for help. For most fleets crossing the 100-robot mark, this is where the unit economics start to matter more than the technical choice.

Wrap

A robot teleoperation platform is infrastructure. The integration into existing control software should be the small, boring part, a YAML block on the robot, a topic subscription in the controller, and the operator's hands on a gamepad somewhere on the other side of the world. If your evaluation is taking longer than the integration, you're probably overthinking the integration.

• Try it: install.adamohq.com
• Read the docs: docs.adamohq.com
• Learn more about Adamo Teleop: adamohq.com/teleop
• Talk to us about managed operators: adamohq.com