Deploy and iterate

Download your trained model, run it on the robot, and improve it when it misbehaves.

Once a training run is marked Done, the model is ready to download to your robot and use as a skill.

Download the model

When a run completes, the trained checkpoint is downloaded to the robot and activated.

Phone app

A completed run appears in the Completed tab (or shows a download button in the Runs tab).

1. Open the completed run

   Navigate to the skill page and open the Completed tab. Find the run you want to deploy.

2. Tap Download

   Tap the download button on the run card. The app downloads the trained checkpoint and dataset statistics file to the robot.

3. Wait for activation

   A progress bar shows the download and verification stages. When it completes, the model is automatically activated — the skill’s metadata.json is updated with the checkpoint path.

Web app

The web app has no manual download step — it relies on auto-download (below). Watch the run reach Done on the Training page; when the robot is on and connected, the checkpoint downloads and activates on its own.

The robot’s brain reloads automatically after activation. Your skill is now live.

Auto-download is also enabled. If the robot is on and connected when a training run finishes, the model downloads and activates without any manual action.

When a model downloads, the robot pre-builds an optimized TensorRT engine for it, so policies run fast on-device with temporal ensembling for smoother motion. This happens automatically — there’s nothing to configure.

Run the skill from the app

The simplest way to test a trained skill is to trigger it directly, with no agent involved — from the web app’s Teleop page or the phone app’s Manual Control. Both list only activated (non-training) skills; see Manual Triggering for each surface.

On selecting the skill and pressing play, the robot moves the arm to the learned start pose and begins running the policy at 25 Hz, reading cameras and streaming arm and base commands in real time. Stopping halts it immediately.

Run the skill from code

Trained skills are available to agents and code-defined skills just like any other skill. The catalog generates a typed reference for each one, so you import and list it exactly like a code skill:

from innate import Agent, SkillRef
from innate_skills.navigate_to_position import NavigateToPosition
from innate_skills.pick_up_cup import PickUpCup   # your trained skill

class TidyUpAgent(Agent):
    @property
    def id(self) -> str:
        return "tidy_up"

    @property
    def display_name(self) -> str:
        return "Tidy Up"

    def get_skills(self) -> list[SkillRef]:
        return [PickUpCup, NavigateToPosition]

    def get_prompt(self) -> str:
        return """You are a tidying robot. Use pick_up_cup to grab cups
        you see, then navigate to the kitchen to put them away."""

The Innate agent calls your trained skill the same way it calls any other skill — the execution pipeline handles loading the checkpoint, running inference, and sending commands to the hardware.

What happens during execution

When the skill runs, the BehaviorServer loads the checkpoint, moves the arm to the learned start pose, then enters a 25 Hz inference loop: it reads both cameras and the joint state, runs the policy, and streams arm and base commands until the task completes. The step-by-step breakdown lives in Policy-Defined Skills.

Multiple training runs

You can train multiple runs with different hyperparameters for the same skill. Each run produces an independent checkpoint stored in its own subdirectory. When you download and activate a run, it becomes the active checkpoint for that skill.

To switch between runs, download a different completed run — activation overwrites the checkpoint path in metadata.json.

Iterating on a skill

Training a policy is rarely one-and-done. Make the first test easy: reproduce the scene you recorded in — same robot placement, object positions, and lighting — and watch a full run without intervening. If the policy fails on its own training distribution, something is wrong upstream, not in your setup.

Common failure modes

Symptom	Likely cause	Fix
Robot doesn’t move or barely moves	Too few episodes, or episodes have inconsistent starts	Record more episodes with consistent start poses
Arm overshoots the target	Jerky demonstrations or high variance in approach angles	Re-record smoother demonstrations; try a larger chunk size
Robot starts well but drifts	Not enough variation in demonstrations	Add more episodes with slight object position changes
Works on first run, fails on repeat	Object or robot position shifted	Record with more position variation; aim for 2–5 cm spread
Gripper doesn’t close at the right time	Inconsistent grasp timing across episodes	Focus on consistent timing when closing the gripper
Robot ignores the object entirely	Lighting or background changed significantly	Record in the current conditions, or control lighting more carefully

How to improve a policy

• Add more data — the most reliable fix. 20–30 episodes covering the specific failure case, then sync and retrain; new episodes are added to the existing dataset, so you never start over.
• Tune hyperparameters — if the behavior is qualitatively close but not quite right, when to change the defaults maps each symptom to the right knob.
• Improve demonstration quality — replay your episodes and replace the weak ones: hesitations and course corrections, runs much longer or shorter than average, and start poses that don’t match the rest.

Scaling up

Once the policy works in the original setup, introduce variation gradually — move the object a few centimeters, swap in the same object in a different color, adjust the lighting modestly. When it breaks, record 10–20 more episodes under the new conditions and retrain. Each round makes the policy more robust.

Invest in data variety and you’ll spend less time debugging — see how many episodes you need for concrete numbers.