Booster and Unitree workflows

Keep robot details in the adapter

Booster K1 is the first physical adapter because Adam uses that platform. It is not HIM’s core robot model. Unitree and every future robot enter through the same RobotManifest, signal contracts, simulator adapters, deployment adapters, safety limits, and conformance suite.

• Core product code never assumes a vendor, joint count/order, topic name, SDK command, humanoid embodiment, simulator, or action representation.
• A Brain declares required capabilities and signals. Compatibility resolves through exact robot and adapter versions.
• Vendor assets, commands, firmware, extensions, and license constraints remain behind their package/adapter boundary.

Booster workflow

1. Replay one approved K1 reference motion and label it Reference Motion Replay—not a trained brain.
2. Train or load one motion-tracking controller using the upstream Booster Train/Isaac Lab workflow.
3. Export a Brain Package containing the checkpoint/deployment artifact, observation/action contracts, normalization, and safety envelope.
4. Evaluate two brains or recipes under the same motion challenge and isolated evaluator.
5. Publish truthful simulation media and fork lineage in Arena.
6. Move only an eligible release into the supervised Adam workflow; start with the least dynamic approved motion.

Read the HIM Package and Isaac workflow docs. Inspect this robotics project before executing anything. Preserve its Isaac Lab layout and native commands. Propose a private .him-only overlay for the K1 train, play, evaluate, and export workflow, and show the diff before writing. Do not invent versions, task names, signal mappings, licenses, or hardware eligibility.

Add Unitree without changing the product

1. Identify the purchased SKU, options, firmware, sensors, limits, and lawful asset/SDK source.
2. Create an immutable RobotVersion and simulator/deployment adapter package.
3. Map native observation/action names, ordering, units, frames, timing, reset, safety, and stale-input behavior.
4. Pass manifest, asset, signal, deterministic reset, simulator smoke, evaluator, timing, version mismatch, and deployment dry-run tests.
5. Run a physically meaningful version of the same challenge and compare embodiment-specific results without changing Arena routes or Compute job types.

What you need

• Absolute local workspace or immutable image and permission to inspect before execution.
• Exact setup, smoke, train/play/evaluate/render commands and clean shutdown behavior.
• Robot/simulator/asset/runtime versions and current source commit/digest.
• Observation/action/normalization/timing/reset/termination mapping and intended evaluator.
• One representative successful output inventory and expected media path.
• Source, asset, weight, output, and publication rights plus required redactions.