Recently there was a posting in the Transport Innovators site that caught my eye. It was entitled “SkyTran a Sham?” I know… I really should join that group and post my thoughts on that site, and lend a little support to what I consider to be a valuable public resource. But I like to scratch my head and measure my words a bit more than most before I open up my mouth, and I am usually too busy to even consider an issue on a timely basis anyway. So I hoard my musings away, like precious little nuggets, to be used as rainy day subject matter for this blog.
I am not so interested in the charge that was made against SkyTran but rather by whom it was made. It was leveled by the author of this study, which starts out promoting and then later disparaging nearly the exact same concepts as SkyTran. In my opinion both have severe problems. The author threw in the towel. SkyTran still purports to be a practical system.
What is it about maglev that makes smart people so crazy as to think that it is appropriate for PRT? maglev’s major advantage is being frictionless, except for air. This is a very minor consideration at city speeds, and yet they want to shoehorn this high speed technology into the sharp cornered, stop and go world of urban transit. A friction free object wants to glide at a steady speed, in a straight line. Navigating a city requires something wholly different. Both systems are designed to travel in excess of 200 km/h (124 mph), far too fast for short trips. Even though he states that, because of G-force constraints, average system speed can never exceed 100km/h (62 mph) in an urban environment, he never wavers from his 200 km/h maglev design, and the inflated track cost that it entails.
In the case of Swift PRT, the author, after all kinds of analysis and simulations, concludes that the track is too expensive (Duh! It’s full of copper coils!) and that vehicles that fast must be spaced way apart to allow exiting, entering, or even simple turns. (Or, alternatively, they need 600 meter ramps to and from the stations.) He states, “If your intersection or station spacing is meant to be <1km apart, you effectively need two lanes in each direction: a fast lane, and an acceleration/deceleration lane. The net result is you have at least doubled your track costs, and the width of your system.” It seems to me that the problem lies with trying to connect 200 km/h fast lanes to every downtown station! That seems to be what SkyTran is advocating as well. Like I say, there seems to be something about maglev that makes people lose their senses.
The conclusions are what bother me most: While I have no problem with his realization that maglev PRT is not cost effective, he then applies his figures to PRT generally. His assumption is that all PRT track must cost 7m/km, even though his own figures show that one way track without the copper coils and in-track electronics would come in at 2m/km. He then, through mathematical inference, extends this inflated cost to justify only putting one station per 2.7 km, and then uses this spacing to assert that PRT (in general) cannot compete because of the long walks to get to the station. His reliance on formulas over common sense has led to the “crap-in, crap-out” phenomena.
What is curious (and unfortunate) is the illogical leap from discovering that his system is too fast and expensive to the conclusion that the future of transportation is in vehicles that run on asphalt. This argument is made without anything to back it up, save the cost and ubiquity of the road system itself. Was it not the shortcomings of the road system that lead him to explore PRT in the first place? Sure, I think we all agree that traffic problems can be reduced by using networking and AI technologies. But asphalt will always be primarily a two dimensional, stop and go system. Multilevel interchanges simply cost too much and are too big to be ubiquitous. So when he compares the cost of his 130 mph, non-stop system against asphalt, he is comparing apples and oranges. If I had to venture a guess, I would say that the author set up an experiment that he was forced to carry it out with scientific rigor, even though the basis for the experiment (his hypothetical system) was clearly flawed. Having exhausted his time and/or interest, he was in no mood to do it all over with a better system, and so hastily framed his results. These conclusions certainly do not reflect the thoughtfulness shown in the sections where he first discusses the original problem.
That being said, one other interesting result of the study highlights the parking problem, something that is often glossed over in PRT discussions. While it has been admitted that PRT vehicles will have to travel around empty sometimes, the extent to which this will occur has been a subject that has remained somewhat opaque. Obviously, during off-hours, if the system is only operating at half capacity, there are 50% empty vehicles, and they have to be somewhere. Are they traveling around in circles? Clearly these vehicles should be staged somewhere, but I have not seen this reality reflected in the various PRT designs. It occurs to me that this is still one more argument for a fully multi-axis (3D) system. Warehousing numbers of empty vehicles would be much more space-efficient if they don’t require long ramps. As with parking cars, a vehicle with a small turning radius is a plus. In PRT, such a radius might be horizontal or vertical. Compact parking is especially important if an attempt is going to be made to shelter those vehicles from the elements. A PRT design that allows a combination of tight turns and compact track switching in full 3D can clearly minimize the real estate (and roofing) required for such storage. Being able to make multiple track configurations in tight spaces would be particularly advantageous in utilizing whatever real estate might be available, including very small or oddly shaped lots. Such parking can be envisioned more in terms of a lattice or matrix, as compared to lines of cars on long parallel tracks typified by the storage of railroad cars.
I might add that tight turning radii in both vertical and horizontal axes is inherently difficult to achieve in systems that use the track as part of the propulsion. This is because of the required tight spacing between track and bogie. Magnetism loses force with distance, so using magnetism between track and bogie for propulsion will always entail a fairly tight fit. This is my major beef with linear motor propulsion, even non-maglev varieties such as simple LIMs, which don’t require coils in the track.
18 comments:
One study that I liked very much is Hermes (http://students.ceid.upatras.gr/~xithalis/index_en.html). Hermes simulator has also strorage for empty vehicles and it can analyze the efficiency of the system (impact of storage location, number of empty vehicles).
Empty vehicles could in many cases be stored simply on extra track segments. It is not very expensive to also cover some of those segments. Personal vehicles would need somewhat more complex storage arrangements (algorithms at least) than use of shared vehicles.
I think your criteria for track design are quite good. The track has to be cheap, and at the same time as adaptable to different environments (and evolution of the system) as possible, and fast too. High speeds are needed if the system will one day connect cities and countries. It would however be also quite feasible to have a second solution / track type for the fastest long distance connections. Some additional switching and waiting time to connect to the other system is not a major problem in the long distance traffic. The basic system should thus be primarily designed for everyday traffic of sort distances (commuting, shopping etc.).
Good analysis, Dan. "GIGO" was exactly my thought, too, when I read the SwiftPRT report. It's not that his actual analysis was particularly wrong -- in fact the author is obviously quite bright when it comes to electrical engineering and algorithms, which is what he obviously has training in -- it's that his primary assumptions were disastrously wrong. Particularly:
* That journeys such as San Diego - Los Angeles constitute typical urban journeys (Um... those are inter-urban journeys; the average urban journey in America is about 8 miles).
* That people drive around cities at 50 mph (actually, it's less than half that for private modes, and close to a quarter that for public modes)
* That you need to go more than twice as fast to be seriously competitive (actually, a 20% improvement in travel time is enough to induce very significant mode shift)
* That travel time is determined primarily by vehicle speed rather than congestion and waiting (completely wrong; in dense urban areas, vehicle speeds beyond about 35 mph are completely superfluous -- starting, stopping, and turning will rarely allow you to exceed that).
* That therefore a PRT system must operate at 125 mph to be competitive (wrong by a factor of 4)
* ...And therefore stations cannot be located closer than 1,200 m apart (wrong by a factor of about 10; he's fallen victim to the nonlinear scaling properties of acceleration vs. velocity...)
* That urban populations are homogeneously distributed and therefore infrastructure calculations can be done proportional to population size / urban area (completely wrong; cities have highly heterogeneous population structures, such that there are typically vast areas which require little to no infrastructure, and very dense areas which require more infrastructure; the upshot is that the median population density is approximately relevant; the mean population density is not. The former is always considerably higher than the latter.)
*...And that you have to be able to capture 100% of the market in order to do a lot of good / create a viable business (who does a business-case analysis on that basis!?!)
All in all, much sound and fury signifying nothing, which is quite disappointing. I'm planning on doing a more thorough demolition of SwiftPRT over the holidays, when I have a bit of time, but it will generally be in line with what you've already said.
Addendum: the real problem with PRT -- and I agree, this is too often glossed over -- is that it does not handle massive demand fluxes as easily as mass transit. PRT doesn't have "crush capacity" -- so the number of vehicles has to scale directly with the level of demand. If the demand pattern is relatively sedate throughout the day -- except for a sudden sharp crush of demand at peak hours -- then it can actually become uneconomical to provide a fleet large enough to meet the crush demand. This is because you have to buy a lot of vehicles which are superfluous 22 hours per day; if your revenue-per-vehicle isn't high enough, that doesn't make sense. In contrast, a mass transit system can handle demand fluxes like that easily -- admittedly by packing people in like sardines, but from the point of view of both transit planners and financiers, that's preferable to buying a large fleet of vehicles that you don't otherwise need.
This problem is exacerbated, for a variety of reasons, when the topology of the demand is very uni-directional and in highly linear corridors.
Where PRT thrives is in areas where demand is relatively constant throughout the day, and relatively omni-directional. This is the type of demand that mass transit is completely unable to efficiently address, and it actually accounts for about 70% of urban journeys.
Now, look at Manhattan island. Consider how many people work in the financial district, vs. how many people actually live there. Look at the topology of the transit networks -- both the streets and the subways -- and consider the extent to which they accurately reflect the actual demand pattern on the island.
Is it not blindingly obvious, upon reflection, that replacing the New York subway is absolutely the LAST thing that anybody would want to do with PRT? I can see PRT eventually being edged in as a complementary system, but basically, New York is the urban context in which mass transit works best, and is not going to be replaced by any small-group systems.
So first, Swift PRT takes a bunch of grossly incorrect assumptions, and discovers that you can't turn them into a workable PRT system. Then they take the last application on earth that you would want to attempt with PRT, and discover that you can't do it with PRT. Then -- most astonishingly of all! -- they glibly state, without any analysis at all, that Robo-cars -- which suffer exactly the same flux-handling limitations as PRT, but are far more expensive and take up vastly more land -- are the superior solution.
Dumb, dumb, and thrice dumb some more.
No arguments on your text, Dan, but did you notice the link actually leads to your hard disk:
file:///C:/Users/Dan/Desktop/Swift%20Transportation%20»%20The%20Future%20of%20Ground-Based%20Transportation%20Systems.htm
Dan the Blogger is pleased… ;)
Thanks, guys, for adding so much thought-provoking material to this blog! And special thanks to you, akauppi, for pointing out the dead link. The post doesn’t really do much good without a link to what it is all about! It should be fixed now.
Juho, I downloaded that simulator a while back on a now-dead computer but got distracted by something and never actually ran it. The Youtube video on how to use it has re-piqued my interest. I hope it allows for slowing for turns, though that is probably too much to hope for. As you know, I’m not a big fan of fixed speed systems, because that speed would have to be slow, and I’d like to see some faster, longer distance commuting capabilities. I can’t help but draw the analogy to the highway system where high speed arteries feed slower side streets. Let’s leave the cars in the suburbs!
Nathan, Glad to see you back! My INDEX, including the section on web resources, is woefully incomplete, but you will notice that your 2008 essay on “PRT Activism” IS included. (A “must read,” in my opinion) It was, btw, akauppi, here, that pointed me to the paper in the first place.
Thanks for the more complete critique. I try to make my points simply and I try not to make the casual reader think TOO much, but in this case, particularly, I knew I was really just scratching the surface and leaving a ton of stuff unsaid. I get blurry-eyed reading studies, I must confess. ADHD!
Don’t be TOO hard on the guy, though… Don’t you get the feeling that this was (beside its purported business aspect) an academic project that ran out of time, midway? … for a professor who was likely a skeptic?
Your take on empty vehicles raises the interesting specter – maybe specter isn’t the right word since it would be a good thing in a way – of a PRT layout that runs well under track capacity yet doesn’t have enough cars for peak hours. Can you imagine militant citizens demanding more PRT vehicles? Now there’s a headline that I would love to see! As for the New York example, One thing that can be said (for subways/light rail) is that after a number of decades the city will grow around it in a way that maximizes its usefulness and ridership. I didn’t pay much attention to this section of the study but it certainly sounds like a nutty idea to even try to simulate it. Unless you want a predictable outcome to support a thesis.
I think the crush-load or peak demand problem is not much of a problem at all. All you need is some demand shaping strategies. Perhaps a premium fare at peak times. This would serve to shift price-sensitive travel out of the peak period, and also make it economical to fund more vehicles that are only utilized at peak. Similarly, you could not go the route of variable fares, but allow queue-jumping for a fee. If the system has more demand than can be served, allow people to wait first-come-first-served or pay a fee for priority service, also helping to fund additional vehicles.
I think big-box transit will still have a role to play in handling peak transportation demand, if for no other reason than it would be cheaper than PRT. And trains that are operating at high utilization are just about the only economical form of transit. So I think widely deployed PRT would see the death of buses in large part and see many subway/LRT services operated on or near-peak only.
Just to add my biggest problem with the SwiftPRT analysis to the critique, the author arbitrarily chose $1,000 as the economical amount of infrastructure investment per resident. He used that figure to conclude that most cities are not dense enough to support a ubiquitous network, and thus the technology is a failure. No sensitivity analysis on that assumption. He then mysteriously endorses robocars, which require investments of tens of thousands of dollars per person served in capital costs, as the only economical alternative to our current model. Bizarre.
Dan: Yeah, when I write my final critique of SwiftPRT, I actually will have to give him credit for doing a number of the calculations correctly. It's not that he screwed up every step of the analysis -- it's more that he showed that one can use perfectly good analysis to turn incorrect assumptions into wildly incorrect conclusions...
Andrew: Agreed on all counts. Demand-shaping strategies are essential for any large-scale PRT system. I'm working to implement realtime farebox variability in the next PRT system that I design. (This can be a politically sensitive issue; I wasn't able to get it implemented at Amritsar, although thankfully there will be differentiation between weekday and weekend fares, and peak and off-peak seasons.)
Also, you're right about big-box transit offering absolutely unbeatable economics during peak hours (and quite poor economics during off-peak hours). My vision of the future of transportation is that PRT and urban rail work side-by side; the former operates 24 hours per day, and can serve 100% of the demand during off-peak hours, at quite a reasonable rate. The urban rail systems operate 10-12 hours per day, and offer the most cost-effective journeys during peak hours. During peak hours, PRT acts primarily as a feeder system to/from local rail stations, while longer-distance PRT journeys are priced at a premium. According to my analysis, this offers the best combination of cost and capacity: the rail system only operates when it can do so cost-effectively, and the PRT system doesn't need to go overboard providing excess vehicles and infrastructure to accommodate peak loads.
Make everybody wait again and again while a few people board and get off? While blocking road traffic?
Personally I would be more inclined toward GRT, where each vehicle could be an "express" (to a different region) that only stops at 3 or 4 stations, tops. PRT could share the track between GRT vehicles(if it constituted a good shortcut) and if there weren't enough passengers going to a given region, PRT could be sent (for that request) instead.
Isn't rail transit a bit like trying to have a 75 story building without separate elevators for the upper floors only?
A good PRT / rail integration would dramatically reduce the number of rail stops, to roughly every 5-10 km. This would allow the rail system to achieve higher throughput with fewer vehicles and fewer stations, which would improve their economics even further -- while giving rail passengers a faster ride than can be achieved with any currently-available PRT or GRT systems. Best of all worlds.
Integrated-infrastructure PRT/GRT systems are another thing entirely, and one that makes a lot of sense in the right circumstances, just as you describe. In fact I'm working on such a system at this exact moment. However there are no currently-available GRT systems which can offer the speed / range of rail, so it's not (yet?) appropriate for all circumstances -- still more appropriate as a neighbourhood carrier (< 10 radius).
Integrating trains with PRT is still a significant logistical challenge. You still need many vehicles that would need to be staged nearby in order to swarm the station when a train arrives in order to clear the platform/station before the next train arrives. Not that this is insurmountable, but a train network at resolutions of 5 or 10 km will result in very busy stations.
Nathan, you are no longer working with Ultra, right?
Dan the Blogger with an important public service announcement!
I’ve just been returning emails from Skytran enthusiasts… I just need to clarify…I said it once in a past post and will repeat it here: The Inductrack technology that Skytran uses is very interesting and promising. It is passive, in that it requires no power to levitate up to 50 times a magnet’s weight. It must, however, be moving so there is no levitation until a certain velocity is reached. And this is only levitation, not propulsion, but still…
So although I think the concept is very cool, especially insofar as it can use aluminum laminations instead of copper, I have no idea how far along the Skytran project has actually gotten. But I would be inclined to think that it is a bit inflexible and pricey for low speed, urban use. But obviously I am prejudiced! As anyone who has witnessed my struggles, over the years, to design the perfect PRT system well knows, the devil is in the details, and I have seen precious few coming out of Unimodal. I would love to know, for instance, how it supports itself while switching! The site is under construction though, so hopefully more info will be forthcoming…
Andrew -
You're absolutely correct -- Rail/PRT is a logistical challenge, but one which can be met by providing large vehicle buffers in advance of the berths. This is something that needs to be done at large PRT station ins general, both to accommodate fluxes in departures (many passengers disembarking from a train at once) as well as inevitable fluxes in arrivals (so that vehicles can queue up while the PRT passengers ahead of them disembark).
To be honest this is something of an under-appreciated problem in most peoples' PRT thinking. Typically it's addressed by having vehicles queue up on a longer-than-necessary station entrance ramp, but when you look at the performance under peak-within-peak demand conditions, that's often not sufficient. That's why you see a large 18-vehicle queueing area in advance of the T5 berths at Heathrow, and why you'll see much larger queuing areas when the Amritsar design is revealed (which, among other things, connects to the city's main rail station).
Big stations like this are quite far removed from the classic "small siding off the main line" image of a PRT station -- but still, it's a solvable problem.
And yes, I no longer work directly for Ultra. It became clear that the system-design & stakeholder-coordination work that I was doing was better done (from an incentives-alignment point of view) from the client's side than from the vendor's side. I now work for a major planning consultancy, Capita Symonds, still specialising in PRT work. I'm still helping to bring forward projects for Ultra, but am now able to work with other vendors as well, in addition to producing vendor-neutral PRT studies and procurements for various clients. My opinions posted here are my own, of course, and not my employer's.
Keep 'em coming Nathan! I'm sure I am not alone in wondering what lessons you have learned...
Well, Juho, I'm still wrestling with it. I currently favor dropping the lower outside pipes to expose a surface that is roughly perpendicular to the surface used by the steering guide wheels. The wheel for this could be
fixed, between them. I still like the hold down wheels as designed for the biggest and fastest iterations, though. My main concern is ease of local track manufacture. In a perfect world we could just order up modified round pipe that was pre-bent and had a lengthwise flat area. This is doable with ordinary roll-forming and pipe bending equipment, but it would be a bit of an art, and I don't like that. For that matter, flat stock can be roll-formed to make the various surfaces, but again, it's an art, and uses a bunch of special rolling wheels and a big custom setup, so the parts would have to be made in mass, warehoused, shipped in...
I am also trying to minimize welding wherever possible. Honestly, I do not really see a method or design that is so superior as to warrant a "standard." If there is such a beast it would be worded vaguely, and so would be more of a definition of a design branch than anything else.
I'll be keeping at it, but I wouldn't hold dinner...
The track truck mechanical engineering concept designs for all suspended PRT systems proposed (except Ultra that interestingly doesnt have one) fails to advance beyond the achievment of 1950's Safage! True? Of course!
This absence of a viable track/truck design is holding back implementation of your intended systems.
At MonoMetro STS Ltd we have developed an engineering design that ticks all boxes with respect to reliability, wear and low cost for implementing suspended mass transit and we are currently engaged in funding development of a 2.5km system for MonoMetro. However as most of you castigate mass transit in preference for multiple smaller vehicles you call PRT you may be interested to know that during mechanical engineering design development of our track/truck system for our urban and inter-urban mass transit system MonoMetro... which is what we are interested in developing, we looked at two alternative track systems and developed both a suspended as well as supported tracking system for small transit vehicles that may be approrpriate for PRT, that could run a few kilometers from A to B perhaps or be networked with our switching system.
Both fit the bill quite nicely for your intended purposes and most importantly they work, being easily constructed at very low cost.
We're prepared to negotiate rights for use of either of these track designs to whoever is able to enter into negotiation with us following necessary examination by your nominated Engineer Experts of course, under legally binding agreements and payment of a reasonable deposit to protect the relationship that can be agreed between our respective lawyers. For smaller systems MonoMetro STS Ltd holds your key! Confidentiality is paramount.
Once our track/truck issue resolves your dilemma for either supported or suspended tracking you will be able to happily get on with implementing your systems. So why not skip the agony of not having an appropriate track and adopt one or other system from MonoMetro STS Ltd?
Business is business.
Kind regards to you all and a Happy New Year!
MonoMetro STS Ltd
Dan the Blogger Responds –
Hello, Anonymous! Thanks for commenting, even if your offering is a wee bit, well, self-serving… You have reminded me that not everyone has followed this site for years, and that I do a pretty poor job of explaining it to the casual reader and especially to newcomers.
In the automotive world, it is common for vehicle makers to compete in auto racing with cars that bear little resemblance to what can be found in their showrooms. This is done to keep their engineers learning and testing new concepts. The experience of pushing the limits, design-wise, has proven invaluable in establishing design paradigms for much less demanding applications.
But in the automotive field, designs that are less than perfect will be replaced relatively quickly by upcoming models. With PRT, any design choices leave behind an orphan – the track. That’s a double whammy. No playing field to test concepts, and the relatively permanent track to serve as a reminder of any hasty engineering choices. Moreover, as you have stated, “business is business.” It is exceedingly rare to task engineers with a complex problem such as this and have them come up with anything close to an optimal answer within a fixed time frame and budget.
So to all newcomers to this blog… Here you will find what, to PRT, the racing circuit is to automakers- a sandbox to try out new ideas, to push the limits. I believe it is impossible to know what configuration will prove best without exceeding every limitation of every existing system just to see how it will break.
There is no particular problem with designing a suspended PRT track/bogie system. There are a bunch of workable designs out there, and the one you guard so closely may very well have substantial advantages. If this is so, let’s hear about them. In the meantime, I will continue to keep pushing the limits – smaller turning radii, (horizontal and vertical) faster speeds, steeper slopes, less noise, less wheel wear, fewer moving parts, greater safety, greater passenger comfort, more mechanical efficiency, better resistance to weather events, easier to produce locally (track), more adaptable to potential specialty vehicles such as ultra-light delivery pods or heavier GRT, etc.
I believe that these explorations, recorded publicly, can facilitate the type of dialogue needed to avoid less merit-worthy designs which might surface within the confines of the limited time/budget constraints I spoke of earlier. Again, if your designs have unique advantages that you feel can add to this exploration, we would be most interested to know what they are.
I don't give the "Swift" guy as much credit as you do. I think his ego is overinflated from his early luck with his software startup. He made many errors, and one pretty egregious error he made was on his hypothetical efficiency gains. I tactfully offered an explanation of his mistake to him, but he responded that he was correct. It's good for him that he abandoned his effort. He doesn't know enough to reliably make good decisions in game changing transportation concepts.
Post a Comment