UnitPort
Reinforcement learning under declared physics
- Locomotion, balance, whole-body control, contact
- Visual canvas, or describe the task to the AI assistant
- Two physics engines, with cross-engine replay before hardware
UnitPort, LeRobot, or Neuracore?
How is UnitPort different from LeRobot and Neuracore? They learn from recorded demonstrations, and UnitPort learns from declared physics.
LeRobot and Neuracore
Demonstration-based learning: recording, versioning, and training from real robot trajectories.
UnitPort
Learning behaviours nobody can demonstrate, from a declared reward under explicit simulated physics.
Different tools. Different jobs.
Where UnitPort fits, and where the other two do.
LeRobot
Demonstration-anchored learning
- Learning or teaching imitation learning
- Prototyping one task on a low-cost arm
- Open-source Python library, self-hosted
Neuracore
Manipulation at fleet scale
- Manipulation, dual-arm, dexterous hands
- Teleoperation demonstrations, curated and versioned
- Managed cloud, VPC or on-prem, with SLAs
Side by side.
Four blocks, row by row. Every LeRobot and Neuracore cell is a plain statement from their own public documentation; a dash means the documentation does not describe it.
Getting in
What it takes to go from nothing to a first run.
| Dimension | UnitPort | LeRobot | Neuracore |
|---|---|---|---|
| Form factor | Browser-based studio | Open-source Python library | Managed platform, SDK and web console |
| Time to first run | Sign in and build. Nothing to install.What setup actually needs | Install, resolve dependencies, configure environment | Sign up, then sales engagement to scale |
| How a pipeline is built | Visual node canvas, or describe the task to the built-in AI assistantWhat the AI assistant does | Write Python | SDK calls and web console |
| AI-assisted setup | Built in. State the task, the assistant assembles the canvas.What the AI assistant does | Not described in the public documentation | Not described in the public documentation |
| Who on the team can use it | Anyone who can read the canvas, including students and hardware engineers | Anyone comfortable working in Python | ML engineers and roboticists |
| What you need before you start | A browser | A dataset, from the Hub or your own robot | A teleoperation rig |
Training
What the training loop is anchored to, and what you need before it starts.
| Dimension | UnitPort | LeRobot | Neuracore |
|---|---|---|---|
| Paradigms covered | Reinforcement learning, first-classPPO and AMP | Imitation learning, reinforcement learning (HIL-SERL, TDMPC), VLA, world models, and reward models | Imitation learning, with RL fine-tuning |
| What the training loop is anchored to | A declared reward under declared physics | A recorded dataset | A recorded dataset |
| Data required to start | None. You define a reward, not a dataset. | A demonstration dataset, from the Hub or recorded yourself | Teleoperation demonstrations |
| Reward design | Composite reward blocks, with per-term contribution visible on the canvasHow rewards are composed | Code | Code |
| VLA and language-conditioned policies | In development | Supported (Pi0, SmolVLA, GR00T N1.5, X-VLA, among others) | Supported |
| Where training runs | Our cloud GPUs, your server, or your local Isaac Lab. Same canvas.Where a run executes | Your own GPUs | Managed cloud, or your VPC or on-prem |
Physics and validation
Which engine steps the physics, and what checks a policy before hardware.
| Dimension | UnitPort | LeRobot | Neuracore |
|---|---|---|---|
| Physics backends | Newton (MuJoCo Warp) by default, with PhysX available as a deliberate switch.Simulators and engines | Per environment. Built-in support for LIBERO, MetaWorld, the MuJoCo-based gym-hil, and custom environments. | Integrations with Isaac Sim, Isaac Lab, MuJoCo, and PyBullet-style environments |
| Backend selection | One default for both MJCF and USD assets. Switching to PhysX is a recorded, per-canvas decision, never inferred from the file format.Simulators and engines | Per environment | Per integration |
| Cross-engine validation | A required ring. Every trained policy is replayed in a second engine before deployment.What sim2sim validation is | Not a built-in step | Simulated and real demonstrations blended in one dataset |
| Train-to-validate physics parity | The Newton path shares a physics source with the in-browser MuJoCo validator. | Not described in the public documentation | Not described in the public documentation |
| Fidelity contract | realized == designed. Declared physics is realized across engines, or fails loudly with a declared, bounded divergence. |
Not described in the public documentation | Not described in the public documentation |
Deployment
The path from a trained policy to a running robot.
| Dimension | UnitPort | LeRobot | Neuracore |
|---|---|---|---|
| Sim2real | In developmentWhere deployment stands | Do it yourself | Supported, with simulator integrations |
| Edge and on-robot inference | In developmentOffline on-robot inference | Do it yourself | Supported, with reported latency on target hardware |
| Deployed-policy monitoring | In development | Not described in the public documentation | Success rates stream back, failures become new demonstrations |
| Fleet scale | Not the current focus | Not described in the public documentation | Multi-robot, with SLAs |
Two physics engines, one canvas.
Most tools pick a physics backend and let you inherit its assumptions. UnitPort trains on Newton, the MuJoCo Warp engine, by default, whether your robot arrives as MJCF or as USD; a USD model trains there without conversion, and an MJCF model is converted once on the way in. PhysX is still on the canvas as a deliberate switch, taken for a PhysX-only feature and recorded on the robot itself, so the engine that stepped a run is never a guess made from a file extension. The Newton path shares a physics source with the MuJoCo validator that runs in your browser, so the engine that trained the policy and the engine that checks it are not arguing about inertia.
That matters because a policy which only works in the simulator that trained it has learned the simulator, not the task. Cross-engine replay is not an optional extra step in UnitPort. It is a ring the policy has to pass.
What we're still building.
The reinforcement learning path, the canvas, both training engines, and cross-engine validation are what work today. Three things are in active development, and we would rather say so here than let you find out after you have built a canvas.
VLA and language-conditioned policies.
Our current strength is reward-driven control. Language-conditioned manipulation is on the path, not on the platform yet.
Sim2real.
Cross-engine validation is live. The last mile to hardware is the ring we are maturing now. It is also the ring that decides whether people who own robots take a platform seriously, which is why we are not claiming it early.
Deployed-policy monitoring.
Closing the loop from a running robot back into the next training run.
Not mutually exclusive.
These tools solve different problems, and plenty of teams will use more than one. LeRobot to learn the field, a manipulation platform for demonstration-driven skills, UnitPort for the reinforcement learning half. If your robot needs to walk, balance, or recover, that is the part we are built for.