I want to dust-off a topic I have posted on before, and add some new thoughts I have had on the matter. The subject, or perhaps the question, regards what kind of routing layout PRT is best suited for, or should start with. Unfortunately I need to get down to some greasy details to make my point.
First I want to point out something about PRT control. In the very early days of PRT, back in the days of the Aerospace Corporation’s involvement, sensor, computer and communication technologies were in their infancy. The logical approach to vehicle control was to have a big computer manage all of the cars like one big machine. That way not much was required in the way of sensors or computing power on board. (Now, of course, we have more computing power in our cell phones than their whole system had.) Merges were conceived in terms of vacant or occupied spaces that were all moving at the same speed, something that can clearly be seen in the video. This required a uniform “line speed.” I am not sure about Vectus, (seems like someone told me it has dynamic speed control) but I believe everyone else pretty much assumes this sort of set speed. (If my information is dated, please correct me!) The going wisdom seems to be that to be financially viable, the track needs to be packed at all times, and so the system must be confined specific, highly urbanized areas. Therefore the routing involves close distances and so the system doesn’t need to go fast.
Then there is the matter of headway limitations. There is a notion out there that vehicles can only go so fast, because the headway requirements increase as the speed increases. Therefore, more cars can pass a point traveling slowly and close together than by going fast and being more spread out. There is a formula that “proves” this. Unfortunately this has led some to conclude that PRT, as a rule, can only go so fast. I have heard specific speeds mentioned.
I believe the arguments listed above are wrong-headed. First, about the packed track/financial viability thing…Perhaps the reason the track needs to be packed is because it is downtown, moving slow, has many stations, only short trips, etc. This all jacks up cost or constrains revenue. Amortizing this cost requires either high fares or a packed track. The per mile/kilometer cost estimates for PRT generally include several elevated stations, assume many long spans across streets, high construction costs because of traffic, buried utilities, etc. Has anyone, ever, given a quote to go across an empty field? Of course not. PRT is too slow to be useful for long haul, and it is too expensive to go anywhere where the track won’t be filled. See where I’m going with this? It’s a circular argument. Maybe it’s expensive because it is downtown and is downtown because it is expensive.
Let’s go back to, before moving on, to that argument about top speed and headway, since nobody is going to trade a 45-minute car ride for a 65 minute PRT ride. It, too, is a false choice. This is because the numbers going into the formula can be changed by simply designing the vehicle differently, and then the answer changes as well. I looked at the formula and found that the variables that must be entered refer to common sense considerations like braking efficiency, response time, and crashworthiness. Therefore any suggested optimal speed or headway distance is the result of plugging in numbers for a particular system’s capabilities. Nobody, (including me, so far) has plugged in the numbers for a system like I have proposed, but I guarantee that the safe headway would be way, way less than for a system where the first part of the vehicle to make contact in a collision is the passenger compartment itself, which is the case all of the systems currently on the market, yet need not be. They don’t need crashworthiness because they don’t go fast, because of, well… more circular arguments.
As far as the controls go, the technology for dynamic speed control is really not an issue anymore. Thousands of calculations can be done in thousandths of a second and transmitted and received with similar speed, although some intrepid programmers need to step forward and write an open-source version of the control software. An example of a demonstrated system (That even works with truly antique computers and sensors) is the PATH program. Insofar as at least some of it was funded by taxpayer money, I sort of hoped that they would at least respond to my requests for the code they used, but, alas, I’m just a lowly blogger…Anyway, with variable speed, another of the factors holding back PRT from being a commuting tool will have fallen.
One note, however… There is the matter of controlling vehicles that run on simple pavement, like ULTra and 2getthere. There is definitely a slippery pavement issue when it comes to going fast for these guys. None of my arguments apply to them. They really do need to keep to routes appropriate to more limited speeds, at least for the time being.
There is the matter of motion sickness, but again, with dynamic speed control, cornering speed would be based on factors including what is comfortable. The individual could (theoretically) even specify the kind of ride they prefer. So the last of the arguments against commuter PRT has been answered. Well, sort of… There is the matter of where to go on the suburban end.
Another thing that has changed since PRT’s inception is the proliferation of “Park & Ride” systems. These are essentially parking lot/bus stops in the suburbs, which are sometimes used in combination with HOV (High Occupancy Vehicle) lanes. The commuter can take the bus or carpool to bypass the clogged freeways. These lots are ready-made outlying destinations for PRT. But why not just take the bus? Because if there is no HOV lane, the bus gets just as stuck in traffic as the rest of the commuters. If there IS an HOV lane, it too, will become clogged over time, when (in some cases) it will magically morph into a toll lane. (Funny how that happens!) Also, upon exiting the HOV lane, the bus cannot take passengers to all of their respective destinations efficiently. And HOV lanes are usually one-way. (reversible) The buses face ordinary traffic on the return trip. Anyway, these Park and Ride lots are generally on inexpensive land that is very close to the freeway and would be cheap to connect to. True, the passengers would have had to drive to these lots, but don’t forget, the downtown traffic comes from somewhere. Typically, the first part of a morning commute goes pretty fast. It is the last five miles or so where the traffic gets really bad. This is nipping it at the bud. Otherwise the ironic alternative might be that the traffic downtown is from people looking for a place to park so they could use the great PRT system! That is one aspect of “short-haul” PRT that has always puzzled me – What does it really save if the passengers have to commute in to use it? (But then again I live in a city where almost nobody lives downtown)
It was recently remarked that PRT needed a network to be effective, that a simple loop or straight line would be a waste. Whereas this is largely true, especially compared to a large network, it is should be pointed out that even on a two-way straight-line configuration travel time can be improved by PRT’s off-line stations, meaning you can go non-stop to your destination, and the fact that PRT is available on demand. This cuts travel time to a fraction of light rail and a fraction of a fraction of bus travel time. In the case limited routing outlined above, though, many passengers would undoubtedly still need further transportation. The Achilles heel of buses is the many stops they must make, both for passengers and for stoplights. But even a very simple PRT loop could eliminate a huge portion of this wasted time. Personally, I wouldn’t like taking a five-minute bus ride to finish my commute, but I would do it if I had already saved enough time getting to the downtown area in the first place. If the last part of the journey were to be taken from a downtown terminal, however, (where an express bus would drop you off) that last leg might be and agonizing 20 minutes instead. I guess I am suggesting a possible symbiotic relationship between the downtown and commuter legs of system.
Finally I want to point out that the cheapest configuration for routing on freeway medians would be actually be a bottom supported design like Skyweb Express, because it would be so easy to construct low-rise track. This is not all that different from the cost/structural dynamics that enabled the spread of traditional railroads. For example, such track could be supported with gravel instead of deeply anchored supports. It is hard to imagine such a configuration costing very much more than a million dollars per mile. In most cases the Park and Rides have structures in place that could be converted into the required elevated boarding areas. In defense of hanging systems, I think they would be much preferred for these very large parking lots since they could pretty much come to your car.
Amortizing a million dollar a mile track is much, much easier than the inner city routes on which it would depend. (OK, it would probably be more, but I like round numbers) Consider amortizing the track over 10 years, with 33 cents per mile going to this purpose. Payoff is 3 million trips, 300,000 per year, or 822 trips per day. That is 34 trips per hour (averaged over 24 hrs) or about one every two minutes. Obviously they are mostly during rush hour, but equally obvious is that Holy-Grail benchmarks like two-second headways probably need not be reached here. More to the point is that a comparable HOV lane costs 5 times as much, and also the size of the parking lot needs to be considered. This may not be PRT’s “killer app” but keeping that many cars out of city center in the first place certainly seems like a worthwhile goal.
Finally, to my friends in the U.S… Happy Independence Day! This is a time when we can all come together and enjoy the sights and sounds that result from the enormous, ultimate, instantaneous release of CO2! :o) Oh well, be Happy. It’s the 4th of July!
Showing posts with label "City Transit Solutions" traffic solutions. Show all posts
Showing posts with label "City Transit Solutions" traffic solutions. Show all posts
Sunday, July 4, 2010
Subscribe to:
Posts (Atom)