// Camera Interface Selection

Cameras for Jetson Edge AI: CSI vs USB vs GMSL vs IP/RTSP (2026)

Last updated: August 2026

Every sizing guide obsesses over the compute and forgets the input. But the camera interface decides your latency, how far the camera can sit from the board, how many you can run, and your cost per node. Here's how to pick between MIPI CSI-2, USB, GMSL, and IP/RTSP — and the JetPack 6 CSI gotcha that catches everyone.

CSI = lowest latency

GMSL = long cable runs

IP/RTSP = multi-camera NVR

USB = fastest to prototype

Quick Answer

Match the interface to distance and camera count: MIPI CSI-2 for lowest-latency, close-coupled single or dual sensors; USB/UVC for plug-and-play prototyping; GMSL when the camera sits meters away or in a rugged environment; IP/RTSP for multi-camera surveillance where each camera has its own power and network drop. Robotics and embedded single-sensor builds lean CSI or GMSL; building-scale NVR deployments almost always end up on IP cameras the Jetson decodes in hardware. And on JetPack 6.2+, a CSI camera no longer works on plug-in — you must enable the connector with jetson-io first.

Planning Takeaway

The interface is a distance-and-count decision before it's an image-quality decision. CSI gives you the tightest sensor-to-inference latency but only over short ribbon cables and a couple of connectors. GMSL buys you meters of reach and ruggedness at the cost of serializer/deserializer hardware. IP/RTSP scales to many cameras over standard network cabling but adds encode/decode latency and a network dependency. USB is the prototyping shortcut. Pick for your physical layout first, then optimize image quality within that interface.

Who This Page Is For

Builders speccing the camera side of a Jetson deployment who've sized the compute but not the input.
Robotics and embedded engineers deciding between CSI and GMSL for sensors that may sit far from the board.
NVR and surveillance integrators confirming IP/RTSP is the right path for many cameras.
Anyone stuck on a CSI camera that won't appear on JetPack 6 and needs the configuration step nobody mentioned.

How to Use This Page

Start with physical layout. How far is each camera from the compute, and how many are there? That mostly decides the interface.
Set your latency requirement. Tight sensor-to-action loops (robotics) favor CSI/GMSL; surveillance tolerates IP-camera latency.
Check the module's connectors. Orin Nano dev kit has two CSI ports; AGX Orin dev kit does not expose standard CSI — plan a carrier or GMSL board for high counts.
Account for decode load. IP cameras stream compressed video the Jetson must decode — that's a real budget, separate from inference.
Validate with tools. Feed camera count, resolution, and codec into the System Designer and Network Bandwidth tool to confirm the host can keep up.

Why the Interface Decides So Much

Camera selection has three axes — sensor, interface, and optics — but for a Jetson build the interface is the one that constrains your whole architecture. It sets how far the camera can be from the compute, how deterministic your latency is, how many cameras you can attach, whether the host has to spend cycles decoding compressed video, and your cost per camera node. A beautiful 4K sensor on the wrong interface for your physical layout is the wrong camera.

The four interfaces split cleanly by use case. CSI and GMSL are point-to-point sensor interfaces — the Jetson talks more or less directly to the image sensor, with the lowest latency and full control, over short (CSI) or long (GMSL) cabling. USB is the convenience interface for getting any webcam working fast. IP/RTSP is the network interface that scales to many cameras over standard cabling but hands you compressed streams to decode. Get this axis right and the rest of the camera spec is detail.

Interface Comparison Table

Interface	Latency	Cable reach	Camera count	Best for
MIPI CSI-2	Lowest	Short (ribbon, ~tens of cm)	1–2 (dev kit); more via carrier	Embedded single/dual sensor, robotics
USB / UVC	Higher, less deterministic	Short (~3–5 m)	Few (shared bus)	Prototyping, single webcam
GMSL	Low (near-CSI)	Long (multiple meters)	Several (via deserializer)	Automotive, rugged, remote sensors
IP / RTSP	Highest (encode + network + decode)	Very long (network)	Many	Multi-camera NVR / surveillance

MIPI CSI-2

CSI-2 is the embedded default: the Jetson talks to the sensor over a short MIPI ribbon, giving the lowest, most deterministic latency and full access to the camera's ISP, exposure, and gain controls. The Orin Nano Developer Kit exposes two 22-pin CSI-2 connectors (note: a wider 22-pin standard than the older 15-pin Raspberry Pi connector, so an adapter cable is needed for RPi cameras), with built-in driver support for common sensors like the IMX219 and IMX477. Higher-end camera partners ship CSI modules doing 4K at high frame rates.

The constraints are physical: ribbon cables are short and not robust, and the dev-kit connector count is low. For more cameras or longer runs you move to a production carrier board or to GMSL. CSI is the right call for a robot, a smart camera, or any build where the sensor sits right next to the compute and latency matters.

USB / UVC

A UVC-compliant USB camera is the fastest way to get pixels into a pipeline — plug it in, it enumerates as a V4L2 device, done. It's ideal for prototyping, demos, and single-camera projects where you want an off-the-shelf webcam and don't want to think about ribbon cables or device-tree overlays. The Jetson's camera APIs (in projects like jetson-inference) stream USB sources alongside CSI and RTSP.

The trade-offs show up at scale and in timing. USB latency is higher and less deterministic than CSI, the bus bandwidth is shared when you attach several cameras, and you get fewer low-level sensor controls. For a single prototype camera, USB is perfect; for a latency-critical robot or a multi-camera deployment, it's usually the wrong long-term choice.

GMSL

GMSL (Gigabit Multimedia Serial Link) solves CSI's distance problem. It serializes the camera data over a single coax or shielded twisted-pair cable — carrying power too — for runs of several meters, while preserving low-latency, near-direct sensor access. It's the interface of choice for automotive, robotics, and industrial deployments where the camera is mounted far from the compute or in a vibration-prone, rugged environment that ribbon cables can't survive.

The cost is design complexity: GMSL needs a serializer at the camera and a deserializer on a compatible carrier board, and the deserializer can aggregate several cameras into the Jetson's CSI lanes (often using virtual channels). That's more engineering and more BOM than a plug-in CSI ribbon, so GMSL is a deliberate choice for builds that genuinely need the reach and durability — not a default.

IP / RTSP

For multi-camera surveillance, IP cameras streaming RTSP are the standard. Each camera has its own power (typically PoE) and network connection, runs over ordinary structured cabling for arbitrary distances, and sends a compressed H.264 or H.265 stream that the Jetson decodes in hardware. This is how you put dozens of cameras around a building and feed them all into one edge node — the model the site's NVR and reference-architecture content is built around.

The trade-off is latency and load. You're adding camera-side encoding, network transit, and host-side decoding to the path, so end-to-end latency is the highest of the four interfaces — fine for surveillance, often not for a tight control loop. And the decode itself is a real resource budget: the number of streams the Jetson's hardware decoder can handle is a ceiling independent of inference. Size that decode load explicitly with the Network Bandwidth and System Designer tools when you plan an IP-camera deployment.

The JetPack 6 CSI Gotcha

One specific trap wastes a lot of time. On JetPack versions before 6.2, connecting a supported CSI camera (e.g. a Raspberry Pi / IMX219 module) was plug-and-play — the camera just appeared. On JetPack 6.2 and later, that changed. You now have to configure the CSI connector first using the jetson-io utility, which applies the correct device-tree overlay, and then reboot before the Jetson will recognize the camera. The sensor driver is built in; the connector still has to be explicitly enabled.

If you've upgraded to JetPack 6 — now the legacy line; JetPack 7.2 is current as of mid-2026 — and your CSI camera "stopped working," this is almost always why. Two related notes: USB-camera commands sometimes need elevated permissions (a udev rule or group change fixes running without sudo), and the AGX Orin Developer Kit doesn't expose a standard CSI port the way the Orin Nano does — high-CSI-count designs use a custom carrier or GMSL board rather than the dev-kit connectors.

Decision Framework

Choose MIPI CSI-2 if:

The camera sits close to the board and latency must be minimal
You need direct sensor/ISP control (exposure, gain, global shutter)
One or two co-located sensors cover the build (robot, smart camera)

Choose USB / UVC if:

You're prototyping or building a single-camera project
You want an off-the-shelf webcam working in minutes
Deterministic low latency isn't critical

Choose GMSL if:

The camera must sit several meters from the compute
The environment is rugged, automotive, or vibration-prone
You need low latency over long cable and can build serializer/deserializer hardware

Choose IP / RTSP if:

You're deploying many cameras across a building or site
Each camera needs its own power and network run over long distances
Surveillance-grade latency is acceptable and you've budgeted decode load

Frequently Asked Questions

Which camera interface is best for Jetson edge AI?

It depends on distance and camera count. Use MIPI CSI-2 for the lowest latency and direct sensor access when the camera is close to the board, USB/UVC for plug-and-play prototyping and a single off-the-shelf webcam, GMSL when the camera must sit meters away from the compute or in a rugged environment, and IP/RTSP cameras for multi-camera surveillance where each camera has its own power and network drop. Most production camera-AI deployments with many cameras end up on IP/RTSP; embedded single-sensor and robotics builds favor CSI or GMSL.

How many CSI cameras can a Jetson Orin Nano take?

The Jetson Orin Nano Developer Kit has two 22-pin MIPI CSI-2 connectors, so two CSI cameras natively. Production carrier boards and GMSL deserializers can expose more lanes and aggregate additional cameras. Note that the AGX Orin Developer Kit does not expose a standard CSI port the way the Orin Nano does, so high-camera-count CSI designs typically use a custom carrier or a GMSL aggregation board rather than the dev-kit connectors.

Do I need to configure anything to use a CSI camera on JetPack 6?

Yes, and this trips people up. On JetPack 6.2 and later, simply plugging in a supported Raspberry Pi camera is no longer enough — you must configure the CSI connector first using the jetson-io utility to apply the correct device-tree overlay, then reboot. The Orin Nano has built-in driver support for sensors like the IMX219 and IMX477, but the connector still has to be enabled. This is a change from JetPack 5, where the camera worked on plug-in.

Are USB cameras good enough for edge AI?

For prototyping and single-camera projects, yes — a UVC-compliant USB webcam works out of the box via V4L2 and is the fastest way to get pixels into a pipeline. The trade-offs are higher and less deterministic latency than CSI, USB bandwidth shared across the bus when you attach several, and fewer sensor controls. For a robot needing tight sensor-to-inference timing, or a multi-camera build, CSI, GMSL, or IP cameras are usually better.

When should I use GMSL cameras with Jetson?

Use GMSL when the camera must be physically far from the compute — several meters of cable — or deployed in a rugged, vibration-prone, or automotive environment. GMSL serializes the camera data over a single coax or STP cable with power, supporting long runs that CSI ribbon cables cannot, while preserving low-latency sensor access. It needs a serializer at the camera and a deserializer on a compatible carrier board, so it is a more involved and costlier design than plugging in a CSI ribbon.

Should a multi-camera NVR use IP cameras or CSI?

For a multi-camera NVR, IP/RTSP cameras are almost always the right choice. Each camera has its own PoE power and network connection, runs over standard cabling for long distances, and streams compressed H.264/H.265 that the Jetson decodes in hardware. CSI and GMSL are point-to-point sensor interfaces better suited to embedded and robotics builds with a few co-located cameras, not a building full of them. The trade-off with IP cameras is added encode/decode latency and dependence on the network.

The Bottom Line

Pick the camera interface for your physical layout before you fuss over the sensor. CSI-2 gives the lowest latency and direct sensor control over short ribbon runs — ideal for robotics and embedded single-sensor builds. GMSL extends that to meters and ruggedness at the cost of serializer/deserializer hardware. USB is the prototyping shortcut. And IP/RTSP is the standard for multi-camera surveillance, scaling over network cabling at the price of added latency and a hardware-decode budget you must size. Whatever you choose on JetPack 6, remember to enable the CSI connector with jetson-io first — that one step saves an afternoon.

Size your camera count, resolution, and codec against the module's decode and compute headroom with the tools below before ordering hardware.