Launch Argument FAQ: Defaults and Supplied Values

A Launch Argument default describes a value supplied by the launch description when its applicable conditions are met. It does not prove that the same value was used in every invocation of a lesson. A parent description or caller may supply a value, and a substitution can retrieve configuration during evaluation. This FAQ reads the ROS 2 Jazzy tutorial and API reference to help a learner explain those relationships. It does not run a launch file, start a node or operate a robot.

What does the declared default tell the reader?

The official Using substitutions tutorial for Jazzy shows launch arguments with defaults and explains that arguments can be passed from another launch file or from the console. A source declaration therefore provides an important starting point, but it is not a complete record of one particular invocation. Keep the distinction between what the file declares and what a caller supplied.

In a lesson note, identify the launch description and the argument name before stating its value. If the only supplied evidence is the declaration, describe the default as a default. Do not relabel it as the observed configuration. That small wording choice prevents a static source-reading exercise from being mistaken for a report of software behavior.

Imagine a hypothetical classroom handout in which a child description declares one namespace while a parent example supplies another. A learner copies only the child's default into the report. The useful correction is to trace the supplied argument relationship. This invented example does not report a failed launch; it tests whether the learner can explain the relevant pieces of the provided source.

Why look at the parent description as well?

The tutorial's parent example passes arguments to an included description. Reading the child alone would omit that part of the example. A useful learning record identifies which description is being included and which named values are passed to it. These relationships should stay visible even if both files happen to use a similar name or happen to contain the same literal text.

Do not infer every launch-scoping rule from a single example. The tutorial demonstrates particular relationships, and an actual project may contain additional includes or conditions. When the supplied files are incomplete, state which relationship cannot yet be traced. Asking for the missing parent description is more precise than assuming that the default must have been overridden somewhere.

Is a substitution already the final string value?

The tutorial explains that substitutions are evaluated during execution of the launch description. The LaunchConfiguration API reference separately describes a substitution that accesses launch configuration variables. Its perform method retrieves the configuration as a string and describes returning a default when the configuration is absent and a default has been set. Keep that evaluation context in the explanation.

For a document-only exercise, a learner can identify where a substitution is referenced without claiming to have observed its resolved result. A source expression, a declared default and a value recorded during evaluation are different items. If the exercise asks about the last of these, the supplied evidence needs to support it. Naming a substitution object is not a substitute for that evidence.

Does an argument listing demonstrate the lesson's behavior?

The tutorial distinguishes showing available arguments and defaults from invoking its example with selected values. A listing can help describe the exposed inputs. It does not, on its own, demonstrate every action in the launch description or establish the final state of a node. Preserve the purpose of each supplied output when writing the learning assessment.

This article does not reproduce launch commands or ask the reader to execute the tutorial. A tutor can review the student's source explanation using the provided files alone. If a separate authorized exercise includes actual software execution, its record should identify that environment and observation. Keep the reading result and any execution result separate so that a later reviewer knows what was actually demonstrated.

What should the final explanation retain?

Record the file identities, argument name, declaration, caller-supplied value where present and the location where the configuration is used. Explain what is known from the source and what would require an evaluation record. If the materials disagree, preserve both versions and ask which invocation the lesson intends to discuss. Avoid filling an empty observation field with a convenient default.

A good review question asks the learner to explain why the default is relevant and why it may not be the value for the supplied parent example. That tests the relationship between the files instead of memorization of a literal. It also gives a tutor a specific basis for requesting a correction when the source path remains unclear.

Both links use the Jazzy documentation route; an actual lesson should retain its own version context. The original illustrations depict no launch trace or node output. Continue through the robot learning collection and article directory. A precise Launch Argument note makes defaults, supplied values and evaluation evidence understandable without claiming an execution that never occurred.