If a ROS 2 LiDAR driver starts normally but ignores values in a YAML file, establish which node the file addresses and which values the running node actually holds. A valid file on disk is not proof that the intended process loaded it. Node names, namespaces, parameter types and launch overrides can all change the effective configuration.
Preserve the exact launch command, resolved node name, package revision and configuration path before editing anything. This workflow investigates startup parameter delivery. The viewer-versus-driver diagnostic remains relevant if the effective configuration is correct but the driver still receives no sensor data.
The Jazzy parameter overview describes parameters as belonging to individual nodes. Do not apply the ROS 1 assumption of a shared global parameter server to a ROS 2 deployment. A value observed on a similarly named node does not configure the intended driver.
Identify the actual process and resolved node
Record whether the driver runs from an interactive shell, launch file, service, container or component container. Save the effective environment and workspace overlays associated with that process. A new terminal showing the expected package path does not establish what an already running service inherited.
List the observed node names and namespaces. Compare them with the launch configuration, including name and namespace remappings. Two robots can run the same package under different fully qualified names. A file addressed to one namespace can therefore be perfectly valid while having no effect on the other.
Check that observations come from the same ROS domain and discovery context. The remote discovery guide explains why a command run in another environment may inspect a different graph or miss the intended node. Establish identity before interpreting a parameter dump.
Verify the file that was actually supplied
Record the absolute path passed to the launch process and a hash of the file contents. Keep source-tree, installed-share and copied deployment files distinct. Editing the source copy does not necessarily change an installed package or a service configuration that points elsewhere.
Inspect startup logs for parameter-file parsing failures and rejected options. Preserve the original message. A wrapper can continue launching other nodes after one component rejects its configuration, making the overall launch appear healthy while the intended driver never accepted the file.
The Jazzy launch Node implementation is a useful reference when tracing how a launch action prepares process arguments and parameter inputs. Match it to the installed launch package. Custom wrappers can add their own transformations or select files conditionally.
| Question | Evidence | Typical mismatch |
|---|---|---|
| Which node? | Resolved full name | Old namespace in YAML |
| Which file? | Actual path and hash | Edited source instead of installed copy |
| Which type? | Declared descriptor and value | String where a number is expected |
| Which value? | Running-node readback | Later override differs from file |
| Which behavior? | Observed output after documented activation | Startup-only setting changed at runtime |
Match YAML scope to node identity
The parameter-file migration guide shows node addressing and the ros__parameters section. Compare the structure with the resolved name rather than merely searching for the desired key somewhere in the document. Indentation and scope are part of the configuration.
Review wildcard sections deliberately. A broad wildcard can supply a value to more nodes than intended, while a narrow node-specific section can miss a renamed component. Write down the intended recipients and compare them with actual readbacks. Do not widen a wildcard merely to make one symptom disappear without reviewing its other recipients.
Separate a parameter namespace inside a node from the ROS node namespace. Similar dotted or nested names can represent different configuration structures. Use the driver’s documented parameter keys and the running node’s parameter list to confirm the expected names.
Where several parameter inputs or launch overrides exist, compare the effective result instead of inferring it from file order alone. Preserve each input and the resulting value. The exact launch arrangement, client library and declaration behavior determine how those inputs are used.
Check types, declaration and accepted values
For each disputed key, record its declared type, descriptor and current value. Quoting a number can turn it into a string. A list of mixed element types may not match a supported parameter type. Preserve the parser or node response instead of silently coercing a value until startup succeeds.
The ROS parameter design explains the ownership and validation model. Use it as architectural context alongside the installed implementation and driver documentation. A parameter existing in the node’s interface does not establish that every possible value is acceptable.
Read back a small set of decisive values from the intended node. Use harmless, documented settings that distinguish the expected configuration from the default. A parameter dump is useful evidence, but do not expose private device addresses or secrets when preparing an external support record.
Check output separately after acceptance. The QoS compatibility workflow is useful when a correctly configured publisher remains silent to one consumer. Parameter delivery and endpoint compatibility are different layers, so preserve observations for both.
Separate startup overrides from runtime behavior
The ROS 2 parameter CLI tutorial provides the context for listing, describing, reading and dumping values. Begin with read-only observations. A runtime change should follow the driver’s documented support and the team’s commissioning procedure.
Some settings are consumed during construction or configuration, while others have supported runtime callbacks. A successful set response does not by itself prove that every downstream device setting changed immediately. Compare accepted values, applicable state transitions and actual output behavior.
If a managed component requires configuration or activation, use the managed-node recovery checklist to identify the required state. Do not assume every LiDAR driver implements that lifecycle. Ordinary nodes can have different startup and reconfiguration contracts.
Prove the saved deployment survives restart
Repeat a normal cold launch with the preserved file and launch method. Compare node identity, file hash and decisive parameter readbacks with the intended baseline. A manually corrected running session is not a reproducible deployment until the normal startup loads the same effective settings.
Keep a bounded comparison showing the original mismatch and the corrected result. If the cause was a wrong path, preserve both paths. If it was scope, preserve the old and corrected node addressing. Avoid changing several unrelated settings in the same comparison.
Share the relevant launch inputs, redacted parameter dump, versions and observations in a reproducible support bundle. State whether the file failed to load, targeted the wrong node, supplied an unacceptable type or was superseded by another input. That distinction makes the repair maintainable.
Include one deliberately mismatched node scope in a local test fixture and verify that the diagnostic distinguishes it from a parsing error. Then restore the intended scope and repeat the normal startup. This tests the explanation of the failure, rather than only showing that one corrected session happens to work.
Retain a small configuration change log naming the original symptom, file hash, resolved node and corrected value. That record helps prevent a later package installation from restoring the old file while the team assumes the successful configuration is still active.
Frequently asked questions
Does valid YAML mean valid ROS parameters?
No. The file must also address the intended node and supply supported keys, types and values through the actual launch path.
Should I use a wildcard for every setting?
Only when the intended recipient set is explicit and checked. Broad scope can configure unrelated nodes unexpectedly.
Does runtime readback prove a sensor changed mode?
No. Confirm the driver’s reconfiguration contract and observe the actual sensor output after the required supported procedure.
