Package Visible, Launch Still Broken: Move to the Next Layer

Suppose a clean shell reports the correct package prefix:

/home/student/robot_ws/install/robotnix_bringup

That closes one question. It does not prove the installed package contains the correct launch file or all of its runtime dependencies.

Now move one layer deeper.

Verify the installed launch resource

The source file should exist at:

~/robot_ws/src/robotnix_bringup/launch/demo_pair.launch.py

The installed package should also contain the launch resource under its share directory after a successful rebuild.

If:

ros2 launch robotnix_bringup demo_pair.launch.py

reports the file is missing, compare source and install state.

Do not recreate the file manually under install.

Check the install rule

The source CMakeLists.txt should include:

install(
  DIRECTORY launch
  DESTINATION share/${PROJECT_NAME}
)

If that rule is absent, colcon can build the package without installing the launch directory.

Repair the source file, then rebuild:

cd ~/robot_ws
colcon build --packages-select robotnix_bringup
source install/setup.bash

Then retry the launch command.

Check whether the launch source was edited after the last build

Source timestamp or content:

src/robotnix_bringup/launch/demo_pair.launch.py

may be newer than the installed copy.

If the runtime still uses an old default topic name, ask whether the package was rebuilt after the edit.

A correct overlay cannot make stale installed resources update themselves.

Runtime dependencies are another layer

The launch file asks for:

package="demo_nodes_cpp"
executable="talker"

and:

package="demo_nodes_cpp"
executable="listener"

If launch finds robotnix_bringup but cannot resolve demo_nodes_cpp, the bringup package is visible. The dependency is not.

Check:

ros2 pkg prefix demo_nodes_cpp

If it is missing, the launch source is not the first thing to rewrite.

The runtime dependency required by the launch design is unavailable in the current environment.

Package manifest and runtime environment should agree

package.xml should record:

<exec_depend>demo_nodes_cpp</exec_depend>

and relevant launch dependencies.

The manifest documents the requirement. It does not install missing packages by magic in every environment.

A deployment or classroom setup process still needs to ensure dependencies are present.

Python syntax errors are different again

Suppose the launch file is installed and demo_nodes_cpp exists, but launch fails with a Python traceback.

Now inspect:

launch/demo_pair.launch.py

for syntax/import/launch-construction errors.

Do not diagnose DDS, QoS, or topic remapping before the launch description can even be imported successfully.

Use the failure message to identify the stage

The purpose of this table is to stop random repair behavior.

Avoid destructive cleanup as the first reflex

Deleting:

build/
install/
log/

can sometimes be appropriate when generated state is corrupt or a clean rebuild is intentionally needed.

It is not the default answer to every failure.

If the actual problem is:

wrong overlay sourced

deleting build output destroys useful evidence and creates more work without addressing the cause.

Diagnose first.

Worked case: package visible, launch file missing

Evidence:

ros2 pkg prefix robotnix_bringup
-> /home/student/robot_ws/install/robotnix_bringup

Source contains:

launch/demo_pair.launch.py

ros2 launch says the file is missing.

Inspection finds no install(DIRECTORY launch ...) rule in CMakeLists.txt.

Diagnosis:

The package overlay is visible, but the source package does not install its launch directory, so the launch file is absent from the installed package resources.

Repair the install rule and rebuild.

That diagnosis is much more precise than "ROS launch is broken."

Your turn

Create a failure table for these cases:

1. package prefix correct, launch file missing;
2. launch file present, Python import error;
3. launch imports, but demo_nodes_cpp not found;
4. source default topic changed, installed launch still uses old default;
5. build succeeds after repair, but shell still uses an old package prefix.

For each case, record:

• failing layer;
• one evidence source;
• one repair;
• one tempting but unrelated repair to avoid.

In the next lesson, you will move beyond package/launch startup and diagnose a runtime that launches successfully but produces the wrong ROS graph.