RVC4 updates?

xperroni

I'm working on a mobile robotics project that's inching towards production. Some of our partners have expressed concerns about the long-term viability of the OAK platform: we know the RVC2 cameras will be available until 2030, but already there are some recent AI model we cannot use due to OpenVINO dropping Myriad X support and the lack of an alternative architecture. This is only to get worse as the AI ecosystem moves on.

I subscribed to the RVC4 newsletter last year, but have yet to receive any issues — if this was simply a delivery problem, it would be nice to have a page where we could read past issues. We would also like to know whether we'll still be using OpenVINO for the AI models (and if not, what will take its place), and whether / when the new RVC4 cameras will be available for pre-order.

erik

Hi @xperroni ,
We should have further information (public release) in May. It will not use OpenVINO, but we can't yet say the framework (as it correlates with chip used in rvc4).

Hector

Hi @erik,

Any updates on this since there was no public release, and when can we get early access to the dev board like FFC-4P?

Thanks

erik

Hi @Hector ,
Some new cameras will be released in Q4 this year, but nothing similar to FFC lineup yet. We don't have any timelines for those unfortunately.
Thanks, Erik

MasonHensley

@eric-soderberg - still trending to Q4? Saw some of the public documentation - looks great, would fit some use cases my customers have better than the existing Oak1's. Also, happy to give beta feedback 🤓

jakaskerl

Hi @MasonHensley
Look out for next week 🙂

Thanks,
Jaka

xperroni

Having read through the description of the first RVC4 cameras available for pre-order, I must confess to being rather disappointed.

I was hoping for an upgrade that would support models built with newer ONNX operators and maybe increase computing capacity a bit, while mostly keeping the form factor, connectivity and workflow of the RVC2 devices. My ideal upgrade would have been an OAK-D Pro W that loaded models in ONNX format and exposed an API for writing custom shave kernels.

Instead what we got is a much bulkier, costly, and frankly bloated line of devices, that I imagine will require an extra power inlet for most USB-based setups (it certainly will for mine). Having a fully flashed SBC crammed into the camera might seem good on paper, but in practice it will require a lot of architecture changes to make it worth the added cost, or even a viable option in terms of mechanics and power delivery.

I sure hope that wee see a "lite" series of upgraded OAK devices in the near term that is more like the RVC2 line in terms of features and cost. Otherwise I might have no choice but to look for alternatives from other vendors in the next few years — perhaps even going so far as do without in-device processing.

erik

@xperroni it's definately not for every application, and we completely understand that. It can consume up to 25W, so it requires POE+, and in most cases it won't be a peripheral device. That doesn't mean it's not usable though, there are many applications where you need huge compute capabilities and perhaps want to run it at standalone mode (no computer), so added SBC is required.

We are going to release similar form factor / power consumption / price point devices as well, just not yet (perhaps in late 2025), as we are still deciding on the SoC to use.

That said, what's the reason for wanting to upgrade from RVC2 line?

xperroni

erik I was hoping to be able to write custom nodes to run in the camera using OpenCV (or an OpenCV-like API), instead of using the ImageManip and Script nodes, which never seem to quite be enough. I've also grown frustrated with how hard it's become to load the OAK's with any model not already present in the DepthAI Model ZOO. Many recent PyTorch models when converted to ONNX incorporate operators not supported in versions of OpenVINO prior to 2023.0, which dropped the MyriadX backend. I suppose it's not impossible to back-port those models, but it's a huge inconvenience, especially when compared to other platforms such as TensorRT which most often enjoy out-of-the-box support.

erik

@xperroni I see, yes Intel dropped support for VPUs quite some time ago, so we can't support newer versions of openvino. That said, can't you specify onnx operation version when exporting (like here)?