Apply camera trigger settings at startup without driver support

Your driver exposes a service for every trigger setting — line mode, trigger mode, trigger source — but no launch-file parameter for any of them, so an externally triggered station comes up in free-run until someone calls the services by hand after every boot. You do not need a driver release to fix that. Persist the trigger configuration in the camera's own user set, make it the power-up default, and have the launch file re-apply and check the settings in a fixed order at startup. You get the write order, the launch-file call pattern for a multi-camera system, the readback checks, and a first-frame timeout with the arithmetic shown.

The settings the services control

Under GigE Vision and USB3 Vision, trigger configuration is a small block of GenICam features. TriggerSelector picks the event the trigger arms, normally the start of each frame. TriggerMode switches external triggering on. TriggerSource names the input line that provides the edge. The I/O block — LineSelector, LineMode and LineSource — decides what each physical line does, and it is the block drivers most often leave out of their parameter files.

AcquisitionMode stays on continuous under hardware trigger: the pulse starts each frame, not the mode. When a camera ignores its trigger wire, acquisition mode and the line block are the first two places to look, in that order — GigE camera ignores an external trigger and hardware trigger source not detected walk both checks. Any area scan camera holds this configuration, and a global shutter freezes a moving part at the trigger instant instead of scanning across it during exposure:

The order that works

TriggerSource points at a line, and the line must already be an input before the camera can register an edge on it. Write the I/O block first, then the trigger block, then arm. The full write order at the camera:

stop acquisition
line selector    -> the trigger input line
line mode        -> input
trigger selector -> frame start
trigger mode     -> on
trigger source   -> that line
start acquisition

Stopping acquisition first matters because several of these features refuse writes while the camera is streaming — apply camera settings while streaming without stalling capture covers the pattern, and GenICam attribute not writable covers the error you see when you skip it.

Step by step: make it come up configured

1. Configure one camera by hand, in the vendor's viewer or a short script, in the order above. Pulse the line and confirm exactly one frame per pulse before you automate anything.
2. Save the result to a spare user set slot and make that slot the power-up default. Power-cycle the camera with no driver running and read the settings back: if they survive, the camera alone now comes up triggered. Save camera parameters as a user set that loads on startup covers the save, and save camera settings across power cycles covers the test.
3. Put one service call per setting in the launch file, wrapped as a launch node: package rosservice, type rosservice, the call in its args, and a unique node name. The call itself passes the value inline:

rosservice call /camera/right/set_line_mode 0

4. Keep the camera's namespace in the path and the camera's initial in the node name: set_line_mode_r for the right camera, set_line_mode_l for the left. With duplicate node names a later call displaces an earlier one, and one camera stays misconfigured while the log looks clean.
5. A launch file does not wait for one node to finish before starting the next. When order matters — line mode before trigger source — put the calls in one small startup script and launch that script as a single node.
6. Read every setting back with the matching get service and compare it against what you wrote, not against what you expect. A mismatch is a failed start: camera trigger mode source readback mismatches lists the causes, with a cached driver value first among them.
7. Arm acquisition last, after readback passes — camera trigger overlap configuration shows how to confirm the boot-time writes landed. Then block on the first armed frame with the timeout below and hand the stream to the hardware trigger grab loop.

Where the launch file runs

The host running the launch file shapes trigger timing as much as the camera does. A vision controller such as the MV-VC3301H-128G66 has 5+ LAN ports. On a right-and-left pair that is one dedicated link per camera, so a burst of frames from one camera never contends with the other's cable — the layout argument in multi-camera system design for reliable image capture.

Worked example: first-frame timeout at a 9 fps trigger ceiling

Inputs: one LS-CMR-0053, a 12 MP GigE camera with a printed 9 fps ceiling; a trigger pulse at that ceiling, one per frame period; and a startup check that must tell a dead trigger line from a slow first frame.

Two rules set the numbers, each with its basis. Exposure gets about half a period, leaving the other half for readout and transfer inside the same frame. The first-frame timeout gets two periods: one for a pulse that lands just after arming, one for jitter.

T_frame = 1 ÷ 9 fps = 0.111 s ≈ 111 ms. Exposure cap ≈ 111 ms ÷ 2 ≈ 55 ms, so configure 50 ms. Timeout = 2 × 111 ms = 222 ms, so configure 250 ms.

Decision: no frame within 250 ms of arming fails the start, loudly, with no silent retry into free-run. Frames arriving but every other pulse empty means the trigger outruns the camera — space pulses at least 111 ms apart, or cut exposure further. Pulses closer than 111 ms cannot buy more than 9 frames per second at full resolution, because 9 fps is the camera's own maximum.

When the saved user set is not enough

The user set covers power cycles with no software attached. Two cases fall outside it, and the launch calls exist for both.

The driver writes over it on connect. Drivers commonly push exposure, gain and sometimes trigger mode when they open a camera, after the user set has loaded. With the driver up, read trigger mode following a cold boot: off after a boot that saved it on means your startup calls are doing real work — keep them.

The I/O lines sit outside the set. On some cameras line mode does not survive the power-cycle test in step 2. If it reverts, move the line settings into the startup script permanently and let the user set carry the rest.

Discovery fails before any of this. GigE Vision finds cameras with broadcast packets, and a router between controller and camera drops them, so the camera never appears to the driver. Put cameras on their own subnet behind a switch, or add the camera by its IP address where your tool supports a remote-camera entry; trigger settings are irrelevant until the camera is open.

Checklist before you ship

• Line mode reads back as input on the trigger line.
• Trigger mode on, trigger source names that line, trigger selector at frame start.
• Acquisition mode continuous, armed only after readback passes.
• Settings survive a power cycle with no driver connected.
• Settings still read back correctly after the driver connects and initializes.
• Every launch call has a unique node name; ordered calls share one script.
• The first armed frame lands inside the timeout — 250 ms in the worked example.
• A failed check stops the start; there is no free-run fallback.

Start the configuration

Choose the camera in GigE area scan cameras or the camera finder, run the configurator from the camera step to match lens and light to it, and pick the host from vision controllers. If the stack needs a look before you order, send the trigger rate and camera count through the contact page and we will mark the decision points in your launch file.