# Going from RVC2 to RVC4

Moving from an [RVC2](https://docs.luxonis.com/hardware/platform/rvc/rvc2.md) device to an
[RVC4](https://docs.luxonis.com/hardware/platform/rvc/rvc4.md) device is usually a four-part migration:

 * Move your application to DepthAI v3.
 * Handle the remaining RVC2 vs RVC4 hardware differences in code.
 * Re-export AI models for RVC4, or switch to a different model when needed.
 * Change how you run and manage the application on RVC4.

The first step is the important one. [RVC2](https://docs.luxonis.com/hardware/platform/rvc/rvc2.md) platforms can run both DepthAI
v2 and DepthAI v3, while [RVC4](https://docs.luxonis.com/hardware/platform/rvc/rvc4.md) platforms run only DepthAI v3. In
practice, that means your first milestone is not "make it run on RVC4", but "make it run on DepthAI v3".

Once your code runs on DepthAI v3, you can usually keep most of the same codebase for both RVC2 and RVC4. The remaining work is
typically limited to a few platform-specific code paths, re-exporting AI models for RVC4 if your application uses AI, and updating
how the application is deployed and managed on the device.

If your current RVC2 project still uses DepthAI v2, start with the [DepthAI V3 Porting
Guide](https://docs.luxonis.com/software-v3/depthai/tutorials/v2-vs-v3.md).

That guide covers the API changes in detail, including:

 * removal of explicit XLink nodes
 * moving from `dai.Device(pipeline)` style startup to `pipeline.start()`
 * queue creation changes
 * migrating older camera usage toward the newer `Camera` node workflow

> **Practical shortcut**
> If you want the fastest path, ask an AI coding agent to port your project using the [porting guide](https://docs.luxonis.com/software-v3/depthai/tutorials/v2-vs-v3.md) and current [`oak-examples`](https://github.com/luxonis/oak-examples) DepthAI v3 examples as reference. If you are porting with an AI coding agent, [Luxonis Agent Skills](https://docs.luxonis.com/software-v3/agent-tools/agent-skills.md) can speed up device connection, setup, and troubleshooting while you validate the migration on real hardware.

Example prompt:

```text
Port the attached Python script from DepthAI v2 to DepthAI v3.

    This should be a proper v3 rewrite of gen2-blur-faces/main.py, not a line-by-line API
    translation. Preserve the script's functionality, but adopt idiomatic DepthAI v3
    patterns wherever appropriate.
    
    Requirements:
     - Use the official migration guide: https://docs.luxonis.com/software-v3/depthai/tutorials/v2-vs-v3/
     - Find the closest matching example in the main branch of https://github.com/luxonis/oak-examples and use it as the architectural starting point.
     - Rebuild the implementation from that example while preserving the original script's behavior.
     - Replace v2 concepts with their v3 equivalents instead of keeping the old structure.
     - Do not invent APIs—use only current DepthAI v3 APIs.
     - Keep all original functionality unless a change is required by v3, and explain any intentional differences.

    In your response:
     - Briefly explain which oak-examples example you chose and why.
     - Summarize the main v2 → v3 architectural changes.
     - Provide the complete rewritten v3 script.
     - Mention any assumptions or limitations.
      
    Try your run with the connected camera and by running main.py from host till you get the expected result
```

Before moving on, it is worth verifying that the new DepthAI v3 code still works on your existing RVC2 device. That gives you a
stable baseline before you change the hardware platform.

Once the application runs on DepthAI v3, the migration is usually down to a few targeted platform checks. DepthAI v3 gives you one
API, but RVC2 and RVC4 still differ in hardware behavior, so you may need to choose different frame types, model variants, or
optional features per platform.

A practical pattern is to detect the platform once and keep those platform-specific choices together:

```python
device = dai.Device()
platform = device.getPlatformAsString()

frame_type = (
    dai.ImgFrame.Type.BGR888i if platform == "RVC4" else dai.ImgFrame.Type.BGR888p
)

model_description = dai.NNModelDescription(args.model, platform=platform)
```

For a practical reference on RVC2-to-RVC4 code changes, use the [`oak-examples`
repository](https://github.com/luxonis/oak-examples). Most current examples support both RVC2 and RVC4 and show the required
platform checks in context.

A good starting point is the `generic-example` in `oak-examples`, because it:

 * detects the platform at startup
 * selects the matching model description
 * switches the replay input frame type between `BGR888p` on RVC2 and `BGR888i` on RVC4

If your application does not use neural networks, you can skip this step. If it does, plan on generating new model artifacts for
RVC4. Existing RVC2 `.blob` and `superblob` outputs are not portable to RVC4 as-is, because RVC4 uses a different conversion
pipeline and runtime stack.

In the simplest case, you keep the same source model and export a new RVC4-ready artifact from it. In more involved cases, moving
to RVC4 is a good time to re-evaluate your model choices, because the extra performance headroom can make newer, larger, or
otherwise better-fitting models practical. This is especially true when a legacy model depends on unsupported ops, needs different
preprocessing, or is no longer the best fit for the workflow you want.

If the model is already in Hub AI, you can convert it directly there. If it is not in Hub AI yet, first [upload the
model](https://docs.luxonis.com/cloud/hubai/model-registry/upload-download.md) and then follow the same conversion flow.

#### 1.Open the model variant

In [Hub AI](https://hub.luxonis.com/ai), open [Models](https://hub.luxonis.com/ai/models), select the model you want to reuse,
scroll to Model Variants, and click Convert next to the variant you want to export.

#### 2.Choose the target platform

Select the target `RVC` platform. The available targets depend on the uploaded base model format. In practice, `ONNX`-based model
sources offer the broadest conversion support across platforms.

#### 3.Configure the conversion form

Review the prefilled values and adjust only what needs to change. If the base model is a raw `ONNX` file, enter the source-model
input settings manually. If the base model is an `ONNX` NN Archive, use its `config.json` as the source of truth and override
values only if the archive metadata is incorrect.

Use the reference sections below for the exact meaning of each field.

#### 4.Export and confirm the result

Click Export to start the conversion. The new model instance first appears as Pending and changes to Success when the converted
artifact is ready. Once it finishes, you can download the archive or reference it directly from DepthAI.

For a full upload-and-convert walkthrough, see this [custom ONNX model video](https://www.youtube.com/watch?v=S4X-CoeINk0). If you
are working with a custom YOLO model, see this [custom YOLO conversion video](https://www.youtube.com/watch?v=LE_yNvDF4jA).

For the full workflow, troubleshooting and platform-specific conversion settings, see [Detailed
Conversion](https://docs.luxonis.com/cloud/hubai/model-registry/detailed-conversion.md).

The other important shift is that RVC4 supports both peripheral and standalone workflows.

 * Peripheral mode means a host computer connects to the device, uploads the pipeline or app assets, and controls execution from
   the outside.
 * Standalone mode means the device runs the application on its own and can start it automatically on boot, without depending on a
   host computer to launch it.

### Standalone vs Peripheral

| Compatibility | Standalone¹ | Peripheral² |
| --- | --- | --- |
| RVC4 | ✅ | ✅ |
| RVC2 | 🚫 | ✅ |

 1. Standalone: The App is run only on the camera. Apps are deployed via
    [oakctl](https://docs.luxonis.com/software-v3/oak-apps/oakctl.md).
 2. Peripheral: The App runs on the camera, but the host computer remains connected to it over a TCP socket.

For users coming from RVC2, the familiar workflow is usually peripheral mode. That is still possible on RVC4, but RVC4 also gives
you a strong standalone option because the device itself runs Linux and can manage applications directly.

This is one of the biggest practical benefits of the move to RVC4:

 * Use peripheral mode when the device is part of a larger host-driven system.
 * Use standalone mode when you want the device to behave more like an independent edge computer.

Peripheral mode

Peripheral mode has basically not changed since RVC2. You still run the application from the host machine and keep the device
connected while the host controls execution.

#### Python

```bash
# Navigate to the project root folder and then
python3 -m venv venv  # only for Linux / MacOS
source venv/bin/activate
pip install -r requirements.txt
python3 main.py
```

#### C++

```bash
cmake -S . -B build
cmake --build build
./build/<your-binary-name>
```

If your existing RVC2 C++ project already uses a different host-side build system, you can usually keep that same flow on RVC4 in
peripheral mode.

Standalone mode

Standalone mode is the big new RVC4 option. The device runs the application itself, so you package it as an OAK App and deploy it
with `oakctl`.

For standalone apps, you need to set up the app filesystem and `oakapp.toml` before running `oakctl app run`. For a minimal
example, see the [template app](https://docs.luxonis.com/software-v3/template.md).

```bash
# Navigate to the project root folder and then
oakctl app run .
```

The deploy command is the same for Python and C++ standalone apps. What changes is the app filesystem contents and the build steps
you define in `oakapp.toml`.

For a deeper explanation, see the [Standalone mode
tutorial](https://docs.luxonis.com/software-v3/depthai/tutorials/standalone.md).

What changes noticeably is how you operate the device. On RVC2, many workflows are centered around a host machine connecting to
the camera, uploading the pipeline, and controlling execution from the host side. On RVC4, controlling and running applications
should primarily be done with [`oakctl`](https://docs.luxonis.com/software-v3/oak-apps/oakctl.md).

Minimal command flow:

```bash
oakctl list
oakctl connect
oakctl app run /path/to/app
oakctl app list
oakctl app logs <app-id>
```

What those commands do:

 * `oakctl list` finds available OAK4 devices on your network.
 * `oakctl connect` opens a session to the device when you want to target it directly.
 * `oakctl app run /path/to/app` builds, uploads, and starts an OAK App on the device.
 * `oakctl app list` shows installed apps and their state.
 * `oakctl app logs <app-id>` lets you inspect runtime output and debug issues.

For the full command set, installation details, and packaging expectations, see the [`oakctl`
documentation](https://docs.luxonis.com/software-v3/oak-apps/oakctl.md).

At this point, you should now have:

 * a DepthAI v3 version of your application
 * a clear understanding of how peripheral and standalone workflows differ on RVC4
 * a concrete starting point for running the app either from the host or through `oakctl`

From here, choose the path that matches what you want to do next:

 * If you want to move into device-managed deployment, [set up your device with Luxonis
   Hub](https://docs.luxonis.com/cloud/hub/connect-oak.md), build out the app filesystem with the [template
   app](https://docs.luxonis.com/software-v3/template.md), refine the package with [`oakapp.toml`
   configuration](https://docs.luxonis.com/software-v3/oak-apps/configuration.md), and then [publish your
   app](https://docs.luxonis.com/cloud/features/application-management/uploading-applications.md) so it is ready for workspace
   deployment.
 * If you want to keep the familiar host-driven workflow, use the [DepthAI v3
   examples](https://docs.luxonis.com/software-v3/depthai/examples.md) to validate your migrated app behavior on RVC4 in
   peripheral mode.