Sunday, August 11, 2013

159> Headway? I Don't Need No Stinkin' Headway!



I wonder if PRT is a technology that, up until now, really wasn’t as ready for prime time as we would have liked to believe.  I started pondering this while considering the concept of “line speed.”   What good is it?  It seems to me that its primary function is to stop insufficiently intelligent vehicles from rear-ending each other.  I know what you are thinking.  Anything other than a set line speed is unnecessarily complicated.  With every vehicle trapped between two others, what is the point?

Let’s consider the unthinkable - congestion on the network.  Yeah, I know, PRT congestion is just not supposed to happen.  Some magical computer in the sky will prevent it.  Yet we know better.  If the network is big enough, and there is excessive demand in one part of it, it will happen, and having the system refuse passengers going to certain destinations is hardly a solution.

Our previous discussion regarding the three lane bridge really brought the matter home. The bridge represents what PRT planners would want to avoid the most; a bottleneck.  This is the antithesis of the grid systems traditionally envisioned for downtown use.  Yet we all know that people’s transportation needs are not uniform, either in time or location.  We also know that there is liable to be scant funding for any route that is not expected to see a whole lot of business.  That means that the less trafficked parallel routes that would take up the slack in rush hour are unlikely to be there in the first place.  Simple “move forward/back by a half-slot” type of merge control becomes a clunky version of variable speed anyway since, in heavy traffic, opening up a slot for a merging vehicle creates a chain reaction that must extend far backward and/or forward until space is found.

One obstacle to a good remedy is the idea of needing a set headway - especially sufficient headway to come to a complete stop if there is an immovable object ahead.  This so-called “brick wall stop” rule is an ill-suited extension of railroad regulations, which I believe may currently extend to “automated people movers.”  No such law, I would note, has been extended to Google’s self-driving cars, which are a much closer comparison to PRT than trains.  Aren’t self-driving cars automated people movers? Be careful of what you call yourself!

Without adding track, the only way to get greater vehicular throughput is to reduce headways and/or increase speed.  And so we must ask the logical question:  “How much headway is really necessary?”  I contend that it is possible to design PRT systems where there need not be any headway at all.  After all, crash damage occurs due to the speed difference between vehicles, (or objects) not the speed per se.  This is a very different situation from either automotive or railroad scenarios.  Unlike either, some PRT designs are be completely captive within the track, preventing lateral skidding or derailing in any weather.  They can also be designed to clamp the track for emergency stops. (preferably at a rate just shy of throwing the passengers around)  Also, unlike cars, PRT vehicles can be designed with perfectly aligned “bumpers.”  With the suspended gondola designs, forward momentum transfers to upward momentum in a swinging motion, potentially eliminating the possibility of contact between cabins altogether. (There would need to be a way to rapidly decelerate the swing before making contact with the track bottom, however)  And let’s not forget the fact that the braking capacity is independently replicated on each vehicle, with no drivers to the slow reaction time.  When a lead vehicle slows, a vehicle twenty cars back can instantly decelerate as well.  Since normal braking is electromagnetic (the motors simply slow down) the deceleration rates can be virtually identical.

These features, combined with variable speed, enable true cooperative merging and the safe elimination of headways, so vehicle density on a track could be taken to the limit.  That limit is having vehicles actually touching, essentially forming a train, but with every vehicle exactly matching the movement of its neighbors through its own propulsion.  And coupling?  Actually, with regular servomotor technology, it really would not matter if they were coupled or not.  Coupling, in the railroad sense, is simply a way for one car to pull another, so that they don’t all need independent propulsion.  Since PRT vehicles have independent propulsion that can produce highly accurate velocities, it really would not matter if the vehicles actually have an interlocking mechanism or not.  I imagine a cushioned magnetic linkup would be just fine, as long as the connection was elastic enough to allow each vehicle to “read” its own performance.  (Servo mechanisms require a steady stream of position information that is derived from their own effort, so that they may continuously adjust their performance.)  A good physical data connection would be useful, though.

Here’s how I see it all working.  Vehicles would have a “suggested” speed, but also would try to distribute themselves to facilitate maximum flexibility at merge points.  As the traffic increases, however, headway distances naturally become shorter.  At some point, this “suggested” speed (which, with sufficient traffic, is a de facto line speed) may be reduced - or not.  This is, after all, just a line of code and a judgment call by the system administrators and the city;  They, don’t, after all, want to scare the passengers!  Anyway, as more vehicles enter the stream, and the spaces between vehicles become too small for easy merging of vehicles, the algorithms that make the vehicles self-distribute change to make the vehicles couple into self-distributing trains (platoons) to open up whatever space is still available.  The entering vehicles merge to fill these spaces. Of course there is a limit to how far even this can go before there are simply no spaces.  There will still be the need to regulate traffic from the stations - to temporarily prohibit certain destinations if need be, but at least the track would be utilized to the full extent possible.  

Why not just skip the first step and have the vehicles group from the start?  Mostly because any system is unlikely to have a traffic problem for quite some time, and even then, heavy traffic would never be anything even close to systemic.  It would almost certainly require a natural bottleneck, such as the bridge, and be for short times.  Why design for the exception rather than the rule?

That being said, the incentive to overload a track infrastructure is undeniable.  Adding vehicles, each of which produces income, could be a very easy and painless way to gain transit revenue, and cutting network costs by never adding less essential routes seems inevitable.  That, while PRT providers need to provide the most “bang for the buck.”  The self-distributing model, I think, is the best, and the other can be seen as a work-around, for lack of adequate routing options.  It seems prudent to build in such a capability from the start, though as PRT should ideally be an unbreakable system that does not require particularly great planning or oversight.

Without diving too deeply into control issues, here is one supporting observation:  If there is enough traffic, the ability to merge will become increasingly difficult to execute locally.  In the extreme example, a specific merge might not even be possible without being timed from the onset of a vehicle’s leaving a station.  Yet this is not how the process is best done in normal circumstances, because coordinating all traffic centrally relies too much on shared computer and communication hardware, not to mention latency and connectivity issues.  The system would be vulnerable to all sorts of possible maladies.  Spreading traffic out massages the problem into one that can be normally solved locally, through vehicle to vehicle communications, (cooperatively) and with sensors and stored data.(autonomously)  Again, the system should be unbreakable.


And that three lane bridge?  Even in the nearer future, before people need or trust “zero headway” enough to use it for human passengers, empty vehicles could still platoon to use such a lane for the least possible time.  Without humans to confuse, a third lane can switch directions as often as needed.  In just a couple of minutes, a train of dozens of empty vehicles could zip across at breakneck speed, and then the lane could be returned to regular traffic or its role as an emergency/ maintenance lane.  Obviously the space saving advantages of platooning empties extends beyond the bridge as well.   


PS - Alert readers will note that the designs shown in this blog have compact bogies that do not touch before the hanging passenger compartments do, complicating platooning, or even safely pushing vehicles.  Elongating the bogies could make them hard to fit in an enclosed, tightly turning track, and figuring out the best compromise is high on the design agenda.  (We are talking about nearly 2 ft. projections, front and rear) It may be that the climbing (pinion) sprockets can be used for such tight turns using the “rack,” instead of the normal track guide surfaces. This could allow constraining parts of the track to be removed or relocated, thus solving the problem.  All of this will made easier to visualize with a physical model, and I am still working on that.

In that regards, in case you missed it, I have started by hand building some servo hub-motors, like in this video, (go to the 5.5 minute mark to just watch it work, without the technical jibber-jabber!)   The remaining three wheels are all coming along… I just completed and tested motor #2, which is really the “production” prototype.  (I wouldn’t like to try to replicate the first one…it was just too complicated!) Motors 3 and 4, modeled after number 2, are in various stages of completion.  What a shame that just when I learn how to build the things in an efficient, procedural way, it is time to move on!  Even worse, now know how to make them much stronger and more efficient, but I need to match motor #1. This is effort is based in Texas, but I am preparing to return to New England, where my more bucolic endeavors reside, so be patient - I think it will be worth the wait!

6 comments:

qt said...

Concerning the bogie-touch problem in your PS, a suggestion:

How about a sacrificial bogie "trailer"? Basically a pair of bumpers connected by a crushable tube (or other structure), hung by an extremely simplified set of wheels and "towed" by the pod's bogie.

Very lightweight, with no power or steering (it follows the main bogie through turns and switches like any other towed vehicle. The bumpers are tough enough to handle routine bumps and perhaps emergency pushes. The rest of the structure is designed to absorb major impacts and deform to spare bogie, pod, and passengers.

Don't know how practical it is, but hey...

Juho Laatu said...

Some short random comments follow.

In this article the traffic control seems to be fully distributed. It could be also hybrid. Instead of having one central computer, each section of the track or even each crossing could have its own computer. (Or maybe you planned even to make two vehicles negotiate between themselves (without any "track computers") which one enters a crossing first?) The idea is anyway that if I want, I could contact all the crossings at my planned track and ask for a slot at the planned time. If I get the slots, I would have an (almost) guaranteed track with agreed timing to my destination. This kind of a system would allow both preplanned trips and distributed recovery from whatever traffic jams. In the beginning there could be one central (track) computer. In the end all major crossings could have their own computer.

Some dynamic route planning is needed in any case. A 100% preplanned system with fixed speed is not good. This is because of the possibility of unexpected problems (e.g. track blocked by a broken vehicle), need to change one's travel plan (e.g. after forgetting one's briefcase at home), and if we want to support just driving around the city, just too see the sights and to see what's going on.

But dynamic dynamic route planning need not stop some vehicles having also fixed routes that take them to their destination in fixed time.

Vehicles could have different priority. Highest priority is of course reserved for emergency traffic. Fixed planned routes may come next. Any (self made) changes in driving plans could lead to lower priority, and one could easily end up in a side track for a minute if one suddenly decides to take some congested route. Actually a good track has some extra space in the stations or in the form of sidetracks where one can push excess traffic when one has to. Better so than to stop or slow down all the traffic on the main track. Lower priority traffic could well wait.

Juho Laatu said...

(continued)

I note that a PRT network could be very heavily loaded because of the low cost of driverless traffic. We could e.g. have lots of low cost cargo traffic. Such vehicles could in principle fill all the gaps in the tracks. Those cargo vehicles (maybe carrying some bulk cargo like grain) could well stop and wait for other traffic whenever needed. We probably need different priority classes for this. Maybe one could also pay more for higher priority (if payments are used in the first place on public tracks).

I can imagine some companies using the PRT tracks even as their storage space (from one factory location to another, or just running around). It may well be cheaper to send material to the PRT track than to build new storage space for it. The storage space could actually be also buffer tracks that have been built to take extra traffic off the main track in case of traffic jams. Or this could be a planned system where companies can be charged for the storage space (maybe in some huge storage areas, or just in small overflow buffers next to main crossings).

From this point of view also the "headway space" could be seen as an additional buffer that could be easily filled. Any track could be filled up to its structural limits (some tracks may allow only one vehicle at a time on some lightweight track segments).

In a system with different static and dynamic/changing priorities a good traffic policy may allow part of the traffic to travel full speed even if part of the traffic has to wait. The pain of traffic jams would thus not be spread evenly to all vehicles. Some vehicles might even get out of the way already when the probability of disruptions to some higher priority traffic grows. Having lots of (low priority) cargo on the system may thus also help others (humans) to have no (experienced) traffic jams at all.

I note that different vehicles could have different preferences. Some might like to travel alone (to feel safer, to see the views, to allow flexible speed), some might want to save energy and form trains.

One more observation. You could have also vehicles with one passenger compartment but with two bogies (on in the front, one in the back). That could give also better stability in high speeds if the bogies are really short. (This may change the bogie connection arm philosophy a bit.)

Andrew F said...

qt, the problem with a sacrificial bogey like you describe is for steering with travelling in reverse. At diverge points, the sacrificial bogey may not choose the same direction as the bogey proper and jam/collide with the guideway. Reversing should not be used all that much, but it would be a shame to give up that capability.

qt said...

re "bogie trailer" problem: Well, that's what I mentioned it for--to see if there was something I'd overlooked in the, oh, thirty seconds I spent thinking about it. :)

Frankly, I don't think it's a particularly serious problem anyway. I only mentioned the trailer as a possible option for a city/utility/whatever that was going to make a big fuss about bumping. Dan didn't seem TOO upset about it, so I wasn't...

JustMoney said...

Don't know if you address another advantage to zero-headway - significant reduction in wind-resistance. As a cyclist I can draft fairly easily at 30mph. Over extended stretches cars should snuggle up to each other as standard practice.