Camera works in vendor tool but not in ROS: one client at a time

You launch the ROS driver, the log finds the camera and reads its model, and then acquisition start fails with access denied [-1005] — while the same camera streams fine in the vendor's viewer. Nothing is broken. Two applications are reaching for one camera, and a GigE Vision camera serves exactly one controlling client at a time; the vendor's viewer is a client too. This guide reads the failure as it appears in a ROS 1 (Noetic) log on Ubuntu 20.04, ranks the likely causes, gives a test for each, and ends with an ownership rule that stops the conflict from returning. The diagnosis is identical for every GigE Vision camera: area scan cameras, line scan models and infrared cameras alike.

The symptom: enumeration succeeds, then start fails

The log tells you the conflict happens late, not early. The driver enumerates exactly one camera, prints its serial, reads the device type (GigEVision) and the model name, so discovery and identity reads work. The failure arrives only at the acquisition start, as the SDK error Could not start acquisition. Access denied [-1005].

Two further messages usually follow, and both are consequences, not causes. The image view stays empty because buffer retrieval fails with NULL pointer dereferenced [-2005]: no acquisition, no buffers. The shutdown path then logs Can't de-initialize camera. Camera is still streaming. [-1004] — a stream is indeed running on the camera, but it belongs to the other client.

One line looks alarming and is not: the warning Feature DeviceLinkThroughputLimit not available, return code 89900400. That GenICam feature caps how fast a camera may push data onto the link; this camera does not expose it to this driver, so the driver skips it and continues. Treat it as informational. Access denied is the only real blocker.

Why it happens: a GigE Vision camera serves one controlling client

Discovery on a GigE Vision network is a broadcast: any number of tools on the subnet can list the camera and read its identity. Control is different. The first application that takes control — writing features and starting a stream — holds it exclusively, and the camera refuses control requests from everyone else until that client disconnects. Your vendor's viewer takes control when it starts streaming; the ROS driver then connects, reads the identity, and is refused at the one call that needs control, the acquisition start.

The rule applies per connection, so a viewer running on a second PC counts exactly like one on the bench machine. The same exclusive-access failure between two desktop tools, without ROS, is covered in GigE camera open fails in a second tool: exclusive control.

Likely causes, most probable first

1. The viewer is open and streaming. The strongest hint is the report itself: the image shows in the vendor tool. That tool holds control.
2. A leftover client still holds the handle. Viewers sometimes keep the camera session alive in a background process after their window closes; a crashed driver or a previous launch can leave a session behind.
3. A second host is on the camera subnet. A colleague's laptop running the vendor tool, a VM with the interface bridged in, a container — each behaves as a client.
4. The camera is stuck streaming after an unclean shutdown. Power lost mid-stream leaves the camera's side of the stream up; the [-1004] teardown message points here.
5. An adapter or SDK-layer problem. Unlikely in this pattern, because the driver reads the model name. That cause applies to cameras that never get that far: Camera detected but not in acquisition tool: fix the adapter layer covers it.

Test each cause

Work top to bottom; the first test settles the most likely cause in under a minute.

1. Close the viewer completely. Stop acquisition in it if it has a stop control, then quit the application — not just the image window. Search ps -ef for the viewer's process name; the list should be empty of it. Launch the driver alone. If the start succeeds, the conflict is confirmed.
2. Sweep for leftovers. Run ps -ef | grep -i ros and the same search with the viewer's process name. Kill any stray PID, wait about five seconds for sockets to settle, and retry.
3. Check the network. Shut down or disconnect every other machine that could reach the camera — bench laptop, VM, container — and retry once.
4. Power-cycle the camera. With no client running anywhere, drop PoE power or the camera's supply for roughly ten seconds, bring the link back up, and start one client only.

If the start succeeds after step 1 or 2 you are done. Step 4 covers the rare case where the camera's own state, not a client, is the problem.

Fix: the clean recovery sequence

1. In the tool that holds the camera, stop acquisition, disconnect, and quit.
2. Confirm no leftover processes remain: search ps -ef for the tool and driver names, kill strays, wait five seconds.
3. Launch exactly one driver instance and read the start line in the log: it should pass without the access-denied error.
4. Open rqt_image_view and confirm frames arrive and update.
5. If access denied [-1005] still appears with no other client anywhere, power-cycle the camera for about ten seconds and launch one client again.
6. If teardown later logs camera is still streaming [-1004], something streamed during your shutdown — repeat with clean exits. The message disappears once every client stops its stream before disconnecting.

Prevention: give the camera one owner

Ownership is a design decision, not a habit. At run time the driver owns the camera; the vendor's viewer is a commissioning tool you open, use, and close before the driver launches. Write the order into the runbook and into the startup scripts: no viewer auto-starts on the camera host.

Exit cleanly, too: stop acquisition, disconnect, then exit, so the camera is free the moment your process dies. ROS camera driver shutdown: release cameras for other apps covers the shutdown path, and Stop a camera stream in Python without closing your app covers scripts that must hand the camera back mid-run.

Guard the launch path. A supervisor that respawns a dead driver plus a manually started instance is two clients racing; keep exactly one launcher. And when a second consumer needs the images, do not open the camera twice — subscribe to the driver's output instead, the way Show a camera live stream in an HMI web viewer widget consumes a stream for display.

One client is not a bandwidth problem

The question comes up every time: the link has room, so why can't two tools share? Because the refusal is access control inside the camera, not a traffic limit. Run the numbers once and you see how little of the link a single client actually needs.

Take the LS-IRC-0044, a 640 × 512 LWIR thermal camera with a 50 Hz GigE stream.

The 2 B/px term assumes a 16-bit pixel format; substitute the byte count of your driver's pixel format if it differs. One client takes about 262 Mbit/s, roughly 26 % of a 1 Gbit/s link, plus a few percent of protocol overhead. A second client would still be refused: the camera declines its control request before any image traffic flows. Sharing happens on the host, between subscribers of the driver's output — never as two opens on one camera.

The same arithmetic runs on any GigE area scan camera, the 2.5 MP MV-CU020-90GC for instance.

When the cause is something else

The access-denied pattern is specific, and its neighbours have their own guides:

• Zero cameras detected, or discovery fails everywhere: that is network territory. GigE Vision camera firewall: ping works, discovery fails walks the firewall and routing cases.
• The stream starts, then stalls or drops: tune the link itself, beginning with Set GigE camera packet size before starting acquisition.
• The view dies mid-run with an error marker: GigE camera red X error in your vision software: a fix plan covers the stream-loss path.
• Frames arrive slowly inside an SDK acquisition loop: Camera stuck at 30 fps in a Python GenTL loop: fix the link first is the reference.

Checklist before the next launch

• One client targets the camera: the driver owns it at run time, the viewer is closed before launch.
• No leftover processes: after any crash, search ps -ef before relaunch; kill strays, wait five seconds.
• One launch path only: manual start or respawn supervisor, never both.
• Clean teardown everywhere: stop acquisition, disconnect, exit — no [-1004] on shutdown.
• Persistent [-1005] with no client anywhere: power-cycle for about ten seconds, then start one client.
• Second consumers subscribe to the driver's output; they never open the camera.
• Settings you care about are saved into the camera, so a power cycle changes nothing.

Next step: if you are standardizing the cameras on the bench, the camera finder filters GigE, USB3 and CoaXPress models by resolution and shutter, and the camera step of the configurator pairs a camera with lens and lighting. More systems-side reading sits on the systems topic page; for a build question that does not fit a guide, the contact page reaches the applications team.