Why Conflict Detection and Reservations Are the Next Major Complexity Increase
V1 has established a minimal loop: tasks enter the system, the manager assigns them, the planner returns routes, and agents execute and report completion. The next question is unavoidable once several robots share the graph: how can the system prevent node and edge conflicts?
Both STATUS.md and TECHNICAL_APPROACH.md prioritize conflict reservations next. This article explains why an operational task loop does not yet establish fleet-level feasibility, why reservations affect more than one local function, and which modules they will push to evolve.
When individual correctness stops being sufficient
V1 answers how a task enters, which robot is idle, how to travel from start through pickup to dropoff, and how an assignment becomes execution. It does not yet answer how two execution processes constrain one another. Each robot can carry out its own work; sharing the same space requires an additional model.
The missing semantics
The manager observes robot_states, finds a robot with status == "idle", calls plan_route, and publishes TaskAssignment. The planner accepts start_waypoint, pickup_waypoint, and dropoff_waypoint and searches an unweighted graph. Together they answer whether a robot is available and whether a route exists for that robot in isolation. They do not establish whether the route remains executable in the presence of other robots.
The manager lacks shared-space state
select_idle_robot() traverses robot_states_ and selects the first idle robot. It knows availability and the reported current waypoint. It does not know which waypoints another robot will occupy in future steps, which edges are reserved during a time window, or whether a new task would conflict with an existing one. It is currently a dispatcher; reservation-aware coordination requires more information.
The planner lacks temporal constraints
shortest_path() checks graph membership and connectivity and uses BFS to find a path. It does not ask whether a node will be occupied at the third second, whether an edge is booked between the fourth and fifth seconds, or whether two robots will traverse the same edge in opposite directions. A shortest graph path can therefore be infeasible in time. Static reachability and execution under shared-resource constraints are different problems.
Why a working demo is not almost a conflict solution
It is tempting to think that routes and two working agents need only a few extra conditions. But the existing validation establishes assignment lifecycle behavior: tasks leave the manager, agents consume routes, and completion returns. It does not establish global consistency of shared-space use.
With reservations, correctness also includes preventing competing node claims and overlapping edge traversal, updating plans when a robot is delayed, and ensuring that the manager and planner agree on occupancy. This changes the state the system must maintain.
Three increases in complexity
From static reachability to temporal feasibility
BFS currently asks whether A can reach B. A reservation-aware system asks whether it can reach B within a particular time window, whether edge occupancy overlaps with another robot, and whether the destination waypoint is already reserved at arrival. The model gains a time dimension.
From robot state to fleet resource state
robot_states_ stores recent reports for individual robots. The new model also needs node owners, edge occupancy intervals, the association between assignments and future resource commitments, and rules for updating or releasing commitments after completion, failure, or delay. Shared spatial resources become explicit entities alongside robots, tasks, and routes.
From one dispatch decision to ongoing consistency
Publishing an assignment currently completes the main dispatch action. Reservations raise continuing questions: when are they created, how do they shift when an agent falls behind, how are old reservations removed during replanning, and which resources can be released after completion? A lagging manager cache must not cause premature release or duplicate allocation. Reservation handling accompanies the whole lifecycle; it cannot be reduced to a check immediately before publishing.
Which modules will change?
fleet_manager
The manager will need to decide whether a task can be dispatched now, whether it conflicts with existing commitments, whether it should wait, and who creates and owns its reservations. The relation between assignment lifecycle and reservation lifecycle will likely become explicit.
path_planner
The present PlanRoute request contains start, pickup, and dropoff. Conflict-aware planning eventually needs additional context: unavailable nodes and edges during particular intervals, whether waiting is allowed, and which reservations must be avoided. Even if the first version keeps some reservation logic outside the planner, a purely static BFS interface may not remain sufficient. The planner moves toward generating paths under constraints.
robot_agent
The current agent advances along a route and reports idle, executing, and completed. A reservation model may need to know whether the robot has entered an edge, is waiting for a resource, is behind schedule, or is blocked or deviating. Feedback granularity becomes a system-wide issue. One important observation is that conflict handling can force finer state throughout the system before it requires a sophisticated search algorithm.
Why establish the basic loop first?
Avoiding basic route conflicts is part of the project’s direction, but introducing reservation data structures, constrained planning, delayed dispatch, resource release, and execution deviation before the minimal loop works would combine scheduling, planning, consistency, and timing problems at once. Failures would be difficult to attribute.
The existing sequence first establishes task intake, planning, assignment publication, waypoint execution, and completion feedback. That provides a known baseline without shared-resource constraints. When reservations are added, failures can be investigated against that baseline: resource model, planning constraints, dispatch conditions, or feedback synchronization.
This explains the documented order: verify assignment/completion flow, add node and edge conflict reservations, then improve scheduling.
Why this is a substantial engineering topic
The next stage asks how several nodes maintain a consistent view of occupancy, why a route is feasible in the current fleet state, where first-idle scheduling falls short, and why single-robot planning cannot stand in for fleet coordination. Manager scheduling, planner constraints, agent feedback, and the overall state model all become connected.
The question changes from whether one task can be planned and executed to whether several tasks and robots can coexist on the same graph during the same period. That is the reason reservations represent a major increase in complexity.
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 !