Multiple cameras ROS launch: plan acquisition and synchronization

Launching several cameras is not just a matter of repeating a node in a launch file. Each stream needs a stable device binding, an independent configuration, and a defined relationship to the other streams. Shared bandwidth and inconsistent timestamps can break an otherwise correct launch.

This guide is for teams building a multi-camera acquisition pipeline in ROS 2. You will define device identities, organize launch behavior, calculate transport requirements, and verify timing and calibration before increasing camera count. For the underlying driver choices, start with ROS camera integration options.

1. Confirm the supported acquisition path first

A launch file coordinates software that already supports the required operation. It cannot add multi-device capability to an acquisition library that permits only one device or one process.

Record the camera interface, operating system, ROS distribution, acquisition library version, and wrapper version. Obtain software and documentation from the manufacturer or its authorized distributors. Check the documented restrictions for simultaneous devices, process ownership, triggering, and timestamp sources.

Distinguish these deployment options before writing the launch configuration:

Process separation may contain a crash, but it does not remove a library restriction or shared hardware bottleneck. The multi-camera acquisition session architecture guide explains how device ownership and session structure affect this decision.

2. Separate device identity from ROS identity

You need three distinct identifiers for each camera: the physical device selector, its ROS namespace, and its coordinate frame names.

Use a documented persistent selector, such as a serial number, rather than enumeration order. A device that appears first after one restart may appear second after the next. For network cameras, verify how discovery and addressing interact with the driver's persistent selector.

A useful configuration record looks like this:

These are configuration concepts, not universal driver parameter names. Map them to the wrapper's documented parameters and confirm the resolved values at runtime.

Namespaces separate topics, services, and parameters, but they do not automatically make frame identifiers unique. Give every optical frame a distinct name and publish its measured relationship to the rig frame. In the TF tree, each child frame should have one parent and one authoritative transform publisher.

If the operating system assigns changing device paths, use the checks in preventing device-path conflicts with multiple USB cameras. Topic remapping alone cannot correct a driver that opened the wrong physical device.

3. Make launch sequencing observable

Build the launch description from a per-camera configuration list. Avoid copying large configuration blocks that gradually acquire inconsistent exposure, image format, or calibration settings.

Use the same commissioning sequence for every device:

1. Start one driver with explicit device selection and its own namespace.
2. Confirm the opened device identity through a documented diagnostic or startup record.
3. Verify the active image dimensions, pixel format, exposure mode, and timestamp source.
4. Confirm image and calibration messages use the intended frame identifier.
5. Add the next device and repeat the checks before enabling downstream processing.

A staged startup can help diagnose discovery or initialization contention. However, a fixed delay is not a readiness check. Prefer a documented device-ready condition, lifecycle state, or health signal where the driver provides one.

Check camera discovery startup contention if simultaneous startup fails but sequential startup succeeds. Do not treat staggering as proof that the full system is stable.

Define shutdown ownership too. Stop dependent consumers, stop acquisition, and release device handles through the driver's documented path. Recovery should not leave a second process competing for a camera that the original process still owns.

4. Budget bandwidth at every shared link

Calculate payload from the transmitted image format, not just the sensor's advertised resolution. Packed monochrome, unpacked monochrome, and color images can have substantially different byte counts.

For an illustrative workload, assume four cameras each transmit 1920 × 1200 images, one byte per pixel, at 30 frames per second:

• Per frame: 1920 × 1200 × 1 = 2,304,000 bytes.
• Per camera: 2,304,000 × 30 = 69,120,000 bytes/s, or about 69.1 MB/s.
• Four cameras: 69,120,000 × 4 = 276,480,000 bytes/s, or about 276.5 MB/s.
• Payload bit rate: 276,480,000 × 8 = about 2.21 Gb/s.
• An initial planning allowance of 25% gives 276.48 × 1.25 = 345.6 MB/s.

These are decimal units and assumed application settings, not specifications for a catalog camera. The allowance is a starting point, not a guarantee: protocol overhead, burst traffic, retransmissions, and host scheduling still require measurement.

Map the entire path. Separate USB sockets may share one host controller. Separate Ethernet camera ports may still converge on a switch uplink, expansion-card connection, or constrained memory path.

The LS-FGB-0004 is a PCIe x4 PoE Gigabit Ethernet card. Check its host requirements, driver support, and aggregate behavior against the proposed acquisition topology.

Use the frame grabbers category and accessory finder to identify interface options. Port count alone does not establish sustainable aggregate throughput.

For GigE acquisition, follow the documented configuration order described in setting camera packet size before acquisition. Packet tuning cannot repair an oversubscribed shared link.

5. Define synchronization as an error budget

First decide what must be simultaneous: exposure, frame delivery, or processing. These are different events.

Software message synchronization groups messages according to their timestamps. It does not cause cameras to expose together. A shared trigger can coordinate supported cameras, but you still need to verify trigger latency, exposure timing, and clock interpretation.

Derive the timing requirement from motion:

Suppose a part travels at 500 mm/s and the permitted cross-camera position mismatch is 1 mm. The timing allowance is 1 / 500 = 0.002 s, or 2 ms. A measured exposure difference of 4 ms would produce approximately 500 × 0.004 = 2 mm of motion mismatch.

Allocate that allowance across trigger skew, clock uncertainty, timestamp interpretation, and exposure duration. Do not spend the entire allowance on message-pairing tolerance.

For every driver, establish whether the timestamp represents exposure start, exposure midpoint, exposure end, or host receipt. Independent device clocks need a documented alignment method before their timestamps can be directly compared. Host arrival time also includes transport and scheduling delay.

Use shared-trigger exposure synchronization for the hardware-timing decision, then interpreting camera buffer timestamps to separate acquisition timing from delivery latency.

6. Keep calibration bound to the actual stream

Calibration belongs to a physical camera, its optics, and its image geometry. A namespace is only a label; it is not evidence that the correct calibration was loaded.

Bind each calibration record to the device identity and record the image dimensions, crop, binning, and any driver-side resizing. Intrinsic calibration describes the image projection. Extrinsic calibration describes the camera's pose relative to another frame. You need both when combining observations geometrically.

Verify that image and camera information messages agree on frame identifiers and acquisition timing. Check reprojection behavior across the usable field, not only near the image center. Then observe a target visible to overlapping cameras and inspect the cross-camera alignment.

Follow the ROS 2 camera calibration validation workflow before relying on downstream geometry. If you reduce transport load through cropping, review camera ROI cropping at the source and update the calibration mapping appropriately.

Recheck extrinsics after moving a camera or disturbing its mount. A healthy image topic cannot detect a mechanically incorrect transform.

7. Choose acquisition parts without assuming ROS support

Select the interface and shutter behavior around the inspection task, then verify the software combination separately. A transport standard does not automatically establish compatibility with a particular ROS wrapper.

The LS-CMR-0053 uses GigE and a rolling shutter. The LS-CMR-0166 uses USB3 and a rolling shutter. These are interface examples, not a verified ROS pairing; confirm acquisition-library and wrapper support before selecting either.

For static scenes or sufficiently slow motion, a rolling shutter may be acceptable. For moving objects requiring tight cross-camera geometry, evaluate global-shutter alternatives and documented trigger behavior in the area scan cameras category. Use the camera finder to narrow the interface and shutter choices.

Match data cables to the camera connector, host connector, routing, and movement requirements. The LS-CBL-0199 is a high-flex GigE camera cable with screw locks. Confirm connector fit and routing clearance for the selected camera.

The LS-CBL-0219 is a high-flex USB3.0 camera cable intended for drag-chain use. Confirm its connector arrangement and suitability for the planned installation.

Browse camera data and I/O cables after the interface is fixed. A correctly selected cable supports the physical connection; it does not add synchronization or resolve software device-selection limits.

8. Bound queues and define failure behavior

An acquisition pipeline can publish images continuously while delivering data too old for the task. Measure age at the consumer, not just publication rate at the driver.

At 30 frames per second, each frame interval is about 33 ms. A queue containing six waiting frames represents approximately 6 / 30 = 0.2 s, or 200 ms, of backlog before further processing.

Choose queue depth from the application's latency and loss requirements. A latest-image viewer may discard old frames, while a recording application may need complete sequences. A synchronized measurement must reject incomplete or stale sets rather than silently pairing unrelated frames.

For ROS 2, inspect publisher and subscriber QoS compatibility. Reliability settings and history depth affect delivery behavior, but they cannot compensate for insufficient processing capacity.

Keep acquisition callbacks short and move expensive processing to bounded worker queues. The multi-camera callback and buffer-queue troubleshooting guide explains why blocking work can stall apparently independent streams.

Define behavior for a missing camera, a clock discontinuity, or repeated incomplete frames. Recovery should restore the documented operating state and verify calibration and identity before resuming combined measurements.

9. Recognize when one launch is the wrong answer

A single launch description is useful for coordinated startup, but it is not always the right acquisition architecture.

Use separate hosts when measured transport or processing demand exceeds a practical single-host design. That choice introduces clock alignment and inter-host transfer requirements, so repeat the timing and bandwidth analysis across the new boundary.

Separate processes may be preferable when independent recovery matters and the acquisition library explicitly supports concurrent ownership of different devices. Conversely, a documented multi-device driver may offer better coordination than several unrelated processes.

If the required camera and software combination does not support concurrent operation, use a supported release, a supported acquisition route, or different hardware. Do not infer that an undocumented launch parameter or duplicated process will make it supported.

Finally, avoid requiring exact exposure alignment when the application only needs independent views. Unnecessary synchronization can add complexity without improving the measurement.

10. Commission incrementally before scaling

Set acceptance limits before testing. Include sustainable frame rate, maximum image age, permissible exposure skew, and behavior when a stream disappears.

Use this commissioning checklist:

• Identity: restart acquisition repeatedly and confirm every namespace still maps to the assigned physical camera.
• Configuration: compare active image format and exposure settings with the saved configuration after startup.
• Transport: run all streams together and inspect incomplete frames, losses, and shared-link utilization.
• Timing: observe a common timed event and verify exposure alignment, not merely message arrival order.
• Calibration: check overlapping observations and confirm frame transforms remain consistent.
• Load: enable recording and downstream processing while monitoring frame age and queue growth.
• Recovery: test a controlled stream interruption and confirm stale observations are rejected.
• Scale: add one camera at a time and repeat the full-system checks.

An initial 30-minute run and repeated acquisition restarts can expose configuration errors, but they are not a reliability qualification. Extend testing to the actual workload, recording duration, and recovery conditions.

Start the camera configuration workflow with your stream count, image format, timing allowance, and host topology. For help checking the acquisition chain, send those requirements through applications support.