RK3588 vs Jetson Orin: Which for Multi-Camera Vision and AMR?

The question usually arrives as a TOPS comparison. Someone has an RK3588 board quoted at 32 TOPS and a Jetson Orin NX at 157, and wants to know whether the extra compute is worth the price difference.

It’s the wrong place to start. On the multi-camera vision and AMR projects we quote, TOPS is rarely the constraint that decides the platform. Camera ingress, the software toolchain, and the power budget decide it first — and by the time those three are settled, the compute question has usually answered itself.

First, what the numbers actually mean

RK3588’s onboard NPU is 6 TOPS. That figure doesn’t change between vendors, because it’s the SoC.

When you see an RK3588 product quoted at 32 or 58 TOPS, the additional compute is coming from an M.2 accelerator module, not the SoC. Our own line is explicit about this: the AE-3588LBT is 6 TOPS onboard + 26 TOPS expansion, and the AE-3588BT is 6 onboard + 52 expansion.

That matters more than the arithmetic suggests. You end up with two compute engines, two memory spaces, and two toolchains in one box. Splitting a pipeline across them — decode on the SoC, inference on the accelerator — is a real engineering task, and the models you can run are constrained by what the accelerator’s compiler supports.

Jetson Orin NX Super 16GB, the module in our AE-NJ60BT, delivers 157 TOPS from one device: CUDA cores, Tensor Cores and the ARM CPU sharing a unified memory space and one toolchain. Nothing has to be split.

So the honest comparison isn’t 32 vs 157. It’s 6 TOPS plus an accelerator you have to integrate versus 157 TOPS you address as one device.

Camera ingress decides more than compute

This is where most multi-camera projects are actually won or lost.

RK3588 takes cameras over MIPI CSI and USB. MIPI is a board-level interface — practical cable lengths are measured in centimetres, and it’s sensitive to noise. USB cameras solve the distance problem but bring host-controller bandwidth limits and non-deterministic timing, which is a problem if you need frames from four cameras aligned.

Jetson Orin, on our AE-NJ60BT, takes 4-lane MIPI CSI or 4× GMSL2. GMSL2 runs high-bandwidth video over a single coax at up to roughly 15 metres, carries power on the same cable, is designed for the EMI conditions of a vehicle, and keeps capture deterministic across channels.

Now apply that to a real AMR. The cameras aren’t next to the compute box — there’s one at each corner, maybe one on the mast, and the cable runs cross a chassis full of motor drives and switching supplies. That’s a GMSL2 problem. Trying to solve it with MIPI extenders or a USB hub is where AMR projects lose months.

An AOI cell is different. One or two cameras, mounted a metre away, in a fixed cell with a controlled ground. MIPI or USB is fine there, and paying for GMSL2 ingress you’ll never use is just cost.

Count your cameras and measure the cable runs before you compare TOPS. If you want the full interface trade-off, we’ve written it up separately in GMSL2 vs GigE Vision.

The toolchain is the cost nobody quotes

RK3588 runs Linux or Android with the RKNN Toolkit, plus ROS2 and OpenCV. It works. You bring an ONNX model, convert it, quantise it to INT8, and validate that the quantised model still hits your accuracy target. For one stable model that you’re not going to change often, this is a perfectly reasonable — and cheaper — path.

Jetson runs JetPack: CUDA, TensorRT, DeepStream and Isaac ROS. The practical difference isn’t raw speed. It’s that if your perception team already works in PyTorch and your navigation stack is ROS2, most of that ports with far less work. DeepStream in particular handles the multi-stream decode-and-inference pipeline that you would otherwise write and debug yourself, which on a four-camera system is not a small job.

The question to ask your software team isn’t “can it run our model.” It’s “how many times will we change the model?” A team iterating on models monthly will spend more on RKNN conversion and validation cycles than they saved on the hardware. A team shipping one frozen model will not.

There’s a lifecycle dimension too: RK3588 platforms are Linux and Android only, so anything requiring Windows is out of the conversation entirely.

Power and thermal — where AMR projects get decided

RK3588 runs at 8–25 W and our RK3588 boxes are fanless from −40°C to +80°C. Jetson Orin runs at 15–60 W, and the AE-NJ60BT is fanless from −40°C to +70°C.

Both are fanless, which is what matters in a dusty plant. The difference shows up on battery. An AMR carrying a 40 W perception load instead of a 15 W one is giving up runtime between charges, and on a fleet running three shifts, that changes the charging schedule and possibly the fleet size. Work out the watt-hours before you assume the extra compute is free.

The +80°C figure on the RK3588 boxes is also worth noting if your enclosure sits near an oven, a laser, or a sealed cabinet in the sun.

I/O and isolation are board decisions, not silicon decisions

A distinction worth being clear about, because it comes up constantly in RFQs: isolation has nothing to do with which SoC you pick.

Our AE-3588BT provides 4000V isolated CAN, RS-232/RS-485 and GPIO because it’s built for energy and semiconductor plants. The AE-3588LBT uses non-isolated, low-latency fieldbus I/O because it’s aimed at AOI and AGV work where the ground is controlled and latency matters more. Same silicon, opposite I/O philosophy. The AE-NJ60BT carries 4× GbE and 2× CAN FD.

So don’t pick Jetson because “it has better I/O,” or RK3588 because “it has isolated CAN.” Pick the silicon for the compute and camera requirements, then specify the I/O separately. If you’re unsure which lines need isolation, that’s a separate question we’ve covered in isolated vs non-isolated I/O.

The four cases we actually see

Where teams get this wrong

• Buying TOPS. If your bottleneck is camera decode, image preprocessing, or memory bandwidth, a bigger inference number changes nothing. Profile the pipeline before you size the compute.
• Treating expansion TOPS as equivalent to onboard TOPS. They’re not interchangeable — different toolchain, different memory, different model support. Read the split.
• Choosing silicon before counting cameras. Camera count, interface and cable length constrain the platform harder than the model does.
• Forgetting the lifecycle question. A perception platform that goes end-of-life mid-programme costs far more than the price difference you were optimising. Ask for the availability commitment in writing — ours is 10 years with BOM control.

The short version

If cameras are distributed around a moving chassis and your team lives in ROS2 and PyTorch, the Jetson AE-NJ60BT is the platform, and the 157 TOPS is a bonus rather than the reason.

If the camera count is low, the model is stable, and unit cost across a fleet is the pressure you’re under, RK3588 is the right answer — the AE-3588LBT where latency rules, the AE-3588BT where the plant is electrically hostile.

If you’re still between them, the fastest way through is to send us the camera count, interface, resolution and framerate, your model and framework, and the power and temperature limits. Our engineers will tell you which platform the requirements actually point to — including when the answer is the cheaper one.