> ## 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=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; 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 robot observations to X-WAM and convert predicted deltas into controller targets. Use the same client as the [quickstart](/robotics/xwam/robotwin/quickstart), replacing synthetic observations with camera frames and measured state. The supplied reference is for RoboTwin `aloha-agilex`; it does not validate transfer to a physical robot or another embodiment. ## Observation adapter Provide all three camera views as RGB `uint8` arrays, with the view names and image geometry in the [reference](/robotics/xwam/robotwin/reference#camera-tracks). Align camera capture and state measurement. Preserve the checkpoint's camera geometry and framing when evaluating compatibility. Pack measured end-effector positions, orientations, and gripper openings into `proprio`. Joint positions alone are insufficient; your adapter must compute the end-effector poses. Use unit quaternions in `wxyz` order and map the gripper to the RoboTwin opening convention. ## Coordinate mapping The [upstream adapter](https://github.com/sharinka0715/X-WAM/blob/72cfb86b33fc5060963ef63412f16439fcfa472f/evaluation/X-WAM/deploy_policy.py) defines two fixed transforms for **RoboTwin**. With column-vector positions and rotation matrices: ```python theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} B = np.array([[0, 1, 0], [-1, 0, 0], [0, 0, 1]]) E = np.array([[0, 0, 1], [0, -1, 0], [1, 0, 0]]) p_model = B @ p_robotwin R_model = B @ R_robotwin @ E p_robotwin = B.T @ p_model R_robotwin = B.T @ R_model @ E.T ``` `B` changes the base coordinate convention; `E` changes the end-effector axes. A physical robot needs its own calibrated mapping into the checkpoint frame. Do not apply these simulator-specific matrices to arbitrary hardware without establishing the frame relationship. ## Action execution For each arm, start at the state used in the request and integrate the returned rows sequentially: ```text theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} p_next = p_previous + delta_position R_next = rotation_from_rotvec(delta_rotation) @ R_previous g_next = g_previous + delta_gripper ``` Convert those targets back into your controller's frame and gripper convention. Your controller owns inverse kinematics, interpolation, joint and workspace limits, and emergency stopping. Validate shape and finite values before execution. Predicted `proprios` are diagnostic and must not replace measured state. The reference simulator executes the full 32-step chunk. If your controller executes only a prefix, discard the remainder and obtain a new observation before replanning. Never restart a relative action chunk from its first row after partially executing it. ## Control loop and recovery Run one prediction at a time. Associate it with the captured state, accept only its matching `step`, and reject duplicate or expired chunks. The model's reply identifies the request, but does not include a sensor capture timestamp or an execution deadline; track both in your client. Camera publishing frequency, inference latency, and controller frequency are separate quantities. Choose the execution cadence for your controller and validate policy behavior at that cadence. The reference client's 15 fps tracks do not specify a 15 Hz robot control rate. Set a maximum observation age and a response deadline for your robot. The replay client's default 30-second response timeout and two retries are debugging defaults, not a hardware control budget. On timeout or disconnect, stop applying old predictions according to your controller's stop policy. Reconnect with a fresh client, discard old replies, and resend the task and current observations. Always close the client in `finally`, as the quickstart does. Measure capture-to-execution time in your application; `prediction.latency_ms` measures only request send to matching reply and excludes the client's frame-delivery wait. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.