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:
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...
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.
(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.)
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.
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...
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.
Post a Comment