Sunday, August 11, 2013
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!
Posted by Dan at 9:32 PM