MIPI, GMSL2, USB3 or 10GbE? Choosing the Camera Link for Multi-Camera Robots

A camera’s job is to move a lot of data with no errors and no delay. On a phone, the camera sits a few centimetres from the processor and a ribbon cable is enough. On a robot, the cameras are on the head, wrists and gripper while the computer is in the torso or a backpack — through moving joints, next to motors. The link you choose decides your bandwidth ceiling, your cable reliability, whether hardware synchronisation is possible, and how much driver work stands between you and a working rig.

Start with the arithmetic

Raw video bandwidth is width × height × bits per pixel × frames per second.

Stream	Format	30 fps	60 fps
1280×800 mono (OV9281-class)	RAW8	0.25 Gbps	0.49 Gbps
1600×1200 mono / colour (2 MP)	RAW10	0.58 Gbps	1.15 Gbps
1920×1200 colour (AR0234-class)	RAW10	0.69 Gbps	1.38 Gbps
1920×1080 colour	YUV422 (16 bit)	1.00 Gbps	1.99 Gbps

A typical egocentric headset — four 1280×800 tracking cameras at 60 fps plus two 1920×1200 RGB cameras — needs about 3.4 Gbps with RGB at 30 fps and 4.7 Gbps at 60 fps, before protocol overhead. Two points follow:

• Bayer RAW is far cheaper than YUV. RAW10 is 10 bits per pixel; YUV422 is 16. Sending YUV costs about 60% more bandwidth for the same image and has already been processed by an ISP you do not control.
• Storage scales the same way. 4.7 Gbps is roughly 2.1 TB per hour of raw capture. Plan recording, offload and retention around that number.

The options

Link	Reach	Practical bandwidth	Power over cable	Hardware trigger	Typical host	Driver effort
MIPI CSI-2	~10–30 cm	~1–2.5 Gbps per lane; 4–10 Gbps per 4-lane D-PHY port (SoC-dependent)	No	Separate wire	Jetson, Rockchip, Qualcomm, Raspberry Pi	Sensor driver per sensor
GMSL2	Up to ~15 m coax	~6 Gbps forward per link	Yes (power-over-coax)	Yes, forwarded over the link	Jetson (via deserializer boards), automotive SoCs	Sensor + serializer/deserializer configuration; NDA documentation
GMSL3	Up to ~15 m	~12 Gbps forward per link	Yes	Yes	Newer deserializers	As GMSL2; fewer off-the-shelf boards
FPD-Link III / IV (TI)	Up to ~15 m	~4 Gbps (III) / higher (IV)	Yes	Yes	Jetson, TI processors	Similar to GMSL
USB3 Gen 1 (UVC)	~3 m passive	~3 Gbps sustained, shared per controller	Yes (900 mA)	Rarely exposed	Anything	Lowest — UVC class drivers
10GbE (with PTP)	100 m (Cat6a)	~9.4 Gbps	With PoE (power budget limits)	Via PTP-scheduled exposure or separate trigger	PC, NIC on PCIe, some SoCs	Aggregator firmware + network stack

When to use what

MIPI CSI-2 — cameras next to the processor. Lowest latency and cost, but reach is measured in centimetres, and long flex cables invite signal-integrity problems. Ideal when a carrier board sits inside the headset or robot head and aggregates cameras locally.

GMSL2/3 — cameras far from the computer on a moving machine. One thin coax carries video, I²C control back to the sensor, power and the frame-sync trigger. This is why automotive and many robotics companies standardise on it. Two cautions from the field: coax and connectors must be specified for continuous flexing in joints and wearables, and each deserializer chip supports a fixed number of links (two for common parts such as the MAX9296, four for parts such as the MAX96712/96724). Multi-camera synchronisation across several deserializers requires a common sync source fed to all of them.

USB3 — prototypes and modest bandwidth. Fastest to get running. Bandwidth is shared per host controller, frames are timestamped on arrival unless the camera embeds metadata, and most UVC modules do not expose a trigger. Excellent for a bench rig or a two-camera stereo module; marginal for six raw streams.

10GbE — raw multi-camera transport from a wearable to a backpack. When a headset aggregates its cameras on a local board, a single Ethernet link carries everything raw with headroom, and PTP gives sub-microsecond clock alignment with the backpack computer. PoE can power the headset over the same cable if the power budget fits.

Converting MIPI cameras to GMSL

Teams that buy GMSL cameras from a single supplier often ask whether they can convert their own MIPI modules. The answer is yes, but the cost is in engineering, not parts:

1. Serializer board behind each camera (e.g. MAX96717 class), small enough for the housing, with power-over-coax filtering and a connector rated for flex.
2. Deserializer board at the host (two- or four-channel), unless an existing board is reused.
3. Linux driver: device tree, sensor mode tables, serializer and deserializer register configuration, I²C passthrough, multi-camera enumeration and trigger routing — validated per sensor.
4. Validation: hours of continuous streaming with zero dropped frames, cable flex cycles, thermal and EMC testing.

Detailed register documentation for GMSL parts sits behind the chip vendor’s NDA, which is one reason few companies build GMSL cameras. Partners who have already completed GMSL2 bring-up on Jetson can shorten this from months to weeks.

A decision rule

• Cameras within 30 cm and total bandwidth inside the SoC’s CSI capacity → MIPI on a local carrier board.
• Cameras spread across a robot, up to 15 m, with power and trigger needed → GMSL2.
• Bench prototype or two-camera module → USB3.
• Wearable sending four to eight raw streams to a backpack → local aggregation + 10GbE with PTP.

Whatever you choose, write the bandwidth calculation and the timing requirement into the vendor specification before the first sample. See Timing Is the Spec for the timing side.