Proposal to add fourth traffic light help transition to autonomous vehicles

[kalvado]

I don't know the folks at N.C. State that are recommending the fourth white aspect, but the "Follow-the-Leader" approach appears to fit very well into the "Merge-at-speed" philosophy used in modern PRT systems.

Well, and how well that functions? I believe FAA awarded contract for a similar free-flow air traffic control system... I am not sure, 2005-2010 range? it is 2023
Quick google look up says 2008 for the  NextGen ATC contract, 2030 current first trial date - lets make it 2050 to be realistic. That is with pilots at controls and communicating with dispatch at all times as a hot backup....

Most of the PRT systems (and AGT systems with similar "slot-based" centralized [master control systems]) also have hot backup (and we always required such on the ones I worked on).  But your comment has a valid point.  Railway traffic control is one-dimensional; highway traffic control is two-dimensional; and air traffic control is three-dimensional.  The "follow the leader" principle only works if all vehicles function well at the same speed *and* the terminal points operate nearly congestion-free.  Which leads to an obvious conclusion...

An efficient autonomous car network will need all of the cars to make quick berthings (passenger drop-offs/pick-ups) in the urban core and then get sent back out (ergo, empty cars).

Oh, oh, oh... And I should mention that the network needs to have enough "lanes" (or parallel "routes") to support the peak demand at the minimum operable headway.  Someone out there is still very angry at me for calculating that a certain proposed PRT system would need to be 12 lanes wide.  On the other hand, one of my colleagues was upset that I used a minimum operable headway of 20 seconds, instead of the industry standard of 45 seconds.  Given the variation of acceleration/deceleration capabilities in such a big fleet, he was probably more realistic than I was.

if those are 6-pax cars on a 45 s headway.. yeah, throughput isn't impressive...
air traffic control would need a full 3d predictive model, and I am really unsure how to even approach that.  But this is nowhere close to my expertise subjects...

[Dirt Roads]

air traffic control would need a full 3d predictive model, and I am really unsure how to even approach that.  But this is nowhere close to my expertise subjects...

My understanding is that in old-fashioned ATC, airspace is divided into uni-directional "lanes" just like I'm familiar with, but the "slots" were assigned based on the characteristics of the lead plane in the "follow-the-leader" philosophy.  If I understand this correctly, say some reason a smaller aircraft needed to enter a "lane" that was normally occupied by larger (and higher speed) aircraft, then the air traffic controller could not assign anything bigger/faster than that puddle-jumper to the slots behind until it got "out of the way" (whatever that means in the ATC world).

Extra care needed to be provided in coordinating the maneuver of an aircraft from a "lane" at one elevation to a "lane" at another elevation.  For landing and take-off, the "lanes" were simply tilted at several different degrees of climb or descent. 

For the record, I just happened to live in a subdivision where almost everyone else were either active air traffic controllers, retired air traffic controllers, air traffic controllers that got out or those married to air traffic controllers (in one family, husband and wife had both been air traffic controllers on both the military and FAA sides).  One other family had a young pilot who rose to become the COO of a small airline during that time.  They were fascinated with me, in part because of how much of my rail transit background was in designing driverless trains within airports, plus the fact that I also had experience working in airport ramp towers in the analysis of ground transportation on the tarmac.  None of that qualifies me for anything in this discussion, other than I've heard enough about how this was "supposed to work" then that I am highly skeptical of how it is "supposed to work" now.

[kalvado]

air traffic control would need a full 3d predictive model, and I am really unsure how to even approach that.  But this is nowhere close to my expertise subjects...

My understanding is that in old-fashioned ATC, airspace is divided into uni-directional "lanes" just like I'm familiar with, but the "slots" were assigned based on the characteristics of the lead plane in the "follow-the-leader" philosophy.  If I understand this correctly, say some reason a smaller aircraft needed to enter a "lane" that was normally occupied by larger (and higher speed) aircraft, then the air traffic controller could not assign anything bigger/faster than that puddle-jumper to the slots behind until it got "out of the way" (whatever that means in the ATC world).

Extra care needed to be provided in coordinating the maneuver of an aircraft from a "lane" at one elevation to a "lane" at another elevation.  For landing and take-off, the "lanes" were simply tilted at several different degrees of climb or descent. 

For the record, I just happened to live in a subdivision where almost everyone else were either active air traffic controllers, retired air traffic controllers, air traffic controllers that got out or those married to air traffic controllers (in one family, husband and wife had both been air traffic controllers on both the military and FAA sides).  One other family had a young pilot who rose to become the COO of a small airline during that time.  They were fascinated with me, in part because of how much of my rail transit background was in designing driverless trains within airports, plus the fact that I also had experience working in airport ramp towers in the analysis of ground transportation on the tarmac.  None of that qualifies me for anything in this discussion, other than I've heard enough about how this was "supposed to work" then that I am highly skeptical of how it is "supposed to work" now.

One of big problems is NYC. There are 3 major and a few smaller airports with interfering approach paths, pretty long headway separations, required emergency escape reserved space... As a result pretty much every configuration (weather dependent!) requires long detours reducing available volume.
There was a demo app from FAA showing complications, and is is tough
Add unpredictable things like thunderstorms or VVVIP security, and delays quickly can spread over entire air traffic system as planes to and from NYC are delayed
My impression is that a totally different approach using intersecting traffic patterns and tight timing control is the only real way to go.

[Dirt Roads]

I've been chewing on this topic for a week or so, and not sure if the "white ball" aspect makes any sense.  Here's some thoughts about the logistics of the operations for a traffic signal using a "white ball"  aspect:

Assumptions:  (1) The centralized traffic system will operate using "slot simulations"  by assigning all vehicles to a "slot" .  (2) The centralized traffic system is in communications with all vehicles that are operating in autonomous mode; "other vehicles"  will be treated as "follow-the-leader"  regardless of whether they are manually driven, partially autonomous or fully autonomous with a "loss of communication"  failure mode.  (3) There is a turn lane for each traffic movement at the signal.   (4) Other vehicles can only "follow-the-leader"  when going straight or turning right at the intersection.  (5) The traffic signal installation must be able to detect all vehicles entering the intersection (and the centralized traffic controller must avoid routing another vehicle into an occupied "slot"  (thus providing some additional braking distance to protect "other vehicles"  using the "follow-the-leader"  rule.  (6)  Large autonomous vehicles will need to slow down in approach to the intersection to provide sufficient safety distance to respond to

Abbreviations:  AV = "autonomous vehicle" ; OV = "other vehicle" ;  CTS = centralized traffic system   Sorry, but the signal aspects are placed in quotations to help me with the logic patterns.

(A) Traditional Signal Operation (nothing but AVs)

"Slots"  are moving along at the design speed in the direction of rush hour traffic, and also in the opposite direction of traffic.  Through traffic gets a "white ball"  in both directions.  Perpendicular signals display a "red ball" .  All left turn signals display the "red arrow" .  AVs in either of these directions move along at the speed directed by the centralized traffic controller.  If an AV is not proceeding at speed, the CTS detects the deviation and

An AV turning right at the intersection is not impeded, but might need to slow down to make the turn (and if so, will bump all following vehicles into the "slot"  behind). 

An AV turning left will need the CTS to create a gap in opposing traffic sufficient to make the left turn at speed (say a gap of 5 moving "slots"  in the opposite direction).   The CTS needs to command any opposing traffic to slow down in approach to the signal to create such a gap.  The CTS adjusts the speeds of the following "slots"  accordingly. 

After a proper cycle time, the CTS changes the route selection and the traffic signal cycles from
"white ball"  to "yellow ball"  to "red ball"  for through movements.  If necessary, the left turn signals can be granted cycle time and will operate in a similar manner.

After changing cycles, accelerating AVs will be detected and slower AVs may need additional gap spacing to make the left turns.

(B)  Follow-the-Leader (with only a few OVs mixed in)

Same as Traditional Operation, except an OV going straight through simply follows the leader through the intersection when the "white ball"  is displayed.  The CTS detects the OV and adjusts the speed of the "slots"  if needed.

An OV turning right simply follows the leader into the intersection when the "white ball"  is displayed, but may need to slow down significantly to make the turn.  The CTS adjusts the speeds of the following "slots"  accordingly.

An AV turning left will need the CTS to create a gap in opposing traffic sufficient to make the left turn at speed (say a gap of 5 moving "slots"  in the opposite direction).   The CTS needs to command any opposing traffic to slow down in approach to the signal to create such a gap.  The CTS adjusts the speeds of the following "slots"  accordingly.  But if an OV is detected in the route displaying a "white ball" , the left turn maneuver must be aborted and affected AV traffic bumped gets into the appropriate "slots" .

Safety concern:  In the case of a few OVs, there is the possibility that an OV will try to follow an AV making a legitimate left turn against the "red arrow"  aspect.  The CTS can probably provide some advance notice to an approaching AV in the long gap of "slots" , but an OV approaching from the opposite direction might be in big trouble.  One solution is that the CTS could detect an OV behind an AV and refuse to grant a left turn maneuver, forcing the AV to stop at the "red arrow" .

An OV turning left is facing a "red arrow"  and must stop.  Both AVs and OVs turning left will need to stop behind the front OV.  The CTS must detect that the left turn position is occupied by an OV and will force the traffic signal to clear out the turn lane after the through route cycle is complete.  The CTS must detect when the left lane queue is becoming full and manage the affected traffic appropriately.

In both of these scenarios, there is no need for a "white ball"  aspect and a "green ball"  could be displayed with the same results.  That probably doesn't carry out in the other scenarios.

Next up:  What happens when there are lots of OVs (and some of them are large trucks)?  Later:  Review some Non-Traditional Operation scenarios where more "white ball"  aspects are added to opposing routes.

[kalvado]

I've been chewing on this topic for a week or so, and not sure if the "white ball" aspect makes any sense.  Here’s some thoughts about the logistics of the operations for a traffic signal using a “white ball” aspect:

OK, let me try. Keep in mind that the first time I heard about the slot approach was last week when you wrote about it! Some of my assumptions may not be the best ones.

1. There are two control modes: RYG and All-way white (AWW). The controller switches to AWW if all of the conditions are met:
(a) all vehicles within 7 slots of intersection are either AV, or AV+OV follower, or large AV (no followers for trucks)
(b) slot fill factor is <2/3 (1/2?)  of total intersection capacity
(c)...

2. Operational assumptions: intersection is 5 lanes = 18 m wide, vehicle design speed is 10 m/s = 36 km/h ~ 20 MPH, the vehicle at design speed can cross intersection from bumper enters to bumper leaves in 2 seconds, less than 1 full slot.

3. Recommended "slot" for manual driving on a highway is 2 seconds; let's make it (maybe optimistically) 3.33 second = 10/3 second. AV gets 1 slot, AV+follower 2 slots, truck may request 2 or 3 slots. For more granularity, maybe, reduce slot to 10/6 = 1.67s minislots;  2 minislots for AV, 5 minislots AV + follower, up to 6 minislots for the truck, etc. 

4. Right turn may be accomplished into 1 empty slot (two risky? 3 minislots maybe?); through the intersection movement requires 2 slots each way with 1 slot overlap; left turn requires 2 slots in crossing direction and 3 in merging direction,  with 1 slot overlap

5. AV can understand "align yourself into the slot", "continue with slot flow",  "slow down 1 slot" or "slow down N minislots" and "to RYG" commands.

Main benefit - reducing minimal cycle time from 4s Y  + 5 s G + 4s Y + 2s all-R to  3 slots (and it is not that impressive of a gain in these assumptions!)


PS- sorry for zillion edits in process.

[Dirt Roads]

I've been chewing on this topic for a week or so, and not sure if the "white ball" aspect makes any sense.  Here's some thoughts about the logistics of the operations for a traffic signal using a "white ball"  aspect:

OK, let me try. Keep in mind that the first time I heard about the slot approach was last week when you wrote about it! Some of my assumptions may not be the best ones.

1. There are two control modes: RYG and All-way white (AWW). The controller switches to AWW if all of the conditions are met:
(a) all vehicles within 7 slots of intersection are either AV, or AV+OV follower, or large AV (no followers for trucks)
(b) slot fill factor is <2/3 (1/2?)  of total intersection capacity
(c)...

2. Operational assumptions: intersection is 5 lanes = 18 m wide, vehicle design speed is 10 m/s = 36 km/h ~ 20 MPH, the vehicle at design speed can cross intersection from bumper enters to bumper leaves in 2 seconds, less than 1 full slot.

3. Recommended "slot" for manual driving on a highway is 2 seconds; let's make it (maybe optimistically) 3.33 second = 10/3 second. AV gets 1 slot, AV+follower 2 slots, truck may request 2 or 3 slots. For more granularity, maybe, reduce slot to 10/6 = 1.67s minislots;  2 minislots for AV, 5 minislots AV + follower, up to 6 minislots for the truck, etc. 

4. Right turn may be accomplished into 1 empty slot (two risky? 3 minislots maybe?); through the intersection movement requires 2 slots each way with 1 slot overlap; left turn requires 2 slots in crossing direction and 3 in merging direction,  with 1 slot overlap

5. AV can understand "align yourself into the slot", "continue with slot flow",  "slow down 1 slot" or "slow down N minislots" and "to RYG" commands.

Main benefit - reducing minimal cycle time from 4s Y  + 5 s G + 4s Y + 2s all-R to  3 slots (and it is not that impressive of a gain in these assumptions!)


PS- sorry for zillion edits in process.

Very well done for your first cut.  For the record, all of the "Merge at Speed" software that I have seen either keeps all of the "slots" going at the same speed all of the time; or adds a feature to forcibly slow all of "slots" in response to a disturbance and then accelerate them all back to full speed.  AVs do not need to keep up with slots they are assigned into.

You were right on target with 3.33-sec slot spacing at 20MPH.  At the maximum safe design speed (say 55MPH), the 2-second rule is easily achievable (as long as the lane capacity far exceeds the demand).  To be honest, I haven't seen a PRT system with an operational speed higher that 40MPH (65KPH) and the technology is oversold at 70KPH. 

No need to design the number of lanes for through traffic yet.  The goal here is to push a single through lane as far as we can without the CTS causing a logjam.  I'll eventually come up with some VPHPD throughput analysis scenarios with my two "basic" scenarios to show how this works.

[kalvado]

I've been chewing on this topic for a week or so, and not sure if the "white ball" aspect makes any sense.  Here’s some thoughts about the logistics of the operations for a traffic signal using a “white ball” aspect:

OK, let me try. Keep in mind that the first time I heard about the slot approach was last week when you wrote about it! Some of my assumptions may not be the best ones.

1. There are two control modes: RYG and All-way white (AWW). The controller switches to AWW if all of the conditions are met:
(a) all vehicles within 7 slots of intersection are either AV, or AV+OV follower, or large AV (no followers for trucks)
(b) slot fill factor is <2/3 (1/2?)  of total intersection capacity
(c)...

2. Operational assumptions: intersection is 5 lanes = 18 m wide, vehicle design speed is 10 m/s = 36 km/h ~ 20 MPH, the vehicle at design speed can cross intersection from bumper enters to bumper leaves in 2 seconds, less than 1 full slot.

3. Recommended "slot" for manual driving on a highway is 2 seconds; let's make it (maybe optimistically) 3.33 second = 10/3 second. AV gets 1 slot, AV+follower 2 slots, truck may request 2 or 3 slots. For more granularity, maybe, reduce slot to 10/6 = 1.67s minislots;  2 minislots for AV, 5 minislots AV + follower, up to 6 minislots for the truck, etc. 

4. Right turn may be accomplished into 1 empty slot (two risky? 3 minislots maybe?); through the intersection movement requires 2 slots each way with 1 slot overlap; left turn requires 2 slots in crossing direction and 3 in merging direction,  with 1 slot overlap

5. AV can understand "align yourself into the slot", "continue with slot flow",  "slow down 1 slot" or "slow down N minislots" and "to RYG" commands.

Main benefit - reducing minimal cycle time from 4s Y  + 5 s G + 4s Y + 2s all-R to  3 slots (and it is not that impressive of a gain in these assumptions!)


PS- sorry for zillion edits in process.

Very well don for your first cut.  For the record, all of the "Merge at Speed" software that I have seen either keeps all of the "slots" going at the same speed all of the time; or adds a feature to forcibly slow all of "slots" in response to a disturbance and then accelerate them all back to full speed.  AVs do not need to keep up with slots they are assigned into.

You were right on target with 3.33-sec slot spacing at 20MPH.  At the maximum safe design speed (say 55MPH), the 2-second rule is easily achievable (as long as the lane capacity far exceeds the demand).  To be honest, I haven't seen a PRT system with an operational speed higher that 40MPH (65KPH) and the technology is oversold at 70KPH. 

No need to design the number of lanes for through traffic yet.  The goal here is to push a single through lane as far as we can without the CTS causing a logjam.  I'll eventually come up with some VPHPD throughput analysis scenarios with my two "basic" scenarios to show how this works.

My main point wasn't that much to go into operation details, mostly did that for myself. I tried to show the difference between RYG and AWW operation.
As far as I understand the purpose of AWW it can be used when most of the traffic obeys central controller, and cross traffic can be shoehorned into small gaps than those created by RYG signal. I just tried to spell out rules in AWW phase to see how much benefit is there to be extracted.
You know, when a physicist is bored..... Honestly speaking, task isn't as bad as I originally though, at least I see the starting point

[Dirt Roads]

^^^
I may have not explained this so well, but my main point is to try to answer this question posed by Rothman:

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

You know, when a physicist is bored..... Honestly speaking, task isn't as bad as I originally though, at least I see the starting point

I used to do this kind of exercise for a living, but it was easier when I had access to simulation software (and a small group of simulation engineers).  The physics behind all of that stuff was fascinating, but this kind of modeling gets you the same answer.  Anyhow, while chewing on this problem some more, it has become obvious that some of the scenarios that I've painted will require a different type of analysis.  I was hoping to get a differential between maximum [theoretical] free-flow line capacity using the inherent losses of "slots" caused by the "white ball" aspect.  That's not going to be easy when I inject OVs into the system (since OVs might cause the traffic signal to cycle into RYG).  It might be easier to calculate the additional [theoretical] throughput injected by utilizing the "white ball" aspect.  (Which just happens to be the real answer to the question posed by Rothman.

It is intuitive that the cost of adding a new Traffic Control System would never be justified by this "white ball" aspect.  But I still haven't boxed out the possibility that adding the "Merge-at-Speed" feature (from the PRT technology) to an existing Traffic Control System wouldn't produce a reasonable increase in [line capacity] that justifies the additional cost.  This thread is a great "doodle box" to explore the whole thing.  Thanks for helping.

[kalvado]

^^^
I may have not explained this so well, but my main point is to try to answer this question posed by Rothman:

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

You know, when a physicist is bored..... Honestly speaking, task isn't as bad as I originally though, at least I see the starting point

I used to do this kind of exercise for a living, but it was easier when I had access to simulation software (and a small group of simulation engineers).  The physics behind all of that stuff was fascinating, but this kind of modeling gets you the same answer.  Anyhow, while chewing on this problem some more, it has become obvious that some of the scenarios that I've painted will require a different type of analysis.  I was hoping to get a differential between maximum [theoretical] free-flow line capacity using the inherent losses of "slots" caused by the "white ball" aspect.  That's not going to be easy when I inject OVs into the system (since OVs might cause the traffic signal to cycle into RYG).  It might be easier to calculate the additional [theoretical] throughput injected by utilizing the "white ball" aspect.  (Which just happens to be the real answer to the question posed by Rothman.

It is intuitive that the cost of adding a new Traffic Control System would never be justified by this "white ball" aspect.  But I still haven't boxed out the possibility that adding the "Merge-at-Speed" feature (from the PRT technology) to an existing Traffic Control System wouldn't produce a reasonable increase in [line capacity] that justifies the additional cost.  This thread is a great "doodle box" to explore the whole thing.  Thanks for helping.

Well, because AWW is not all way green (AWG) in a few  aspects. It is not a "protected" phase, it is "controlled by other device".  In particular, cross traffic is allowed and expected (with control assumptions) when the light is white for me. If there is any consistent cross  traffic while I am approaching to green light, I would assume that the light is broken and act accordingly.
A  message similar to AWW may be relayed by all-way blinking yellow. That's not without its problems as currently blinking yellow implies that I have right of way and cross traffic has blinking red = stop. A different blink pattern may be used, though. Not a problem-free idea as well, but comparable to double-red  beacons at pedestrian crosswalk. Eliminates the cost of new heads, though 

[kalvado]

I was hoping to get a differential between maximum [theoretical] free-flow line capacity using the inherent losses of "slots" caused by the "white ball" aspect.  That's not going to be easy when I inject OVs into the system (since OVs might cause the traffic signal to cycle into RYG).  It might be easier to calculate the additional [theoretical] throughput injected by utilizing the "white ball" aspect.  (Which just happens to be the real answer to the question posed by Rothman.

Original paper upstream shows some calculations and simulations - in a form I am not ready to dive into, though. At a first glance, things are not  unreasonable.  Of course, it is entirely possible they are overselling the idea...

[kphoger]

How do cyclists fit in with this idea?

[kalvado]

How do cyclists fit in with this idea?

As a roadkill, maybe?
On a serious note, though, they suggest first use in industrial areas, like ports. Pretty much in line with autonomous vehicles already running in mines. In industrial area, mandating more pedestrian and bicyclist discipline - including, for example, signal beacons and mandatory use of "beg buttons" is possible, on top of already mandated high visibility gear.
And pedestrian/bicyclist detection is  indeed a serious problem for AV in general.

[Dirt Roads]

How do cyclists fit in with this idea?

It is unlikely that any traffic signal installation is going to be able to detect bicycles; therefore the CTS will not be able to adapt with "slot" protection.  But that doesn't mean that the individual AVs won't provide an adequate level of protection for bicyclists.  The question that I have is whether manually-driven cars and trucks (OVs) will respond better to bicycles when the majority of vehicles are running autonomously (ergo, lots of AVs).  My suspicion is many OVs will simply copycat the AV ahead making an evasive maneuver around a bicycle, which is possibly into the oncoming path of a vehicle in the opposite direction (even worse, if the OV is travelling in the opposite direction of the rush hour traffic, such an incursion into oncoming traffic is probably catastrophic).  However, the safety of bicycles when the OVs making "follow-the-leader" right turns and left turns may actually be improved (as those OVs would be enveloped within the "gap" created by the CTS for the AV ahead).

Kalvado's AWW (all way white) assumption would certainly be more dangerous for bicycles, since we have no way of predicting how OVs will respond to a "follow-the-leader" rule whenever there is no AV "leader".  There is certainly a possibility that OVs in all four directions could simultaneously try to enter the intersection at the design speed (or higher).  Any bicycles entering the intersection at such time are doomed.  My first thought was that AWW was going to perform poorly as compared to a CTS that only provides the "white aspect" to vehicles travelling in the direction of [rush hour traffic].  But the injection of bicycles (and pedestrians) may actually be a "fatal flaw" of AWW operation (perhaps literally).

[Dirt Roads]

Other than having a lot of experience with railroad preemption circuits and related traffic signal phasing, I'm not very experienced with traffic signal timing (so I'm sure that I'm not speaking the correct language as the traffic signal guys).  Since the primary purpose of the "white aspect" is to increase intersection throughput (which is generally an issue only during rush hour), I'm going to simplify the analysis by trying to duplicate the longest recorded traffic cycle (about 2 minutes, 15 seconds).

This is a typical intersection phasing for NEMA pre-programmed traffic signal controllers (ignore the pedestrian phases for this exercise).


In my scenario, Phase 6 is the primary flow of traffic.  Phase 6 (Φ6) and Phase 2 (Φ2) are controlled to display in "white aspect" as long as possible.  Whenever any vehicle is stopped for more than 2m:15s, Φ6 and Φ2 will cycle through the yellow and red aspects and the affected phase(s) will go into a clear-out cycle (with other phases in permissive mode, as appropriate).  If necessary, the signal will go through a traditional cycle: Φ3/Φ7 green, then Φ4/Φ8 green, then Φ1/Φ5 green before going back to the "white aspect" phase.  (If the CTS is capable of improving the throughput of those cycles, some of those phases could be granted a "white aspect").

In the AWW scenario posed by Kalvado, all eight phase try to display the "white aspect" as long as possible.  Whenever any vehicle is stopped for more than 2m:00s,  Φ6/Φ2 and Φ1/Φ5 will cycle through the yellow and red aspects (assuming that the cross street needs priority).  The signal will go through a traditional cycle: Φ3/Φ7 green, then Φ4/Φ8 green, and then Φ1/Φ5 green.  If necessary, Φ6/Φ2 will also get a green aspect cycle before returning the traffic signal to AWW.

For sake of simplification, let's assume that the intersection is a tight enough design to support a 3-second yellow and a 2-second all red transition.

For cross traffic Φ4 when Φ6 has a "white aspect", the CTS needs to create a 3-slot gap in the approach to Φ6 and a 5-slot gap in the approach to Φ2.  Right turn traffic Φ4 should be able to hit that same slot.  The same would work for left turn Φ7, either separately (or preferable at the same time as Φ4).  Additional slots may need to be added to the gap in the approach to Φ6.  Additional slots will be needed for each OV that is "following-the-leader".  OVs that "follow-the-leader" on a right turn Φ4 will barely have enough protection with three slots, and will bump any oncoming AVs in through traffic Φ6 at least one slot backwards.  If there is more than one OV making that same right turn, the affected AV might need to stop midway through the intersection.  I would suggest that the AWW approach needs to cycle around to all-red, and start all over again.

Cross traffic Φ8 and left turn Φ3 can be handled more efficiently by sending Φ2 and Φ5 into a cycle through the yellow and red aspects.  That would allow cross traffic Φ8 to get across with only a 3-slot gap in the approach to Φ6.  Left turn traffic Φ3 might need to add another slot to the gap in the approach to Φ6 if any vehicles are pulled up beyond the left turn stop bar for Φ5.  At 55MPH and 2-second "slots", the three-slot gap gives an AV about 161 feet to react to a slow turning vehicle.  At 20MPH and 3.33-second "slots", the three-slot gap gives an AV about 97 feet for reaction.  But there are some speeds in between where the "slot length" is approaching the safe braking distance.  Thus, the loop detection circuitry would need to have multiple redundancies and be proven very reliable to allow for an anti-valent safety design (so we don't miss anything whenever we drop down to three "slots").

Hopefully, left turn traffic Φ1 should be easy to coordinate with opposing through traffic Φ2 (otherwise, we've got a bunch of problems with "white aspects").  Assuming that left turn traffic Φ5 has stopped, the CTS needs to create a 5-slot gap in oncoming through traffic Φ6.  But if we can keep left turn traffic Φ5 moving at the safe turn speed, we ought to be able to reduce the gap down a "slot" or perhaps two. 

One more item for thought:  Right turn Φ4 can easily be made safer with a slip lane plus an acceleration lane.  For AV maneuvers, through traffic Φ6 only needs a small gap of about one "slot" if the acceleration lane is long enough to reach the design speed.  This is the traditional "merge-at-speed" software philosophy.

[Dirt Roads]

I'm starting to finish up a test run of the model for the prioritized "white aspect" traffic signal, and the results thus far are very promising.  But it's got me wondering if the typical response to "clear out" the backlog on a particular lane (ergo, complete clear-out cycle for all affected lanes) is too drastic of a response for the AWW (all-way "white") alternative.  Here's the highlights thus far:

• The first test run assumes 2-second "slots" in the priority flow of traffic (northbound Φ6, per the diagram above).
• The first test run is set for AV arrivals every 5 seconds.
• Left turns Φ3 and right turns Φ4 flowing into the priority direction are both set for 50% of priority flow of traffic Φ6.
• First model assumes all AVs (only looking at priority flows Φ6/Φ3/Φ4 plus cross-traffic Φ4).  There was no difference between prioritized "white aspect" operation and AWW operation*.
• Second model assumes 10% OVs, randomized, (again only looking at priority flows Φ6/Φ3/Φ4 plus cross-traffic Φ4).
• The basis model is a typical traffic signal set for only 30 seconds in the priority flow of traffic, then a complete "clear out" for all other lanes".

Surprisingly, this amount of cross-traffic AVs is pushing the 30-second traffic signal hard.  I was hoping to adjust the operation for a longer cycle time [northbound], but the cross-traffic Φ3 is building up to 4 cars in the turn queue and the 5th one arriving during the clear-out phase.  This is also pushing the prioritized "white aspect" operation and AWW operation pretty hard, as well, but the cross-traffic volume is low enough that left turn Φ3 never queues up and cross traffic Φ4 is always able to get pushed across to release the right turn Φ4 before that lane starts to queue up.  The AVs models do show some interesting iterations where the early traffic flows appears to be eclectic then enough AVs get slowed down to create a much different but consistent pattern that rotates.  I certainly didn't see that coming.

*I'm wondering if there should be a discernible difference in operational logic between prioritized "white aspect" operation and AWW operation.  My first thought was that AWW uses first come, first serve operation (and the arrival times of AVs be slightly tweaked at random).  But I am concerned is this will penalize the AWW.  It is likely that an AWW traffic signal controller would need to adapt to serve the priority flow of traffic, but perhaps not exactly like the prioritized "white aspect" operation.  One factor here is that the prioritized "white aspect" operation is intended to work similar to a traffic signal that is connected to a modern-day Traffic Signal Control System network along an arterial route.  Not sure that the AWW needs to be networked with other traffic signals.

Any ideas here?

[kalvado]

I'm starting to finish up a test run of the model for the prioritized "white aspect" traffic signal, and the results thus far are very promising.  But it's got me wondering if the typical response to "clear out" the backlog on a particular lane (ergo, complete clear-out cycle for all affected lanes) is too drastic of a response for the AWW (all-way "white") alternative.  Here's the highlights thus far:

• The first test run assumes 2-second "slots" in the priority flow of traffic (northbound Φ6, per the diagram above).
• The first test run is set for AV arrivals every 5 seconds.
• Left turns Φ3 and right turns Φ4 flowing into the priority direction are both set for 50% of priority flow of traffic Φ6.
• First model assumes all AVs (only looking at priority flows Φ6/Φ3/Φ4 plus cross-traffic Φ4).  There was no difference between prioritized "white aspect" operation and AWW operation*.
• Second model assumes 10% OVs, randomized, (again only looking at priority flows Φ6/Φ3/Φ4 plus cross-traffic Φ4).
• The basis model is a typical traffic signal set for only 30 seconds in the priority flow of traffic, then a complete "clear out" for all other lanes".

Surprisingly, this amount of cross-traffic AVs is pushing the 30-second traffic signal hard.  I was hoping to adjust the operation for a longer cycle time [northbound], but the cross-traffic Φ3 is building up to 4 cars in the turn queue and the 5th one arriving during the clear-out phase.  This is also pushing the prioritized "white aspect" operation and AWW operation pretty hard, as well, but the cross-traffic volume is low enough that left turn Φ3 never queues up and cross traffic Φ4 is always able to get pushed across to release the right turn Φ4 before that lane starts to queue up.  The AVs models do show some interesting iterations where the early traffic flows appears to be eclectic then enough AVs get slowed down to create a much different but consistent pattern that rotates.  I certainly didn't see that coming.

*I'm wondering if there should be a discernible difference in operational logic between prioritized "white aspect" operation and AWW operation.  My first thought was that AWW uses first come, first serve operation (and the arrival times of AVs be slightly tweaked at random).  But I am concerned is this will penalize the AWW.  It is likely that an AWW traffic signal controller would need to adapt to serve the priority flow of traffic, but perhaps not exactly like the prioritized "white aspect" operation.  One factor here is that the prioritized "white aspect" operation is intended to work similar to a traffic signal that is connected to a modern-day Traffic Signal Control System network along an arterial route.  Not sure that the AWW needs to be networked with other traffic signals.

Any ideas here?

What kind of traffic counts we're talking about? My expectation is that once total traffic exceeds  50% of slot capacity in preferred direction, things are going to be messy.  I bet nothing will beat ol'good RYG with loooong cycle  at LOS F. In a sense, this is remotely similar to roundabout operation where dense traffic screws up the concept pretty quick.

[Dirt Roads]

What kind of traffic counts we're talking about? My expectation is that once total traffic exceeds  50% of slot capacity in preferred direction, things are going to be messy.  I bet nothing will beat ol'good RYG with loooong cycle  at LOS F. In a sense, this is remotely similar to roundabout operation where dense traffic screws up the concept pretty quick.

At 5-second headways, we're looking at only 720 VPH for [northbound] Φ6 and [westbound] Φ4 (with half of Φ4 turning [northbound] at the signal).  Left turn cross-traffic Φ4 is only half that amount, so 360 VPH.  Using 2-second "slots" (for higher speeds), we're looking at 1,800 VPH typical throughput; using 3.33 second "slots" (for lower speeds), it's down to 1,081 VPH.  But the AV technology does allow the vehicles operate bunched up in the "clear out" cycles (the model currently assumes that AVs and OVs can operate at 1-second headways downstream of the intersection, as long as there is a sufficient gap ahead to let the front cars accelerate away from the rest).

With all AVs, both the prioritized "white aspect" operation and AWW operation are able to pump out 1,377 VPH downstream northbound (which is quite close to 1,400 injection rate).  Even the prioritized RYG is cranking out 1,364 VPH.  At no time did the traffic signal ever need to go into a "clear out" cycle.  There were 833 "protection slots" per hour (leaving only 8 "half-slots" that could be occupied), which gives us a theoretical maximum output of 1,372 VPH.  Note that there are some rounding errors (due to having three cars arriving in the first slot for Φ6/Φ4RT/Φ3LT). 

When we inject 10% OVs into prioritized "white aspect" model, the system responded even better and cranks out 1,438 VPH downstream.  That's also due to those rounding errors. 

Heading further downstream along the arterial route, it is going to be more difficult to inject this much traffic from the [side routes].  But once we start to push up against the maximum limits, we can start to add some simple roadway features to improve throughput:  (A) slip ramps for the Φ4 right turns; (B) longer queue capacity for Φ3 left turns; (C) additional through lanes for [northbound] Φ3; and possibly (D) acceleration lanes out of the slip ramps for the Φ4 right turns.  The model is going to need to be changed drastically, since it is assumed that there is minimal impact for the low volume Φ3/Φ4 cross-traffic, but that will have a much worse impact on Φ6+Φ4RT+Φ3LT throughput as the Φ6 injection rate increases.  This is probably easier to calculate the impact rather than modelling. 

[kalvado]

What kind of traffic counts we're talking about? My expectation is that once total traffic exceeds  50% of slot capacity in preferred direction, things are going to be messy.  I bet nothing will beat ol'good RYG with loooong cycle  at LOS F. In a sense, this is remotely similar to roundabout operation where dense traffic screws up the concept pretty quick.

At 5-second headways, we're looking at only 720 VPH for [northbound] Φ6 and [westbound] Φ4 (with half of Φ4 turning [northbound] at the signal).  Left turn cross-traffic Φ4 is only half that amount, so 360 VPH.  Using 2-second "slots" (for higher speeds), we're looking at 1,800 VPH typical throughput; using 3.33 second "slots" (for lower speeds), it's down to 1,081 VPH.  But the AV technology does allow the vehicles operate bunched up in the "clear out" cycles (the model currently assumes that AVs and OVs can operate at 1-second headways downstream of the intersection, as long as there is a sufficient gap ahead to let the front cars accelerate away from the rest).

With all AVs, both the prioritized "white aspect" operation and AWW operation are able to pump out 1,377 VPH downstream northbound (which is quite close to 1,400 injection rate).  Even the prioritized RYG is cranking out 1,364 VPH.  At no time did the traffic signal ever need to go into a "clear out" cycle.  There were 833 "protection slots" per hour (leaving only 8 "half-slots" that could be occupied), which gives us a theoretical maximum output of 1,372 VPH.  Note that there are some rounding errors (due to having three cars arriving in the first slot for Φ6/Φ4RT/Φ3LT). 

When we inject 10% OVs into prioritized "white aspect" model, the system responded even better and cranks out 1,438 VPH downstream.  That's also due to those rounding errors. 

Heading further downstream along the arterial route, it is going to be more difficult to inject this much traffic from the [side routes].  But once we start to push up against the maximum limits, we can start to add some simple roadway features to improve throughput:  (A) slip ramps for the Φ4 right turns; (B) longer queue capacity for Φ3 left turns; (C) additional through lanes for [northbound] Φ3; and possibly (D) acceleration lanes out of the slip ramps for the Φ4 right turns.  The model is going to need to be changed drastically, since it is assumed that there is minimal impact for the low volume Φ3/Φ4 cross-traffic, but that will have a much worse impact on Φ6+Φ4RT+Φ3LT throughput as the Φ6 injection rate increases.  This is probably easier to calculate the impact rather than modelling.

At the end of the day, if this thing is going to see the light of the day, you need a workable simulation algorithm is required to flash into controller.
But looks like idea isn't crazy overall...

[Dirt Roads]

At the end of the day, if this thing is going to see the light of the day, you need a workable simulation algorithm is required to flash into controller.

One reason that I honed in on Prioritized "White Aspect" Operation is that I know of two large tech firms that supply both Traffic Signal Control System networks/software and Automated Vehicle Supervision (AVS) network equipment/software (plus there is another huge tech conglomerate that serves as a systems integrator in both of these industries).  Three players make it a viable commercial prospect if the cost/benefit works out.  But if I am correct, none of these players have a "Merge at Speed" technology that can command an AV to accelerate to precisely "hit a slot" in the middle of dense traffic.  Two of these were huge tech conglomerates are no longer active in the industry, and one of those two is still a big player in Air Traffic Control.  But right now, the "gap protection" methodology used in this model doesn't require "Merge at Speed" capabilities (which appears to be capable of working fairly well if you don't have too high of a traffic saturation).

But looks like idea isn't crazy overall...

I'm still not sold yet, but this looks much better than I ever imagined.  The bigger problem is going to be real-time downlink to the AVs.  The railroads had a horrible time working with the FCC trying to get bandwidth for high-tech Positive Train Control (which works much different that the older stuff used on the Northeast Corridor).  Railroads were asking for a lot of bandwidth, which may not be needed for "Merge at Speed" capabilities (the original WVU system in Morgantown accomplished this with only 8-bit packets at 1200 baud, which was overkill at the time).  (For the record, the Morgantown PRT is not a good example of how this should work, but the operating concepts there are indeed similar).

[kalvado]

At the end of the day, if this thing is going to see the light of the day, you need a workable simulation algorithm is required to flash into controller.

One reason that I honed in on Prioritized "White Aspect" Operation is that I know of two large tech firms that supply both Traffic Signal Control System networks/software and Automated Vehicle Supervision (AVS) network equipment/software (plus there is another huge tech conglomerate that serves as a systems integrator in both of these industries).  Three players make it a viable commercial prospect if the cost/benefit works out.  But if I am correct, none of these players have a "Merge at Speed" technology that can command an AV to accelerate to precisely "hit a slot" in the middle of dense traffic.  Two of these were huge tech conglomerates are no longer active in the industry, and one of those two is still a big player in Air Traffic Control.  But right now, the "gap protection" methodology used in this model doesn't require "Merge at Speed" capabilities (which appears to be capable of working fairly well if you don't have too high of a traffic saturation).

But looks like idea isn't crazy overall...

I'm still not sold yet, but this looks much better than I ever imagined.  The bigger problem is going to be real-time downlink to the AVs.  The railroads had a horrible time working with the FCC trying to get bandwidth for high-tech Positive Train Control (which works much different that the older stuff used on the Northeast Corridor).  Railroads were asking for a lot of bandwidth, which may not be needed for "Merge at Speed" capabilities (the original WVU system in Morgantown accomplished this with only 8-bit packets at 1200 baud, which was overkill at the time).  (For the record, the Morgantown PRT is not a good example of how this should work, but the operating concepts there are indeed similar).

As far as I understand, v2v and v2i spectrum allocations exist. Although that band may be a bit too rain sensitive...

[Dirt Roads]

As far as I understand, v2v and v2i spectrum allocations exist. Although that band may be a bit too rain sensitive...

Sadly, the old V2V movement didn't get off the ground.  But there is some bandwidth remaining for Intelligent Transportation Systems (typically used for remote VMS signage).
https://www.theverge.com/2022/8/12/23303191/car-v2v-fcc-spectrum-wifi-court-ruling

[kalvado]

As far as I understand, v2v and v2i spectrum allocations exist. Although that band may be a bit too rain sensitive...

Sadly, the old V2V movement didn't get off the ground.  But there is some bandwidth remaining for Intelligent Transportation Systems (typically used for remote VMS signage).
https://www.theverge.com/2022/8/12/23303191/car-v2v-fcc-spectrum-wifi-court-ruling

V2V... A cool idea, but I never really understood where it is going after all...

[Dirt Roads]

The model for AWW had a hard time keeping up with this same level of traffic when assuming first come/first serve (randomized).  The traffic signal never needed to go into a "clear out" cycle, but it got close a few times.  There were numerous instances where we saw three AVs backed up into a queue (worst delay was 15 seconds plus speed reduction time), such that the fourth AV was able to proceed at speed as close as one or two "slots" behind the third AV in the queue (actually had several random instances where the next AV was able to proceed at a slightly reduced speed in the "half-slot" behind the queue, and the model hasn't been tweaked to add in the extra delays for speed reduction at that close of a distance).  In many cases, the traffic signal needed to release right turn/left turn traffic in the different sequence than first come/first serve in order to minimize the impact of "slot protection".  I never expected a FIFO order of protection, but this didn't even get close.  On the other hand, it appears that this model actually provides more available "half-slots" for cross-traffic.

This hammered the AWW throughput down to 930 VPH.  I was hoping that AWW would perform better under first come/first serve because it would eliminate the need for a coordinated centralized traffic signal system/network to manage the flow of vehicles through the intersection.  I haven't checked yet, but suspect that the Prioritized "White Aspect" model would simply revert to "Plain Ole' RYG" operation a good chunk of the time under this traffic flow when dealing with first come/first serve.

[Dirt Roads]

V2V... A cool idea, but I never really understood where it is going after all...

V2V appears to a necessity for operating autonomous vehicles and trains at spacing closer than the safe braking distance.  The latency response times added to braking distances for each successive vehicle or train gets unsafe pretty quickly.  Keep in mind that this is also true with entrained vehicles (ergo, trains).  Most trains have pneumatic trainlines that help speed up the braking response on successive cars, but many trains also need electrical trainlines to facilitate braking response such that the minimum emergency brake rate on the train is assured.  But of course, we can do all of that with copper wires (although the newer trainline networks use fiber optics on each car).

Most of today's cars with semi-autonomous are operating at sufficient spacing to allow each car enough of a time-slice to deal with your typical latencies.  But I am concerned about the auto manufacturers that are allowing "drivers" to set the adaptive cruise control (ACC) at an 0.5-second nominal spacing.  The biggest issue is the reaction time needed when an accelerating AV encounters an emergency braking application, which can more than double the reaction time needed to achieve the full service brake deceleration rate.  Then add that same problem to all of the following AVs.

[kalvado]

V2V... A cool idea, but I never really understood where it is going after all...

V2V appears to a necessity for operating autonomous vehicles and trains at spacing closer than the safe braking distance.  The latency response times added to braking distances for each successive vehicle or train gets unsafe pretty quickly.  Keep in mind that this is also true with entrained vehicles (ergo, trains).  Most trains have pneumatic trainlines that help speed up the braking response on successive cars, but many trains also need electrical trainlines to facilitate braking response such that the minimum emergency brake rate on the train is assured.  But of course, we can do all of that with copper wires (although the newer trainline networks use fiber optics on each car).

Most of today's cars with semi-autonomous are operating at sufficient spacing to allow each car enough of a time-slice to deal with your typical latencies.  But I am concerned about the auto manufacturers that are allowing "drivers" to set the adaptive cruise control (ACC) at an 0.5-second nominal spacing.  The biggest issue is the reaction time needed when an accelerating AV encounters an emergency braking application, which can more than double the reaction time needed to achieve the full service brake deceleration rate.  Then add that same problem to all of the following AVs.

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.