It is a browser studio for robot reinforcement learning. The stack underneath is the one you already trust — Isaac Lab for training, MuJoCo for sim2sim — but the environment, reward terms, PPO settings and export live as six blocks on a canvas instead of a repo you maintain by hand.
Why Us
Questions builders ask before their first training run.
Technical, compute, deployment, and pricing answers about building robot RL pipelines on UnitPort — from your browser to a real robot.
Getting started
What UnitPort is, what you have to install, and how far the first day gets you.
No. Sign in and build a canvas in the browser — no CUDA, no simulator, nothing to clone. Installing anything is only for training on hardware you own: pipx install unitport pairs your GPU machine with the canvas, and it dials out, so you open no inbound port.
Not to start. Templates ship with working observation terms, reward recipes and PPO hyperparameters, so a first run is a few clicks away. Nothing is hidden, though: every parameter a researcher would tune stays on the node, and the AI assistant explains a term before you change it.
Minutes to launch: pick a robot, pick a template task, press Run. There is no environment to install and no dependency to resolve. Training itself is hours of GPU time — the canvas is there to shorten everything on either side of that, not the physics in the middle.
It edits the canvas you are looking at — setting parameters, adding reward terms, shaping a task — and an edit is committed only if the same validator that gates Run reports zero errors. It cannot change the training backend, and it never commits a canvas that would not compile.
Technical
Robots, simulators, algorithms — and where the ceiling is.
Unitree Go2, A1, G1 and H1 and Boston Dynamics Spot are the launch set, each carrying real joint, drive and inertial tables read from its published model. Go2-W, B2, B2-W and Mini Pupper v2 are registered too, and anything else comes in as your own URDF.
Isaac Lab for training, MuJoCo for sim2sim validation. Inside Isaac Lab the default engine is Newton (MuJoCo Warp) for both asset formats, with PhysX kept as an escape hatch you switch on deliberately. MuJoCo is pinned to one exact version, because the version is part of the artefact.
PPO, and AMP the moment you attach reference motion clips — AMP is derived from the task, never picked from a menu, so a clip can never be loaded and silently ignored. Recurrent policies, a privileged-critic split and multi-stage schedules are settings on the trainer.
Yes — upload a URDF and it opens in the robot editor, parsed in your own browser, where you assign joint roles, check inertials and set the actuator model. UnitPort converts it to the MJCF and USD the training stack needs. MJCF and USD ingest is refused loudly rather than half-done.
Rewards are composed, not written: 28 built-in terms — tracking, gait, contact, effort, stability, termination — stack with their own weights, and the canvas shows each contribution separately. Terrain, command, observation-noise, action-scale and termination curricula sit beside them.
Training & compute
Where a run actually executes, what it needs, and what it costs.
Three places, chosen per run: UnitPort's own GPUs, your own GPU server, or the machine next to you. The canvas, the logs and the playback are identical in all three — only the compute moves. Our cloud never trains and never renders; it compiles, stores and relays.
An NVIDIA RTX card with a CUDA driver current enough for the Isaac Lab release you run, Isaac Lab installed, and Python 3.9 or newer on Windows or Linux. Nothing else, and no inbound port — the helper dials out. unitport doctor checks the machine before you rely on it.
Runs take hours — that is the physics, not the platform. On hardware you own it costs nothing beyond electricity. On ours, GPU time is metered by the hour, with included hours on a monthly plan and a lower member rate beyond them. See the pricing page for current rates.
Yes. The run lives on the machine doing the work, not in the tab — close it, lose your network, come back later, and the run and its logs are still there. One GPU runs one Isaac Lab job at a time, though, so parallel experiments mean more machines, not more tabs.
Yes. Checkpoint is its own block feeding the trainer, and it offers three start points: train from scratch, resume the latest run, or warm-start from any checkpoint you pick. Because it is a block, the choice is part of the canvas rather than a flag you have to remember.
Validation & deployment
From a trained policy to something that runs on a robot.
Because a policy that only works in the simulator it was trained in has learned that simulator, not the task. Sim2sim replays the trained policy in MuJoCo under the same task definition, and it runs in your browser — real MuJoCo and ONNX runtime — so a gap shows up before hardware does.
Because raw kp/kd are engine-specific numbers pretending to be physics. UnitPort stores natural frequency and damping ratio and bakes the gains per engine at compile time from the robot's own mass matrix — so Isaac Lab and MuJoCo end up comparing the policy, not the tuning.
A policy bundle: ONNX or TorchScript weights, the observation and action contract that says how to feed it, normalisation statistics, a sim2sim pack and the canvas that produced it. It is a folder you download, and nothing inside it needs UnitPort in order to run.
Today you take the bundle and do that part yourself. The export carries the deploy contract — joint order, observation scaling, control rate, effort limits — which is the part that usually goes wrong. But there is no robot-side runtime and no ROS 2 bridge from us yet. We would rather say so.
Yes. Inference is one ONNX or TorchScript forward pass on whatever computer the robot carries — no network, no account, no call home. UnitPort is where the policy is made, not something the policy depends on once it exists.
Data, openness & pricing
Who owns what, what is readable, and how billing works.
You do. Robot models, canvases, motion clips and trained policies are yours, downloadable at any time, and we train nothing of our own on them. Your files sit in a storage partition scoped to your account and are reached only with your own session.
The platform is proprietary. The local helper — the part you install on your own GPU machine, and the only part that touches your hardware and your files — is published so you can read what it does before you pair a machine with it.
Building is free and stays free: the canvas, the compiler and every run on hardware you own cost nothing. Exactly two things are metered — GPU time on our machines, and the AI assistant, billed on the tokens the model reports. Neither can start without you choosing it.
There is a CLI — unitport login, up, doctor, config, finalize — but it is the connector for your GPU machine, not a second way to author a run. The canvas is where a run is defined. A headless authoring SDK is not something we ship today.
Canvases, robot models, policies and motion clips can be published to the community, and anyone can pull one into their own workspace. There is no shared team workspace with joint editing. For anything broken, the feedback page reaches us directly.
Ask the people building it.
Drop into the community, or just start a run — the fastest way to know if UnitPort fits your robot is to build one canvas.