Congestion-aware traffic planning for dense and narrow industrial environments

本文转载自 ROS Discourse，原文链接：Congestion-aware traffic planning for dense and narrow industrial environments

Background

I am evaluating Open-RMF for a dense industrial production environment similar to a semiconductor fabrication facility.

The environment contains:

• Many AMRs operating simultaneously
• Long and narrow bidirectional corridors
• Bottleneck sections that can accommodate only one or two robots
• Limited passing and pull-aside space
• Robots dynamically entering the traffic system
• Frequent route overlap, negotiation, stop-and-go behavior, and deadlock risk

In this type of environment, minimizing the travel time of each individual robot is not the main objective.

We can accept longer travel distances and additional travel time if the overall traffic flow becomes more stable.

Problem

When routes are strongly biased toward minimum travel time, multiple robots tend to select the same shortest corridors.

This causes traffic to concentrate at bottlenecks and leads to:

• Repeated head-on conflicts
• Frequent negotiation
• Excessive waiting near narrow corridors
• Oscillating route decisions
• Local congestion spreading to other areas
• Increased probability of deadlock as more robots enter the system

Negotiation can resolve some individual conflicts, but it occurs after robots have already selected conflicting routes.

For dense and predictable industrial traffic, I believe many conflicts should be prevented during route planning and corridor admission rather than handled repeatedly through negotiation.

Desired behavior

The traffic system should:

• Prefer a longer route when the shortest route is expected to become congested
• Distribute robots across alternative corridors
• Penalize routes that substantially overlap existing itineraries
• Avoid opposite-direction entry into narrow corridors
• Reserve bottlenecks before a robot enters them
• Limit the number of robots admitted into a constrained area
• Use designated holding points when access is temporarily unavailable
• Replan only the affected group of robots when traffic conditions change
• Use negotiation mainly as a fallback for unexpected conflicts

A possible route evaluation function could be:

route_cost = travel_time + predicted_lane_occupancy + route_overlap_cost + opposite_direction_conflict_risk + bottleneck_entry_cost + expected_waiting_time + negotiation_risk + deadlock_risk

The weights could be configured so that traffic stability is prioritized over minimum travel time.

Possible architecture

My current assumption is that a robust solution would require several cooperating layers.

1. Schedule-aware route planning

The planner generates multiple feasible route candidates and evaluates them against committed and predicted traffic.

A slightly longer route should be selected when it significantly reduces future conflicts.

2. Bottleneck reservation and admission control

Narrow corridors should be treated as shared resources.

The system should be able to:

• Reserve a corridor direction
• Prevent opposite-direction entry
• Limit the number of admitted robots
• Queue robots at appropriate holding points
• Release the reservation after the corridor is cleared

3. Localized replanning

When a new robot enters or a substantial delay occurs, the system should replan the locally affected participants rather than always keeping every existing itinerary fixed or globally replanning the whole fleet.

4. Negotiation as a fallback

Negotiation should resolve unexpected spatiotemporal conflicts, but predictable bottleneck congestion should ideally be prevented before negotiation becomes necessary.

Questions for the Open-RMF community

1. Is this division of responsibility appropriate for Open-RMF?
2. Should schedule-aware congestion avoidance be implemented in the path planner, in a separate route-candidate evaluator, or in the negotiation proposal evaluator?
3. Is generating multiple route candidates and evaluating them against the traffic schedule preferable to directly modifying the A* accumulated cost?
4. Are mutex groups sufficient for directional narrow-corridor control, or is a separate corridor reservation and admission-control mechanism required?
5. Is there a supported way to trigger localized replanning of the participants affected by a newly added robot?
6. Which parts can realistically be implemented in the legacy rmf_traffic system?
7. Would the next-generation Open-RMF traffic-management interfaces provide more appropriate extension points for congestion-aware planning, bottleneck reservation, and alternative traffic algorithms?

I would appreciate feedback on the recommended architecture and on how the responsibilities should be divided between graph design, path planning, schedule evaluation, corridor reservation, localized replanning, and negotiation.

1 post - 1 participant

Read full topic