Adamas Robot Operations Platform: Architecture and Deployment Model
Adamas is the XR operations layer for robot fleets. It connects human operators to physical and simulated robots through a hardware-agnostic device interface, realtime transport, and robot-side SDK. Engineering teams use it to add teleoperation, supervision, remote intervention, and synchronized data capture without replacing their existing robot, simulation, or autonomy stack.
The operating principle is direct: deploy robots today, then use operational experience and high-quality human interaction data to automate them tomorrow.
What Adamas does
An operator opens the Adamas web application, enters a fleet, and sees the robots that are currently connected. The operator can select a local input device, choose a robot, view its available video and telemetry streams, and start or stop control.
The robot remains in charge of its own low-level control and safety behavior. Adamas transports normalized operator intent to the robot, while the robot integration decides how that input should move a particular arm, mobile base, humanoid, or simulated system.
This separation makes the platform useful across different robot embodiments and control devices. Teams can keep their existing robot software, simulation environment, and AI stack while adding a shared operations layer around them.
The overall architecture
Adamas is divided into four main layers:
Operator and input device
↓
Adamas web application
↓
Cloud control plane + realtime data plane
↓
Adamas Robot SDK
↓
Physical robot or simulation
1. Operator application
The browser application is the operator workspace. It handles authentication, fleet selection, robot and device selection, video, telemetry, and control lifecycle actions.
Input devices produce a generic state made of poses, axes, buttons, and joints. That common representation allows different devices to share the same transport while leaving robot-specific mapping on the robot side.
2. Cloud control plane
The control plane manages users, fleets, robot credentials, and robot presence. It answers questions such as which robots belong to a fleet and whether a robot is currently connected.
It is intentionally separate from the realtime control path. Database requests and account management should not sit inside the fast operator-to-robot loop.
3. Realtime data plane
Adamas uses WebRTC-based realtime infrastructure to carry control input, safety signals, robot telemetry, and video between the operator and robot.
Fast-changing control and telemetry use latest-value delivery, while lifecycle commands such as stop, reset, and home use a reliable path. This keeps the control protocol focused on current robot operation rather than treating it as a general message bus.
4. Robot integration
The robot or simulation integrates the Adamas Python SDK through an
AdamasRobotAdapter. The host application keeps ownership of its control loop.
The adapter receives operator state, maps it into robot-specific actions, and
publishes the video or JSON telemetry streams that operators need.
This boundary works with a custom robot stack and can sit alongside systems such as ROS 2, Isaac Sim, or Isaac Lab. Adamas complements those systems; it does not replace the robot controller, simulator, or autonomy policy.
Integration and deployment workflow
The basic workflow is:
- Create a fleet in the Adamas portal.
- Add the Adamas Robot SDK to a robot or simulation process.
- Configure the fleet credentials and a stable robot identity.
- Map the generic operator state into commands appropriate for that robot.
- Register the video and telemetry streams the operator should see.
- Start the robot process and open the fleet workspace.
- Select an input device and robot, inspect the streams, and enable control.
A team can begin with one robot and one defined workflow. Once the integration and safety behavior are understood, the same structure can be extended to more robots, devices, tasks, and deployment environments.
Primary deployment models
Research and R&D
Researchers can use Adamas to operate simulated or physical robots, test new control mappings, evaluate operator interfaces, and run repeatable human-guided experiments. The generic device model also makes it easier to compare input devices without rebuilding the full network stack.
Demonstration and intervention data workflows can be built around the realtime streams. The current transport is an operations protocol rather than a complete dataset format, so teams should connect it to the recording, storage, and annotation pipeline required by their research program.
Robot deployment and remote recovery
Deployment teams can use the platform as the foundation for remotely viewing, controlling, and recovering robots when autonomy encounters an exception. A shared fleet workspace reduces the need for a different operator tool for every robot or customer deployment.
Advanced workflows such as policy-to-human handoff, operator assignment, multi-user permissions, and intervention recording can build on this same separation between the control plane, realtime transport, and robot adapter.
Simulation and integration testing
Robot developers can connect a simulator before physical hardware is ready. This helps validate authentication, device mappings, video, telemetry, and control behavior before moving the workflow to a real robot.
Custom teleoperation interfaces
The device and robot boundaries allow teams to add new operator hardware or robot-specific control mappings without changing the entire platform. Browser devices, XR interfaces, and future native device agents can all produce the same normalized operator intent.
Intended teams
Adamas is designed for robot manufacturers, embodied-AI teams, research groups, deployment engineers, and fleet operators that already have a robot or simulation but do not want to build and maintain every piece of teleoperation infrastructure themselves.
It provides the connective layer between the operator, the network, and the robot—so the team can focus on the robot, the task, and the path toward greater autonomy.