61> Classification of PRT/PAT

One of the essential steps in any kind of open-source collaboration would be some kind of classification shorthand to enable the parties to better reference their work, and the work of others. For example, if I want, presently, to refer to a system in which the vehicle is perched on a vertical extension of a captive bogey which extends from a slotted track, I have call it an “ITNS” or “Ed Anderson” design and mention Taxi 2000” or “SkyWeb Express”, (or vice versa) to be evenhanded. Making comparisons and design offshoots using those and a few other systems in a single discussion could get pretty confusing. The confusion would extend to procurement, contract awarding, etc. At some distant future point, someone will create some kind of certification process for aspects like track construction. That’s kind of hard when you can only describe the track in terms like, “It’s like the ULTra track but it will have screened middle sections like MegaRail…with a third rail…”

Originally I was going to fold this all under the “SMARTS” umbrella, (Small-scale Modularized Automated Rail Transit System) but realized that some important systems fall outside of that description. (A little note here. I think I like “Standardized Modular Automated Rail Transit” better. It is more descriptive of what I am up to…) Anyway, I believe breaking up the systems by key attributes, rather than vendors and inventors, allows a more substantive dialogue.

There are also obvious disadvantages. First of all, without the above picture as a key, nobody can use the system to classify anything. Secondly, who really knows the exact numbers to put in for the various systems except the designers themselves? I imagine one half-solution would be to simply “x” out the unknown latter details, so that the ULTra would be a “BGBxx” while MISTER would be a TIxx and I have been designing a TELxx, but Anderson likes the BELxx.

All I can say is that just because I don’t have the resources to make something happen, it doesn’t mean it is entirely useless to point the way. After all, classifications are essential for everything else, including roads, bridges and the vehicles on them.

Finally, I would like to thank alert reader “afransen” for pointing out that I can feature recently posted comments on the main page. (On right, scroll way down) This may help stop threads from going dead so quickly. Unfortunately it doesn’t show which post the comment refers to. Perhaps very alert readers will learn to preface their comments with a post number when they are commenting on older threads, which I will do myself. We’ll see how it goes. I’d love to see the threads get more content rich over time.

This feature is one of what Google calls “Gadgets” and it turns out that there are a whole lot of them, including the our new search feature. Believe it or not, I have been spending time every day this week creating an index. If I had known about the search “gadget” I would not have bothered. Now that it’s half done, I will probably finish it. If anyone cares, it is post zero. (oldest of the old posts) It links to posts by subject matter. When it is more complete I will show it as a link under the search bar.

60> Prestressed Concrete Track for PRT and Other Automated Transit

One concept worth considering is making track from prestressed concrete. I’m not sure how it would work for the inner city or spans with a lot of curves or branches, but it might be a good candidate for freeway medians.



The groove on top and the corresponding hole in the support structure is for electrical or communication cables, and is meant to be covered by a metal cap. One might be tempted to question whether it is really feasible to cast such a shape. Actually it is really excellent, because by piping steam through a collapsible inner form, the concrete can be caused to set much more quickly. Beams can, in this manner, be removable within hours, allowing multiple castings per day.



The picture above shows the various rubber-mounted running surfaces associated with the previously shown designs. In a situation such as a high-speed longer distance application, not only would the rubber be unneeded, (concrete absorbs sound which, in freeway median applications, wouldn’t be and issue anyway) but most of the steel itself could be dispensed with, as well.
In applications with lots of stations and curves and branches it is easy to imagine a track in terms of a profile that serves all of those needs. For the duration of long, straight runs, however, the metal “fins” used in switching need not be present. Furthermore, larger wheels are probably in order for higher speeds, as suggested in post 56. Therefore the running surfaces normally used for the smaller low speed guide wheels should be removed or recessed, so that the small guide wheels don’t spin. In fact, I’m not sure that any of the steel shown is needed.
Without any buried utilities to prevent more closely spaced support posts, this might be a very cost effective way to handle the commuter market and reduce freeway traffic.

By the way, it occurs to me that most readers, even those with some engineering instincts, would be intimidated by the thought of trying to learn a new program, especially a 3D modeling program. Well the folks at Google are no fools, and they wouldn’t get into the 3D software business if they didn’t have something pretty special.

Here is a chair that I drew in under 3 minutes, following this YouTube tutorial. Try it. It’s fun!

59> A Milestone and a Call to Arms

Many of you who have followed this site, which is now nearly eighteen months old, may be wondering about this “Open-Source” thing. Obviously just showing my own design ideas isn’t really open-source. At the same time, I started at a readership of zero. I had to achieve some visibility. There has always been a compromise between what would grow the site and what would populate it with engineers. Anyway I have decided that it is time to take this project to the next level.

For several months now, this site has had the capability of enabling not just the sharing of my designs and ideas but of yours as well. Unfortunately, I’ve had a lot of problems figuring out what I was doing so I could clearly explain it to you, the readers and potential users. The problem was compounded because it really takes more than one computer and IP address to experiment with a system like this. Luckily I have recently found the time to at least partially figure it out, so, without further delay…HERE IT IS! (Corks pop and the sounds of noisemakers ensue)

First, if you want to not just look at my designs but play with them like you had drawn them yourself, I have posted the address of a download site to the right. (You will currently need Google’s free 3D modeling program “SketchUp”, although later the site may be populated with many other file types.)

Furthermore, they may be improved and resubmitted, or you can share your own projects. PRT control software would be nice!

It works like this. Google holds the files. We each have folders, which, when updated from the Google site, will have identical contents. Each of us can then open any project file in the folder and work on it. When we want to quit, we simply close the file in the usual way. It can then be either submitted to be shared, or reverted. If it is submitted, a text box will open where you will hopefully describe your work, so the rest of us do not get confused. You can also share your own project files by putting them in the folder and submitting them. Another option is to branch a project by changing a file and submitting it under a new name.

This is all done by a magic little helper program. (SVN) I am using one called Tortoise.
It runs in the background and you access it by right-clicking the file or folder to get at its menus. It places little badges on the file icons in your folder – blue for one you just added, red for one you just modified, and green for the shared version that Google is holding. (A note on SVN jargon - Submitting a file is called “committing”. Your folder is called a “local repository”.)
So anyway, by right clicking, you can ADD, REVERT, COMMIT, (individual files) or UPDATE. (The folder)

To get started, just go to the OpenPRT site, and go to “downloads” to get a MS Word doc with step-by-step instructions. By the way, those files under “Downloads” are already old. It’s best to go to “Source” > browse> svn>trunk to get the whole up-to-date library. Right now all I have is mostly the models that I used for illustrations for this blog. At some point we will need to start designing in earnest, from scratch. Note that there is even a wiki. This might just become the most important part of the site because wikis are great at linking related subjects. The design of any part of a PRT system inherently relates to many other parts, as well as to statements of design requirements, such as safety, cost, modularity, replacement/repair cycles, etc. With a wiki, every part can have it’s own page, and everyone can contribute and edit. This part-by-part discussion can then be put into 3D and worked on via the SVN. At the present the wiki is like a big unopened box. I invite you to create the first page.

It has become clear to me over the past months that I will need a lot of help with all of this. I think it is worth starting discussions about how to incorporate volunteers and create some kind of formal administrative structure. Wikis, SVN, managing open source projects…. None of this is really up my alley. I really hope we can get some good discussions going in the comment section this time. I really could use some guidance as to how to make this thing unfold.

58 > Defining The Problem

One of the hallmarks of PRT/PAT travel is that the vehicle takes you from your origin directly to your destination with minimal waiting time. There are no transfers, no stops for other passengers, etc. The track, being for small vehicles, can be so light and inexpensive that it can be built into very extensive networks very cheaply.

In practice, however, the initial track layout will be extremely limited and it will take many years to spread citywide. Therefore it probably won’t take you from origin to destination. Furthermore to really make an impact, PRT should address the commuter, not just travel around the central business district. What is the point of PRT if you need to drive 10 miles and pay for parking to get to it? Do the models that various PRT venders are promoting address the crowded freeways? Is any PRT model that addresses the freeways even close to the model that addresses the central business district? What about the suburbs?

If the need were only in the Central Business District (CBD), I think I would give the edge to the general design parameters envisioned by ITNS/Skyway Express models. This will surprise many, as I have a record of advocating a hanging system. The difference is, in the CBD, the main emphasis is footprint. Speed, and cost of track and stations are secondary. Having elevators in every station is actually a pretty good way to economize sidewalk space, and it takes less energy to lift a passenger than a whole vehicle. In an environment of all multi-story buildings, second floor stations can be accomplished with little more than a balcony.

The situation changes markedly as the system expands outward from downtown, however. Here, the expense of the track and stations becomes critical as individual station ridership begins to drop. In these areas, bus rides to town are short and convenient. Putting up elevator-equipped stations on every block is far less attractive than it was downtown. Now the advantage, in my opinion, shifts to hanging systems, because they are generally more versatile in terms of slopes and curves and multiple speeds, and can accommodate open-air stations that may double as bus stops. Because of population density, stations should still be within walking distance of each other, but many passengers will just be passing through.

Next comes the suburban sprawl. This mixed-use area goes on for miles and is punctuated by mini urban centers, residential neighborhoods and distribution parks. There is enough housing and employment that many of the residents never go downtown. Here distance, and therefore speed, starts to become a real issue. The potential riders currently utilize a variety of road types to get around. Often there is a freeway nearby. The challenge for the PRT planner is to provide a system that can match speed and convenience with the combinations of freeway and back street shortcuts that are utilized by the drivers living and working here.

Because of the sheer size of the suburban sprawl, it is unlikely that any form of PRT will blanket such an area for quite some time. This suggests a “low hanging fruit” strategy, where major “hub” areas are accessible but many low volume routes are not incorporated at first. City buses (horrendously inefficient for long trips because of the many stops) could, none-the-less, be a reasonable option for going a few blocks to get on the PRT grid. Here it would seem to make sense to have some kind of PRT express lanes that go quite fast to connect community hubs. This is an entirely different model than the CBD, both in terms of preferred track and stations and preferred vehicle. Speed, versatility and track cost would seem to be the main design factors.

Finally there are the outlying suburbs and satellite communities. Commuters typically travel at posted speeds until they get close to town and then traffic backs up. These people generally have large engine vehicles because aggressive driving, for them, is somewhat of a survival skill. Keeping these cars out of city limits would do a city a lot of good. Here 30 mph PRT would be useless. It must be much faster to compete with the freeway. People in outlying communities cannot expect to have PRT vehicles come by their homes. Dual mode vehicles would be a poor substitute for the pick-up trucks and SUVs that get them around now. To be perfectly honest, I have serious doubts about whether PRT is the right tool for this job. It certainly calls for fast vehicles on a fast track, but why individualized vehicles? A park-and-ride GRT (Group Rapid Transit) station on the out-of-town side and an ad hoc drop off scheme might be a more efficient. Here is some thinking on this.

The main drawbacks with group travel are waiting and having the station locations that are catered to the average passenger but are not anyone’s exact origin or destination. I believe, however, that with automation and an intelligent system these problems can be largely solved. For example, the problem of fixed scheduling and associated waiting is largely a communication problem, as is inconvenient transfer locations. (Passengers and transit have had to meet at a prearranged time and place, because it is presumed that they can’t talk to each other.) If the “system” knows the complete itinerary of every passenger, the right size vehicle can be sent at just the right time for the group. Is transferring a really the problem if the time waiting for the transfer vehicle is eliminated? After all, PRT vehicles can swarm incoming GRT vehicles moments before arrival, and the “system” can decide where this meeting would take place. GRT requires heavier track, but the other choice may be requiring all PRT vehicles to be more costly and robustly configured than would otherwise be the case. Building super fast PRTs to go slow is a waste. Building high-speed high-capacity track might be a better investment. After all, this might find dual use for freight. There is also the matter of spreading the weight. Perhaps a “fast lane” with greater headways between vehicles and greater spacing between bogies would not need to be that much more expensive.

The track profile I have been working on is specifically designed to be adaptable for multiple weights and speeds. This brings up the question of track “permissions.” Obviously a heavy vehicle must not use light track, but light vehicles could use heavy track. Clearly slow vehicles should not hold up fast ones, but fast ones might want to use a slow track, on occasion. These questions are for a different day, but, to rap it up, I suspect automated transit is not a “one-size-fits-all” technology, and different parts of a city have differing transit needs, and therefore different optimal designs. I also wonder… What starting configuration gives the most bang for the buck?

Next week: The long awaited grand opening of the design collaboration site.

57> Roads, Roads and more Roads

A note about this post… One of the problems with a blog format is that the passage of time buries old posts more and more deeply, and with them, ideas that were considered foundational. After 57 posts, how do new readers even know what I’m talking about? I am caught between trying to build on previously explored concepts and not becoming so obscure as to turn new readers away. What follows is not exactly new to some of you, but will be to many. I think it is important to try to get everyone on the same page.

PRT has been aptly described as “The Physical Internet.” (Bill James, JPods) But what really fits the bill is the present road system. They don’t call the Internet the “information super highway” for nothing. Our road system has become an amazingly pervasive network, and, coupled with cheap fossil fuel and advances in cars and highways alike, has created the most mobile population that the world has ever known. The system works so well that very few people ever consider the negative implications of continuing its expansion. Also invisible, to most of us, is its costs. In fact, the only thing that wakes us up at all is when the system breaks down.

Roads have been built on tradition, more than real analysis of transportation design requirements. Paths became trails, carts needed flatter wider trails, faster wagons needed smoother roads, then there were cars, then trucks. Now our little paths need to support 80,000 lb. vehicles and can be hundreds of feet across.

It’s not that roads are cheap. They are not cheap to plan, to fix, to clean, to patrol, to connect to, drain around, to elevate, to bank, to clear from accidents, grade for, purchase land for, license drivers for… I could go on… But the costs are so buried in established practices that we don’t even see them anymore. We can’t even imagine a world without that money leaving our collective wallets. We not only lose millions of hours each day in traffic, we perversely pay more for roads when we are stuck in gridlock, through taxes levied on the gas we are wasting. (A little footnote here: As cars become more fuel efficient, these funds for road improvements decrease. Eventually the cost savings from owning a more efficient car will need to be offset by higher taxes.)

We can’t do without a sophisticated transportation network. That Genie cannot be put back in the bottle. But the developing world (and the world at large) cannot afford to see this concrete network model unfold to its logical conclusion.

Suppose we could start all over again, but with modern technology and environmental awareness. Knowing what we know now, were we dropped onto a primeval planet, and had to build a new network from scratch, would we begin by terraforming the habitat with bulldozers and dynamite so that foot thick ribbons of concrete could connect parking lots with each other, as the preferred way to connect structures, goods and people? Wouldn’t it be cheaper both in the short term and long term to plant some pylons in the ground to support pre-fabbed sections of guideway or track? (Don’t forget the environmental impact of changing drainage patterns and the habitat segmentation that roads create.)

I acknowledge importance of truck access. It’s pretty hard to build a house without it, much less a building. Yet truck access also shapes need and development. First comes truck access, then comes deforestation. Soon to follow are deliveries of heavy, bulky materials that can only be delivered by, of course, truck. The economics of suburban sprawl are directly tied to the economics of our “physical internet”. I do not pretend that this hypothetical alternative transportation network would be equal or advantageous in all respects. We have become used to having virtually all addresses accessible by very heavy equipment, even hundreds of miles from city centers. Would the pioneer inhabitants of our brave new world choose to abandon the road paradigm altogether? I doubt it, but I can’t imagine that they would want to revisit all of the cost and effort and environmental damage that went into the present system either, were a viable alternative available. I think they would look at the road for what it is, a great way to deliver truly heavy freight beyond shipyards and train yards, but not such a great medium for a one-and-only, all pervasive “physical internet”.

So what would make a great “physical internet” in this brave new world? Four things.
1. Very cheap. (in materials, construction costs, and upkeep)
2. Very versatile (as many applications as possible within the constrains of it’s form)
3. Elevated, both to unlock the value of the land below. (economic, aesthetic, environmental) and to minimize the amount construction that needs to be done on-site.
4. Very, very efficient, meaning fast, low energy, high though-put.

There are many iterations of PRT/PAT, but the two projects currently under construction, (ATS’ Heathrow Airport and 2getthere’s Masdar City ) projects are based on the familiar concept of the road, although it is usually described as a “guideway”. I hope these companies have a firm grasp on just how poorly their "guideways" stack up, on the basis of the above-mentioned criteria, compared to other designs that have been put forth. With any luck they already have “second generation” plans in the works. At the moment one is forced to compare their systems’ performances to that of user-driven electric vehicles on a similar guideway. I acknowledge that “going electric” and reducing lane widths is a major improvement. But why not just widen bicycle paths or paint off sections of road for small electric vehicles, private and/or rented? What is the point of having vehicles do something automatically that people can do as well or better? The value of automation comes when machines can vastly out-perform their human counterparts. It would seem that weather, or pedestrians, for example, would tend to keep automated roadway based transport forever slow for safety reasons.

Every journey begins with a single step, and the people who control the money are rightly conservative, and roads are familiar and proven, so I heartily endorse these projects, and congratulate the companies for landing the contracts. The driverless automation part, though less than essential on roads, is an absolute requirement for raised thin-guideway or rail systems that need sophisticated traffic management. All PRT efforts help develop that key element, so these companies are providing a needed boost. But let’s also keep our eyes on a bigger prize – a next-generation “physical internet” that is vastly better than what we have now. Only a system that demonstrates overwhelming superiority (by the previously mentioned criteria) will have the ability, in a free market world, to significantly impact our longstanding transportation traditions within our lifetimes, and so deliver the benefits that such a system could bring to all of humanity.