Add your own robot

Needs: ~1 hour to a moving model, ~2 days to a live twin, 1–2 weeks to a trained policy · advanced · your robot, an edge computer (64-bit Raspberry Pi, Jetson, the robot’s onboard computer, or a Mac for local development), Docker, Python 3.10+, a URDF with meshes · free to start; MuJoCo simulation uses credits This guide is for hardware makers and teams with custom hardware: a custom robot, an in-house prototype, or a niche industrial machine. It takes you in order from “is my robot already supported?” to “my twin moves my robot”. When you finish, anyone with access to your asset can spawn a twin of your robot, simulate it, drive the real machine from the browser or the SDK, record data, and put a trained policy in control. That holds whether the hardware is on the same desk or on the other side of the world. File layouts, upload fields, limits, physics settings and driver config are in the Asset and driver spec.

Check if your robot is already supported

Cyberwave ships 80+ devices in its catalog. Catalog devices like the-robot-studio/so101 are assets that already exist, and many already have a driver. Check Supported hardware first. If your robot isn’t there, you can integrate it yourself. Cyberwave connects any device with an API, serial interface or network protocol.

Teams typically bring a brand-new piece of hardware fully online with Cyberwave in about 2 days, versus the months a bespoke integration usually takes, because the digital twin, transport, UI, workflows and data tooling already exist. You only supply the asset and the driver.

How it works

You build two things:

An asset. The reusable definition of your hardware: its 3D meshes and kinematic model (a URDF). Every twin starts from an asset.
A driver. A small Docker container that bridges your device’s native interface to Cyberwave’s MQTT layer. It publishes telemetry (joint states, odometry, camera frames, sensor data) up to the twin. It turns dashboard, SDK and workflow commands into actions on the device.

A twin is a live instance of the asset inside an environment. Edge Core runs your driver next to the hardware and links it to the twin. Because integration happens at the driver layer, Cyberwave works with ROS 1 / ROS 2, VDA5050, OPC UA, Modbus, gRPC, REST and serial / USB. See Supported protocols.

Support levels

Pick a target level before you start. Each level builds on the one before it and has a test you can run yourself.

Level	What works	Pass test
L0 Model	Kinematics and meshes render; the twin moves in the free browser Playground	`arm.joints.set(...)` in `cw.affect("playground")` moves the right link, in the right direction, within limits
L1 Sim	Physics is complete enough for MuJoCo (inertials, collisions, actuators)	A MuJoCo simulation starts with your twin in the scene, and the twin holds its pose without exploding or drifting
L2 Telemetry	The live twin mirrors the real robot	Move the robot by hand (or with its vendor tool). The twin follows, and `arm.joints.get()` in `cw.affect("live")` returns the real values
L3 Control	Declared commands, teleop, safe failure	Teleop from the browser moves the robot. The teleop overlay lists only commands the driver handles. Cutting the network mid-teleop leaves the robot in a safe state, and an alert appears on the twin
L4 Learn	Record, train, deploy	Record episodes, export them as a dataset, fine-tune a policy, assign it as the twin’s controller, and watch it run on the robot

Time budget. These are planning ranges for a team that already has a clean URDF and a working ROS 2 driver: L0 in about an hour, L2 in 1–2 days, L3 in 3–5 days, L4 in 1–2 weeks. Without a ROS 2 driver, add the time it takes you to write one against your vendor SDK.

What you need

Hardware
Cyberwave account
Dev tools

The device you want to integrate (robot arm, mobile base, sensor, drone, anything with a controllable interface)
Knowledge of its native interface: ROS 1 / ROS 2, VDA5050, OPC UA, Modbus TCP/RTU, gRPC, REST, or raw serial / USB
An edge machine to run the driver on: a Raspberry Pi, a Jetson, the robot’s onboard computer, or your Mac for local development
A working driver or vendor SDK for your robot

The CLI and Edge Core require a 64-bit architecture (arm64/aarch64) on Raspberry Pi.

Plan your integration

Write a one-paragraph plan: your target level, who maintains the driver (you, Cyberwave, or the community), and whether the driver is open or closed source. Decide early whether the asset will be private to your workspace, shared with your organization, or public. Start private and change it later. For closed-source drivers, see Licensing your driver. Done when: the target level is written down and you know who owns the driver image.

Prepare your URDF package

Cyberwave accepts a single ZIP archive with one main .urdf (or .xacro) file and every mesh, texture and material it references. Use relative paths that match the ZIP layout. Include inertials and joint limits now; L1 needs them.

my-robot/
  urdf/
    robot.urdf
  meshes/
    base_link.stl
    arm_visual.obj
  textures/
    arm_albedo.png

The full packaging rules (file types, symlinks, size limit) are in Asset package.

Don’t have a URDF yet? Most robots ship one with their ROS package, or you can export one from your CAD tool. For a sensor-only device (like a camera) you can start from a simple placeholder mesh and refine it later.

Start from the sample URDF

Want a concrete reference? Download this sample drone URDF (a DJI Mini 4 Pro). It defines a base_link plus four propeller links connected by continuous joints, and references its meshes by path.

Sample URDF: dji-mini-4-pro.zip

A complete single-file URDF (5 links, 4 continuous joints, materials, mesh references). Unzip to read it, add your meshes/ folder, and re-zip to upload.

<robot name="dji_mini_4_pro">
  <link name="base_link">
    <visual>
      <geometry>
        <mesh filename="meshes/body.stl" scale="0.01 0.01 0.01"/>
      </geometry>
      <material name="drone_grey"/>
    </visual>
    <!-- collision + inertial omitted for brevity -->
  </link>

  <joint name="prop_front_left_joint" type="continuous">
    <parent link="base_link"/>
    <child link="prop_front_left"/>
    <origin xyz="-0.10764 0.06722 -0.00450" rpy="0 0 0"/>
    <axis xyz="-0.10884 0.23674 0.96546"/>
  </joint>
  <!-- prop_front_right, prop_back_left, prop_back_right joints follow the same pattern -->
</robot>

The downloadable sample references its meshes with package:// URIs (a ROS convention). When you build your upload ZIP, switch those to relative paths that match the archive (for example meshes/body.stl) and include the referenced .stl files in a meshes/ folder.

Validate it locally

The same parser library the platform uses is on PyPI. It has a Python API, not a CLI:

pip install cyberwave-robot-format

from cyberwave_robot_format.urdf import URDFParser

schema = URDFParser().parse("my-arm/urdf/robot.urdf")
print(schema.validate())                       # validation issues
ctx = schema.extensions.get("parse_context", {})
print(ctx.get("warnings"), ctx.get("errors"))  # recovered quirks

The parser tolerates common URDF quirks (a missing type on a joint, say) and records each one in parse_context. Anything under errors means something in your file was discarded. Starting from MuJoCo? cyberwave_robot_format.mjcf.MJCFParser parses MJCF the same way. Done when: validate() returns no issues and parse_context["errors"] is empty.

Create the asset

Create a private asset in your workspace from the dashboard. Open Add asset from the catalog or the environment editor and choose Upload a 3D file.

Package: upload your ZIP

On the Package step, drag and drop your ZIP into the URDF Package (ZIP) drop zone, or click to select it. The archive should contain your URDF/Xacro plus all referenced meshes. Click Continue.

Details: describe your asset

Give the asset a clear name (for example, Acme Arm v1) and a short description of what the robot is.

Expand Advanced if you need it. Set Main URDF path only when the ZIP has more than one URDF, and add an optional Thumbnail. See Upload form fields.

Click Continue.

Access: choose visibility and workspace

Choose who can see and use the asset, then pick the workspace it belongs to.

Visibility	Who can view
Private	Only you
Organization	All members of your organization
Public	Anyone on the platform

Click Create Asset.

Cyberwave unpacks and validates the archive. Once it’s ready, you can spawn twins from the asset in the dashboard, the Python SDK, or the REST API. To upload from a script or CI instead, use POST /api/v1/assets/create-with-urdf. See Upload from the API and the Catalog page. Note the asset’s slug, for example acme/catalog/my-arm. Your driver and its manifest target it later.

Start Private while you iterate on the URDF and driver, then switch to Organization or Public when it’s ready to share. Visibility can be changed after creation.

Not a URDF? Other ways to create an asset

Add asset offers three choices:

Choice	Best for	What to check
Describe the object	Editable dimensions and supported mechanical parts, with an optional reference picture	Review the proposed design and estimated physics. Detailed organic shapes may need another method.
Upload a 3D file	Preserving an existing model’s structure and detail	Include referenced files; add the processed asset to your scene from the catalog.
From a photo	Recreating appearance for visual props and organic shapes	A photo is required; description is optional. Scale, hidden surfaces, moving parts and physics need review.

For Describe the object, enter your dimensions and intended interaction, then follow Describe → Review → Use in the modal header. In Review, edit the name, build description and dimensions, or request a change with Update design. Review the assumptions, then continue to Use. Choose Private or Public and select Build object. Public creation requires confirmation and only publishes the completed catalog object. Your scene does not become public.You can close the dialog while it builds. Catalog creation saves the object in your workspace; starting from an environment also adds the completed object to that scene. The build keeps your reviewed design so later revisions have context. Review collision geometry, physical properties and robot reach before training.

Spawn a twin and test the model

An asset is a reusable definition. A twin is a live instance of it inside an environment. You can spawn one from the SDK or the dashboard.

SDK
Dashboard

from cyberwave import Cyberwave

cw = Cyberwave()                         # reads CYBERWAVE_API_KEY
arm = cw.twin("acme/catalog/my-arm")     # prints the environment URL
cw.affect("playground")                  # free browser simulation
print(arm.joints.list())
arm.joints.set("joint_1", 30, degrees=True)

In the dashboard, create a New Environment and give it a name like Acme Arm Lab.
Click Add from Catalog in the left panel and search for your asset. It appears in your workspace catalog.
Add it and position it to roughly match where the real hardware sits.

The twin isn’t connected to anything yet. Note its UUID (in its properties panel). Your driver receives it at runtime. Done when: every joint moves the right link in the right direction and stops at its limits. You are at L0.

Declare capabilities and sensors

Capabilities decide which UI panels and SDK classes your twin gets. They live in the asset’s universal schema under extensions.cyberwave.capabilities, next to a sensors list.

can_actuate enables joint control and the re-calibrate action.
can_locomote enables Missions.
can_grip and has_joints enable the controller UI.
A non-empty sensors list enables sensor windows.

The full table is in the feature-to-capability matrix. Fix them on the asset page’s onboarding checklist, in the JSON editor (Editing a universal schema), or from the SDK:

asset = cw.assets.get("acme/catalog/my-arm")
cw.assets.patch_universal_schema(
    asset.uuid,
    path="/extensions/cyberwave/capabilities/can_grip",
    value=True,
    op="add",
)

For each sensor, set its id, type (rgb, depth, lidar_3d, imu, …), mount offset, and, for cameras, width, height and FOV. The declared resolution must match the frames your driver actually publishes. If the aspect ratio differs, the object_pose workflow node refuses to deproject (aspect_mismatch). Mimic joints are covered in Mimic joints. Other schema helpers are in Universal schema helpers. Done when: the twin shows the panels you expect (joint sliders, gripper, sensor windows) and nothing else.

Make it simulate

Set world physics on the asset, for example cw.assets.set_physics(asset.uuid, timestep=0.002, ...). All fields, defaults and tuning advice are in Set physics properties.
Enable MuJoCo on the asset under Simulator compatibility. New twins inherit it; existing twins keep their own setting. MuJoCo won’t start if any twin in the environment isn’t marked compatible.
In the environment editor, open Simulation readiness → Prepare simulation. It lists missing data and proposes fixes (Simulator compatibility).
Run cw.affect("simulation"). This starts a MuJoCo instance, which is billable (credits).

Done when: MuJoCo starts with your twin and it holds a commanded pose. You are at L1.

Write the driver

The driver bridges your device’s native protocol to the twin. Pick a starting point:

ROS 2 driver
Python SDK
AI driver skill
Fork a reference driver

If your robot already has a ROS 2 driver, subclass BaseROS2Driver and forward topics with from_ros. You don’t write MQTT code or message conversion:

from cyberwave.driver import CallbackGroup, DriverOperationMode, TopicSpec
from cyberwave.driver.ros2 import BaseROS2Driver, Ros2TopicSpec, run_driver_main


class MyArmDriver(BaseROS2Driver):
    REGISTRY_ID = "acme/my-arm"        # your asset's registry ID
    DEFAULT_NODE_NAME = "my_arm_driver"

    def define_interface(self, iface) -> None:
        iface.add_publisher(
            TopicSpec(
                topic_slug="cyberwave/joint/{twin_uuid}/update",
                payload_schema_ref="JointStatesPayload",
                description="Forward /joint_states to the twin",
            ),
            CallbackGroup(),
            from_ros=Ros2TopicSpec(topic="/joint_states"),
            operation_modes=frozenset(DriverOperationMode),
        )


if __name__ == "__main__":
    run_driver_main(MyArmDriver, anchor=__file__)

CW_ROS2_AUTO_ACTIVATE=true is recommended during development. The SDK stamps source_type=edge on everything from_ros publishes. Full reference: BaseROS2Driver.

No ROS? Subclass BaseDriver and call your vendor SDK. For arms and grippers, compose the driver mixins rather than writing joint-command plumbing yourself.The official SDKs handle twin synchronization, file I/O and reconnection logic, so you focus on the hardware:

Python SDK: cyberwave
C++ SDK: see the C++ SDK docs

pip install cyberwave

A driver does two things: it subscribes to commands and turns them into hardware actions, and it publishes telemetry and state back up to the twin:

from cyberwave import Cyberwave
import os, time

cw = Cyberwave(api_key=os.environ["CYBERWAVE_API_KEY"], source_type="edge")
twin_uuid = os.environ["CYBERWAVE_TWIN_UUID"]

# --- Publish observed joint states up to the twin ---
def on_hardware_state(names, positions):
    cw.data.publish("joint_states", {
        "ts": time.time(),
        "names": names,
        "positions": positions,
    })

# --- Subscribe to incoming commands and drive the hardware ---
def handle_command(cmd):
    if cmd["command"] == "stop":
        my_device.stop()
    elif cmd["command"] == "move_forward":
        my_device.move(cmd["data"].get("linear_x", 0.0))

# Wire handle_command to cyberwave/twin/{twin_uuid}/command, then run your loop:
while True:
    names, positions = my_device.read_joints()   # your native protocol here
    on_hardware_state(names, positions)
    time.sleep(0.05)

cw.data.publish(...) writes to the edge data bus, which makes the data available to local worker containers and ML models with zero network overhead. Canonical channels include joint_states, frames/default, position, imu and battery. You can also publish over MQTT directly for cloud consumers (frontend, telemetry, workflows). Topics and payloads: MQTT reference.

The Cyberwave Driver skill for Claude Code asks a few questions about your hardware and scaffolds a driver project: the Dockerfile, local dev setup, cw-driver.yml, and a working twin connection.Install the skill:

git clone https://github.com/cyberwave-os/driver-skill ~/.claude/skills/cyberwave-driver

Then in any Claude Code session:

/cyberwave-driver

The skill source is open source at cyberwave-os/driver-skill.

Copy a Cyberwave driver whose hardware shape matches yours, then trim what you don’t implement:

Repository	Good template for
cyberwave-edge-so101	Joint-bus manipulator (arm)
cyberwave-edge-camera-driver	USB / RTSP camera as a twin
cyberwave-edge-ros-ugv	Mobile base with locomotion + onboard camera

Run the driver with CYBERWAVE_API_KEY and CYBERWAVE_TWIN_UUID set. Edge Core injects both in production, along with the other driver environment variables. If you write listeners, never act on inbound edge* messages. That’s your own feedback (source-type convention). The full container contract is in Writing compatible drivers. Done when: the twin mirrors the robot in Live mode. You are at L2.

Declare the interface

Your driver’s interface is a cw-driver.yml at the driver repo root, next to the Dockerfile. For ROS 2 drivers it’s the exported manifest.yaml instead. It’s the contract between your hardware bridge, the platform APIs, the web UI and the SDK. It lists which MQTT topics you use and which command strings you accept, so teleop overlays, SDK methods and agents line up with what the hardware actually does. Which file does what: Driver config files. Point registry_ids at your asset, then declare only the topics and commands your code handles:

registry_ids:
  - acme-corp/acme-arm-v1   # the registry_id of YOUR asset
mqtt:
  schema_version: 1
  driver_family: python      # ros_cpp, python, android, ...
  joint:
    update:
      direction: both
      payload_schema_ref: JointStatesPayload
      description: Joint targets in, observed joint states out
  twin:
    command:
      direction: in
      payload_schema_ref: TwinCommandPayload
      description: Discrete and continuous commands for the arm
    telemetry:
      direction: out
      payload_schema_ref: TelemetryPayload
      description: Lifecycle and status JSON
  commands:
    supported:
      - stop                                 # discrete (one-shot)
      - { name: move_forward, continuous: true, rate_hz: 10 }  # stick-held

Each YAML path compiles to a flat MQTT topic. For example mqtt.joint.update becomes cyberwave/joint/{twin_uuid}/update, and mqtt.twin.command becomes cyberwave/twin/{twin_uuid}/command.

Only declare what you actually implement. Arm / joint-bus drivers should omit the WebRTC topics; camera video flows through child camera twins and the media service, not WebRTC topics on the arm twin.

Use the reference manifests as templates: the SO-101 arm for a joint bus plus command topic, or the UGV Beast for continuous locomotion. Copy the namespaces that match your robot and delete the rest.

For ROS 2 drivers, export the combined manifest at build time with python main.py write-manifest.

Register it on your twin

By default the driver registers its own interface when it starts (auto_register_interface = True calls twin.driver.set_schema(...)). To register it without running the driver, or from CI:

from cyberwave import Cyberwave

cw = Cyberwave(api_key="...")
twin = cw.twin(twin_id="acme/twins/my-arm")

# Compile the manifest, persist it on this twin, re-bind catalog methods
twin.driver.set_schema("./cw-driver.yml")   # or MyArmDriver.get_manifest()
print(twin.driver.get_supported_commands())

# Inspect the catalog the UI and SDK now use
print(twin.commands.get_schema()["commands"]["supported"])

# Call any command you declared
twin.commands.stop()
twin.commands.move_forward(linear_x=0.3, duration=0.5, rate_hz=10)

set_schema compiles the file on the platform (POST /api/v1/twins/{uuid}/driver-schema), writes metadata.mqtt on the twin, refreshes the catalog cache, and re-binds twin.commands.<name>. Re-run it whenever you change the manifest so teleop, agents and SDK callers stay aligned with your driver. Details: Writing compatible drivers.

set_schema updates this twin’s metadata, so you can iterate without changing a shared asset definition. When the driver is solid, you can apply the same metadata.mqtt to the asset so every new twin inherits it.

Done when: the teleop overlay and get_supported_commands() list exactly the commands your driver implements.

Package and run the driver

Build and test the image locally

Package the driver as a Docker image. Build it for every edge platform you support. For local development, run it with the same environment variables Edge Core uses:

docker run --rm \
  -e CYBERWAVE_TWIN_UUID="your-twin-uuid" \
  -e CYBERWAVE_API_KEY="your-api-key" \
  -e CYBERWAVE_DATA_BACKEND=zenoh \
  --device /dev/ttyUSB0 \
  acme-arm-driver:latest

Push the image

Push to Docker Hub or to the Cyberwave registry registry.cyberwave.com (Enterprise; authenticate with docker login registry.cyberwave.com using your API key, see Docker registry). Version tags are immutable there.

Bind the image to the asset

Edge Core reads the asset’s metadata.drivers block and starts one container per linked twin:

{
  "drivers": {
    "default": {
      "docker_image": "registry.cyberwave.com/acme/my-arm-driver:v0.1.0",
      "params": ["--network", "host"]
    },
    "linux-aarch64-jetson": {
      "docker_image": "registry.cyberwave.com/acme/my-arm-driver:jetson-v0.1.0",
      "prefer_gpu": true
    }
  }
}

Edge Core picks the most specific platform key for the host and falls back to default. Key rules, multi-container services and env vars: metadata.drivers keys.Set it on the asset from the SDK (read, merge, write), or edit a twin’s metadata in the environment editor under Advanced editing. Changing the asset affects twins created afterwards.

asset = cw.assets.get("acme/catalog/my-arm")
metadata = dict(asset.metadata or {})
metadata["drivers"] = {"default": {"docker_image": "registry.cyberwave.com/acme/my-arm-driver:v0.1.0"}}
cw.assets.update(asset.uuid, {"metadata": metadata})

Pair the edge device

On the machine wired to your hardware, install the CLI and pair:Run sudo cyberwave pair and select your twin. Edge Core pulls and runs your driver image with the environment variables injected automatically, beside the device, on the robot, in the cloud, or on your laptop. Watch it with cyberwave edge status and cyberwave edge logs -f.

Open your environment. The twin should show an online presence indicator, with joint states or telemetry updating live as the real hardware moves. If it doesn’t, check cyberwave edge logs and confirm the driver isn’t exiting on a hardware-access error.

Done when: on a clean device, sudo cyberwave pair followed by selecting your twin pulls the image, the container starts, and the twin goes online. More on Edge Core: Cyberwave Edge.

Make it fail safely

Your driver must fail loudly and stop safely.

Exit non-zero when required hardware is missing (a missing /dev/video* device, a disconnected peripheral). Edge Core then raises driver_start_failure and applies its restart policy. run_driver_main exits with code 1 when the driver raises.
Stop on silence. If commands stop arriving mid-teleop, bring the robot to a safe state. Zenoh command channels support watchdog_ms with an on_command_timeout hook. For MQTT, implement the timeout in your driver.
Raise alerts operators can see: create_twin_alert(...) or AlertManager from the SDK (Alerts).
Calibration: a twin with can_actuate shows a Re-calibrate driver action in Live mode. Test it against your robot, and document any vendor calibration steps on the asset.

Done when: you cut the edge device’s network during teleop, the robot stops safely, and an alert appears on the twin. You are at L3.

Record data and train a policy

Dock your cameras to the robot as child twins with an asset kit. Edge Core passes child camera twins to the parent driver in CYBERWAVE_CHILD_TWIN_UUIDS.
Record teleop episodes and export them (LeRobot is one of the export formats).
Fine-tune a VLA and assign it with twin.policy.assign(...).

Worked example: SO-101 teleop dataset → Train a VLA. Done when: a policy trained on your robot’s data drives the robot. You are at L4.

Publish your robot

Give the asset (and kit) a clear description, bill of materials and troubleshooting notes. Then switch the asset’s visibility to Public. Public assets are visible to anyone on the platform. To be listed with a support level, or for closed-source driver distribution, contact Cyberwave or email info@cyberwave.com with your target level and the pass-test results. Done when: the asset is public and you’ve sent your level evidence to Cyberwave.

Use every platform feature

With an asset and a driver, your hardware behaves like any catalog device. The same MQTT topics and command surface drive everything below, with no extra integration:

Workflows

Chain perception, models, and motion into repeatable automations, low-code or in Python.

Replay & recording

Record episodes, scrub the timeline, and export datasets for training and review.

Teleoperation & remote takeover

Drive your hardware from anywhere and take over from an AI policy with one click.

Controllers & models

Assign keyboard, teleop, or trained AI policies as the controller for your twin.

Simulation

Validate behavior against the digital twin before it ever touches real hardware.

Digital twin

A live, synced virtual mirror of your hardware that the whole platform builds on.

Checklist

Copy this into your tracker.

- [ ] Target level, maintainer and licence decided
- [ ] URDF/xacro ZIP with meshes and relative paths; inertials and joint limits present
- [ ] cyberwave-robot-format: validate() clean, parse_context errors empty
- [ ] Asset created (private); slug noted
- [ ] L0: every joint moves correctly in the Playground
- [ ] Capabilities correct; UI shows the expected panels only
- [ ] Sensors declared; width/height match what the driver publishes
- [ ] Physics set; MuJoCo enabled on the asset
- [ ] L1: MuJoCo starts with the twin; pose holds
- [ ] Driver subclasses BaseROS2Driver or BaseDriver; publishes source_type=edge; ignores inbound edge*
- [ ] L2: live twin mirrors the robot
- [ ] cw-driver.yml / manifest.yaml lists only handled commands; set_schema applied
- [ ] Image built for every target platform and pushed
- [ ] metadata.drivers set on the asset (default + platform keys)
- [ ] Clean-device test: cyberwave pair -> image pulled -> twin online
- [ ] Non-zero exit on missing hardware
- [ ] Command-loss watchdog stops the robot; alert raised
- [ ] L3: network cut mid-teleop leaves the robot safe
- [ ] Kit with cameras docked
- [ ] L4: dataset recorded, policy trained and running as controller
- [ ] Visibility Public; description, BOM, troubleshooting
- [ ] Level evidence sent to Cyberwave

Next steps

Asset and driver spec

ZIP layout, upload fields, physics, driver config files and env vars.

Writing compatible drivers

Container contract, cw-driver.yml, MQTT catalog and sensor output.

UR Sim with a ROS 2 driver

A working BaseROS2Driver against a simulated UR arm.

Supported hardware

Robots that already have a driver.

Get started

Build with AI

Simulate & test

Connect hardware

Train & improve

Deploy & operate

Check if your robot is already supported

How it works

Support levels

What you need

Plan your integration

Prepare your URDF package

Start from the sample URDF

Sample URDF: dji-mini-4-pro.zip

Validate it locally

Create the asset

Spawn a twin and test the model

Declare capabilities and sensors

Make it simulate

Write the driver

Declare the interface

Register it on your twin

Package and run the driver

Make it fail safely

Record data and train a policy

Publish your robot

Use every platform feature

Workflows

Replay & recording

Teleoperation & remote takeover

Controllers & models

Simulation

Digital twin

Checklist

Next steps

Asset and driver spec

Writing compatible drivers

UR Sim with a ROS 2 driver

Supported hardware

​Check if your robot is already supported

​How it works

​Support levels

​What you need

​Plan your integration

​Prepare your URDF package

​Start from the sample URDF

Sample URDF: dji-mini-4-pro.zip

​Validate it locally

​Create the asset

​Spawn a twin and test the model

​Declare capabilities and sensors

​Make it simulate

​Write the driver

​Declare the interface

​Register it on your twin

​Package and run the driver

​Make it fail safely

​Record data and train a policy

​Publish your robot

​Use every platform feature

Workflows

Replay & recording

Teleoperation & remote takeover

Controllers & models

Simulation

Digital twin

​Checklist

​Next steps

Asset and driver spec

Writing compatible drivers

UR Sim with a ROS 2 driver

Supported hardware

Check if your robot is already supported

How it works

Support levels

What you need

Plan your integration

Prepare your URDF package

Start from the sample URDF

Validate it locally

Create the asset

Spawn a twin and test the model

Declare capabilities and sensors

Make it simulate

Write the driver

Declare the interface

Register it on your twin

Package and run the driver

Make it fail safely

Record data and train a policy

Publish your robot

Use every platform feature

Checklist

Next steps