ROS infrared topics no messages: check stream enable settings

An infrared image topic can appear in ROS tools even when the camera driver is not acquiring infrared frames. That distinction matters when color and depth work, but an infrared viewer waits indefinitely. For ROS integrators, the first task is to separate a registered publisher from a working image stream—not to replace the camera or change transport settings immediately.

The procedure below targets ROS 1 systems. It checks message flow, startup parameters, and launch configuration before making changes. The command examples use illustrative names under /camera; substitute the names discovered on your running system.

1. Distinguish an advertised topic from an active stream

A driver can register its image publishers during initialization, independently of whether each acquisition stream is enabled. Consequently, a topic listing can show an infrared endpoint that never receives an image message.

These observations answer different questions:

Treat a silent topic differently from a black image. A black image is still a message containing pixel data; a silent endpoint has no arriving image to inspect.

For the broader distinction between an unresponsive application and absent camera data, start with checking topic publication before diagnosing a startup hang.

2. Measure message flow before changing settings

Use the same sourced ROS environment and intended ROS master for your diagnostics and camera launch. Otherwise, you may inspect a different graph from the one running acquisition.

1. Discover the actual node and topic names.

rosnode list
rostopic list

2. Inspect the infrared image endpoint and its publisher.

rostopic info /camera/ir/image_raw
rosnode info /camera

The node name in the second command is illustrative. Use the publisher identified by the first command. With nodelets, also identify the camera component inside its manager; the manager name alone may not identify the component's parameter namespace.

3. Subscribe to the image and calibration endpoints.

rostopic hz /camera/ir/image_raw
rostopic echo -n 1 /camera/ir/camera_info

Allow a defined observation period, such as 10 seconds after startup has completed. Stop a waiting command with Ctrl+C. Repeat for the second infrared stream if your device and driver expose one.

Compare these observations with a working color or depth topic. If those messages arrive while both infrared image and camera-info endpoints remain silent, stream configuration deserves an early check. That pattern is evidence for investigation, not proof of a particular driver behavior.

3. Inspect the effective stream-enable parameters

Find the documented infrared enable setting for the installed driver version. Parameter names and meanings vary: a driver might provide one infrared switch, separate switches for individual imagers, or a stream-selection configuration.

An option named enable_ir is one possible naming convention, not a universal ROS feature. Do not assume that copying that name into an unrelated driver will enable anything.

List parameters, then inspect the namespace belonging to the actual camera component:

rosparam list
rosparam get /camera

Check the following items against the installed driver's documentation:

• Whether infrared acquisition is enabled.
• Whether the switch applies to one infrared imager or both.
• Whether the setting is read only during initialization.
• Whether the selected stream combination is supported.
• Whether an infrared resolution and frame-rate profile must also be selected.

Record the values before editing anything. Preserve a copy of the relevant launch configuration so you can reverse the change.

A parameter-server value is not always proof of active hardware state. A node may read a value at startup and retain it internally. Conversely, placing an unused parameter on the server does not make the driver recognize it.

Look for startup logs reporting enabled streams or selected profiles. When available, a documented runtime status interface provides stronger confirmation than a parameter value alone.

4. Trace the launch configuration that actually ran

A correct edit in the wrong launch file changes nothing. Identify the top-level launch command or service entry point used for this acquisition session, then follow its included files and loaded parameter files.

The effective setting may come from several layers:

• A launch argument with a default value.
• A parameter assignment inside an included launch file.
• A loaded configuration file.
• A command-line argument passed by a service or startup script.
• A different installed copy of the package from the one you edited.

A launch argument and a ROS parameter are not interchangeable. The launch configuration must explicitly pass an argument into the parameter consumed by the camera node. Supplying an argument that the launch file does not declare can fail; setting a similarly named parameter may simply have no effect.

Also check namespace resolution. A private parameter belongs to the camera node or component's private namespace. A value at a parent namespace may not be the value the driver reads.

Make one change in the configuration source that owns the setting. Avoid accumulating conflicting assignments until the stream happens to work. After restarting, compare the new parameter value and startup log with the intended configuration.

5. Apply the change through the supported lifecycle

Determine whether the documented stream-enable setting supports runtime changes. If it is initialization-only, changing it with rosparam set will not necessarily reconfigure acquisition.

Use this sequence:

1. Pause dependent inspection or guidance tasks through the machine's approved operating procedure.
2. Enable the required infrared stream in the active launch configuration.
3. Keep the working stream profiles unchanged for the first test, unless the documentation requires a different combination.
4. Restart the affected camera node or nodelet through its normal launch or service mechanism.
5. Read the startup log and inspect the effective parameters again.
6. Reconnect diagnostic subscribers and verify publication.

Account for automatic respawn or service supervision. Stopping a process manually while its supervisor immediately recreates it can obscure which configuration is active. Avoid restarting unrelated cameras when the affected component can be restarted independently.

If initialization now reports an unsupported profile, resolve that specific configuration error. Do not treat every failure after enabling infrared as another instance of a disabled stream.

6. Verify images, camera information, and sustained delivery

Successful recovery requires more than seeing the topic name again. Confirm that image messages arrive, camera information is available, and the image content responds to changes in the scene.

rostopic hz /camera/ir/image_raw
rostopic echo -n 1 /camera/ir/image_raw/header
rostopic echo -n 1 /camera/ir/camera_info

Inspect timestamps, frame identifiers, image dimensions, encoding, and the calibration information associated with that image stream. Do not substitute the color camera's calibration merely because it is already available.

For an illustrative stream configured at 15 frames per second, a 10-second observation suggests approximately 150 images:

This is an observation target, not a guaranteed delivery count. Startup delay, scheduling, transport, and subscriber behavior can affect the measured value. Measure after acquisition settles and use the driver's documented operating limits when deciding acceptance criteria.

Camera-info publication policy can differ from image publication policy. Some integrations publish calibration alongside images; others provide it differently. Verify the documented behavior rather than requiring matching rates without justification.

Repeat the test after another controlled restart. A stream that works only after a manual intervention still has an unresolved startup configuration problem. For persistent rate differences, follow the approach in verifying camera startup frame rate and configuration readback.

7. Change direction when the evidence changes

Stream-enable configuration is a strong early candidate when endpoints exist but remain silent. It is not the explanation for every infrared problem.

If the required imaging endpoints or underlying sensors are absent, use the missing mono-sensor diagnostic path. That is different from an advertised infrared endpoint whose acquisition was disabled.

If startup logs reject an encoding, use pixel-format checks for missing streams. If multiple streams disconnect or fail under load, move to camera bandwidth and power diagnostics.

Do not change firmware, drivers, stream profiles, and launch defaults simultaneously. Preserve a known configuration and change one relevant variable per test.

8. Check integration requirements before changing hardware

A configuration fault does not establish that you need another camera. Resolve the software evidence first. If a new integration genuinely requires separate infrared images, make that an explicit selection requirement.

The 3D sensors category includes different sensing approaches. The MV-DLS300P-04 is listed as a laser galvanometer stereo camera:

The MV-DPS200P-02 is listed as a projected structured-light 3D camera:

Those descriptions alone do not establish ROS compatibility, independently accessible infrared images, launch parameter names, or camera-info publication behavior. Confirm those requirements through the manufacturer's documentation before selecting either device for this workflow.

Likewise, area scan cameras are not automatically substitutes for a calibrated stereo or depth system. Compare the required outputs, not just the presence of an image interface. Use the camera finder to browse hardware after defining the acquisition requirements.

Before closing the fault or placing an order, check:

• Publisher identified: diagnostics target the actual acquisition component.
• Messages measured: image traffic was tested with a subscriber connected.
• Startup source confirmed: the edited launch configuration is the one being used.
• Enable setting verified: its name, namespace, and lifecycle match the installed documentation.
• Output checked: infrared images and the appropriate calibration information are available.
• Restart repeated: the corrected behavior survives a controlled relaunch.
• Hardware requirements documented: required streams and software support are confirmed rather than inferred.

If infrared remains silent, bring the launch command, relevant parameter values, startup log, and topic-rate observations to integration support. If hardware selection is necessary, start with the camera configurator and specify the required stream outputs explicitly.