Crossroads - A Time-Sensitive Autonomous Intersection Management Technique Edward Andert, Mohammad Khayatian, Aviral Shrivastava Arizona State University

Testbed for our Scale Model “1/10 scale” model of an intersection Arduino Mega 2560 is used as the main controller. Arduino Nano is used for monitoring encoder data. Network is handled by 2.4GHz transceivers. Intersection manager platform a laptop and program is implemented in Matlab®

Model Specifications Single lane intersection 𝐿𝑎𝑛𝑒 𝑊𝑖𝑑𝑡ℎ = 0.605 m Request line distance from intersection= 3 m 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝐿𝑒𝑛𝑔𝑡ℎ = 0.568 m 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝑊𝑖𝑑𝑡ℎ = 0. 296 m 1 Request Line 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐿𝑖𝑛𝑒𝐷𝑖𝑠𝑡 𝐿𝑎𝑛𝑒 𝑊𝑖𝑑𝑡ℎ 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝐿𝑒𝑛𝑔𝑡ℎ 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝑊𝑖𝑑𝑡ℎ

Velocity Transaction Intersection Management When a vehicle reaches request line, transmits its current and destination lane, speed and position. Intersection Manager processes the received data and returns a target velocity to vehicle. Vehicle execute the command when the receives the new target velocity. We will call this “Velocity Transaction Intersection Management” or VT-IM. 1 Request Line 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐿𝑖𝑛𝑒𝐷𝑖𝑠𝑡 𝐿𝑎𝑛𝑒 𝑊𝑖𝑑𝑡ℎ One way to implement, define charecteristics

VT-IM (Velocity Transaction Intersection Management) Intersection Manager Request Line Enter Exit 𝑉 𝑇 = 3.0 𝑉 𝑇 = 2.5 When the car reaches the request line, sends its info (speed, in/out lane, position, ID, etc.) to IM. IM processes the data considering the other cars which are already in the intersection and send back the target velocity to the car. Car tracks the received target velocity as soon as it receives the command.

VT-IM Pseudo-Code Vehicle Code: Intersection Manager Code: 1 SendRequest(){ // Sends request to enter the IM Transmit([ 𝑇 𝑖 , 𝐷 𝑇𝑜𝑖 , 𝑉 𝑖 , LI, DI, LO, DO]); Wait(until_response); Receive( 𝑉 𝑇 ); Set( 𝑉 𝑇 ); } 6 Interrupt(request line crossed){ // Received reply from IM 7 timeElapsed = 0; SendRequest(); 9 Interrupt(timeElapsed > timeout){ //Re-requests if no reply received from IM 10 If( 𝐷 𝑇𝑜𝑖 <= 𝐷 𝑆𝑡𝑜𝑝𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 ) 11 𝑉 𝑇 = 0; 13 SendRequest(); Intersection Manager Code: 1 if(request received) { AddVehicleToQueue(LI, DI, LO, DO); 𝑉 𝑇 = CalculateDesired 𝑉 𝑇 ( 𝐷 𝑇𝑜𝑖 , 𝑇 𝑖 , 𝑉 𝑖 ); send [" 𝑎𝑐𝑐𝑝𝑒𝑡𝑒𝑑", 𝑉 𝑇 ]; 5 } More to algorithm, not present here for berevity

VT-IM Must Account for Position Uncertainty For safe operation, the intersection manager should take into account all kinds of errors and uncertainties in the system. Sensor Error (GPS, encoder, etc.) Time Synchronization Error (Synchronization accuracy, clock precision, etc.) Tracking Error (delays due to dynamics of the system and controller parameter) Error is modelled as a Safety Buffer around the vehicle: 𝑬 𝑳𝒂𝒕 𝑬 𝑳𝒐𝒏𝒈 𝑳 𝑾

How Large is the Safety Buffer Using our real-life implementation, we measured how big a Safety Buffer needed to be. 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝐿𝑒𝑛𝑔𝑡ℎ = 0.568 m 𝐸 𝐿𝑜𝑛𝑔 = 0.15m @ 𝑉 𝑀𝑎𝑥 𝑜𝑓 𝑜𝑢𝑟 1 10 𝑚𝑜𝑑𝑒𝑙, 3.5𝑚/𝑠, 12.6km/h, 7.8 mph 𝑬 𝑳𝒂𝒕 𝑬 𝑳𝒐𝒏𝒈 𝑳 𝑾 We measured worst case error for safety buffer by comparing expected position and actual one.

Large Safety Buffer Lowers Throughput Intersection Manager Request Line Enter Exit 𝑉 𝑇 =1.5 𝑉 𝑇 =3.0 𝑉 𝑇 =2.5

Defining the Timing Problem Round Trip Delay (RTD) is being ignored Caused by computation delay and network delay. Request Position Actual Receive Position (ARP) IM 𝑃 𝑟 Actual Receive Position = 𝑃 𝑟 +(𝑅𝑇𝐷 ∗𝑉) Best Average Worst Worst Case Receive Position Difference Expected Message Receive Position

Time Delays Will Cause Crashes Intersection Manager Request Line 𝑉 𝑇 =3 𝑉 𝑇 =2.5 Depending on network delay and IM computation time, vehicle receives the target velocity with some delays.

Accounting for Delays 𝑳 𝑾 A real intersection manager must also take into account delay in the system. Transmission Delay Computation Delay Summation: Round Trip Delay (RTD) In existing implementations, delays will have to be modeled as additional Time Buffer around the vehicle: 123.791 milliseconds (Source: our implementation) 36.885 milliseconds (Source: our implementation) 150 milliseconds (Source: our implementation) 𝑬 𝑳𝒂𝒕 𝑬 𝑳𝒐𝒏𝒈 𝑳 𝑾 𝑬 𝑫𝒆𝒍𝒂𝒚

Real-life Computation and Network Delay

How Large is the RTD Buffer Using our real-life implementation, we measured how big a Safety Buffer considering RTD needed to be. 𝐸 𝐷𝑒𝑙𝑎𝑦 =3.5×0.15=0.525 ( 𝑉 𝑀𝑎𝑥 𝑖𝑛 𝑜𝑢𝑟 1 10 𝑚𝑜𝑑𝑒𝑙 𝑖𝑠 3.5𝑚/𝑠) 3x 𝐸 𝐿𝑜𝑛𝑔 𝑬 𝑳𝒂𝒕 𝑬 𝑳𝒐𝒏𝒈 𝑳 𝑾 𝑬 𝑫𝒆𝒍𝒂𝒚

How Large is the RTD Buffer Using our real-life implementation, we measured how big a Safety Buffer considering RTD needed to be. 3.46x Original Vehicle Length Adding the safety buffer due to timing error will degrade the throughput.

Our Approach: Crossroads We set the execution location (execution time) according to the Worst-Case Round-Trip Delay (WCRTD) on our system. E𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛 𝑃𝑜𝑠𝑖𝑡𝑖𝑜𝑛=𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝑃𝑜𝑠𝑖𝑡𝑖𝑜𝑛 + 𝑉𝑀𝐴𝑋×(𝑊𝐶𝑅𝑇𝐷) Execution Position Request Position IM Actual Receive Position Best Average Worst Actuation Begins Different animation, show 2 cars with different RTDs being fixed by execution position Fix animation with expected location Actuation Begins Expected Message Execution Position = EP

Crossroads Code Vehicle Code: Intersection Manager Code: 1 SendRequest(){ // Sends request to enter the IM send [ 𝑇 𝑖 , 𝐷 𝑇𝑜𝑖 , 𝑉 𝑖 , LI, DI, LO, DO]; Wait(until_response); Receive 𝑉 𝑅𝑒𝑡 ; Set 𝑉 𝑇 = 𝑉 𝑅𝑒𝑡 ; } 5 Interrupt(request line crossed){ // Received reply from IM 6 timeEapsed = 0; 7 SendRequest(); 8 } 9 Interrupt(timeEapsed > timeout){ // Re-requests if no reply from IM 10 If( 𝐷 𝑇𝑜𝑖 <= 𝐷 𝑆𝑡𝑜𝑝𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 ) 11 𝑉 𝑇 = 0; 13 SendRequest(); Intersection Manager Code: 1 if(request received) { AddVehicleToQueue(LI, DI, LO, DO); 𝑉 𝑇 , 𝑇 𝑜𝐴 = CalculateDesired( 𝐷 𝑇𝑜𝑖 + ( 𝑉 𝑀𝑎𝑥 ∗ WCRTD), 𝑇 𝑖 , 𝑉 𝑖 ); send [" 𝑎𝑐𝑐𝑝𝑒𝑡𝑒𝑑", 𝑉 𝑇 @ 𝐸𝑥𝑒𝑐𝑢𝑡𝑖𝑜𝑛𝐿𝑖𝑛𝑒, 𝑇 𝑜𝐴 ]; 5 } IM calculates the desired Time of Arrival, T oA, and the execution time, TE, (actuation position PE) based on WCRTD Fix this slide

Crossroads Eliminates Time Buffer Unlike the VT-IM methodology, Crossroads does not require a Time Buffer ~ 3.5x Original Vehicle Length -> ~ 1.5x

AIM (Autonomous Intersection Management) A tested and effective FCFS (First Come First-Served) policy Dresner and Stone propose and IM that: Vehicle requests to entire intersection at ToA and VoA IM simulates the trajectory of the vehicle Responds YES if the trajectory has no overlap with the reserved spots of other vehicles Responds NO otherwise. Must state problem - RTD is ignored – the problem is RTD is ignored

AIM is a query-based approach Intersection Manager Request Time of Entry, (TOE) Velocity of Entry Receive Accept Request Line Enter Exit Vehicle Begins Actuation of Proposed TOE Explain timing problem and how it is solved

AIM is a query-based approach Intersection Manager Request Time of Entry, (TOE) Velocity of Entry Receive Reject Request Line Enter Exit Vehicle Begins Actuation of Proposed TOE Explain timing problem and how it is solved

Related Work: AIM Vehicle Code: Intersection Manager Code: 1 SendRequest(){ // Sends request to enter the IM send [ 𝑇 𝑇𝑜𝑖 , 𝑉 𝐴𝑒 ]; // Position, Velocity, Lane of // Entry, Direction of Entry, Lane of Exit, Direction of exit Receive 𝑉 𝑅𝑒𝑡 ; Set 𝑉 𝑇 = 𝑉 𝑅𝑒𝑡 ; } 5 Interrupt(request line crossed){ // Received reply from IM 6 timeEapsed = 0; 7 SendRequest(); 8 } 9 Interrupt(timeEapsed > timeout){ // Re-requests if no reply from IM 10 If( 𝐷 𝑇𝑜𝑖 <= 𝐷 𝑆𝑡𝑜𝑝𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 ){ 11 𝑉 𝑇 = 0; 12 } 13 SendRequest(); } Intersection Manager Code: 1 if(request received) { SimulateIfSafe( 𝑇 𝑇𝑜𝑖 , 𝑉 𝐴𝑒 ); send ["accepted" 𝑜𝑟 "𝑑𝑒𝑛𝑖𝑒𝑑"]; 5 }

Related Work: AIM Aim was tested virtually with 1 real and a number of simulated autonomous vehicles for the Darpa 2007 challenge AIM was implemented in real life with Four 1/10 scale vehicles Vmax .5m/s, or at scale 18 km/h so they may have missed the problem √ Achieves a theoretical throughput of .5 vehicles/lane/s. √ Considers a Safety Buffer X Computation time is large X High communication overhead X Many re-requests X Cannot efficiently schedule vehicles AIM communication overhead AIM cannot re-schedule effeciently

Scale Model Test Setup Performed 10 intersection scenarios, 2 planned, 8 randomized – repeated each scenario 10 times 𝐿𝑎𝑛𝑒 𝑊𝑖𝑑𝑡ℎ = 0.605 m 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐿𝑖𝑛𝑒𝐷𝑖𝑠𝑡 = 3.0 m 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝐿𝑒𝑛𝑔𝑡ℎ = 0.568 m 𝑉𝑒ℎ𝑖𝑐𝑙𝑒 𝑊𝑖𝑑𝑡ℎ = 0.296 m 𝑉 𝑀𝑎𝑥 = 3.0 m/s 1 Request Line 𝑅𝑒𝑞𝑢𝑒𝑠𝑡 𝐿𝑖𝑛𝑒𝐷𝑖𝑠𝑡 𝐿𝑎𝑛𝑒 𝑊𝑖𝑑𝑡ℎ

Results of Scale Models Boundary Cases: SB – SafetyBuffer, TD – TransmitDistance, VL – Vehicle Length Intersection Scenario #1 Heavy Traffic Load Intersection Scenario #10 Light Traffic Load Scenario 1 Scenario 10 Not to scale Not to scale

Crossroads Performs Better in Scale Tests Car arrival scenarios instead Heavy Traffic INTERSECTION SCENARIO NUMBER Light Traffic

Simulation in Matlab, N=160

Crossroads Performs Better in Simulation .35 Traffic Light Max Flow .5 Round- about Light Max Flow Figure out ideal that is possible Mark interesting region Mark traffic signal limits Spend more time, add more slides

Conclusion An Intersection Manager (IM) must account for position uncertainty as a Safety Buffer Position uncertainty comes from sensors, actuators, etc. An IM must account for timing problems as Time Buffer Computation Delay Network Delay AIM approach solves timing problem with a yes/no approach. Our technique (Crossroads) eliminates the Time Buffer It is replaced by timestamp-based execution Crossroads maintains high schedulablility in addition to safety, thus increasing throughput 1.62x Crossroads vs VT-IM and 1.36x Crossroads vs AIM on average Missing main points Needs work