# Making Autonomous Vehicles Agree at Intersections

Hi, I am [Mathesh](https://mathesh.me/). I have been working on this project for the last few months at [UC Santa Cruz](https://ucsc.edu/), with guidance from Professor Mohsen Lesani, and I wanted to share the current updates and findings from my research. My broader interest is in distributed systems, especially peer-to-peer and edge computing infrastructure, and this project sits at the intersection of autonomous vehicles, wireless communication, and distributed consensus.

The central question I started with was whether autonomous vehicles can coordinate with each other at an unsignalized intersection without depending on traffic lights, cloud control, or a central roadside unit. At first this looks like an AI problem, because the vehicle needs perception, planning, and control. But when I looked closer, the hard part was not only deciding what one vehicle should do; it was deciding how multiple vehicles should agree on a shared action under time pressure.

Humans already do a loose version of this. At a signalized intersection we mostly obey the light, but when there is no signal we coordinate through arrival order, road rules, emergency-vehicle priority, hesitation, eye contact, or small gestures. That informal negotiation is basically a consensus problem. For autonomous vehicles, I wanted to explore whether that negotiation can be replaced with a deterministic vehicle-to-vehicle protocol.

Autonomous vehicles like Tesla and Waymo are already strong at many perception and control tasks, but intersections still create difficult edge cases. In those cases, relying only on probabilistic decisions from isolated agents feels weak. A better direction is to let vehicles communicate their intent, agree on a pass order, and then execute that decision consistently.

There are already real examples showing why this matters. During a San Francisco blackout, reports showed Waymo vehicles blocking roads after traffic signals stopped working. I am not using that as a criticism of one company; I am using it as a reminder that autonomy needs coordination when infrastructure becomes unreliable. You can read one of the reports [here](https://www.nbcnews.com/tech/tech-news/videos-show-waymo-self-driving-cars-blocking-roads-san-francisco-black-rcna250483).

This problem is not limited to vehicles. Any autonomous system where multiple agents share physical space eventually needs mutual decision-making. Warehouse robots, drones, delivery bots, manufacturing robots, and autonomous vehicles can all be locally intelligent, but local planning does not automatically produce safe group behavior. If two agents both decide that their own next move is valid, the system can still deadlock, block a path, or create unsafe motion.

This short clip shows the same coordination failure at a smaller scale. It is not from my vehicle simulation, but it captures the reason this research is interesting beyond V2V. The issue is not only whether one autonomous agent can sense and plan; the harder question is whether a group of autonomous agents can agree on what should happen next when they share the same physical space.

[![](https://img.youtube.com/vi/oSNIcwXwAwg/hqdefault.jpg align="center")](https://youtube.com/shorts/oSNIcwXwAwg?feature=share)

_Watch the clip: [autonomous robots stuck in a coordination conflict](https://youtube.com/shorts/oSNIcwXwAwg?feature=share)._

## Why intersections?

I chose unsignalized intersections because they are a good baseline problem. They are small enough to simulate and reason about, but still hard enough to expose the issues that matter in real deployments: wireless packet loss, changing membership, partial visibility, fairness, priority handling, and real-time decision-making. If a coordination protocol cannot work in this constrained setting, it is unlikely to work in a larger autonomous traffic environment.

There is also a clear safety motivation. The 2023 FARS table below shows 11,843 intersection fatalities in traffic crashes, which makes intersection coordination a concrete safety problem rather than only an academic distributed systems exercise.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/45b99f96-c40d-45db-81f5-0c20fafeab2e.png align="center")

_Figure 1: 2023 FARS intersection fatality data used to motivate why intersection coordination is a safety-relevant problem._

At a high level, every vehicle has local perception. It can observe its own lane, position, speed, acceleration, and nearby vehicles, but local perception is not always enough. At an intersection, the safety of one vehicle depends on what other vehicles intend to do next, so the decision needs to be coordinated rather than purely local.

This is where the pipeline changes. Traditional autonomous driving is often discussed as PCDA: Perception, Collection, Decision, Action. Prior work in this area, including [this IEEE paper](https://ieeexplore.ieee.org/document/10041971), frames the coordination problem as PICA: Perception, Initiative, Consensus, Action. The important addition is the consensus stage, where a vehicle does not simply decide alone; it participates in a protocol that produces a shared decision.

## What is the goal?

The goal of this project was to evaluate whether a group of autonomous vehicles approaching an unsignalized intersection can exchange enough state to agree on a safe pass order with low latency and low wireless overhead. The output of the system is a pass queue. Once that queue is committed, vehicles execute the crossing order instead of independently guessing who should move first.

Each vehicle proposal contains the fields needed to reason about the next crossing decision:

* vehicle id
* lane id
* position
* speed
* acceleration or deceleration
* expected turn direction
* priority flag, for example ambulance or police vehicle

This sounds straightforward with four vehicles, but it becomes much harder with 20 or 50 vehicles because the communication layer becomes part of the algorithm. In a data center, consensus protocols can assume relatively stable links, controlled membership, and reliable infrastructure. In vehicle-to-vehicle communication, the network is wireless, shared, lossy, and changing while the protocol is running.

That network constraint is the biggest bottleneck. The system needs decisions on a sub-second timeline, but it cannot depend on data-center style infrastructure. Vehicles communicate over broadcast wireless channels, where messages can collide, delivery can be asymmetric, and two vehicles in the same physical intersection may not hear the same set of neighbors. That makes V2V coordination an edge distributed systems problem, not just an autonomous driving feature.

For this project, I used IEEE 802.11p / WAVE as the wireless model. 802.11p is the Wi-Fi-derived vehicular communication standard behind DSRC-style V2V and V2I communication. It is designed for short-range, low-latency exchange between vehicles and roadside units, usually in the 5.9 GHz ITS band, and it supports infrastructure-less broadcast. That matters for this problem because vehicles at an unsignalized intersection should not need to associate with an access point or wait for a cellular round trip before exchanging safety-critical state.

There are newer V2X directions as well. C-V2X introduced cellular sidelink communication, 5G NR-V2X extends that direction for more advanced connected and automated driving use cases, and IEEE 802.11bd is the next-generation evolution of the 802.11p family. These technologies are important, but the goal of this project was not to benchmark radio standards. I chose 802.11p because OMNeT++ and Veins have mature support for it, it gives a realistic lossy broadcast model, and it is a conservative baseline for testing whether the consensus protocol itself can survive wireless contention, packet loss, and partial visibility. If the coordination layer cannot work over this kind of constrained V2V channel, moving to a newer radio will not automatically solve the distributed systems problem.

## Simulation setup

To test this properly, I built my application logic on top of a simulation stack using OMNeT++, Veins, and SUMO. SUMO handles the mobility side: vehicles entering lanes, slowing down, stopping, turning, and crossing the intersection. OMNeT++ and Veins handle the network side, including WAVE / IEEE 802.11p communication, which is closer to realistic vehicular wireless behavior than an ideal in-memory network.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/75fb56c5-685a-4700-b92d-9e50472a3f8f.png align="center")

_Figure 2: SUMO mobility simulation with an OpenStreetMap-based road network and vehicle movement around the intersection._

The simulation includes:

* IEEE 802.11p broadcast messaging
* channel contention
* packet loss
* wireless latency
* calibrated urban path loss
* Nakagami multipath fading
* building and vehicle obstacle shadowing
* SINR-based packet delivery
* OpenStreetMap-based road layouts

I collected telemetry from each run so that I could evaluate the protocol as a system rather than only as an algorithm. The telemetry included vehicle position, speed, acceleration, lane, turn intent, message latency, packet delivery, decision latency, total wait time, and sent/received message counts. The point was not just to implement a protocol and assume it works; it was to observe where a data-center-style protocol starts breaking in a fast-moving wireless edge environment.

## Baseline: all vehicles participate in consensus

The first version was intentionally simple. Every vehicle broadcasts its status, collects the status of other vehicles, and participates in a consensus process. I used Raft as the baseline because it gives a clean structure for leader election, quorum acknowledgement, and committing a decision.

In this setting, the simplified Raft-style flow is:

* elect a leader
* have the leader collect status from participants
* compute the next pass order
* commit the decision after quorum acknowledgement, where quorum means a majority of participants, roughly 51 percent or `(n / 2) + 1` votes
* broadcast the committed decision back to the group

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/07c32933-93dc-4fe2-bc27-1f2b5c0e4cbb.png align="center")

_Figure 3: Baseline all-vehicle Raft flow where every vehicle participates in status collection, consensus, and quorum acknowledgement._

This was a useful baseline, but it also exposed why directly applying data-center consensus to vehicles is difficult. Raft was designed for a very different environment: relatively stable nodes, reliable links, and membership that does not change every second. Vehicles at an intersection are not data-center nodes, and as the number of vehicles grows, every participant has to send more, receive more, reply more, and wait for more acknowledgements.

The wireless plots were useful while debugging because they made the network behavior visible. Channel utilization showed when vehicles were actively using the shared WAVE channel, and in these runs it stayed close to 50 percent, so the channel was busy but not in an obviously broken state. SINR showed how signal quality changed over time. Together, these plots revealed an important point: the issue was not simply that the channel was always saturated or that SINR was always terrible. Even when the channel did not look completely overloaded, the protocol could still fail because vehicles did not share the same communication neighborhood.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/45c67c5e-a3aa-4880-b77e-9242365a0e4a.gif align="center")

_Figure 4: Channel utilization over simulation time, showing when vehicles are actively using the shared WAVE wireless channel._

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/af3ae202-be86-44cc-906d-679f2f23bcd0.gif align="center")

_Figure 5: SINR variation over time, used to understand signal quality and packet delivery behavior in the wireless model._

As density increased, the all-vehicle design became increasingly expensive. More vehicles meant a larger consensus group, more status messages, more replies, and more quorum pressure. The protocol was not only doing more work; it was doing more work on a wireless channel where delivery is already fragile.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/29406adb-c09d-4141-8231-033d3a40a59e.png align="center")

_Figure 6: Scaling issue in the all-vehicle approach as more vehicles enter the intersection and the consensus group keeps growing._

## What went wrong with the vanilla method

With a small number of vehicles, all-vehicle Raft works reasonably well. The problem appears as vehicle density increases. Wait time grows, and the number of received messages grows aggressively because every vehicle is trying to participate in the same coordination process. At that point the protocol is no longer just computing a pass order; it is also creating wireless load that makes the pass order harder to commit.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/6cf14626-0824-41a7-8c00-a134643c1f3e.png align="center")

_Figure 7: Wait-time CDFs and message growth for vanilla all-vehicle Raft under increasing vehicle density._

The reply delivery rate shows the issue even more clearly. At 4 vehicles, reply delivery is perfect. At 8 vehicles, it is still high. By 16 vehicles, it is already close to the risk region, and at 20 vehicles the median plotted delivery rate drops to 52 percent, with some minimum values going below 40 percent. That is a dangerous region for a quorum-based protocol because Raft needs a majority of votes to commit. Once delivery is hovering around the 50 percent boundary, and sometimes falling well below it, a small amount of loss or asymmetry can stop the leader from collecting enough acknowledgements on time.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/bd3b7819-3520-4f5e-b088-42502ddb3957.png align="center")

_Figure 8: Reply delivery rate drops as fleet size increases, making quorum-based coordination harder in the all-vehicle design._

Adding more participants does not automatically make a wireless consensus decision stronger. If the additional participants increase contention and reduce reply delivery, they make the decision harder to finish. In the all-vehicle design, the system was asking every vehicle to participate in a process that only a smaller set of vehicles actually needed to decide the next crossing order.

The next problem is communication range. The image below shows the basic issue: every vehicle has a limited wireless neighborhood, so broadcast does not mean "everyone in the intersection receives the packet." A vehicle near the center may hear several approaches, while a vehicle farther back in one lane may only hear vehicles on its own side of the intersection. Vehicles on opposite arms may be outside each other's reliable range, and buildings, other vehicles, multipath fading, and road geometry can reduce delivery even when they look physically close.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/4602b47a-bbc7-4875-9910-11936d705d09.png align="center")

_Figure 9: Wireless communication range creates partial visibility because each vehicle only receives broadcasts from the vehicles inside its effective radio neighborhood._

This means each vehicle builds its own local view of the intersection. One vehicle may know about nine nearby proposals, another may know about six, and another may only know about the vehicles directly ahead or behind it. For all-vehicle Raft, that is a serious problem because the leader is trying to collect acknowledgements from a membership set that may not be equally visible to every participant. Some nodes may never receive the request, some replies may not reach the leader, and different vehicles may believe different sets of vehicles are currently active at the intersection.

So the failure is not only "too many messages." The deeper issue is that the communication graph is local and uneven. Consensus assumes a group that can exchange enough messages to agree, but wireless range turns the intersection into overlapping neighborhoods instead of one fully connected group. This is why forcing every vehicle into one consensus group increases delayed replies, missing acknowledgements, and split views. Wireless range is not a minor networking detail here; it is one of the main constraints shaping the protocol.

## Broadcast can hurt, but it can also help

At first, broadcast looked like the problem. If every vehicle broadcasts and every other vehicle replies, the channel gets crowded, and more vehicles create more contention and packet loss. But broadcast also has a useful property: many vehicles overhear the same information, even when that information does not reach every node directly.

That observation changed the direction of the protocol. Instead of treating broadcast only as a source of congestion, I started using it as a way to spread proposals through gossip. A vehicle that misses a direct proposal may still learn it from another vehicle that heard it, which helps repair partial visibility without requiring every vehicle to become a voting participant in consensus.

The new idea was to use gossip for visibility and selective clustering for agreement. In the current design, selected vehicles are mainly front-of-lane or lane-leader vehicles, because they represent the next movement from each incoming lane. Instead of 20 vehicles participating in Raft, the cluster can stay bounded around four participants for a four-way intersection.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/a0342366-aca4-4932-9cbb-4f792dfc85e4.png align="center")

_Figure 10: Gossip helps spread missing proposals and lets lane leaders build a more complete view without making every vehicle a Raft participant._

If there are not enough lane leaders available, the system can fall back to inviting additional vehicles to participate so that the consensus group still has enough members for fault tolerance. The full fleet still receives the final pass queue, but the expensive decision process is handled by the small group of vehicles that matter most for the immediate crossing decision.

## Final protocol

The final protocol has three main parts: perception, consensus, and action. Vehicles first generate and broadcast signed proposals, then lane leaders use the gossiped proposal set to run a bounded Raft decision, and finally the committed pass queue is broadcast and gossiped back to the fleet. The key difference from the baseline is that consensus is scoped to a small group instead of being run across every vehicle.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/f6b0909e-cb19-4153-9262-176ceb4e2670.png align="center")

_Figure 11: Final protocol design combining perception, signed proposal broadcast, gossip, lane-leader Raft consensus, and pass-queue execution._

The flow looks like this:

1. Each vehicle reads local perception data from sensors and simulation state.
2. It creates a signed proposal containing lane, position, speed, acceleration, turn intent, and priority.
3. Vehicles broadcast proposals over WAVE.
4. Other vehicles receive proposals and verify signatures.
5. Missing proposals are spread through gossip.
6. Lane leaders are selected for the consensus group.
7. The selected group runs Raft to agree on a pass queue.
8. The pass queue is broadcast back to the full group.
9. Vehicles gossip the decision to nodes that may not have heard the first broadcast.
10. Vehicles execute the pass order.

The protocol also includes several engineering pieces that are important in the wireless setting: message compression to reduce load, public/private key authentication for vehicle identity, application-level CSMA/CA to reduce message collisions, fallback cluster invitation when there are too few lane leaders, and batching to improve fairness while reducing repeated computation. The important point is that every vehicle can share state, but only a bounded set of vehicles participates in the core decision.

## How the decision algorithm thinks

The decision algorithm takes proposals and converts them into a pass queue. It collects vehicle proposals, groups vehicles by lane and movement, selects front candidates, accounts for priority vehicles, batches compatible movements, and commits the next pass queue through Raft. This is deliberately simple: the point of the project was not to invent a complicated traffic scheduler first, but to understand whether the coordination protocol could survive realistic wireless behavior.

Batching matters because a strictly one-by-one pass order can be safe but inefficient. If two vehicles do not conflict, the system should be able to schedule them together. Fairness also matters, because a protocol that always favors one lane due to better wireless conditions is not acceptable. The decision logic has to balance priority, arrival order, and lane progress.

## Results

The main result is that clustering reduced the size of the expensive consensus group. In all-vehicle mode, the Raft participant count grows with fleet size; with 20 vehicles, all 20 can become part of the decision process. In cluster mode, the Raft participant count stays around four because only front-of-lane vehicles participate.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/d26d057c-585c-4d78-85a0-d96a547af074.png align="center")

_Figure 12: Cluster mode keeps the Raft participant count bounded while all-vehicle Raft grows with fleet size._

This bounded cluster size is what keeps reply delivery stable. In the plotted runs, cluster mode stayed at 100 percent reply delivery while all-vehicle mode dropped as density increased. The wait-time and message-load results show the same pattern: cluster mode reduced wait time as vehicle density increased and reduced the number of messages each vehicle had to receive.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/e316f580-87ee-4151-b0dd-386eb9a0f8ec.png align="center")

_Figure 13: Cluster mode reduces wait time and received-message load compared with the all-vehicle baseline._

At 20 vehicles, all-vehicle mode had around 1616 received messages per vehicle, while cluster mode had around 535. That difference matters because every extra message competes for the same wireless channel. Reducing received-message load is not only a performance optimization; it directly improves the chance that the coordination protocol can finish within the time budget.

Decision latency also became much more stable. In all-vehicle mode, decision latency increased sharply as the number of vehicles increased, while cluster mode stayed much closer to constant. Throughput improved as well, with cluster mode crossing more vehicles per second than all-vehicle mode, especially at larger fleet sizes. I also tested priority vehicle behavior to make sure that a priority vehicle could benefit from the protocol without completely breaking fairness for normal vehicles.

![](https://cdn.hashnode.com/uploads/covers/6230a03bc4a093f00c8ac11a/7a215898-11dc-4d3f-9939-7d10c990294c.png align="center")

_Figure 14: Cluster mode improves decision latency and throughput while preserving priority-vehicle behavior._

Across these experiments, the overall result was about 2x latency reduction, about 3x throughput improvement, controlled received-message growth, bounded Raft participant count, decision latency around 40 to 50 ms in cluster mode, and 100 percent consensus success in the tested crash-fault tolerant scenarios. The most important point is not just that the numbers improved; it is why they improved. The protocol became aligned with the physical network instead of fighting it.

## Takeaways

The biggest lesson from this project is that distributed systems protocols cannot be moved blindly into wireless mobile environments. Raft is a strong protocol in the environment it was designed for, but an unsignalized intersection has different constraints: membership changes quickly, wireless links are unstable, packet delivery is asymmetric, range creates partial visibility, acknowledgements can create broadcast storms, and decisions have real-time deadlines.

The first version failed because it treated every vehicle as an equal participant in one global consensus group. The improved version worked better because it accepted the physical shape of the system. Vehicles are naturally organized by lane, and the next crossing decision only needs the front candidates. The rest of the vehicles need to learn the decision, but they do not need to participate in the core consensus process.

That is why gossip and clustering fit this problem. Gossip repairs missing information across the wider group, while selective clustering keeps the consensus group small enough to make progress under wireless constraints. The same principle can apply to other autonomous systems too: warehouse robots, drones, humanoid robots, and multi-agent AI systems can all run into the same issue where each agent is locally intelligent but the group still needs a coordination protocol.

The broader question is not only whether each agent can plan. It is whether the group can agree while communication is local, unreliable, and time-sensitive. This is what makes the problem interesting to me as a distributed systems problem rather than only an autonomous driving problem.

## Limitations

This work currently focuses on crash-fault tolerant behavior. It does not solve Byzantine or malicious vehicle behavior, and it assumes L4+ autonomous vehicles that can understand and execute a committed pass order. It also works best in a homogeneous fleet where vehicles follow the same protocol and trust model, which is easier than a mixed environment where every manufacturer has a different stack, message format, and security model.

There is more work needed on formal safety proofs, larger road layouts, mixed traffic with human drivers, adversarial wireless behavior, and real hardware validation. So I do not see this as the final protocol for autonomous intersections. I see it as a practical experiment showing that if we want autonomous systems to coordinate in the real world, the consensus layer has to be designed with wireless physics in mind.

## Conclusion

This project started with a simple question about autonomous vehicles, but it became a project about distributed coordination under physical constraints. The first idea was to run consensus among all vehicles. That was clean, but it did not scale well under realistic wireless behavior because the protocol made the communication problem worse as density increased.

The better approach was to combine gossip with selective clustering. Gossip spreads state, clustering keeps the decision group small, Raft provides agreement inside that bounded group, and the final pass queue is broadcast and gossiped back to the fleet. That combination gave lower latency, higher throughput, and more stable behavior as the number of vehicles increased.

For me, the interesting part is that the same principle may apply beyond vehicles. The core question is how to coordinate many autonomous agents when communication is local, unreliable, and time-sensitive. My current answer is that the protocol should not fight the shape of the environment; it should use it.

The next direction for this research is to make the protocol work under stronger Byzantine settings and connect it with a more complete perception stack. That means moving from "vehicles share honest proposals" toward a system that can reason about faulty or malicious behavior, while still staying fast enough for real autonomous coordination.

If you are interested in this work, want to discuss the protocol, or are working on related problems in autonomous systems and distributed coordination, feel free to email me at [mthiruma@ucsc.edu](mailto:mthiruma@ucsc.edu) or [mati02official@gmail.com](mailto:mati02official@gmail.com).