> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reactor.inc/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace.
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The video model catalog — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Robotics policy documentation starts at /robotics/overview; X-WAM observations, actions, and client integration are under /robotics/xwam/; Cosmos3 Nano Policy DROID is under /robotics/cosmos/nano-policy-droid/. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# Integration

> Map your camera, joint, and gripper state to the DROID policy contract.

Reactor supplies the action endpoint and SDK transport. Your application supplies camera capture,
state measurement, joint control, execution timing, and local safety behavior. The reference
simulator is not a validated hardware driver.

## Check embodiment compatibility

| Adapter responsibility | Required mapping |
| - | - |
| Arm | DROID's seven joints in the trained order; measured positions in radians |
| Gripper observation | Measured normalized closure: `0` open, `1` closed; convert from your driver's units |
| Cameras | Wrist, left exterior, and right exterior views with suitable calibration and placement |
| Arm execution | Absolute joint-position targets in the same ordering and zero/sign conventions |
| Gripper execution | Map continuous closure output to the driver's command convention; RoboLab uses a `0.5` threshold |

Check the
[DROID robot definition](https://github.com/NVlabs/RoboLab/blob/ad45d4f974725d020f82c2b0d77d78533aeba2b3/robolab/robots/droid.py)
and
[Cosmos3 simulator client](https://github.com/NVlabs/RoboLab/blob/ad45d4f974725d020f82c2b0d77d78533aeba2b3/policies/cosmos3/client.py)
for the reference mapping. Do not add the returned joint targets to the current joint positions. Do
not infer compatibility with another Franka configuration, gripper, or embodiment from tensor shape
alone.

## Implement the control loop

1. Register the reply handler before connecting, await `connect()` until `READY`, then publish all
   three tracks.
2. Send a task and fresh measured state. Accept the first valid `(32, 8)` chunk with `step: 0`.
3. Validate targets against your robot's position, velocity, acceleration, and workspace limits.
   Execute through your local controller; the reference cadence is 15 Hz.
4. Capture fresh observations after execution, update state, then acknowledge the received step with
   the rows actually executed. Accept only the expected next counter.
5. On a timeout or disconnect, stop advancing the remote loop and apply your local hold/stop policy.
   Reconnect with current observations before resuming.

This serialized loop incurs inference and transport delay between chunks. The 2.13 seconds of motion
in a chunk is not automatically a latency budget that hides that delay. If you introduce pipelining
or change the executed horizon, evaluate the resulting observation delay and policy behavior
explicitly.

## Validate on your rig

Begin with observation capture and action inspection without actuation. Confirm camera identity,
joint units/order, gripper polarity, frame age, and reply ordering. Then evaluate controlled tasks
with your controller's limits and emergency stop in place. Measure observation-to-execution latency
and tracking error, as well as task success.

A step acknowledgement reports client progress; Reactor cannot verify that the robot moved. The SDK
does not provide a hard real-time servo loop or collision avoidance.

## Observation timing

Camera tracks and state commands arrive independently. Timestamp observations at capture and set
limits for their age and cross-camera skew; a reply counter does not establish capture alignment.
Publish actual observations rather than treating repeated images as new measurements.

Measure capture-to-execution age and controller queue depth. Validate the complete loop in a
simulator or replay harness before adapting it to hardware.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.