A thermal camera lists itself happily in the maker's own tuning tool, then your ROS node launches the driver and the log ends in a null-pointer exception. Nothing you type into the launch file changes that, because the failure happens before any parameter is read. This page is for integration engineers wiring a thermal or LWIR GigE camera into an SDK-based pipeline. You will learn why a driver opens only the camera family it was built for, what the LogicalErrorException NULL pointer dereferenced [-2005] class of message actually tells you, a five-minute test that separates a driver mismatch from a network fault, and the two supported paths that get frames flowing.
Why does the camera work in the tuning tool but fail in the ROS driver?
Because the tuning tool and the ROS driver are two different programs with two different support lists: the maker's viewer talks to every camera that maker builds, while the driver you launched only constructs camera handles for the one family it was written against.
An SDK is not one universal library. It is a family product: the maker writes a driver layer per camera line, and the viewer, the sample code and the ROS package are all built on top of that layer. The viewer's device list comes from a lower, transport-level enumeration, so it shows any GigE device on the subnet that answers. The driver's connect call is different — it filters for the model and family identifiers it knows, and everything else is refused, sometimes loudly, sometimes with a null handle.
The same family logic appears on the GenTL side of the machine-vision standards, where a consumer only sees cameras exposed by the producer library it loads; the GenTL camera open failure after successful discovery checklist walks that variant. Neither the camera nor the driver is broken. They have no contract with each other.
What does the "null pointer dereferenced" error actually mean?
The message LogicalErrorException NULL pointer dereferenced [-2005] means the driver tried to build an internal camera object from your device, got nothing back, and dereferenced the null result — a driver-side software failure, not a fault in the camera, the cable or the network.
The error fires at the connect step, after discovery has already run: the driver found a device on the network, tried to construct its camera object from that device's identifiers, and had no code path for the family it saw. That ordering rules out the usual suspects. A cable fault or a wrong subnet fails earlier, at enumeration. A camera already opened by another program raises an access error instead. Read the message as a contract statement — the driver has no entry for this device — and no camera-side setting can change it.
Can you fix it by editing the launch file?
No, editing the launch file cannot fix it, because launch parameters are applied to a camera only after the driver has opened it, and this driver never gets that far with a camera from a family it does not support.
Serial number, pixel format, exposure and frame rate all travel through the driver's API after a successful open. Connect fails first, so the parameter block never executes; every edit meant to match the camera's settings is dead code.
Two related faults do live in launch files, and they are worth separating from this one. A driver that opens the camera but rejects a renamed or moved parameter is a settings mismatch, not a family mismatch; the renamed ROS launch parameter fix covers it. A mismatch between SDK version and camera API generation is a build-time problem with its own diagnostics; see diagnosing a ROS camera SDK API mismatch at build time. Most camera software faults break down layer by layer like this, and the machine-vision systems topic groups the walkthroughs.
How do you confirm a driver family mismatch in five minutes?
Run the driver's own enumeration and the maker tool's device list side by side: a camera that appears in the maker's list but not in the driver's — or appears and then throws [-2005] on connect — confirms a family mismatch in under five minutes.
- Open the maker's tuning tool and write down the camera's device identifier exactly as it is shown.
- Start the driver node and read its enumeration output; most ROS driver packages print every camera they can see at startup.
- Check the transport. A driver built for USB3 camera families cannot open a GigE device at all. A USB camera that shows up as a generic device has the same root cause on the USB side — the generic UVC device name fix walks that one.
- If the camera is missing from both lists, the fault sits upstream of any driver: subnet, firewall or privileges. The GigE camera red X fix plan works that side, and the Windows privilege case is in the GigE configurator admin-rights fix.
Camera present in the maker tool and absent — or [-2005] — in the driver: family mismatch confirmed. Move to the fix.
| What you see | Likely cause | Confirming test | Fix |
|---|---|---|---|
| Camera in the maker tool, absent from the driver list | Driver filters by family | Compare both lists | Maker SDK or generic GigE Vision path |
| Camera in both lists, logical error [-2005] on connect | No code path for a foreign family | The maker SDK opens the same device | Maker SDK or generic path |
| Camera in neither list | Subnet, firewall or privilege fault | Ping the camera, check privileges | Red X fix plan |
| Driver opens the camera, a parameter read fails | Settings mismatch inside a matched driver | Read one known parameter | Driver-mismatch parameter fix |
| Open succeeds, stream setup fails in a GenTL consumer | Producer and consumer do not match | Load the producer the camera ships with | GenTL open-failure checklist |
One nearby case to rule out: a matched driver that cannot read a parameter is a settings problem inside a supported family. That scenario starts where this article ends — with a driver that already opens the camera — and the GigE driver parameter-read fix is its walkthrough.
Which driver should open the camera?
Open it with the SDK family that was built for it: the camera maker's own SDK first, and a GigE Vision/GenICam consumer second when the camera is a GigE Vision device; a USB3 Vision camera has no such generic fallback.
Path A — the maker's own SDK. This route carries the full contract. Every feature the camera documents, including the thermal-specific ones such as radiometric output, shutter calibration and internal corrections, is reachable through the libraries the maker ships. Write your node against that API, or wrap it in a thin bridge that publishes frames to the rest of your stack.
Path B — a generic GigE Vision/GenICam consumer. The standard exists precisely so a consumer and a camera from different suppliers can talk: the camera publishes its feature description, the consumer reads it and streams pixels. Plain acquisition needs no maker code. The limit is features — a control the maker did not expose in the camera's feature description cannot be reached from the generic side.
Path C is the swap: replace the driver with one that matches the camera family — which is Path A — or replace the camera with one the driver already supports. There is no supported configuration that makes one maker's driver open another maker's camera.
Does a generic GigE Vision path carry a thermal stream?
Yes for acquisition: GigE Vision is vendor-neutral by design, and a 640 × 512 thermal stream at 16-bit pixels and 50 Hz needs about 262 Mb/s, roughly a quarter of what a tuned GigE link carries.
A 640 × 512 sensor with 16-bit pixels produces 655,360 bytes per frame. At 50 Hz that is 32.8 MB/s, or 262 Mb/s. A GigE link runs at 1,000 Mb/s, and a machine-vision stream with jumbo frames typically moves 800–950 Mb/s of real payload, so this camera occupies roughly 28–33% of the practical ceiling. If the camera appends 32-bit radiometric values per pixel, the same arithmetic gives 524 Mb/s — half the link, still inside it, but the headroom for a second camera on the same network port is gone.
Two settings decide whether you see those figures in practice: the camera's packet size, which is a standard GenICam feature, and the host network driver and buffers. Set large packets on both ends. Keep the 16-bit pixel format intact instead of letting the consumer downconvert to 8 bits — the high-bitdepth thermal export walkthrough shows how to carry the full depth out of a thermal camera.
What should you order so the mismatch never reaches a build?
Order the driver and the camera as one decision: choose a camera family whose maker publishes an SDK for your operating system and language, or commit in the purchase order to a GigE camera you will drive with generic GenICam acquisition.
That is one line in your specification: camera family and driver family, together, with the SDK's supported-camera list attached. Free expert support with every order means you can put the stack question — operating system, language, ROS or not — to the applications team before the purchase order, not after the camera arrives.
A GigE-interface LWIR camera keeps both routes open, because the generic GenICam path and a maker SDK both speak to the same transport. The thermal and infrared camera category lists the range, and the camera finder filters it by interface, resolution and spectrum.
The LS-IRC-0044 is a 640 × 512 LWIR thermal camera with an 8-14 μm spectrum, a GigE interface, a 50 Hz frame rate, an 88.5° × 73.2° field of view and a 9-24 V DC supply.
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
- Spectrum
- LWIR
The Hikrobot MV-CI003-GL-N25 is a 0.3 MP LWIR camera with a GigE interface, an M34x0.75 mount and an EFL of 25 mm.
- Lens mount
- M34x0.75
- Interface
- GigE
- Resolution
- Up to 3 MP
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
How do you keep the mismatch from coming back?
Lock the trio of camera family, SDK version and driver version into your BOM and your integration test: a three-line smoke test that opens the camera and grabs one frame on every build catches the mismatch while it is still a desk problem.
Run the smoke test on the host that will run production — for a single-camera ROS node, a fanless industrial mini PC beside the cell is enough — and run it again after every SDK, firmware or operating-system update, because each can move a device outside a driver's supported range. Keep the pairing in the BOM so the next engineer inherits the contract, not just a part number. If the host carries several cameras, plan acquisition and synchronization per family; the multiple-camera ROS launch plan covers the launch-side layout.
If both lists agree and the camera still refuses to open, send both logs through the contact page with the family, SDK version and driver build included — that is the set of facts the answer turns on.
Questions
Does a null-pointer error ever indicate broken camera hardware?
Almost never. A camera that lists and streams in the maker's own tool has a working sensor, link and firmware; the [-2005]-class error is raised inside the driver process before any camera command is sent. Genuine hardware faults show up earlier and in every program: no link light, no enumeration in any tool, or a stream that dies everywhere, not only in one driver.
Can two camera families from different makers share one host PC?
Yes, with one driver per family and, for GigE cameras, preferably one network interface per family. Two SDKs coexist as separate libraries; conflicts appear when their network filter drivers stack on the same port or when both claim the same camera. Separate NICs and a per-family enumeration test keep them out of each other's way.
What if the camera maker publishes no driver for my operating system?
Three options remain. If the camera is a GigE Vision device, drive it with a generic GenICam consumer in your own node — acquisition works, family-specific controls may not. Run the maker SDK on the operating system it does support and bridge frames over the network to your node. Or swap the camera at quote time for a family that supports your stack natively.
Why did the same driver work yesterday and fail today?
Something in the contract changed. A camera firmware update can move the device outside the driver's supported range, an SDK update can drop an old family, and uninstalling one vision package can remove a network filter another SDK depends on. Compare SDK and firmware versions against the day it worked; the difference between the two states usually names the cause.