> ## 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; The launch policies are Cosmos Nano DROID (/robotics/cosmos/nano-policy-droid/), DreamZero DROID (/robotics/dreamzero/droid/), and FLUX Action DROID (/robotics/flux-action/droid/), organized by model family and embodiment. 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

> Connect your cameras and robot controller to Praxis-1 DROID.

Reactor receives camera images, measured robot state, and a task instruction. It returns predicted
end-effector pose and gripper targets. Your application sends the observations and checks the
returned targets. Then it tells the controller of your robot when to execute them.

There is no reference client for a physical robot with this model yet. Connect your own camera and
robot-control software, and test the complete setup.

## Check embodiment compatibility

The model expects the cameras and state conventions of the DROID rig. Your application translates
between that format and the software of your robot.

| Part of your setup | What your application must do |
| - | - |
| Cameras | Supply the exterior and wrist views with DROID-like placement. Check calibration and which image goes to each track. |
| Arm state | Send the measured end-effector position in meters and orientation as a quaternion, scalar first, in a frame listed under `pose_frame`. |
| Gripper state | Send the measured gripper value on the DROID scale: `0` open. |
| Arm control | Treat each pose as an absolute Cartesian target in the same frame. Convert it to joint motion with your controller and enforce its limits. |
| Gripper control | Convert the returned gripper value to a command your gripper accepts. The endpoint does not threshold it for you. |

## Implement the control loop

1. Subscribe to `action_prediction` and `prediction_failed`. Connect, and wait for `READY`. Start to
   publish both camera tracks at 15 fps.
2. Send the task. Keep sending the measured robot state, at least the last 25 rows. The first reply
   has `step: 0` and 21 rows.
3. Check that all values are finite. Then check that the targets stay in the position, speed,
   acceleration, and workspace limits of your robot.
4. Give the targets to your controller. The rows are 1/15th of a second apart. Use `timestamps` to
   schedule them.
5. After execution, send the measured state. Then send `set_executed_step` with the received `step`.
   This tells the model that it can calculate the next chunk.
6. Keep only one chunk outstanding at a time. Expect `step` to increase by one with each reply.
7. If you receive `prediction_failed` or the connection stops, hold or stop the robot with your
   controller. Follow the safety policy of your application. After a failure, the next chunk starts
   a new episode. After a lost connection, start a new session.

A full chunk takes 1.6 seconds to execute. The model calculates the next prediction after your echo,
so network transfer and inference add a wait between chunks. Make sure that your controller can hold
the robot during that wait.

## Validate on your rig

Before you connect your integration to hardware, test it with the [simulator
adapter](https://docs.reactor.inc/robotics/praxis/droid/simulation.md) or with recorded observations.

On your robot, first disable movement. Capture observations, inspect the predictions, and check
these points:

* Each camera sends to the correct track.
* The poses use the correct frame and units.
* The open and closed gripper values are not reversed.

Then test controlled tasks. Keep the limits of your controller and the emergency stop active.
Measure task success. Also measure the time from the capture of an observation to the execution of
its prediction, and how accurately the robot follows the requested poses. Your local controller is
responsible for motion timing and collision avoidance.

## Observation timing

Camera images and robot state travel separately. They can arrive at the model at different times,
even when you capture them together. Record the capture times in your application. Decide how old an
observation can be before you discard it. The `step` counter of a reply does not show when its input
images were captured.


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