DDS Sandbox Restrictions and the Limits of ROS 2 Runtime Verification

Some behavior that remains unverified in this project is blocked by restrictions on ROS 2 communication in the execution environment, rather than by a demonstrated application-logic defect.

Keeping those categories separate matters. Otherwise, a working application path may be dismissed as incomplete, or an environment-specific discovery problem may send us repeatedly editing the wrong layer.

The project’s BUGS.md and STATUS.md record the distinction: DDS socket restrictions affect the sandbox, and an independent ros2 service call can remain stuck waiting for discovery. In a normal shell, however, end-to-end demo submission and recovery after planner rejection have been exercised successfully. These are the results recorded for this stage of the project, not a claim that every later environment behaves identically.

The Question at This Stage

The goal is practical: when a ROS 2 system runs in a restricted environment, how do we decide whether application code has failed or the available verification path has reached an environmental limit?

ros2-fleet-coordinator depends on several nodes, topic communication, service discovery and calls, and launch-time filesystem writes. Blocking any one of those layers can make the whole system appear disconnected. The diagnosis must identify which layer actually failed.

What Happened in the Sandbox?

Nodes could start, but DDS reported socket-permission restrictions. A separate ros2 service call /submit_task ... client waited for service discovery without completing.

There was also an earlier filesystem issue: ros2 launch tried to write under ~/.ros/log, which was read-only in the sandbox. ROS_LOG_DIR had to point to a writable workspace directory.

Layer One: The Launch Log Directory

Without addressing the log location, launch itself can fail. The documented workaround was:

1

export ROS_LOG_DIR=/home/bruce/project-a/ros2-fleet-coordinator/fleet_ws/log/ros

This is a filesystem-permission issue with a direct workaround.

Layer Two: DDS Discovery and Sockets

The communication restriction is more significant. It affects whether participants discover one another and whether an independent CLI client can connect to the service.

The resulting symptom can be misleading: the nodes appear to be running and produce logs, but a CLI-driven runtime check cannot complete. That looks much more like an application fault than a simple log-directory error.

Why It Is Easy to Blame the Application

When launch succeeds but a service call waits indefinitely, plausible first suspicions include an unregistered service, a broken manager callback, a misspelled service name, or a disconnected task pipeline.

Those possibilities should be investigated, but the project documentation does not simply label the observed sandbox behavior as unfinished application code. It records an environment limitation, with no corresponding application-code fix established.

The distinction is between the system behavior we are trying to test and the mechanism available to observe it. If that mechanism is blocked, changing scheduling logic may accomplish nothing.

What Has Actually Been Verified?

According to the status recorded for this stage:

• fleet_msgs, fleet_manager, robot_agent, path_planner, and fleet_bringup build successfully.
• demo.launch.py starts the node set in a normal shell.
• submit_demo_task.sh submits a demo task through ros2 run.
• submit_task accepts the request, and the manager queues and assigns it to an idle robot.
• The planner returns a route on the configured graph.
• The agent advances through the waypoints and reports completion.
• check_planner_failure_path.sh verifies that a valid later task can still complete after planner rejection.

These are recorded runtime results, not merely intended behavior. The project is therefore more than a collection of packages that compile: its main task lifecycle has been exercised, in an environment that supports the required communication.

What Remains Outside That Evidence?

The incomplete check is more specific: an independent CLI participant in the sandbox cannot finish the discovery path needed for the service call.

That leaves the sandbox-only CLI verification route unproven. It does not establish that the manager cannot receive tasks, that the planner never responds, that assignment handling is absent, or that the system cannot run anywhere.

Conversely, success in a normal shell does not prove that the restricted environment supports the same participant and transport paths.

Four Different Verification Layers

For a multi-node ROS 2 system, these are separate questions:

1. Can the packages build and be discovered?
2. Can launch start the nodes with the available filesystem permissions?
3. Can the main runtime path communicate and complete a task in the tested shell environment?
4. Can a separate sandboxed CLI participant discover and call the service?

The first three have supporting results at this stage. The fourth remains restricted. A statement that verification “passed” or “failed” is useful only when it names the environment and the path that was exercised.

Why the Documentation Structure Helps

BUGS.md tracks the environment block as a distinct issue, while STATUS.md separates the normal-shell results from the sandbox limitations.

That organization prevents several mistakes: rolling back a working implementation because of environmental noise, treating a successful demo as proof of every deployment scenario, and losing track of which conclusions come from evidence versus assumptions.

Clear attribution can be more valuable than a single undifferentiated label saying that everything is fixed or broken.

What Comes Next?

The main application path has been demonstrated, while stronger scheduling and conflict handling remain functional development areas. Runtime verification itself also has boundaries that must remain explicit.

This leads naturally to the next design question: why has the project not adopted a Nav2-first integration? A graph, BFS planner, and simulated agent keep the current coordination problem visible. Introducing a larger navigation stack before the existing environment boundaries are understood would add more possible failure layers.

The central lesson is that a failed ROS 2 runtime check does not automatically prove failed application logic. Here, the unresolved sandbox path concerns DDS discovery and socket restrictions, while the main lifecycle has been verified in a normal shell.

• ← Previous Post
• Next Post →