Proposal to add fourth traffic light help transition to autonomous vehicles

[kphoger]

From my perspective, this doesn't require long range v2v, but rather an IR transmitter in taillights.  1 khz modulation should be easy, and sufficient for a simple "emergency brake" message.

Will this be affected by snow buildup on taillights?

[kalvado]

From my perspective, this doesn't require long range v2v, but rather an IR transmitter in taillights.  1 khz modulation should be easy, and sufficient for a simple "emergency brake" message.

Will this be affected by snow buildup on taillights?

AV performance on a snowy road is the first question to ask. From my perspective, slick road would require increased following distance anyway

[kphoger]

From my perspective, this doesn't require long range v2v, but rather an IR transmitter in taillights.  1 khz modulation should be easy, and sufficient for a simple "emergency brake" message.

Will this be affected by snow buildup on taillights?

AV performance on a snowy road is the first question to ask. From my perspective, slick road would require increased following distance anyway

While that is indeed true, snowy roads are not the only place to encounter snow-blocked taillights.

Think of the road-tripper who drives through three hours of snowstorm, then comes out the other side.  Clear roads, no snow falling, but taillights still obscured.

Or think of the farmer who drove, slipping and sliding, five miles on muddy farm roads to get into town during the rainy season.  It could be a perfectly clear day, blue skies, but his taillights are completely obscured by dried mud.  On the other hand, now I'm imagining an autonomous vehicle navigating muddy farm roads to begin with...

[kalvado]

From my perspective, this doesn't require long range v2v, but rather an IR transmitter in taillights.  1 khz modulation should be easy, and sufficient for a simple "emergency brake" message.

Will this be affected by snow buildup on taillights?

AV performance on a snowy road is the first question to ask. From my perspective, slick road would require increased following distance anyway

While that is indeed true, snowy roads are not the only place to encounter snow-blocked taillights.

Think of the road-tripper who drives through three hours of snowstorm, then comes out the other side.  Clear roads, no snow falling, but taillights still obscured.

Or think of the farmer who drove, slipping and sliding, five miles on muddy farm roads to get into town during the rainy season.  It could be a perfectly clear day, blue skies, but his taillights are completely obscured by dried mud.  On the other hand, now I'm imagining an autonomous vehicle navigating muddy farm roads to begin with...

OK, now can you apply all those cases to a situation "I couldn't see lights of that guy, so I didn't realize he stepped on his brakes"? Essentially the same scenario in manual driving.

[kphoger]

OK, now can you apply all those cases to a situation "I couldn't see lights of that guy, so I didn't realize he stepped on his brakes"? Essentially the same scenario in manual driving.

Correct.  However, if I'm following a vehicle with non-working brake lights, then I can remember that for the whole rest of the time I'm following him, and drive accordingly.

[kalvado]

OK, now can you apply all those cases to a situation "I couldn't see lights of that guy, so I didn't realize he stepped on his brakes"? Essentially the same scenario in manual driving.

Correct.  However, if I'm following a vehicle with non-working brake lights, then I can remember that for the whole rest of the time I'm following him, and drive accordingly.

And that is your answer - if communication isn't established treat that other guy as non-cooperative

[Dirt Roads]

^^^^
^^^^
The V2V analogy in railroading is that generally the fifth car back really needs a lot of help dealing with latency times when using onboard fiber optics connected.  (Coincidentally, we have a similar 4-car train length problem in electrical trainlines, except that the voltage drop is the issue rather than latency).  If I use the same rule for autonomous vehicles, the V2V function would be nice between adjacent AVs in a platoon, but would be required between the first AV and the fifth AV (as well as between the first vehicle and preferably all successive AVs behind the fifth one). 

A car-skipping daisy chain arrangement would also work, as long as the last AV in the platoon is close enough to connect the loop comms to the front AV for redundancy.  You can probably come up with a more sophisticated approach (and multiple acceptable approaches), but we are smacking into difficulties with interoperability already. 

One interesting point about Kalvado's I/R approach is that if a following AV can make the data connection with the car ahead, it would be permitted to operate at a say 2-foot spacing.  The front AV needs to communicate its position in the chain, and the next AV needs to properly acknowledge its position before communicating to the next AV behind.  Either the fourth AV needs to shut off its I/R behind, or the fifth AV needs to calculate how far to back off due to accumulated latencies.

Just in case anyone is really taking serious notes, a fair safety warning:  The physics calculations used for calculating "minimum safe braking distance" typically assumes a "safety pad" for speed, detection time, control response time, brake response latency as well as deceleration rate.  But the calculations used for the original BART system and other similar technologies also assume a "runaway" condition whereby the train (or vehicle) is actually at the highest available acceleration rate when the emergency brake actuation occurs.  The industry considers this to be overly cautious, but there are some speed/mass/downgrade situations whereby slippery surfaces (very common on steel rails) and/or certain failures in the brake system do result in some serious consideration for the transition between acceleration and deceleration.  Some or all of this may also apply to the common automobile, but all of my experience with single vehicles is between 4 and 21 tons or so.

[Dirt Roads]

These models have also been computing the accumulated and average delay times for each car in the [northbound] direction of traffic, which includes the amount of time each vehicle is slowed from its normal speeds.  In the process of adding the "Slowed" calculations to the Prioritized "White Aspect" with Random OVs model, I caught something big that needed correcting.  There was one randomly-generated Φ3LT(OV) and it didn't get detected by the model.  The model currently assumes that all Φ3 vehicles are equally spaced at 5-second intervals, and alternating one through and one left turn.  For the record, the 5-second intervals for the Φ4 [northbound] traffic seems to be sweet spot that pushes the traffic controller hard, but the 10-second intervals for other traffic is kind of "mushy" (if you catch my drift).

Anywhoosit, an OV that is truly operating 10 seconds behind an AV, it can't be detected by the traffic controller and allowed to cross traffic safely by flashing up a "white aspect" (so far, no reasons that you can't flash up a G/Y/R countdown except that cross traffic is displaying "white aspects" instead of red*).  Since the [eastbound] Φ8/Φ3LT and the [westbound] Φ7LT/Φ4 (including Φ4RT) are normally displaying red, the traffic signal only needs to detect the OV in the queue and start a countdown timer.  In the normal RYG model, I arbitrarily assumed a 30-second maximum wait time before triggering the opposing yellows and AWR (all-way red), then going into a "clear out" cycle before resuming "white aspect" operations in the priority direction of traffic.  That has an interesting coincidence, in that four Φ3LT vehicles were in the queue prior to the "opposing yellow" and another Φ3LT vehicle entered during that "opposing yellow" to fill the queue.  The remaining traffic encountered only a few slight delays and slowings while the queue was stacking up.  The OV got hit with a 42-second delay plus an additional 2 seconds of slowing (at 55MPH at roughly 10 MPHPS decel the model adds about 0.9 seconds to the overall delay time).  Pardon me for previously indicating that this particular model wasn't showing any such issues.

With the exception that when three OVs randomly hit the intersection in the first 10 seconds of the model, this was the only time that the model got hit with an AWR (all-way red) condition.  Since I run the model until the traffic perturbations smooth out into a consistent operating pattern, this rolls out to two AWR conditions about every 5 minutes (this run came out to 5m:08s, if you really care).  A flurry of OVs would trigger "Plain Ole' RYG" operation, but it looks like certain patterns of random OVs arriving at the intersection could be problematic.

* This reminds me that there should be no side entrances to this arterial within say 3 or 4 "slot lengths" from the stop bar at the intersection.  At 55MPH, were looking at about 500 feet or more from the intersection.

[kalvado]

These models have also been computing the accumulated and average delay times for each car in the [northbound] direction of traffic, which includes the amount of time each vehicle is slowed from its normal speeds.  In the process of adding the "Slowed" calculations to the Prioritized "White Aspect" with Random OVs model, I caught something big that needed correcting.  There was one randomly-generated Φ3LT(OV) and it didn't get detected by the model.  The model currently assumes that all Φ3 vehicles are equally spaced at 5-second intervals, and alternating one through and one left turn.  For the record, the 5-second intervals for the Φ4 [northbound] traffic seems to be sweet spot that pushes the traffic controller hard, but the 10-second intervals for other traffic is kind of "mushy" (if you catch my drift).

Anywhoosit, an OV that is truly operating 10 seconds behind an AV, it can't be detected by the traffic controller and allowed to cross traffic safely by flashing up a "white aspect" (so far, no reasons that you can't flash up a G/Y/R countdown except that cross traffic is displaying "white aspects" instead of red*).  Since the [eastbound] Φ8/Φ3LT and the [westbound] Φ7LT/Φ4 (including Φ4RT) are normally displaying red, the traffic signal only needs to detect the OV in the queue and start a countdown timer.  In the normal RYG model, I arbitrarily assumed a 30-second maximum wait time before triggering the opposing yellows and AWR (all-way red), then going into a "clear out" cycle before resuming "white aspect" operations in the priority direction of traffic.  That has an interesting coincidence, in that four Φ3LT vehicles were in the queue prior to the "opposing yellow" and another Φ3LT vehicle entered during that "opposing yellow" to fill the queue.  The remaining traffic encountered only a few slight delays and slowings while the queue was stacking up.  The OV got hit with a 42-second delay plus an additional 2 seconds of slowing (at 55MPH at roughly 10 MPHPS decel the model adds about 0.9 seconds to the overall delay time).  Pardon me for previously indicating that this particular model wasn't showing any such issues.

With the exception that when three OVs randomly hit the intersection in the first 10 seconds of the model, this was the only time that the model got hit with an AWR (all-way red) condition.  Since I run the model until the traffic perturbations smooth out into a consistent operating pattern, this rolls out to two AWR conditions about every 5 minutes (this run came out to 5m:08s, if you really care).  A flurry of OVs would trigger "Plain Ole' RYG" operation, but it looks like certain patterns of random OVs arriving at the intersection could be problematic.

* This reminds me that there should be no side entrances to this arterial within say 3 or 4 "slot lengths" from the stop bar at the intersection.  At 55MPH, were looking at about 500 feet or more from the intersection.

SInce white light means "follow AV leader", a lone OV must switch controller into RYG.

[Dirt Roads]

I may have mentioned that I was concerned that injecting random OVs into the AWW model might cause some chaos with the other phases.  The original models didn't bother with the cross-traffic (or opposing traffic) since there was plenty of additional "slot" capacity to handle those phases with lower throughput.

I've tried to add the remaining phases to the model, but it is requiring a bunch of "hand manipulation" to push some of the cross-traffic through during at the first available "slot".  Even then, the model appears to be showing that the perturbations are going to resonate for quite a while after coming out of RYG mode.  It's going to be much easier to set the model up for traditional phase sequencing.  But this is definitely going to stack a few cars in some of these queues (even when there are no OVs in the picture).

         

• Φ2 at the same as Φ6
• Φ7LT at the same time as Φ3LT
• Φ8 at the same as Φ4/Φ4RT
• Φ5LT at the same as Φ1LT

I was able to get some additional throughput with the following, but this was simply too much for today.

• Φ1LT just after the last Φ5LT
• Φ7LT during "slot protection" by holding Φ8 (add "slot protection" after Φ7LT)
• Φ8 during "slot protection" when there is no Φ7LT (add "slot protection" after Φ8)
• Φ5LT after Φ6 by holding Φ7LT (add "slot protection" after Φ5LT)

I'll probably do a hand analysis of how much additional throughput is available for these situations.

By the way, this is an area where my background in railroad operation gets conflicting.  Dispatchers in rail transit are more likely to try to slot the first train in each queue at the earliest possible moment, whereas railroad dispatchers are more likely to hold more trains in certain queues and get the "slow boats" out of the way, then "let the parade begin".  Finally, I get to use the word "slot" without quotes.  That just made my day.

[Dirt Roads]

^^^^
Need to add a caveat.  The mess caused by three random OVs showing up in the first 10 seconds of the model is getting the cross-traffic out of sync for a while.  Until that bubbles through, the following sequence works better (by moving up the long "slot protection" window).

• Φ2 at the same as Φ6
• Φ8 at the same as Φ4 (the Φ4RT usually doesn't show up in time)
• Φ7LT at the same time as Φ3LT
• usually just a lonely Φ4RT (could push Φ8 and Φ4 if they arrive in time)
• Φ5LT at the same as Φ1LT

It's looking like the model may never get out of this pattern.  But there are some OVs on the horizon that will bump everything into a different pattern.

[Dirt Roads]

^^^^
^^^^
Finally got a reasonable output from AWW with 10% of the [northbound output] traffic as random OVs.  Whether I like it or not, there is a need to let any delayed cross-traffic to go ahead and go during the "slot protection" windows, which of course, adds another "slot protection" window.  The patterns do tend to adhere to the traffic cycle concepts listed in the above two posts.  Traffic signal engineers probably understand this better than I do, but this actually worked much better than the AWW with only AVs (which didn't model all of the cross-traffic patterns).  Some observations:

• Every OV that triggers a "RYG" operation with clear-out starts a new operational pattern.  In all such cases, we were able to revert to "White Aspect" instead of another "Green Aspect".
• Back-to-back OVs actually help improve AWW operation if they can "catch up" with the AV ahead.  Not so much so with Prioritized White Aspect.
• There are a bunch of cases where the next AV misses its cycle, including [northbound] Φ6.
• In one case, when the OV triggered a "RYG" operation (after 30 seconds), the Φ6 traffic before the "yellow aspect" also got caught in the extended "slot protection" windows and waited out the "clear-out" cycle.

This AWW model shows hardly any additional throughput capacity.  After the first three random OVs come through, it settles into a 10-second complete cycle.  After the next OV, it alternates between 9-second and 11-second cycles until the next OV disrupts things.  This seems to be the norm and the 10-second cycle must have been an coincidence.  It's only pushing through 4 vehicles [northbound output] every cycle (the rest are cross-traffic).  For comparison, the simple AWW with all AVs usually pumped 4 vehicles [northbound output] every 8 seconds (although they weren't always in the same order).



Here's a quick comparison (the numbers have changed from previous posts, as the model logic has improved somewhat):

	THROUGHPUT	AVG DELAY
RYG (regular arrivals) (30-sec Red for cross-traffic)	1,364 VPH	20.6 sec
Prioritized White Aspect (or AWW) with all AVs (regular arrivals)	1,414 VPH	2.74 sec
Prioritized White Aspect [northbound] (regular arrivals) (plus random OVs)	1,438 VPH	4.52 sec
AWW (regular arrivals) (plus random OVs)	1,197 VPH	3.92 sec

Note:  Average delays determined only for [northbound output] traffic (Φ6/Φ3LT/Φ4RT).

[Dirt Roads]

White means to just follow the car in front of them?  Why not just keep it green?

I think I can finally answer the "original question posed by Rothman".  The "white aspect" allows a traffic signal controller equipped with V2X data [downlink] communications capabilities to coordinate the movements of AVs through the intersection (and also protection some of the OVs operating behind directly them).  If a "lonely OV" (which might also be a non-communicating AV) is detected, the traffic signal controller can flip from "white aspect" to "red aspect" immediately and force that vehicle to stop, allowing other traffic to proceed.  This allows several types of signal operation, including "All Ways White" (AWW, as discussed by Kalvado) and "All Ways Red" (AWR).  We haven't discussed AWR, but there's no reason that we can't allow controlled AVs to "blow through" a red light as long as everybody else (OV, bicycles and pedestrians) know when to stay put (and patient).  Under AWR, the "white aspect" would only be displayed if the traffic signal controller detects one or more OVs following an AV and decides to let them "follow the leader".

On the flip side, there's no reason that a "green aspect" can't be made more efficient using some of these same techniques.  Cross-traffic controlled AVs could be permitted to cross during the "red aspect" if there is a sufficient gap, and with V2X data [downlink] communications capabilities the traffic signal controller could also create a gap in a string of AVs to permit cross traffic to "blow through" the intersection under certain conditions.  OVs would only be permitted to enter the intersection under a "green aspect" (or "riding the yellows").  The important thing for all of these configurations is to try to squeeze as many Φ4RT and Φ3LT movements into the free flow of Φ6 [northbound] traffic as possible.

"The simulations tell us several things,"  Hajbabaie says. "First, AVs improve traffic flow, regardless of the presence of the white phase. Second, if there are AVs present, the white phase further improves traffic flow.

I no longer have access to IEEE publications, so I haven't read the N.C. State study.  To be honest, I've read the articles a dozen times and still have no clue how they came to the dual conclusion that "AVs improve traffic flow" and "white phase (sic) further improves traffic flow".  But I've run enough models to actually achieve some of those results myself (with a far less complicated algorithm).

[kalvado]

White means to just follow the car in front of them?  Why not just keep it green?

I think I can finally answer the "original question posed by Rothman".  The "white aspect" allows a traffic signal controller equipped with V2X data [downlink] communications capabilities to coordinate the movements of AVs through the intersection (and also protection some of the OVs operating behind directly them).  If a "lonely OV" (which might also be a non-communicating AV) is detected, the traffic signal controller can flip from "white aspect" to "red aspect" immediately and force that vehicle to stop, allowing other traffic to proceed.  This allows several types of signal operation, including "All Ways White" (AWW, as discussed by Kalvado) and "All Ways Red" (AWR).  We haven't discussed AWR, but there's no reason that we can't allow controlled AVs to "blow through" a red light as long as everybody else (OV, bicycles and pedestrians) know when to stay put (and patient).  Under AWR, the "white aspect" would only be displayed if the traffic signal controller detects one or more OVs following an AV and decides to let them "follow the leader".

On the flip side, there's no reason that a "green aspect" can't be made more efficient using some of these same techniques.  Cross-traffic controlled AVs could be permitted to cross during the "red aspect" if there is a sufficient gap, and with V2X data [downlink] communications capabilities the traffic signal controller could also create a gap in a string of AVs to permit cross traffic to "blow through" the intersection under certain conditions.  OVs would only be permitted to enter the intersection under a "green aspect" (or "riding the yellows").  The important thing for all of these configurations is to try to squeeze as many Φ4RT and Φ3LT movements into the free flow of Φ6 [northbound] traffic as possible.

"The simulations tell us several things,"  Hajbabaie says. "First, AVs improve traffic flow, regardless of the presence of the white phase. Second, if there are AVs present, the white phase further improves traffic flow.

I no longer have access to IEEE publications, so I haven't read the N.C. State study.  To be honest, I've read the articles a dozen times and still have no clue how they came to the dual conclusion that "AVs improve traffic flow" and "white phase (sic) further improves traffic flow".  But I've run enough models to actually achieve some of those results myself (with a far less complicated algorithm).

Honestly speaking, if 100% of traffic is AV then traffic light is not needed to begin with. Role of white  is to pass a message to human drivers, so allowing AV to run red light may be totally safe - but humans may get agitated with all-way green or cars bravely driving into red (not to mention that is illegal by today's law).  I assume that's the main role of 4th light is to let humans know that computer is in command. .

[Dirt Roads]

Honestly speaking, if 100% of traffic is AV then traffic light is not needed to begin with. Role of white  is to pass a message to human drivers, so allowing AV to run red light may be totally safe - but humans may get agitated with all-way green or cars bravely driving into red (not to mention that is illegal by today's law).  I assume that's the main role of 4th light is to let humans know that computer is in command. .

Modelling "all AVs" was simply meant to be an easy-to-describe logic pattern that took my background in PRT and put it to the test of adding cross traffic, then adding a certain percentage of OVs into the mix.  All of this was to get a feel for how the PRT "slot movement" logic would respond to certain tasks.  I do hope that nobody mistook this.  After all "All AVs" is pretty much the same as PRT.  Just a reminder that the N.C. State study was convinced you only need 30% AVs to get a significant improvement, but all of those AVs needed to be equipped with futuristic V2X data communications to a node on the Centralized Traffic System.

Humans do indeed get agitated (or concerned, sometimes to a level of panic) when confronted with unexpected vehicle behaviors in the AGT world (including PRT systems).  The most extreme example was on the (now) PlaneTrain at Hartsfield-Jackson International Airport.  In the original configurations, the train would drop all passengers at the end-of-line station then proceed to a "pseudo-station" beyond the end-of-line on the same track, and then reverse before crossing over to the other track.  All in the dark of the tunnel.  Passengers in the front car of the next train entering the end-of-line station would see the train ahead coming straight back towards it (with headlights on, to boot) and some passengers would indeed panic.  (The system has been reconfigured so many times that it may not operate this way anymore).

Anywhoosit, I'm sure that cross traffic AVs that "blow through the signal" are going to cause quite a commotion at times.

I assume that's the main role of 4th light is to let humans know that computer is in command. .

Correct.  But I read somewhere that (perhaps in this thread) that there was a discussion of using the "white aspect" as a command to a [non-communicating] AV to proceed through the intersection (insinuating that this would completely eliminate the V2X data communication requirement).  That raises some serious safety concerns in my book.

[Troubleshooter]

I have seen too many cases of self-crashing cars to ever want them on the roads.

And they learned to not use white for railroad signals in the 1800s. Too many engine drivers mistook a white light they saw that was not the signal for the all-clear signal.