ROS camera launch parameter not supported: fix renamed settings

You updated a ROS 2 camera wrapper, kept the same launch file, and the console now fills with Parameter '...' is not supported warnings while the stream you configured starts at defaults, or not at all. This is the standard regression after a wrapper point release, and the wrapper hands you the diagnosis in the same message: it prints the exact parameter list the installed build accepts. Below are the three causes in order of probability — a renamed parameter in the camera include, arguments a parent launch forwards into the camera node, and a stale install space still serving the old launch file. Each has a one-minute test and a definite fix, so by the end you will know which warnings break the stream and which are only noise.

What the warning tells you, and the one-minute test

A ROS 2 node declares its parameter set when it starts. Any override that is not in that set is printed as a warning and ignored. That gives you a hard decision rule:

• The warning names a key you set in the camera include: functional break. Your value never reached the node — fix it before tuning anything else.
• The warning names a key you never set: it arrived from somewhere else, almost always the parent launch. The node ignores it; the fix is scoping, not renaming.

The supported list inside the warning is the authority for the build you are running — trust it over a wiki page or the README of an older tag. Copy it out of the console and diff it against your launch file.

The one-minute test is to run the camera launch file alone:

ros2 launch <camera_wrapper> wrapper_launch.py

A clean console means your include is fine and every warning you saw in the stack run was forwarded from above. The same warnings alone mean the break sits in your own file.

Scope: any wrapper that declares its parameters

The mechanism is wrapper-generic, not tied to one driver family. Depth wrappers, area scan camera drivers exposing GenICam-style feature names and ToF wrappers all behave the same way: the node declares its parameters and warns on the rest. Plan the same parameter triage on every driver update, whether you bring in stereo and structured-light 3D cameras or area scan cameras.

A laser galvanometer stereo camera such as the MV-DLS300P-04 reaches a ROS graph through exactly this kind of wrapper, profile parameters included:

Time-of-flight cameras such as the MV-DT01WMU are the other common case, with a depth wrapper whose parameter names and renames are its own:

Cause 1: the wrapper renamed the parameter

Between wrapper 4.56.x and 4.57.x, rgb_camera.profile became rgb_camera.color_profile. The value format did not change: widthxheightxfps. This break is quiet in the worst way — the node starts, drops the old key and runs color at the default profile, so the stack "works" while the topics carry the wrong resolution.

The fixed include reads:

launch_arguments={
    'camera_namespace': '',
    'enable_gyro': 'true',
    'enable_accel': 'true',
    'unite_imu_method': '2',
    'enable_infra1': 'true',
    'enable_infra2': 'true',
    'align_depth.enable': 'true',
    'enable_sync': 'true',
    'rgb_camera.color_profile': '640x360x30',
}.items(),

Two details bite alongside renames. unite_imu_method takes its numeric value as a string — '2', not 2. And profile keys are split by stream family: depth_module.depth_profile and depth_module.infra_profile for depth and IR, rgb_camera.* for color. When a second stream misbehaves, diff its key against the supported list before touching hardware.

Some update regressions go deeper than a rename. If the color sensor vanishes from the device outright, read depth camera RGB sensor not detected after an ISP update failure before assuming launch syntax.

Cause 2: the parent launch forwards its arguments

IncludeLaunchDescription with launch_arguments pushes those pairs into the included launch, and wrapper launch files copy every launch argument into the node's parameter block. A bringup that declares global_params, args and odom_args for its mapping and odometry nodes therefore delivers all three to the camera node, which warns and ignores them. This is why the pattern is "clean alone, noisy in the stack": the extra warnings appear only when the parent runs.

The fix is structural — one dict per include:

camera = IncludeLaunchDescription(
    PythonLaunchDescriptionSource(camera_launch),
    launch_arguments={
        'camera_namespace': '',
        'enable_sync': 'true',
        'rgb_camera.color_profile': '640x360x30',
    }.items(),
)

mapping = IncludeLaunchDescription(
    PythonLaunchDescriptionSource(mapping_launch),
    launch_arguments={
        'odom_args': odom_args,
        'global_params': global_params,
    }.items(),
)

From then on, arguments for other nodes cannot reach the camera node. The same scoping rule keeps multi-camera bringups quiet, because each include carries only its own settings — multiple cameras ROS launch: plan acquisition and synchronization works through the same layout. When the failing launch file belongs to the mapping side rather than the camera, apply the same method: fixing a ROS SLAM launch file whose node went missing.

Cause 3: a stale install space or a version mismatch

If you renamed the key and the warning still prints the old supported list, the file you are editing is not the file you are running. Overlay workspaces do this silently: an older overlay shadows the new wrapper. Check where the launch actually comes from:

ros2 pkg prefix <camera_wrapper>

Fix it by deleting the stale workspace's build/ and install/ trees, rebuilding with colcon build --symlink-install, and re-sourcing only the workspaces you need. Keep the wrapper package and its message package on one release — apt policy on both should show the same version family, since the parameter set moves with the wrapper, not with the messages. When the package itself went missing or fails to load after the update, that is a different failure: camera driver package not configured: restore camera detection and ROS camera package unavailable: check compatibility and setup cover it.

Worked example: four warnings from one bringup launch

The inputs, from a real 4.56.x to 4.57.x update:

• The camera include sets 9 arguments: camera_namespace, enable_gyro, enable_accel, unite_imu_method, enable_infra1, enable_infra2, align_depth.enable, enable_sync and rgb_camera.profile.
• The parent stack declares 3 arguments for other nodes: global_params, args and odom_args.
• The requested color profile is 640x360x30.

The rule: unsupported-parameter warnings equal renamed keys in your include plus parent keys forwarded into the camera node.

The arithmetic: 9 set + 3 forwarded = 12 candidate parameters; 1 renamed + 3 forwarded = 4 warnings — exactly what the console showed.

Check what that profile asks of the link, so the fix is not a guess:

Decision: rename the one key — color returns at 640 × 360 and 30 fps. Scope the three parent keys — warnings drop from four to zero. Any survivor after both fixes is a second rename, and the console list names its replacement.

The fix, in order

1. Copy the supported list out of the warning and diff it against your camera include. Rename every key of yours it lacks; rgb_camera.profile → rgb_camera.color_profile is the known 4.57.x change.
2. Run the camera launch file alone. If it is clean, move every non-camera argument out of the camera include and into the include of the node that owns it.
3. Still seeing the old list? Check ros2 pkg prefix <camera_wrapper>, delete the stale build/ and install/ trees, rebuild with colcon build --symlink-install, then re-source.
4. Confirm wrapper and message packages share one release with apt policy.
5. Re-run the stack and count warnings. Zero is the pass condition; a survivor means another rename — back to step 1.

Verify the streams, not only the console

A silent console is not yet a result. Confirm the data and the parameter:

ros2 topic list | grep color
ros2 topic hz /camera/camera/color/image_raw

Then run ros2 param list on the camera node and read back the renamed key: it should appear with your value, and the topic rate should match the fps in your profile — 30 in this case. If you bench-test with the camera uncovered, treat the depth projector window as a laser source and keep your eyes out of its beam at close range.

When the usual answer is wrong

• Warnings persist but every stream runs at your settings: forwarding noise. Apply the cause 2 scoping fix; do not hunt renames that are not yours.
• The key is accepted without a warning and the stream still misbehaves: the value, not the name, is rejected or clamped. Exposure and gain limits are the usual offenders — color stream exposure control: diagnose rejected settings walks that case.
• Raw topics flow but compressed or rectified topics stay empty: the parameter lives downstream in image transport, not on the camera node — image transport compression parameters: diagnose missing settings.
• One camera of a pair misbehaves after the update: check inter-camera sync mode before parameters — multi depth camera synchronization: slave mode and trigger setup.

Prevention: pin, diff, scope

Pin the wrapper release in your deployment manifest and take updates on a bench, never in the cell. Run the wrapper once on the old and once on the new version, save each supported-parameter list, and diff them — a rename shows up as a one-line change you fix in the launch file before it reaches production. Keep one dict per include from day one, so forwarded-argument noise can never mask a real rename.

Checklist

• [ ] Warning's supported list copied from the console and diffed against the include
• [ ] rgb_camera.color_profile carries the old rgb_camera.profile value
• [ ] Camera launch file runs alone with zero warnings
• [ ] Parent launch passes only camera keys to the camera include
• [ ] ros2 pkg prefix points at the workspace you are editing
• [ ] Wrapper and message packages on one release
• [ ] ros2 topic hz matches the fps in your profile
• [ ] Wrapper version pinned; supported-list diff saved for the next update

If the driver update is part of building the cell rather than maintaining it, the camera finder and the system configurator sort the hardware side, and the applications team answers integration questions on every part we sell. More systems and integration guides cover camera setup, synchronization and driver issues.