Robotics Programming
Studio’s supported visual, Python, and C++ workflows share a representation for robot behavior.
Developers
Robotics developer resources.
Learn how Studio represents robot projects, runs programs in simulation, and captures evidence for debugging.
Start with the engineering guide and a browser example. SDK contracts and installation guidance will follow verified releases.
Developer Tools
A software foundation for robotics experiments.
Studio engineering work covers programming, project models, simulation, and diagnostics. Release verification varies by workflow.
Project Models and APIs
Studio’s internal project model keeps robot definitions and program state together. The public Core interfaces are in development.
Simulation and Testing
Use deterministic runs and replay to investigate behavior in the engineering build.
Hardware Interfaces
Engineering work covers transport interfaces and firmware generation. Physical release testing is pending.
ROS 2 Interoperability
Studio’s engineering work includes a bridge and a browser-tested setup workflow. Live ROS 2 graph and physical-robot verification remain open.
Diagnostics and Reliability
The engineering build includes runtime inspection, local recovery, and flight recording workflows.
Extensible Workflows
Studio’s engineering work on extensions informs development of the public Robotics SDK.
Developer Documentation
Know where the interfaces meet.
The engineering guide explains the current project, execution, and recording boundaries. Public installation steps, API reference, and a supported-hardware matrix await release verification.
Project and model formats
Studio’s .nrobot project remains the source of project state. Engineering import and export for URDF and SDF are bounded and can lose unsupported semantics.
Recording and replay
Engineering tests cover recording, replay, and Studio’s MCAP profile. A recording captures run evidence separately from project state.
Before testing hardware
Physical and native release validation varies by board, transport, platform, and ROS 2 configuration.
Development Approach
Make experiments repeatable.
We use clear interfaces, test before deployment, and prefer established standards where they fit the workflow.
Specify the boundaries
Record the software version, project format, and inputs that define the test.
Separate kinds of evidence
Source tests, simulation, and native or physical-device runs each answer different questions.
Document what carries over
Record compatibility limits alongside examples so developers can see which assumptions apply.
Start with a repeatable example.
Observe how the scripted rover responds to a barrier. Then see how the Studio runtime handles a virtual run.