Congestion-aware traffic planning for dense and narrow industrial environments

[han30230]

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.

[grey]

Thanks for this detailed description of your use case and requirements. This is very helpful for us while steering the technical direction of the project.

I’ll address your questions from two angles: What we currently offer in the “Original” Open-RMF, and what we’re building up towards for the “Next Generation” Open-RMF.

Original Open-RMF

We definitely recognize that aggressively trying to take the shortest route is often not the most optimal approach for managing traffic. The negotiation system actually does prefer to reroute robots to avoid head-to-head congestion. However it won’t always appear that way for one particular reason: It’s very difficult to always accurately predict when and how bottlenecks will happen. If we use a deterministic model for robot motions, it will often be too optimistic and underestimate the delays that will occur due to congestion. Those underestimations will allow robots to prefer entering congested areas rather than take a longer route because the expectation of deterministic execution implies that the robot will not very long to traverse the congestion, but that expectation is not accurate.

The negotiation system might be more effective at making these judgments if it used a statistical model that could account for uncertainty in delays caused by moving through congested areas. However this is a challenging problem which we weren’t prepared to take on in the original implementation of the traffic system. Instead we recommend using the rmf_traffic_editor to lay out unidirectional lanes to force a consistent flow of traffic and prevent the congestion caused by head-to-head conflicts.

A more flexible/dynamic option to consider is lane closure. You could create lanes that go in both directions but then temporarily close one direction or the other at runtime based on how you want to shape the traffic flow.

Next Generation

We realize that the limits of the Original traffic system will be unappealing for many use cases. Explicitly controlling the flow of traffic along discrete lanes might be more rigid than some users would prefer. A dynamic risk and stability evaluation like what you’ve described might yield better traffic behavior.

It’s unlikely that a one-size-fits-all approach will be feasible for the traffic system. There are many competing multi-agent path finding algorithms out there, and they all have their particular strengths and weaknesses, which might matter more or less in different deployment settings. To account for this, we’re re-architecting Open-RMF to have a modular traffic system. It will be possible to swap out the traffic system for different implementations, and even create third-party traffic systems to plug into an Open-RMF deployment. This should make it more feasible to introduce sophisticated route cost calculations which may be specific to certain use-cases.

[SaMullinsJr]

Hi @han30230,

Your willingness to accept longer routes for more stable overall flow caught my attention. I’m Steven, founder of BAION Systems, where
I’m developing SCF, a field-based coordination substrate. I’m exploring whether it could help with congestion-aware routing in settings
like the one you described.

Following @grey’s suggestions, are you still finding a gap when using one-way lanes or dynamic lane closures? In particular, is the
remaining difficulty deciding when to divert robots or hold them before a bottleneck as conditions change?

If so, would you be open to sharing a simplified corridor layout and one troublesome traffic scenario? A sketch and rough fleet size
would be enough to start a conversation about whether there is a useful evaluation to scope.

Steven Mullins Jr.
BAION Systems | https://baion.dev/

[han30230]

Hi @grey, thank you for the detailed explanation, and apologies for the late reply.

Our main challenge is a narrow bidirectional corridor with no alternative route, but with side bays where robots can move aside and wait. We are currently testing with up to four robots.

We understand the benefits of one-way lanes and dynamic lane closures. However, we would also like to explore whether the Original Open-RMF can coordinate robots to wait before entering the corridor or yield into a bay.

We are experimenting with local joint planning for a small group of robots, but this is still under evaluation.

For this scenario, would you recommend focusing on the negotiation system, the planner’s search for holding-point alternatives, or a separate corridor admission mechanism? A minimal example or relevant discussion would be very helpful.

Thank you for your guidance.

[han30230]

Hi @SaMullinsJr, thank you for reaching out, and apologies for the late reply.

Yes, deciding when and where to hold robots before a bottleneck is a key part of our problem.

Our simplified scenario is a narrow bidirectional corridor with no alternative route, with side bays where one robot can wait while another passes. We are testing with up to four robots, including two robots traveling in each direction. New tasks may arrive while robots are already moving.

We have observed repeated negotiations and situations where robots stop making progress. We are exploring local joint planning, but it is still under evaluation.

Could you explain how SCF would handle this scenario, particularly yielding into bays and deciding the passing order? Do you have a technical overview or demo, and how would it integrate with the Original Open-RMF?

I would be happy to put together a simplified, anonymized layout and one representative scenario for discussion.