Why the Project Has Not Chosen Nav2-First Integration
A natural question about ~/project-a/ros2-fleet-coordinator/ is why a ROS 2 multi-robot project did not integrate Nav2 from the beginning. Maps, localization, planning, and Nav2 are familiar parts of robot navigation, so a small demo without them can look excessively simplified. The answer follows from the project’s current objective and verification boundaries: first establish the fleet coordination flow.
The current objective
According to README.md, STATUS.md, and TECHNICAL_APPROACH.md, V1 is a verifiable fleet coordination prototype built on a graph model. Its chain is: submit a transport task, let the manager choose a robot, translate the task into a route, and let an agent advance along that route and report completion.
The central concepts are transport tasks, waypoint routes, assignment lifecycles, and execution feedback. These are coordination semantics. Continuous-space navigation belongs to another layer. The integration order is therefore a question of priorities.
What the present system actually models
A discrete graph planner
The technical approach describes a waypoint-based environment and an unweighted demo graph for which BFS is sufficient. The planner reads graph_waypoints and graph_edges, computes start -> pickup -> dropoff, and returns discrete route_waypoints. It translates a transport request into a graph route. It does not implement a full navigation stack.
An execution-state simulator
The agent receives TaskAssignment, stores the route, advances its route index on a timer, publishes idle, executing, and completed, and fills pose from waypoint coordinates. It does not perform local obstacle avoidance, continuous trajectory generation, control output, localization fusion, or recovery behavior. It simulates task execution semantics. This distinction is essential to evaluating the architecture fairly.
What early Nav2 integration would add
Coordination and navigation configuration would arrive together
The current questions are whether an assignment forms, whether the agent consumes its route, whether completion returns to the manager, and whether the robot becomes available again. Adding Nav2 immediately introduces costmaps, global and local planner configuration, lifecycle nodes, localization dependencies, controller tuning, behavior trees, recovery, and action timing.
These are real engineering concerns, but they would complicate failure attribution while the coordination chain is still being validated. A failure could come from task allocation, navigation configuration, localization, maps, action feedback, or the runtime environment.
The verification surface would expand
The DDS sandbox article already shows that runtime verification depends on environmental conditions. A navigation integration would add action-server/client connectivity, localization stability, map/planner consistency, recovery behavior, and synchronization between navigation results and fleet state. System complexity and environmental complexity would increase together.
Agent responsibilities would become harder to separate
At present, the manager assigns, the planner supplies routes, and the agent reports execution. With an early Nav2 bridge, it becomes necessary to distinguish task lifecycle management from action forwarding, scheduling failures from navigation failures, and transport-task completion from navigation-action completion. Those distinctions matter, but they are not the first complexity the current project needs to absorb.
Why graph, BFS, and a simulated agent fit this stage
The simplified model is a deliberate way to validate coordination with a small set of moving parts. For a pickup/dropoff task, the manager currently needs the robot’s discrete location, pickup and dropoff waypoints, and an explainable connecting path. A waypoint graph provides that information.
On an unweighted graph, BFS finds a minimum-hop route. With a fixed graph and neighbor order, its behavior is repeatable, easy to debug, and easy to connect to the engineering analysis in this blog. That interpretability is valuable at this stage.
The simulated agent turns a static assignment into observable progress and a completion event. Establishing this feedback path gives the coordination layer a testable foundation before introducing a physical execution stack.
Graph topology and waypoint coordinates are launch-time parameters. Route logic, map content, and execution feedback already have some separation, which leaves room to replace the execution layer later.
Where Nav2 fits in the roadmap
Nav2 remains relevant. The documented order is to verify assignment/completion flow, introduce conflict reservations, improve scheduling, add visualization, and then consider heavier navigation integration. This first clarifies the coordination state model, then shared fleet resources, and finally a more realistic execution layer.
Will the current work survive that integration?
The project has already established Task, TaskAssignment, RobotState, manager dispatch semantics, the manager/planner boundary, and execution/completion feedback. Those higher-level coordination concerns are not automatically supplied by Nav2.
A later integration would likely replace the simplified agent execution with a bridge to real navigation while retaining much of the coordination structure. Interface details and state granularity would change, but the project would not necessarily need to be rewritten from scratch.
An open architectural point is that postponing Nav2 does not mean rejecting it. It means first separating the responsibilities of fleet coordination from those of navigation.
The accompanying articles establish manager allocation, discrete route generation, agent feedback, V1’s actual scope, the next reservation challenge, and environment-dependent verification. Against that background, the current integration order follows the question the project is trying to answer: can tasks, assignments, routes, and feedback form a coherent fleet coordination chain? The graph, BFS, and simulated agent provide a controlled way to answer that before navigation-stack integration adds its own dependencies.
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. All the images used in the blog are my original works or AI works, if you want to take it,don't hesitate. Thank you !