There are many many articles about this that appeared over the past couple days
here's one
https://www.popularmechanics.com/technology/infrastructure/a42804174/fourth-color-traffic-light-white/
Huge problem, we don't have autonomous vehicles and we aren't likely to get "real" iterations soon.
White means to just follow the car in front of them? Why not just keep it green?
Red-green colorblind people would have problems with the white light, since green lights are already diluted in their vision. A magenta shade of purple would work better, if we really must do this, as purple is suggested in the article.
I cannot imagine the cost of replacing every single traffic light chassis in the country or even in one state and having to program the timing of it only to have this be a temporary stopgap
Quote from: Dustin DeWinn on February 11, 2023, 09:50:48 AM
I cannot imagine the cost of replacing every single traffic light chassis in the country or even in one state and having to program the timing of it only to have this be a temporary stopgap
Yep. Signals right now are extremely expensive, when in years of yore they were considered cheap. In central NY, signal replacements for one typical intersection are now maxing out at $300,000. Signal replacement projects were set up to handle multiple locations, so those projects are increasing in price considerably. $1m projects are now costing $3m...
White means you can walk across the intersection.
Quote from: Big John on February 11, 2023, 11:10:02 AM
White means you can walk across the intersection.
Unless it's an emergency signal.
White is also used for LRT and BRT systems.
https://maps.app.goo.gl/LMpW8rUXhWnFnYuG9
Quote from: Rothman on February 11, 2023, 10:01:20 AM
Quote from: Dustin DeWinn on February 11, 2023, 09:50:48 AM
I cannot imagine the cost of replacing every single traffic light chassis in the country or even in one state and having to program the timing of it only to have this be a temporary stopgap
Yep. Signals right now are extremely expensive, when in years of yore they were considered cheap. In central NY, signal replacements for one typical intersection are now maxing out at $300,000. Signal replacement projects were set up to handle multiple locations, so those projects are increasing in price considerably. $1m projects are now costing $3m...
What's driving the cost increase? Aren't signal heads these days basically just plastic? And LEDs aren't that expensive... Is it just higher cost of labor and chips?
Quote
For the dawning age of the self-driving car, transportation engineers from North Carolina State University are proposing the addition of a fourth "white light" whose function would be to alert humans to simply "follow the car in front of them."
Sorry but what? We've taught drivers for decades to never trust that another driver will do a certain thing or take a certain action, and now we're supposed to just drive straight through an intersection because the oh-so-smart autonomous car in front of us is?
Quote from: plain on February 11, 2023, 11:19:11 AM
White is also used for LRT and BRT systems.
https://maps.app.goo.gl/LMpW8rUXhWnFnYuG9
Lunar white is also used in railroading, but means "Call-on Signal". This has a similar connotation as to the use of a white aspect with autonomous vehicles. While the "Call-on Signal" gives an aspect that indicates "Proceed, prepared to stop in 1/2 sight distance" the actual use indicates to train crews to "follow the leader". The intention here may be similar as well, since the practical use of the "Call-on Signal" is to pull a train through to the other side of the [intersection] (ergo, interlocking) rather than stopping at the signal and blocking the route of next train.
I have a concern about the use of a white aspect on traffic signals for this purpose. Human drivers will soon learn that whenever one driver gets a "Follow-the-Leader" aspect, then everyone else can do the same (even if the traffic signal goes into a different phase and turns yellow, then red). It is one thing that in New Jersey, six to eight cars will run the light after it turns red. It is another thing when 15 to 20 cars decide to "Follow-the-Leader" to hop over to the next junction. This is a sure-fire way to get into a gridlock situation somewhere down the line.
Quote from: MultiMillionMiler on February 11, 2023, 08:30:08 PM
Traffic lights wouldn't be needed at all if all cars were self driving. There would just be 2 continous perpendicular streams of cars essentially passing between each other as they approach the intersection at high speed. A supercomputer network would control the precise speeds and directions of the cars so they would all never hit each other (although they may come within a few millimeters of each other).
And pedestrians?
The traffic lights, they turn blue tomorrow.
Quote from: Scott5114 on February 11, 2023, 06:22:51 PM
Quote from: Rothman on February 11, 2023, 10:01:20 AM
Quote from: Dustin DeWinn on February 11, 2023, 09:50:48 AM
I cannot imagine the cost of replacing every single traffic light chassis in the country or even in one state and having to program the timing of it only to have this be a temporary stopgap
Yep. Signals right now are extremely expensive, when in years of yore they were considered cheap. In central NY, signal replacements for one typical intersection are now maxing out at $300,000. Signal replacement projects were set up to handle multiple locations, so those projects are increasing in price considerably. $1m projects are now costing $3m...
What's driving the cost increase? Aren't signal heads these days basically just plastic? And LEDs aren't that expensive... Is it just higher cost of labor and chips?
Nope. I am talking complete reconstruction, so including replacing poles, if necessary.
So, yes, materials and labor are rising in cost, especially as more funding is provided at the state and federal levels and contractors in rural and small urban areas are overwhelmed by the increase either in number of lettings or in contract size (we can afford the big project now!). These are the main variables.
However, policy changes may also be a factor. NYSDOT, with every paving job that requires ripping up loops, is replacing loops with video detection. That's an increased cost as those systems are installed as well. Secondary to material cost increases, but a big number two.
I will respond here like I did on Facebook:
Extend the yellow light by a second, extend the all-red phase by a second, and change the definition for a yellow light to "go if you can cross the stop bar before the red light" to encourage more people getting into the intersection... which would entail following the car in front of them!
What do you do if you're the first car, and the light is white anyways? There would inevitably be some difficulty detecting which car is self driving; yeah there can be some kind of transponder, but stuff breaks all of the time.
This would also require a standard to be established for cars to communicate with signal controllers... which standard will win? Will current autonomous vehicles become useless?
Not to mention, there are a fair number of issues with autonomous driving in the first place, before you even touch a signal head. I will not elaborate here, because that horse is already dead and beaten!
A Gizmodo writer from Portland overlooking the safety aspects regarding cyclists and pedestrians.
Kind of sad when I need these people to be useful idiots for the likes of me and they can't be bothered.
Quote from: Hobart on February 12, 2023, 01:40:55 AM
Extend the yellow light by a second, extend the all-red phase by a second, and change the definition for a yellow light to "go if you can cross the stop bar before the red light" to encourage more people getting into the intersection... which would entail following the car in front of them!
I'm with you there. Human drivers have a hard enough time dealing with the three signal colors we've already got, let alone with recent additions like the flashing yellow arrow for permissive left turns.
Add infrared diodes to yellow as a second color if that is for computer only. No confusion for humans...
Quote from: Max Rockatansky on February 11, 2023, 09:34:59 AM
Huge problem, we don't have autonomous vehicles and we aren't likely to get "real" iterations soon.
Actually we do. Not in the streets, but there are mines running with driverless trucks. They make a good point that some facilities, like cargo terminals, may get more of those.
I still don't understand what autonomous vehicles should be doing here if that cannot be relayed to a regular RYG head
I say there should be a separate signal for autonomous vehicles that will correspond to the traditional RYG phase. If I were an engineer for FHWA, I'd come up with the following proposals:
STOP: Red octagon
CAUTION: Yellow triangle indicating travel direction (up for straight through, and sideways for left/right turns)
GO: Green triangle, also indicating travel direction
Quote from: Henry on February 14, 2023, 10:54:34 AM
I say there should be a separate signal for autonomous vehicles that will correspond to the traditional RYG phase.
What would be the benefit of that? Why would autonomous vehicles have separate traffic light phases?
I also don't understand the reasoning for a white light. "Just keep following the vehicle ahead of you." What if I don't want to go that way?
Quote from: Henry on February 14, 2023, 10:54:34 AM
I say there should be a separate signal for autonomous vehicles that will correspond to the traditional RYG phase. If I were an engineer for FHWA, I'd come up with the following proposals:
STOP: Red octagon
CAUTION: Yellow triangle indicating travel direction (up for straight through, and sideways for left/right turns)
GO: Green triangle, also indicating travel direction
It is a totally different concept.
What they say is white should be a permissive phase where connected vehicles do communicate and use smaller gaps in traffic. Sort of yield in high-tech version with every automatic car being willing to cooperate. They assume automatic cars can slow down and accelerate to optimize gaps in the stream to let cross and left turns through (unlike humans who are always willing to accelerate and close the gap)
paper is available: https://www.newswise.com/pdf_docs/167577509263217_Hajbabaie%20white%20phase%20intersection%202023%20FINAL.pdf
Although there are too many formulas from my perspective to make things believable.
UPD: OK, to clarify: concept is that driverless cars can negotiate a very short, maybe 2 second "red" period during white phase to allow 1 car from a low traffic side road to squeeze through. That is instead of minimum 10 second for traditional red (including both yellows)
Quote from: kalvado on February 14, 2023, 11:09:35 AM
What they say is white should be a permissive phase where connected vehicles do communicate and use smaller gaps in traffic.
"Merge-at-speed" is a common function in modern Personal Rapid Transit (PRT) systems that utilize much of the same technology as [autonomous cars]. These PRT system do have a centralized [master control system] that is similar to Automated Transit Supervision (ATS) in other forms of rail transit and automated guideway systems. The ATS for a PRT system generally assigns vehicle "slots" that operate around the mainline; some of the "slots" are occupied by vehicles and some the "slots" are virtual and unoccupied. The typical PRT philosophy involves "off-line stations" where the vehicles pull off the mainline to discharge passenger, pull forward to receive passengers at a different berth and then accelerate to the merge point to access a "slot". In cases where no slot is available, the ATS will slow down some vehicles to create a new slot in advance of the merging vehicle. This same approach could be used at perpendicular intersections. Which leads us to...
Quote from: MultiMillionMiler on February 11, 2023, 08:30:08 PM
Traffic lights wouldn't be needed at all if all cars were self driving. There would just be 2 continous perpendicular streams of cars essentially passing between each other as they approach the intersection at high speed. A supercomputer network would control the precise speeds and directions of the cars so they would all never hit each other (although they may come within a few millimeters of each other).
Signals are still needed at all intersections and merge points. One of the most difficult issues we deal with in the world of [driverless trains and other similar thingys] is that the vehicles can (and do) lose their automation, and even worse, lose communication with the centralized [master control system]. Dealing with all of the crazy issues related to what the industry calls "Non-Communicating Trains" (NCTs) is a technological and philosophical world unto itself. All of which requires wayside signals to deal with the safety issues related to how a manually-driven vehicle can avoid side-swipes in the middle of a sea of autonomous vehicles.
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.
Quote from: Dirt Roads on February 14, 2023, 05:15:00 PM
Quote from: kalvado on February 14, 2023, 11:09:35 AM
What they say is white should be a permissive phase where connected vehicles do communicate and use smaller gaps in traffic.
"Merge-at-speed" is a common function in modern Personal Rapid Transit (PRT) systems that utilize much of the same technology as [autonomous cars]. These PRT system do have a centralized [master control system] that is similar to Automated Transit Supervision (ATS) in other forms of rail transit and automated guideway systems. The ATS for a PRT system generally assigns vehicle "slots" that operate around the mainline; some of the "slots" are occupied by vehicles and some the "slots" are virtual and unoccupied. The typical PRT philosophy involves "off-line stations" where the vehicles pull off the mainline to discharge passenger, pull forward to receive passengers at a different berth and then accelerate to the merge point to access a "slot". In cases where no slot is available, the ATS will slow down some vehicles to create a new slot in advance of the merging vehicle. This same approach could be used at perpendicular intersections. Which leads us to...
Quote from: MultiMillionMiler on February 11, 2023, 08:30:08 PM
Traffic lights wouldn't be needed at all if all cars were self driving. There would just be 2 continous perpendicular streams of cars essentially passing between each other as they approach the intersection at high speed. A supercomputer network would control the precise speeds and directions of the cars so they would all never hit each other (although they may come within a few millimeters of each other).
Signals are still needed at all intersections and merge points. One of the most difficult issues we deal with in the world of [driverless trains and other similar thingys] is that the vehicles can (and do) lose their automation, and even worse, lose communication with the centralized [master control system]. Dealing with all of the crazy issues related to what the industry calls "Non-Communicating Trains" (NCTs) is a technological and philosophical world unto itself. All of which requires wayside signals to deal with the safety issues related to how a manually-driven vehicle can avoid side-swipes in the middle of a sea of autonomous vehicles.
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....
Quote from: Dirt Roads on February 14, 2023, 05:15:00 PM
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.
Quote from: kalvado on February 14, 2023, 05:49:54 PM
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.
Quote from: Dirt Roads on February 14, 2023, 07:32:49 PM
Quote from: Dirt Roads on February 14, 2023, 05:15:00 PM
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.
Quote from: kalvado on February 14, 2023, 05:49:54 PM
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...
Quote from: kalvado on February 14, 2023, 09:16:25 PM
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.
Quote from: Dirt Roads on February 14, 2023, 09:54:48 PM
Quote from: kalvado on February 14, 2023, 09:16:25 PM
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.
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.
Quote from: Dirt Roads on February 21, 2023, 11:10:24 PM
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.
Quote from: Dirt Roads on February 21, 2023, 11:10:24 PM
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:
Quote from: kalvado on February 22, 2023, 07:21:53 AM
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.
Quote from: Dirt Roads on February 22, 2023, 01:43:06 PM
Quote from: Dirt Roads on February 21, 2023, 11:10:24 PM
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:
Quote from: kalvado on February 22, 2023, 07:21:53 AM
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
^^^
I may have not explained this so well, but my main point is to try to answer this question posed by
Rothman:
Quote from: Rothman on February 11, 2023, 09:41:11 AM
White means to just follow the car in front of them? Why not just keep it green?
Quote from: kalvado on February 22, 2023, 01:54:16 PM
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.
Quote from: Dirt Roads on February 23, 2023, 10:49:12 AM
^^^
I may have not explained this so well, but my main point is to try to answer this question posed by Rothman:
Quote from: Rothman on February 11, 2023, 09:41:11 AM
White means to just follow the car in front of them? Why not just keep it green?
Quote from: kalvado on February 22, 2023, 01:54:16 PM
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
Quote from: Dirt Roads on February 23, 2023, 10:49:12 AM
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...
How do cyclists fit in with this idea?
Quote from: kphoger on February 23, 2023, 11:10:20 AM
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.
Quote from: kphoger on February 23, 2023, 11:10:20 AM
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).
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).
(https://ops.fhwa.dot.gov/publications/fhwahop08024/images/4_3web.png)
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.
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?
Quote from: Dirt Roads on February 28, 2023, 10:20:08 AM
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.
Quote from: kalvado on February 28, 2023, 11:43:50 AM
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.
Quote from: Dirt Roads on February 28, 2023, 05:58:31 PM
Quote from: kalvado on February 28, 2023, 11:43:50 AM
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...
Quote from: kalvado on February 28, 2023, 06:17:45 PM
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).
Quote from: kalvado on February 28, 2023, 06:17:45 PM
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).
Quote from: Dirt Roads on February 28, 2023, 09:21:32 PM
Quote from: kalvado on February 28, 2023, 06:17:45 PM
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).
Quote from: kalvado on February 28, 2023, 06:17:45 PM
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...
Quote from: kalvado on February 28, 2023, 10:11:06 PM
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
Quote from: Dirt Roads on February 28, 2023, 10:33:18 PM
Quote from: kalvado on February 28, 2023, 10:11:06 PM
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...
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.
Quote from: kalvado on March 01, 2023, 02:58:49 PM
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.
Quote from: Dirt Roads on March 02, 2023, 11:46:52 AM
Quote from: kalvado on March 01, 2023, 02:58:49 PM
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.
Quote from: kalvado on March 02, 2023, 11:59:37 AM
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?
Quote from: kphoger on March 02, 2023, 12:19:19 PM
Quote from: kalvado on March 02, 2023, 11:59:37 AM
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
Quote from: kalvado on March 02, 2023, 12:29:30 PM
Quote from: kphoger on March 02, 2023, 12:19:19 PM
Quote from: kalvado on March 02, 2023, 11:59:37 AM
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...
Quote from: kphoger on March 02, 2023, 12:43:07 PM
Quote from: kalvado on March 02, 2023, 12:29:30 PM
Quote from: kphoger on March 02, 2023, 12:19:19 PM
Quote from: kalvado on March 02, 2023, 11:59:37 AM
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.
Quote from: kalvado on March 02, 2023, 04:18:05 PM
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.
Quote from: kphoger on March 02, 2023, 04:27:44 PM
Quote from: kalvado on March 02, 2023, 04:18:05 PM
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
^^^^
^^^^
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.
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.
Quote from: Dirt Roads on March 03, 2023, 12:42:01 PM
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.
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).
(https://ops.fhwa.dot.gov/publications/fhwahop08024/images/4_3web.png)
- Φ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.
^^^^
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.
^^^^
^^^^
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).
Quote from: Rothman on February 11, 2023, 09:41:11 AM
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.
Quote"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).
Quote from: Dirt Roads on March 07, 2023, 11:29:11 AM
Quote from: Rothman on February 11, 2023, 09:41:11 AM
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.
Quote"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. .
Quote from: kalvado on March 07, 2023, 04:35:03 PM
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.
Quote from: kalvado on March 07, 2023, 04:35:03 PM
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.
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.