The Development Studio
Everything
in one orbit.
The Studio gathers the entire robotics workflow into a single environment, from the first simulated frame to a fleet running in production.
On this page
- Why one environment beats twelve
- What the Studio contains
- The bridge from simulation to reality
- Writing once and running on many bodies
- The real-time runtime underneath
- Fleet operations and enterprise controls
One place, not twelve
Drop the tangle
of tools.
Your stack shapes your robot, and your pace.
Most robotics work is a relay race between disconnected tools. A simulator here, a data pipeline there, a deployment script taped to the side, and an operating system nobody on the team fully trusts. Each one arrives with its own format, its own credentials, and its own way of forgetting what the last one knew.
That is not a workflow, it is a tax. The Studio replaces the relay with a single track. A simulation and template library seeds reproducible data and carries you across the gap between simulation and the real world. Robotics foundation models sit a click away rather than a migration away. Build, deployment and fleet management are stages of the same project, not separate products you integrate on a Friday.
The compounding matters more than the convenience. Every hour you do not spend gluing tools together is an hour spent on the robot itself, and that difference accumulates over the life of a program.
The test we hold ourselves to
You should be able to open a project you have never seen, run it in simulation, understand where its data came from, and deploy it to a body you own. If any of those four steps needs a conversation with us, the Studio has failed at its job.
What the Studio contains
Nine parts of a workflow,
under one roof.
None of these are add-ons. They are the pieces a robotics project needs in order, and they are built to hand work to each other without translation.
- Simulation
- Run a robot entirely in software first, where mistakes are free and iteration is fast. The viewport runs against the same real-time runtime your hardware will use, so what you watch in simulation is a fair preview of what you will get on the bench.Fast, forkable, and safe to break.
- Template library
- Reproducible worlds and project scaffolds that capture setup which normally lives in one engineer's head. A template records the scene, the physics assumptions, the sensor configuration and the evaluation conditions together, so a result can be repeated rather than described.Includes templates published to the Creator Hub by other makers.
- Reproducible data
- Simulated and collected data is versioned alongside the project that produced it. An experiment that worked yesterday works again today, and on someone else's machine, because the inputs are pinned rather than remembered.Datasets carry their lineage, not just their contents.
- Robotics foundation models
- Models tuned for robotics, not adapted from somewhere else, available inside the project instead of behind a migration. This is where a policy learns what good looks like, from your data, your simulation, and any skill you reuse from the Hub.Training runs are reproducible and attributable.
- Authoring and behaviors
- Write behaviors as code, compose them from published skills, and keep both in the same project history. Behaviors are versioned artifacts with an evaluation record attached, which is what makes reuse safe for the person on the other end.A low and no-code builder is in progress.
- Cross-robot compatibility
- A compatibility layer in the development environment, so a behavior authored for one body can target another without a rewrite. Kinematics, actuation limits and sensor layout are described to the project rather than assumed by it.Author once, retarget deliberately.
- Build and packaging
- One build path produces what simulation runs and what hardware receives, with the same version identifiers on both. If a deployment misbehaves, you can name exactly which build is on the robot.Reproducible builds, not snapshots.
- Deployment and fleet management
- Carry a project from simulation into production with versioning, staged rollout, rollback and observability. Fleet state is visible in the same place the behavior was authored, which shortens the distance between a symptom and its cause.Enterprise controls included.
- Real-time operating system
- A lightweight, efficient operating system with real-time capabilities runs underneath all of it. It is deliberately small, because a runtime you cannot reason about is a runtime you cannot certify, debug, or trust with a machine that moves.The same runtime in simulation and in the field.
Simulation to reality
Cross the bridge
with your work intact.
The simulator imagines it. The real world proves it. Balance between the two is where reliable robots are made.
The expensive part of robotics is rarely the first demonstration. It is the second one, on real hardware, after the assumptions that held in simulation quietly stop holding. Most teams absorb that cost by starting their calibration over at the threshold, with a new set of scripts and a new source of truth.
The Studio treats that crossing as part of the project, not the end of it. The same project carries its data, its templates and its evaluation conditions into production, and the telemetry that comes back is written into the same place the behavior was authored.
- Pinned inputs. Data, templates and model versions travel with the project, so the real run and the simulated run are comparable.
- Evaluation before rollout. A behavior carries the evaluation pack it was judged against, and that record follows it onto hardware.
- Staged exposure. Roll a build to one robot, then a cell, then a fleet, with rollback that does not require a rebuild.
- Telemetry that returns. Field data flows back into simulation, so the next loop starts from what actually happened.
Author once, run on many
One behavior,
several bodies.
Cross-robot compatibility is built into the development environment, not offered as a porting service. A project describes the body it is targeting, so the same policy can be retargeted to another body by changing the target rather than rewriting the behavior.
Retargeting is still an engineering decision, and the Studio treats it as one. Reach, payload and actuation limits are checked against the new target, and the evaluation pack runs again before anything reaches hardware.
from impless import Studio, Behavior studio = Studio(target="atlas-arm") sim = studio.simulate("tabletop.sim") # reuse a skill published to the Hub grasp = Behavior.from_hub("balance.skill") policy = studio.train(grasp, sim, steps=5e4) # same policy, another body report = studio.evaluate(policy, target="quad-mini") studio.deploy(policy, to="quad-mini", rollout="staged") ready: sim to real bridge, royalty posted to balance.skill
The runtime underneath
A small operating system,
on purpose.
A robot operating system earns its place by being predictable. Ours is lightweight and efficient, with real-time capabilities, and it is the same runtime in the viewport and on the machine.
Real-time capabilities
Control paths are scheduled for predictable timing instead of best effort, because a machine that moves cannot wait for a garbage collector to finish its thinking.
Small by design
A runtime you cannot reason about is one you cannot debug at two in the morning. Keeping it small is what makes the rest of the stack auditable.
Efficient on real hardware
Robots run on the compute they can carry and the power they can spare. The runtime is written for that constraint instead of a datacenter.
One stack, both worlds
Simulation runs against the same runtime as the field, so the gap between the two is physics and sensing, not an entirely different software story.
Observable from the start
Telemetry, logging and tracing hooks are part of the runtime, not a wrapper around it, which is why fleet observability needs no second agent.
Open to read
The runtime is public like the rest of the platform. When behavior surprises you, the answer is in a file you can open, not a ticket you have to file.
Operations and enterprise
What a serious fleet
asks for before it trusts you.
Rollout
Versioning and staged release
Every build is identified, deployable to a subset, and reversible. Rollback is a decision, not a rebuild, and the version on each robot is a fact you can look up, not one you infer.
Visibility
Observability across the fleet
Fleet state, telemetry and failures surface in the same environment where behaviors are authored, so the engineer who can fix a problem is the one who can see it.
Control
Access, audit and ownership
Teams need to know who deployed what, and when. Enterprise controls cover access, review and audit trails, and your projects and data remain yours to export.
In progress: the low and no-code builder
Authoring a behavior should not require fluency in a programming language. A low and no-code builder is on its way, built on the same project format the code path uses, so work started in one can continue in the other. It is not finished, and we will not describe it as though it were.
Questions we get
The Studio,
asked directly.
Do I have to use the whole Studio to use any of it?
No. The pieces are designed to hand work to each other, but they are not welded together. Teams commonly start in simulation with the template library, or arrive with a trained policy and use the Studio only for evaluation and deployment. Because the source is public, the boundaries are inspectable rather than contractual.
What does cross-robot compatibility actually guarantee?
It guarantees that retargeting is a configuration change rather than a rewrite, and that the Studio checks your behavior against the new body's kinematics, limits and sensing before it runs. It does not guarantee that a policy trained on one body will perform identically on another. Physics does not negotiate. The evaluation pack is there to tell you the truth early.
Can I run this on my own hardware and my own servers?
Yes. The runtime is designed for the compute a robot can carry, and the repositories are public, so you can build and run the stack yourself. Projects and data are exportable by design, because portability is the point of the platform rather than a concession in it.
How is this different from stitching together existing open source tools?
Those tools are good, and several of them are better than anything we would write from scratch. What they do not have is a shared project format, a single version identity, and a path that carries data and evaluation from simulation into production. The Studio is mostly an argument about those seams. It is also where reuse becomes economic, because a skill pulled from the Creator Hub pays its author automatically.
Is the simulator good enough to trust?
It is good enough to eliminate most mistakes cheaply, and not good enough to replace hardware. We say so plainly because a platform that oversells its simulator costs you the one thing you cannot buy back, which is the time between a confident demo and an honest one.
Start in the Studio
Bring a project,
or bring a question.
Tell us the body you are building for and the stage you are at. We will answer with the templates, the targets and the honest limits that apply to it.