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!
