It has been said, “History is written by the victors.” Well it appears that the victor, in the war of competing PRT standards, is the ULTra/2Getthere steerable design. It is reasonable to assume that the systems will work as advertised… well enough to get some new contracts while continually improving. Therefore:
“PRT” now means automatic, driverless cars that travel on pavement. It doesn’t really matter anymore that PRT started out as something different. PRT is, and will be, a short-range automatic shuttle service for airports, campuses and the like. PRT will require snow plowing, battery charging and replacement, and will compete for space with cars, bicycles, golf carts, or pedestrians. Get used to it.
The fact that some of us have tried (or are still trying) to craft PRT as a next century transit solution is beside the point. That is not what PRT will be in the minds of most people a decade from now. As the folks at ULTra proudly point out, they have more people working on “PRT” in their company than all other PRT companies combined. To those of us who see PRT’s potential as a means to a more environmentally sustainable and efficient future, I can only say we had better retool our message, and do it fast.
Of course Masdar and Heathrow will have one beneficial effect. They will demonstrate the viability of computer-directed traffic management for small, automated vehicles. At least that is one hurdle out of the way…but honestly…was that outcome ever in doubt?
Our goal will be, then, to widen the discussion to include less pavement, not more, higher speeds, longer distances, more efficient ways to deliver power to the motors, much larger scale networks, etc. It will be hard to talk about it, though, because the term “PRT” has switched from being overly inclusive to being downright misleading. Now discussions about PRT deployment for a city will logically begin with providing ground-level right-of-way, similar to mapping out potential bicycle lanes. Discussions about elevating significant portions of this “track,” I predict, will end pretty quickly, as the logistics become apparent.
I think I like the term “microrail PRT.” (Not to be confused with “MicroRail,” a small gauge train from MegaRail Transportation Systems Inc.) It is reminiscent of the word “monorail” but obviously refers to something smaller. Remember, most people have no idea what PRT is, and it takes a while to explain. Say “microrail PRT” and they might get a picture of a tiny monorail in their heads. (or maybe something on a roller coaster track) Either way, it’s minimal and elevated. PERFECT!
I think PRT, as it was originally envisioned, was really a multipart invention. It synergistically combined the concept of many small computer-controlled vehicles with the concept of an electrically powered light rail system that could be economically run above street traffic.
The cost of free-spanning, beam-like support structures, you see, is reduced exponentially (I’m using the term informally) as their weight bearing requirements are reduced. It’s like fleas jumping 200 times their body length. Some things are possible only at smaller scales. The lightest human-carrying vehicles are in a weight range where a single-beam track can be almost ridiculously cheap, especially when compared with the other options in densely populated areas. It is true that access-for-the-disabled laws, or any scheme that enables capacity much beyond the average (110kg for autos) occupancy greatly increases track costs. That was a clear lesson of Raytheon’s PRT debacle. Nonetheless, carefully designed vehicles can still allow track costs that would enable a true transportation revolution… of that I am convinced. This is both the challenge and promise of PRT… er… microrail PRT…hmmm… microrail podcars? Automated Microtrack Transit? Autonomous Minirail Transit? HELP! We need a new name!
This just in!… After persistent rumors of a historic PRT deployment above the Artic circle, intrepid reporter Dan the Blogger goes to the North Pole to interview the big guy himself. That’s right, folks. Santa Claus himself has made a “ringing” endorsement of PRT technology at his northernmost campus…Here are excepts from the interview…
Dan the Blogger: “Santa, I must say I’m a bit surprised to see you adopt such cutting-edge technology. What made you turn to PRT?”
Santa: “Simple logistics Dan, I run a tight ship here. It’s a pretty big enterprise. We’ve got daily shipments coming in…one hell of a payroll…I can’t be wasting time stuck up to my keester in snow, trying to get the reindeer hitched-up. What’ya think? I should snowshoe all the way from the house to the workshop? And it’s worse for the elves, ya know…I used to have to issue periscopes and shovels or they’d get lost entirely!
Dan the Blogger: “It looks like you went with Vectus. Any particular reason why?”
Santa: “Have you ever tried to fit a reindeer in one of them “Skyweb” things? Damn uncomfortable for the reindeer, I’ll tell ya.”
Dan the Blogger: “Wow, it seems like you really put PRT to good use.”
Santa: “That ain’t the half of it, Dan. I even got track runnin’ between the warehouses and the docks.”
Dan the Blogger: “the docks? I thought you…”
Santa: What? Fly everything from here in a single night? What are you in? The 1860’s? The stuffs gotta be staged, ya know…I got warehouses all over. Plus I got ships comin’ in from China almost daily.”
Dan the Blogger: “I….I thought the toys were made by elves…”
Santa: “Chinese elves, Dan. “…do a wonderful job.”
Dan the Blogger: “My readers are probably wondering what you think of having the linear motors in the track instead of on board… I guess that probably saves weight and space as well, doesn’t it?
Santa: Don’t need motors, Dan. I just tie some cars together and put a reindeer in the front one. Works like a charm…. Hey, I gotta get back to it, ‘less you wanna see 5000 little girls get headless dollies…
Dan the Blogger: Thank you Santa, for this interv….
Santa: “yeah, yeah,.. Keep your stick on the ice, fella… oh, and Dan…”
Dan the Blogger: “Yes, Santa…”
Santa: “You know damn well I can’t give you THAT kinda thing for Christmas…”
For some time now I have advocated designing PRT for more than strictly CBD (Central Business District) use. Even though the “flight to the suburbs” in the U.S. has led to the need for urban renewal, and PRT would be a terrific tool for just that, the suburbs and highway fed satellite communities already exist, and need service too.
Companies wishing to get a PRT product to market do not have infinite time and development dollars, and their efforts necessarily must start from the basic building blocks of stations and loops. There is little point in promoting a vision that they are not yet prepared to follow though on. Unfortunately, a scaled-back, slow version of PRT is a lot like a scaled-back, slow version of the Internet. Eighty people being able to dial up a dozen sites won’t exactly make you thunderstruck by the possibilities. Yet that is a stage that was, at one point, a future vision.
So here’s a little peak at a PRT “trunk” line, which, of course, can only happen when there are massive networks on either end to feed it. In this picture there are four tracks going in the same direction. Reversible lanes would offer up to five possible configurations, direction-wise.
Here are some sample numbers. With a one second headway, and vehicles traveling at 60 mph, (88 ft. spacing) and the U.S. average of 1.2 passengers per vehicle, the capacity would be 17, 280 passengers per hour. Not bad for fitting over a strip of grass no wider than a residential driveway! With vehicles that can swing forward from sudden deceleration and bumpered bogies that clamp the track for extra stopping power in an emergency, still shorter headways and higher speeds can be expected without much technological challenge, especially if platoon strategies are employed. I think what is informative here is the capacity vs. the minor amount of steel and concrete needed to achieve it. By the way, with rubber wheels inside of a sound-insulated track casing, the system would be nearly silent.
______________________
It occurs to me that when I invent, I frequently start at an endpoint or finished product and work backwards toward the present. In a world of cause and effect, one can start at the desired effect and try to envision the causes that could create it. This is why I have been advocating a standards-based open-source PRT solution. Can you imagine a single company ever being able to successfully scale up to this kind of volume? I can’t. The only way I can see it is if the track is a simple and standardized design, buildable by local firms, the control system is infinitely extensible, and multiple manufacturers can compete for business with certified, standards compliant vehicles. The funding needs to come out of the highway budget, and there needs to be a non-profit organization specifically tasked with organizing and fostering the public/private partnerships to make the whole thing happen, as well as developing and maintaining the standards.
I do not rule out one company building a starter network and growing substantially from there. I just do not think that the design choices that are best for the company’s shareholders in the short or medium term are the best choices for PRT as a long-term technology. PRT can have extremely positive effects on society and the planet and still be the basis for very profitable businesses, but there is no reason to believe that a system designed to be profitable and saleable today will resemble the design that has the most transformative potential. In particular, I think current designs have traded away flexibility in a rush to have a market-ready product. These designs have limitations in terms of speed, station layout, turning radius, scalability, safety, track pitch, and a host of other issues. Once deployed, these limitations become set. If they later become burdensome, there is not necessarily any way to remedy the situation while maintaining compatibility with the legacy system and its installed infrastructure.
P.S. I have added a Table of Contents. Now you can enjoy one-click access to all 110 posts in the archive! Also, there have been no malware alerts connected with this site per se; The one reader who has reported a problem apparently only gets a warning from the use of his “Google Alerts” redirect function to this site and not the site itself, so I’m not going to worry about it.
First this note; I have recently been informed that this blog has twice triggered a virus alert for one reader. Has anyone other than this one reader had any malware alerts when visiting this site? I take this matter very seriously and have not been able to identify any malicious code. I have removed the “recent comments” feature from the sidebar, (again) since, in the Blogger forums, it has been suggested that such third-party “widgets” could be to blame, although no mention has been made of this (most popular) one specifically. Anyway, if you have received any alerts, please tell me about it, via email or the comments section. I am hoping it is a false alarm.
While I was out of touch last month, up at the cabin, an extraordinary thing happened that I just found out about. Apparently Google unveiled small fleet of driverless cars that had secretly logged 140 thousand miles of varied California driving with essentially no human assistance. It seems that the age of the Robocar is really here – at least as far as the science goes.
I am an unsuccessful contestant in a recent Google contest, which was about world-changing ideas. I can’t believe they picked the “Shweeb” concept over open-source, standards-based PRT. Now they have invested in Robocars. These people are no strangers to PRT, I just wish they would jump in with both feet.
It seems to me that Google has “out-ULTra-ed” ULTra. After all, couldn’t Google’s modified Toyotas make the runs around Heathrow with ease? For that matter, it seems like they could just take you the rest of the way to your door. Back a few posts, I speculated that the real value proposition for a four-wheeled, pavement-driving designs like ULTra is really dualmode. Now it seems pretty clear that Google could clean their clock in that, and their present business too, if they wanted to.
In a way, my worst fears have come to pass. I believe that much (if not most) of the promise of PRT lies in the establishment of an alternative to roads, rather than making vehicles automatic. Regular roads are designed to carry huge loads, making them very expensive to elevate. Yet it is wildly inefficient to remain on the ground, where there are constant conflicts between people and cargo going different directions. There is also limited space. In most cities, well over 30% of the land is devoted to vehicles, either for roads or parking. This huge, paved landmass is an environmental nightmare, atmospherically, climatically, and hydrologically, not to mention a giant waste of very valuable real estate.
Because of the public’s resistance to having substantial overhead structures in front of their houses or businesses, it is essential for PRT track to have a minimalistic profile. This suggests something in the shape of a simple beam, and certainly not a wide, flat running surface, which would form an umbrella over the real estate below. (particularly at junctions) Robocar makers may pay lip service to raised track, but practical realities say otherwise. Additionally, the removal of any way to “hook” into the track automatically makes travel in icy conditions something that just can’t be done at reasonable speeds.
With PRT being broadly defined to include four wheeled, steerable vehicles, advocates, (such as myself) are faced with the assumption, by many, that PRT is simply robocars on a designated roadway. This is defining PRT away from its original premise. Under the broadest definition the vehicles could even be gasoline powered. This is very, very far from the promise of PRT as envisioned by the early developers of such systems. No wonder people consider driverless cars as being an equally viable alternative to PRT. The PRT that they are familiar with has been stripped of most of its advantages.
I just hope the good people at Google understand the unintended consequences that are inherent in their technology. Private driverless cars will encourage greater fuel consumption, because being free from driving will encourage other ways to pass the time, such as eating and drinking, watching TV, doing office work, etc. The resultant mobile office/living room will mean bigger, not smaller, vehicles. The comfortable and productive ride will encourage longer, not shorter commutes. It will encourage more pavement, not less.
Having robotic cars, especially with special lanes, may seem tantamount to a true PRT system to many, and this fact endangers PRT adoption. You can’t morph private cars on roads into PRT. PRT is meant to replace the need for more cars and roads. It is, at its core, efficient public transportation, which, in turn, encourages the building of truly efficient communities, leading to reduced environmental impact and greater prosperity.
Robocars will only help alleviate traffic, without cutting down on driving. It will make private car ownership even more desirable in emerging countries like India and China. This will eventually encourage even MORE driving and consequently MORE sprawl, just as faster highways have ended up doing across the U.S. And mark my words, if they are privately owned, they will be BIG, powerful and very comfortable. I’ll take the camper!
Recently astute reader Ken MacLeod suggested that we consider certain computer-generated steering behaviors for merging PRT vehicles, and included this link.When I looked at them, (He specifically referred to the queuing example) I was first reminded of a thought I expressed in post 41, where I touched on the possibility of flocking or schooling behavior to help alleviate traffic, although I really didn’t know what it was called at the time. And so I responded by saying that the behaviors seemed more suited to traffic management. Now I get it, however.
Flocking (and the other related behaviors) is actually extremely relevant to PRT because of how it is generated. It is the interaction of imaginary gravity and antigravity between objects in motion. Specifically, it happens when there is very strong close-range anti-gravity and weaker, longer-range gravity. The gravity creates a group or “flock” and the antigravity keeps the “birds” from hitting each other. A favorite demonstration of this is “Boids,” which, as it sounds, supposedly came from the word “birds” combined from someone’s strong (New York area?) accent. In this example, the programmer periodically changes the parameters, (number of fish) leading to stronger schooling or flocking (gravity) forces. Anti-gravity is localized to the area immediately around each fish.
When we drive our cars there is a similar effect going on, except that it is highly linear. The anti-gravity part is dominant and stems from driver reluctance to follow a vehicle too closely. The closer you get, the faster and harder you are likely to apply the brake. When you follow at a safe distance, you are liable to maintain an equilibrium between braking and accelerating. When you see the gap getting larger, you are free to apply the gas petal, discounting other factors like speed limit. In auto traffic, there is no appreciable gravity effect, however, as there is no benefit to clumping cars together, (with the possible exception of convoys of speeders.)
Note that the “anti-gravity” at extremely close range (like actually touching) can be set to infinity. Therefore brakes are applied to maximum extent possible to avoid touching bumpers. In PRT, it seems that something similar is almost unavoidable. The question is whether collision avoidance through some kind of proximity sensors should be an add-on for redundancy or emergencies only, or integrated directly into the control processes.
As I mentioned in the beginning of this post, it has been suggested that such algorithms could be used in PRT for merging as well as headway control. In such a scenario a computer could consider where, in a line of vehicles, the merging vehicle would be expected to eventually fit, and then gradually apply more and more anti-gravity to that spot. Thus it is like a ghost vehicle slowly materializing and repelling the vehicles around it. It increases this short-range anti-gravity toward mathematical infinity until it has forced a space for the merging vehicle. This is an interesting approach because all decision-making can be localized to the vehicles involved. It also doesn’t need too much or particularly fast communications. Each vehicle simply responds to the proximity-induced repelling forces while trying to maintain forward speed.
One problem with this approach, however, is that it lacks intelligence in the choosing of where, in a line of vehicles, a merging vehicle should be placed. For example, what if a single merging vehicle is near the front of a group of 15 vehicles with plenty of space in front of the group. It seems like it shouldn’t split them up, but rather speed up and merge in front them, if there is time. At least it should delay as few vehicles as possible. But then again perhaps the anti-gravity could be set so that the group collectively repels the single car into such a choice. Or perhaps the group is self-dispersing, because the anti-gravity’s range is sufficient to “de-clump” the 15 vehicles in the first place.
In such a system there is no problem controlling traffic in the event that a section of the system becomes “over-booked.” The traffic would simply slow down. In an earlier post I outlined a control method based on precisely synchronized timing, where vehicles could “book” a split-second “reservation” to go through a merge point without conflict. The system begins with fuzzy time estimates at the point of departure, and but reschedules with more and more precision as the vehicle nears a merge-point and utilizes track markers to time itself. Such a system has automatic traffic control; it can be set to never allow overbooking of a route. It becomes more problematic, however, as fast and heavy traffic pushes the limits of communications and reduces the margin for error. Perhaps the two methods can be combined. Thanks again, Ken. You’ve reminded me again that many heads are better than one!
Here is omething to think about… As I have previously pointed out, because of the boom in highway projects started in the 50’s, cities in the U.S. tend to be spread out. Instead of one central business district, there are usually many little ones. To get people to leave the car at home is to get people to travel many miles without it, and there is no predictable direction of travel, just the likelihood that where they are going isn’t far from a freeway. Therefore I have tried to accommodate this need with my designs.
Building PRT along freeways follows a different logic than many of the systems that are out there today. It is like creating “worm-holes” between the more traditional routing schemes. Naturally the structural requirements are different for both track and vehicles.
The track can be much cheaper as I will show.
Urban track must not be too visually imposing and must be routed to minimize distance between stations. This generally means one-way. There is also a lot of interference of all kinds in terms of track support placement. This includes driveways, corners, underground utilities, telephone poles, signs, and traffic issues during construction. Freeway following track, on the other hand, can have more frequently placed posts, which means shorter (less expensive) spans. It can have two-way traffic supported by each post. There is less of the double track associated with stations and “Y” interchanges. (With two-way traffic this necessitates up to four tracks, something that would create an unwanted umbrella effect, hence the general adoption of one-way urban designs.)
Freeway following track represents a real chance to highlight one of the advantages of PRT, which is the limited weight of the vehicles. Freeways must support 18 wheel trucks, and this sturdy construction is overkill for commuting purposes. When a highway becomes congested, the call goes out to estimate the cost of another lane. Each new lane is expected to absorb a certain number of cars for a certain number of dollars. PRT vehicles can be substituted for cars in this equation. I recently read a Houston Metro study, which was an evaluation of a HOV lane running parallel to a section of I-10 (the main East-West interstate across the southern U.S.) The project was evaluated as a success primarily on the number of vehicles diverted from the main road. As most of us know, one lane of PRT equals many lanes of ordinary highway. It would be hard to make such a clear-cut case in a typical PRT route of convoluted loops. Of course PRT vehicles are not free to the city, like cars, which are supplied by the commuters. But autos are not revenue producers either, unless it is a toll road. With PRT there is also no increase in traffic congestion on either end of the highway leg. It may be a complicated cost-benefit analysis, but I think it’s less so than most of the other route proposals I have seen. They generally look like nightmares of compromise and contentious litigation.
And so I have devoted some time to the problem and have come up with this. In the picture above, the need for excavating has been eliminated by creating a support structure with a “foot.” It occurred to me that the weight of concrete traffic dividers could be utilized along with a wide base to create a system that could be placed in the breakdown lanes. Such a structure could not be made with just concrete and rebar because the edges must taper to nothing, so that vehicles’ tires can roll onto it freely. Therefore there must be some clever integration of steel plate into the design. In addition to its shear weight, (about a ton per running foot) the base can be further immobilized by pinning it into holes drilled into the concrete.
Such track could be installed cheaply and rapidly by being pre-fabricated and trucked to the job site. Sections of the concrete lane-divider would be interlocking or connected by steel splines, so that individual sections cannot be tipped or moved by impact.
Hopefully I will be able to figure out a realistic cost estimate in the near future, since estimating labor and materials appears to be a pretty straightforward job. I do not think I would go with the previously shown truss design, though, because it is for long spans, not cheap and easy construction. Anyway, my guess is that we will be pleasantly surprised.
In the world of TCP/IP, and even Ethernet, and especially any wireless version of either, there are transmission delays that limit what such technologies can do for synchronizing PRT vehicles. That is not to say that such delays cannot be overcome. The problem is that off-the-shelf solutions are only just emerging. Building an IP-based PRT network infrastructure that doesn’t rely on proprietary techniques is, for the time being, still fairly complicated.
Modern computer networking involves lots and lots of flexibility, security, compatibility and legacy issues. After all, computers are used for all sorts of things that were developed over time by many players. Anything resembling a standard communication procedure needs to address many unknowns. Remarkably, the present systems are designed to handle messages of unknown length, coming in at unknown speed, which will be forwarded along an unknown route. The original designers of these systems wisely prioritized accuracy and completeness of the data being sent over speed, and the protocols reflect this. Hence these systems (as they analyze and sort bits of information like a postal worker sorting letters) produce the delays we refer to as latency.
Luckily PRT vehicle control is not the only application that requires minimal network latency. Two others come to mind. The first is industrial processes. Machinery must often interact with split-second precision. The ubiquity of Ethernet as a way to network computers has created a market for methods to achieve “real-time” process control using the same equipment. One interesting open-source project worth exploring is RTnet, which has advanced to the point of having suites of development tools written for it.
A second area driving change is VOIP. (Voice Over Internet Protocol)You see, VOIP cannot tolerate latency. Unlike the data packets that will re-assemble into an Email or even a streaming movie, the packets that comprise your telephone conversation must arrive in order and on time. (relatively speaking)With new “smart phones” appearing daily, higher quality VOIP is becoming essential. Getting there involves a reversal of the previous priority of completeness and accuracy. For example, if a split-second part of a conversation is lost or scrambled, it should just be tossed out, leaving a click or silent spot in the audio. In ordinary TCP/IP, the system would detect the damaged data and ask that it be resent, even if it came in two seconds late. The bottom line is VOIP is forcing a rethink of this and all of the other latency producing steps used in communication and networking. Furthermore, telephones are inherently mobile. When a person travels down the highway talking on the phone he is forcing the network to find a seamless way to “hand-off” his call from one antenna (network access point) to another. This is similar to the problem PRT designers face if they want to minimize the number of vehicles in any subnet and want to minimize the number of hops any transmission must take.
Telephone standards have been referred to in terms of which “generation” they come from. We are coming to the end of the 3G era. Aspects of 4G are already appearing. Whereas some 3G systems had legacy analog capabilities for better phone reception, 4G is 100% packet based. Previously cellular carriers had little incentive to adhere tightly to standards such as the various flavors of IEEE 802, preferring to compete with proprietary protocols. The convergence of corporate data networks, internet, smart phones and the like will surely lead to more “Plug-and-Play” solutions for mobile users interacting with private networks. And that means more standardization between carriers. And, speaking of IEEE 802.xx, the next generation of standards (such as 802.20) looks pretty awesome. But what is “state of the art” now?
There is a lot of activity surrounding the 802.16e standard, which is being commercialized as “WiMAX.” (successor to WiFi) Supposedly latencies are in the in the 40 ms range, but I’m skeptical as to whether real world performance is anything like that. I assume, for example that that is a one-way number, which would double in a round-trip message that included a confirmation. But I am no expert.
I also am not sure what, specifically, can be done with a guaranteed round-trip transmission in, say, 50 ms that can’t be done with a turnaround time of a second or more. It seems to me that for real split-second control issues, 50 ms is still an eternity. It is possible that real-time Ethernet (like RT net) could be adapted for “leaky cable” but that seems like a lot of effort for the hypothetical portion of the PRT control that needs 10ms to one second access times. After all, there is still direct sensing and switching, which is essentially instantaneous. I guess it would be worthwhile to take a good look at the specific maneuvers that a PRT vehicle must make in terms of actual time requirements, from control signal to electro-mechanical response, before getting too far in terms of favoring one technology over another. More specifically, I question whether sub-second communications are really necessary for pre-merge maneuvers. This question leads to track layout and capacity considerations as much as anything else. Should vehicles be packed so closely together and run so fast between closely spaced merge points as to necessitate split-second communications? It seems to me that a little traffic management and prudent track design could go a long way toward allowing a bit of latency. And there is also my often-stated preference for putting more control at the vehicular level, limiting the need for top-down control.Meanwhile, technology marches on. Maybe PRT should run on the Android OS!
For those of you expecting, from the last post, for me to explain my method of requiring only a byte-sized communications to perform a merge, I’m afraid I have to retract that claim. What seemed, at first glance, to be a two-bit digital message is more accurately a couple of blips in an analogue signal, because the timing of the blips is part of the message. It is a moot point, though, because from a transmission point of view it is much smaller and simpler than preparing any sized packet, the usual way of sending it in digitized form.
I want to reiterate that I am not trying to reinvent the wheel. Some variant of ordinary digital networking technology is certainly the way to go as a primary system. I believe, however, that the following examination is worth doing for a number of reasons. For one thing, it forces us to look squarely at the details of the task at hand, which gives direction to what future PRT software and network structure might look like. Secondly, it relates more directly to the kind of systems that have gained regulatory approval in the past, such as trains or people movers. It is possible that it might be simpler to gain approval for a system that is built on top of the same kind of circuit-switched system logic that older, approved systems use. Thirdly, if there will be a back-up system, it would seem logical to have something dissimilar enough to be easily and completely partitioned from the primary. Lastly, this blog has some role to play as an educational resource. Exploration of the problems of control and safety can be simplified by doing so in an allegorical way, since most readers are not well versed in modern telecommunications methodologies. All that being said…
This illustration shows the information accumulated over a few seconds by two proximity sensors positioned at corresponding locations on the two tracks leading to an upcoming merge point. The vertical lines represent units of time and the numbered “blips” represent PRT vehicles. In an animated version of this illustration everything would be traveling right to left, so that information gathered on the left of the picture is older than the information on the right. Imagine it like a window looking out on a highway with the traffic moving right to left, and a snapshot has been taken as the fourth vehicle crosses the midpoint of the field of vision.
Here a reference voltage drops with the breaking of a beam, although other schemes could be used. In this example the vehicles mark twice, once at the front of the vehicle and once at the back. This enables the calculation of velocity. This, then, gives all of the necessary information required to determine if the sampled vehicles will have a conflict at the merge point, and what routines can be used to solve it. Additional monitoring points can be used to create a complete picture of traffic, although from any particular vehicle’s point of view very little of that picture is actually relevant. The picture above represents the “view” of vehicle 4.
Below shows the required broadcast areas for such a system. Traveling through such an area gives each vehicle a chance to construct a representation like the illustration above by “listening” to the traffic cross the sensors in real time. Each vehicle would have a different “picture.” I would suggest that sending the data directly in such a raw form through dedicated channels, fibers or circuits might well make more sense than digitizing it on the spot and directing it through a multicast addressing protocol, especially as a back-up system. In such a scheme normal attenuation (fading of the signal as distance from the transmission source increases) could limit the communications to the relevant vehicles. Note, however, that no communication between vehicles is actually required. If they all have the same information they would, in theory, move independently in the “faith” that neighboring vehicles would be moving as expected as well. This would be highly risky but for the fact that some form of headway distance monitoring is already required as part of a collision avoidance safety system.
I dislike, as is well known, the notion of complicating the track with sensors and controllers as a general rule, and this scheme doesn’t change that. But one can never weigh any trade-off without examining both sides. This round goes to the wayside control model, although a vehicle-based equivalent is doable. For example, the vehicles themselves could “sound-off” as they pass a marker or RFID tag, and a pair of non-interfering RF channels could be used in a leaky feeder system. (I believe I have been too worried about “cross-talk” with a leaky feeder system. There should be plenty of radio bands available that can coexist on one or more cables.)
On a personal note, I am back from New Hampshire, and will get to my Email backlog very soon. Besides making a portable shower stall that snaps together like Styrofoam Legos and a solar hot water heater, I made good progress on this 14x18’ experimental structure that will be a garage/shop/storage building and a place to hang an electrical meter. (My cabin is too far from the road for electric service, but I really need my power tools) I have been a busy boy! I wish I had cleaned the site a bit before taking the picture, but it’s all clean and partially sheathed now. By the way, what’s shown is less than $1600. into the project, including everything – labor, delivery, and materials. (including the 25 tons of gravel under the insulated, pre-plumbed slab) I should have it completely dried in for under $8. sq. ft. Now that’s sweat equity!… and my excuse for posting so infrequently over the past 7 weeks. I thought you all might like to know where I’ve been.
I think it is high time we talk about control with a bit more specificity. Here are some thoughts to ponder.
It seems to me that if everything else fails, PRT vehicles should still be capable of getting to the next station, at a reduced, uniform speed, without hitting each other. This implies a certain amount of autonomy. It also seems to me that PRT should certainly have full and speedy Internet, and also be networked for traffic management purposes.
As far as control goes, it gets a little more complicated. Because of safety concerns, certain aspects must be virtually instantaneous. One would not, for example, want to have to call a central server to suggest that a collision is imminent and an appropriate braking routine is needed.
Let’s take a look at who needs to talk to whom. Fig. 1 shows the obvious case of vehicle A needing to communicate with leading and tailing vehicles. What is not as obvious is that since this zone of needed communications is constantly moving, a centralized control system has no built-in way to keep the relationship between the vehicles special. A zone-based hierarchy (zone controller) would limit the number of vehicles that are communicating to a better number. (note: It is quite possible that an off-the-shelf Linux-based router can be hacked (in the firmware) to make a serviceable zone controller, something that would address most of my previously stated concerns) However that is all a bit off-topic, because I still do not think one is needed.
In Fig. 2, we address the matter of merges. Here I have used the same red zone to indicate where instantaneous communication is most important, with the blue arrows indicating the lines of communication. Here again, there is a special relationship between a small number of vehicles, and this relationship persists until there is an interchange. In this picture we have four little networks that must have very fast communications. It is not clear to me whether communications with any entity outside of this network needs to be particularly fast.
Here’s where all of this leads. First, as a last resort backup, (hurricanes, terrorists, sunspots, earthquakes, plane crashes) the lines of communication shown in blue must persist, or vehicles will be stranded. This is a big no-no if there is no easy way to exit the vehicle. Also it seems probable that regulatory approval would be easiest to approach with a slow, “failsafe” mode first. So… If we assume that we want such an autonomous mode underlying the rest then what “rest” are we talking about?
I, for one, have not identified any communications other than those shown in blue that need to be particularly fast at all. If that is the case, why not have the rest be internet-based, and take advantage of the existing cellular or satellite infrastructures? Such a scheme would isolate the high-speed from the safety portion of the problem in a way that would seem logical.
The fact is that the lines of communication that we are talking about are not even particularly well suited to normal TCP/IP communications in the first place. If such a task were easy, the military would certainly like to know, for such a thing would greatly enhance battlefield strategies. . Requiring ad hoc “mesh” networks are not great way to simplify a PRT system, in my opinion. It reminds me of my friends daughter, who likes to “text” with her friends, even when they are in the same room, and could simply talk instead. Maybe a better example is a fire alarm that alerts your smart phone instead of making it’s own audible signal.
Surgeons fix things with scalpels, carpenters with wood and nails. Is it possible there is a little of that going on here with my IT savvy readers? After all, working systems have been around since before TCP/IP was invented, based on direct switching and signaling. And, by the way, there is precedent for this in the form of current railroad practice. I’m not so sure where we stand on the other, in terms of gaining regulatory approval.
Don’t get me wrong. I believe that the last 10% or more of optimal throughput will absolutely require an advanced dedicated network infrastructure. This future capability must be baked in from the start. I believe though, that we must be careful not to lump real-time control issues (collision avoidance) with traffic management, which can easily have latencies of many seconds without consequence. I have analyzed what exactly would have to be communicated on those little blue arrows and it is amazingly little – less than a byte each way. If I told you how, though,.. well, I’d have to think of something else to write about next time!
A few months ago, I taped my TV remote onto the side of an acrylic rod and covered the connection in foil. Then I pointed one end of the rod at my TV and became one of only a handful of people worldwide to use intra-bedroom fiber optics to turn on The Late Show. This demonstrates a couple of things. First, that you know you need help with your tinkerer addiction when you just happen to have cast acrylic rod hanging around the house. Secondly, it showed that you can transmit data into the SIDE of a fiber optic media and have it be readable coming out the end.
In Ed Anderson’s PRT designs he uses “leaky-cable” to send and receive messages from the vehicles to a zone-controller. Leaky-cable is essentially coaxial cable with slits in the covering that lets radio signals “leak” in and out. This technology was originally used to communicate in mines but is increasingly being used to extend wireless “hot-spots” such as in hotels or dorms since running the cable down the hall is all that is required to give connectivity to the computers in all of the rooms on either side.
Unfortunately these products are designed to broadcast and receive over a wide area, usually up to 30 meters from the cable. That creates the issue is cross-talk. Inside of a PRT track, these products are shouting instead or whispering, since the signal only needs to extend a couple of centimeters. Putting a backup or any second cable won’t work, since each would broadcast and receive from the other. Anderson used time-division multiplexing to let vehicles take turns using the one cable. This is apparently a workable arrangement, but lets just say it is not exactly a modern LAN without some major tweaking. It certainly seems, in theory, that the “volume” could be turned way down and some kind of shielding might be used to enable a second cable (to get more bandwidth) but this is just speculation.
So I have been wondering about infrared. Have you seen “side glow” fiber optic cable? It looks like a flexible neon light. It is the direct optical equivalent to leaky cable. One thing about it is that there is no issue with cross-talk if the cables are shielded. It turns out that before RF wireless connectivity became the standard, there were quite a few infrared products out there for computer networking. Now I can’t really find any, although apparently it is sometimes used for financial and other confidential data because it cannot be hacked into from outside the room, since it relies on “line-of-site” between the transmitter and receiver.
There is one fundamental realization that got me thinking. Since an infrared transmitter, such as my TV remote, is essentially just an LED, (like a light bulb) why be bound to using just one? Why not have, say, 100 all blinking as one? It would be a bit like sending Morse code by plugging and unplugging a string of Christmas lights. Clearly this would be a simple way to broadcast over a wide area. What about the other direction? Can there be multiple, distributed receivers as well?
I am a bit out of my field here, but it seems to me that with Ethernet there is a designated wire from any computer to a router or switch. Could a track-based receiver(s) plug a passing vehicle into an LAN without the lengthy discovery protocol? After all, to the network, it wouldn’t be apparent that different passing vehicles were sending the data. I think the limit is 256 such nodes. I guess there are some Mac or IP address hurdles.
I have to say that this is a somewhat arbitrary exercise at this point. I probably should be starting with a fine-grained examination of exactly what needs to be communicated when and to whom. Speaking in generalities is just not cutting it. Form needs to follow function, not philosophy or “rules of thumb.” As far as rapid communication goes, it would be very rare indeed for it to involve many more than a dozen vehicles, and they are in a predictable positional relationship. (equidistant from a merge) Those positional relationships need to be the starting point for designing any network, as well as firmware and software. I’ll try and explore these more next time.
Well folks, life is very good up here on the land, but not real good for working on PRT. Fact is, I haven’t even been answering emails. “Bear” with me, for I’ll only be at this for a few more weeks. In the meantime here is a picture I dug up that you might find interesting. It shows a forklift, overhead crane and elevator that could run on a PRT like operating system. Apparently similar devices are already used to warehouse frozen goods, saving forklift drivers from the cold. They are closing the library now...Life without the internet...try it!
Hello from the “off the grid” New Hampshire! As some of you know, I often get away to my cabin here, where it is, to put it mildly, rustic. Well, it’s always something. Now the folks here say they can’t give me a license plate without a “911 address.” That takes 5 weeks. That means my car (with expired Kentucky tags) is illegal to drive, which means I can’t keep its battery well charged, (I have no AC on site) which means everything that runs AC or is rechargeable has to be kept to an absolute minimum. I am building a garage, you see, near the road, which will provide a gateway for such utilities. If you can call it a garage… Actually it is an experimental structure, sort of a pregnant “A-frame” with a curved roof. It relies on the strength of curves and of laminations, and can be built single-handedly, even by a 56 year old. (me) It should cost less than half of a traditional structure. Anyway, the point is that the computer I am writing this on is one such energy drain, and is competing with my rechargeable tools. So I might not be around a lot, blog-wise. I am currently at the library, but that an option best suited for rainy days, and it is beautiful outside today.
Now on to some thoughts on PRT. The real obstacle to PRT is, and has always been, the business model. Without a lot of political will, it is hard to get the government funds needed, and that political will cannot exist while there is fear, uncertainty and doubt. Two “Fortune 500” companies have abandoned PRT after sinking millions into it for that very reason.
It is not the track or the stations, for steel companies and builders would love the contracts. After all, they will get paid regardless. Vehicle builders would love it too, although they have a bigger, longer lasting stake. But building vehicles (warranties included) is what they do. Everybody, so far, is within their core competencies, and structuring a deal would be similar to what they do every day.
Not so control. This is a little manufacturing, a little maintenance, a long-term service…
Business-wise, it’s a real mess. PRT companies can stand up bravely all day long and explain how they will always be there, but no one is going to listen. Bankruptcies are just part of the game these days, and all that leaves a city with is a bunch of useless hardware.
It stands to reason then, that the matter should be attacked directly. What can be done to get a handle on this “vendor-dependency issue? What I have endeavored to do, as a first step, is to make the problem smaller. In my last post, I detailed a time-based control system that could reside largely in cyberspace. It could be hosted by almost anybody. It could handle most traffic management and fare collection, things that are not affected by the inherent latency of the internet. On the other end, I have strived to give more control to the vehicles themselves. After all, not bumping into each other seems like a task well suited for those vehicles directly involved.
I do not claim that a global internet-based traffic management system along with autonomous cars is all that is required. As traffic density increases, the ability of vehicles to act with any kind of autonomy will all but vanish, just as it does in auto traffic. The combination I have described is inadequate for the job of high speed, high density, minimal headway traffic. But this does not change the fact that predicating a control architecture on the health of an untested company is a serious, probably fatal, drawback. At least with the combination I suggest, if the PRT company goes under and no longer provides any parts, training or support, the system would still work. Just not optimally. This would give the city some breathing room while they search for a fix. After all, the problem with PRT companies is that they are irreplaceable.
So, to recap, my objective is to structure a PRT construction and control architecture that cannot leave a city stranded, or come as close to that objective as possible. This may not make for the prettiest software code or networking structure, but it is, in my view, the only way forward. At the very least, we should all be looking at exactly what can be done to structure the control aspect of PRT into simple, definable businesses with ordinary equipment requiring minimal special training. What equipment, where? How many people? Is there scheduled maintenance? Replacement? What communications gear does the track need? Who will install that? You get the point. If we can divide and conquer this stuff, we will be a long way ahead.
Well, I didn’t say I wouldn’t post… Part of not having to post every week is to give me the time to explore ideas more fully before I write about them. The matter of PRT control, however, is something that I have already written about extensively in draft form, both to clarify it in my own mind and to try to figure out a way to explain it. Here is a little sample for your consideration that cuts right to the heart of the matter.
Consider the most critical maneuver in PRT, the merge. Weaving PRT traffic can be done through exact scheduling, direct sensing/communications between merging vehicles or through an intermediary. Over a decade ago, When J. Edward Anderson wrote about the problem, using an intermediary was the only practical solution. I believe that paradigm is no longer the only game in town.
Let’s compare a similar type of system, also designed many years ago, air traffic control. Here, airplanes are controlled by an intermediary, the control tower, which I think is roughly analogous to Anderson’s “zone-controllers.” Could we cut this intermediary out? Consider what would happen if the tower went dark but the planes could communicate with each other directly, and they all had the airport’s schedule. It would be a fairly simple matter for the first plane on the schedule to call the second when it was about to touch down, and again when it was clearing the runway, with the second giving similar guidance to the third, etc. Moreover, if they synchronized their watches, they could simply make a schedule for themselves, landing a plane, say, every minute, so that the first might touch down at 4:00, the second at 4:01, and so fourth. If they all knew who was in the air around them and what the landing order was, they could speed the process by all advancing their schedules each time the landing plane beat the scheduled time.
This is the essence of what I propose for PRT. With PRT, at the inception of every trip, it is necessary to know if the trip can be completed and if so, by what route. Since any trip can be broken down into pieces, dividing the trip into segments beginning and ending at merge points makes as much sense as anything else. Since the travel time between merge points can be estimated, there should be, at the beginning of any trip, a knowledge of what time each merge point will be encountered. This would be an opportune time to assess the traffic load through the various merge points and to consider alternative routing.
Furthermore, upon logging these plans at the boarding kiosk, a system-wide database can be generated which may be divided and sorted in different ways. One such way would be to list all vehicles scheduled to pass through a given merge point, sorted by time of arrival. A group of such lists (one for each merge point on a route) could be downloaded to every vehicle upon leaving the station and updated. In this way, every vehicle in every stretch of track knows the identities of every other vehicle on that track segment, as well as those on the corresponding track segment that is connected at the next merge. Now a LAN can be established. Furthermore, every vehicle knows which vehicles are the most relevant from that list, those being the ones that are closest chronologically. This is not very different from the example of the pilot-to-pilot communication described above, with the most important conversations being between those first in line.
Now all of the vehicles in the two connected segments have each other’s “phone numbers” (so to speak) and can initiate communication as needed. There are a number of things that might be done to help things along, such as either distributing or “clumping” vehicles together, prioritizing vehicles by swapping merge schedules, or even pushing vehicles faster through the merge than would normally be acceptable, to help avoid an upcoming traffic jam, or even switching routes if there is a diverging track.
Listing all of the ways traffic could be shaped is too involved to get into here, and traffic shaping software would probably evolve over time anyway.
It is worth noting that this system consists of smaller, faster, shorter distance, and more critical networks overlaid upon larger, slower, potentially less timely ones. For example, the kiosk booking and initial routing, it seems to me, could be done via the web, while last second communications between vehicles about to enter the merge should probably be circuit-switched (“hard-wired”) instead of packet based, and would include only those vehicles directly involved. Such a general architecture could offer excellent fault tolerance through the redundancy of multiple networks and independence from central control.
Two points to add – First, in regards to previous posts and comments about cameras and sensors and seeing around corners … I want to point out that if vehicles can broadcast location updates more or less continuously, this is functionally equivalent. “Dark” vehicles can be detected as missing from the network, and in the scheme above their relative location is also known. Second, in regard to previous discussions about variable speed, I used the example of catering to people who are prone to motion sickness as one benefit. I think a far better example is that of empty vehicles. In a rush-hour situation, great numbers might need to be shuttled back empty to pick up new passengers. These empties have no issues to restrict speed at all, and their lighter weight means they can have less headway. In fact, I see no regulatory obstacles to coupling them into platoons. (Platooning occupied vehicles would be a lot easier to sell after it has been widely used for empties.) This is easily accommodated by the control system outlined above. Anyway, it is adaptive, variable speed I am advocating, not gentle rides or fast empties or platooning or prioritized traffic. These incremental improvements can evolve later, as long as the system architecture supports such tweaking.
Well folks, this is post number 100, and I have a sad announcement. I’m afraid I will no longer be posting on a weekly basis, at least that will no longer be a goal. There was a time when the subject matter was so simple and abundant that I could whip out a post in a few minutes. Now, frankly, I’m starting to repeat myself. And anything I haven’t already said probably takes a few pages to say. In research and design, the work is becoming more fine-grained as well, full of time-consuming details. So I will post only when I can do a quality job of it, and when the topic makes a significant contribution to the body of work that I have already posted. Maybe that will free up the time for some long overdue improvements to the site. One hundred posts. It’s been a long journey... Now on to the topic of the day.
Whenever I talk about PRT control, I am usually pointed toward the work of Dr. J. Edward Anderson. I want to take a minute explain what I don’t like about Dr. Anderson’s method of PRT control, why I think it was designed the way it was, and how I think it could be improved.
First of all, it is important to note that we are talking about a system that was created well over a decade ago. I do not want to imply that the later generation systems currently offered by Taxi 2000 or PRT International are anything but top-notch, although since they are proprietary I know nothing about them. From what I can gather from his 1998 paper, Anderson did a good job of working with what he had, and to understand his control methods, we must understand the technological limitations of the day and how his “Asynchronous Point Follower” system was designed to overcome them.
At that time, “packet switched” data transfer was still in its infancy. The word “Internet” was just becoming a common term. There certainly wasn’t any good way to move information back and forth between a bunch moving of vehicles. Information was directed by “circuit switched” methods, so to direct information to its proper place, the various vehicles and a “zone-controller” would have to take turns sharing a dedicated line through a technique known as “time division multiplexing.” This multiplexing needed a hardware platform. The dominant computing architecture of the day was “client-server,” so a wayside server became the “zone controller” which played the role of both old-time telephone switchboard operator and commander-in-chief. These days such limitations are rapidly falling away. Many vehicles can talk directly to each other wirelessly, exchanging massive amounts of data, all at the same time.
Anderson was controlling vehicles that were comparatively “blind, deaf, and dumb.” Is it any wonder that he would “lead them by the hand?” That’s what “point following” essentially is. The zone controller extends its “hand” like someone leading a blind person across a street. Letting go, even for a few seconds, needed to be very predictable, so there were minimal adjustment moves, measured and known by both the controller and the vehicle. These days a vehicle could pretty much watch out for itself. Actually the whole concept can now be done in the negative. Instead of the safe spot that the “hand” (moving point) represents, the space close to other vehicles can be considered the “unsafe spots” and everything else can be fair game, as it is in ordinary auto traffic. Anderson’s variation from earlier point-following schemes was a move in this direction, because he allowed the stretching the distances between these points.
Greatly helping along the shift from “moving point” control is the proliferation of network-ready, “plug-and play” sensors, to give the vehicles “eyes.” It also doesn’t hurt that vehicles can continually update their positions in real time without over-burdening the system.
In merges, Anderson’s zone controller would weave the safe zones together, keeping the vehicles constrained within them. The beauty of this whole scheme was that the vehicles did not need to have synchronized internal clocks. These days that is not a problem either, which enables an interesting alternative. Simply give each of the vehicles a specific, exact time to pass the merge point. This “appointment” could be set and reset, negotiated among vehicles approaching the merge point, something that would have been utterly impossible a decade ago.
Finally computers, back then, were big, heavy, slow, expensive energy hogs that generated a lot of heat. There was only so much that a vehicle’s computer could be expected to do, so much responsibility necessarily had to go to the zone controller. The moving points scheme was a good division of labor. The zone controller could weave many points but the vehicle just had to follow one. That has obviously changed. Now every thing that the zone controller knew or calculated can be known or calculated by each of the vehicles independently in a fraction of the time.
It has been mentioned that the simplicity of such a system is a good thing. If it works, why change it? Especially for something much more complicated, such as asynchronous, autonomous control?
,
I am not at all sure it IS more complicated. What must a vehicle do? Wait, accelerate, decelerate, cruise and exit. There’s not a lot to it. With Anderson’s “Asynchronous Point Following,” acceleration and deceleration are handled by the vehicle executing equations that are meant to move the vehicle backward or forward by a precise amount, into a safe spot, double-checked by the zone controller. That does not seem simple to me. Why try to backwards engineer a system designed to overcome obstacles that no longer exist?
Autonomy has generally inferred limited outside influence, but with modern communications there is no clear line anymore. As our computing platforms have become more mobile, the relationship between those connected computers has changed. Once upon a time the only model was client-server, where a giant mainframe computer would perform tasks, often on a time-share basis, for people working at relatively dumb terminals. PRT control systems were born of that era, often designed to run linear motors mounted in the track itself, so that the vehicles were just objects being magnetically pushed around a giant machine.
Anderson’s designs pushed control much more toward the vehicle, (toward autonomy) especially by putting the linear motors in the vehicles themselves. Slow processing power and communications were limiting factors in that mobile environment. These days, the barriers have all but fallen, and the client-server model is just one of many. There is cloud computing, distributed computing, parallel computing, grid computing, P2P computing. And there are many types of networks, and they can even be overlaid with each other.
Perhaps the traditional definitions of PRT control (synchronous, asynchronous) have outlived their usefulness, since virtually all systems are hybrids between the two. More useful would be to analyze how the control responsibilities are divided and shared in terms of network structure(s). For example, if all accelerating and braking is physically done at the vehicular level, how far away should that control be pushed? Certainly the closest vehicles should have some say in the matter, but what is the point in sharing the small maneuver details any farther than that? Yet how such maneuvers effect the vehicle’s ETA would certainly be of interest to the system globally, for traffic management. But that data is of a wholly different type, organized and accessed differently. An overlaid network. More localized traffic management might be best handled still differently. Its time for a fresh start, one that better leverages the qualities of recently emerging network, sensor, and communications technologies.
Lastly I would refer the reader to post 76, although it shows what I have been saying about repeating myself. I think it is important to get this right, to have an architecture that can evolve with the times with a minimum of disruption, and can be implemented without creating the poisonous “vendor dependency” that I have written about. In upcoming posts I will try and lay out, more specifically, what kinds of networking and control structures I have in mind and why.
One of the hazards of getting into deep technical subjects every week is that it’s easy to lose track of what I’ve already posted and what I haven’t. Earlier today I was ready to post a rather long-winded examination of how to synchronize communications and control. It turns out, though, that I posted much of the same concept a few weeks ago, although not all of the details. In view of that, and the fact that it was way too long a piece, I think it’s time to go back to the drawing board. Actually, speaking of drawing boards, I have spent more than my allotment of “PRT time” this week trying to design the door mechanisms for my little green and white pods. So I’ll go easy on myself and just leave you with this picture, and call it a day.
Yeah, I know, I have railed against elevated stations in the past, but mostly because I don’t think they should be the ONLY way to board. I have to admit, though, it sure has a small footprint compared to the ground level station below…
See what you did? You made me dig up ANOTHER picture! And I was saving that one… Oh well, Cya next week!
Every now and then an alert reader asks a question so profound that I just can’t keep it buried in the comments section. This time the honor goes to cmfseattle for this question, posted under Control Issues Part II.
“Why would vehicles be going at different speeds, anyway? For any given segment of track, there is a maximum safe speed. Why not just have the vehicles go at that speed?”
The short answer is passenger comfort. A system like the one I envision is capable of much higher speed maneuvers than most passengers would be willing to endure. But let me put this in context. I do not believe that previous PRT designers have chosen centralized or zone-based control because it is better, but rather because they had to. Autonomy requires cheap, powerful computers, sensors and very fast and flexible communications. Since all of this is pretty standard stuff these days, these obstacles have been removed. Another factor is the nature of the network. Most PRT designers and vendors have envisioned systems where short trips are taken around a downtown area by hoards of passengers. Since they look at their systems primarily as a business venture, if a track segment wouldn’t be packed with vehicles, that segment would not be built. The strategy of only “picking the low hanging fruit” and then moving on to different city makes perfect business sense, and requires only relatively slow vehicles moving in unison. Let me give an example of how this philosophy creates limitations.
In most PRT systems, with the vehicle riding on top of a guideway or rail, the need for going fast around sharp curves is addressed by banking that curve. In the case of “y” interchanges, however, banking is impossible. This leaves these systems with two choices. One is to go slow, the other is to make the “Y” structure very gradual, creating the need for much more track. It has been pointed out that with frequent stations, a large percentage of the overhead track would, in fact, be double, creating extra cost and an unwanted canopy effect. The option of slowing for a curve is not needed because the vehicle is going slow in the first place. I do question just how smooth these interchanges can be made without slowing down, though. Going at a fixed, slow speed has other benefits. All curves can be sharper and banked at the optimum angle for line speed. The vehicles need not be particularly crash-worthy. Of course less expensive propulsion systems can be used as well. Finally, since they (PRT vendor/designers) see themselves having absolute control over all aspects of the system, there is no need to consolidate control. Some control could be with the stations, some with the vehicles, some with the track and some with a central system. This hairball approach is perfectly logical if nobody outside of your company will ever have to work on it. Anyway, within the context described above, a fixed speed which is controlled from outside of the vehicle makes perfect sense.
As soon as you move to higher speeds, however, the fixed speed approach gets much more cumbersome. Even with a hanging, self-banking design, there are limits to what kind of G-forces passengers will tolerate. Variable speed allows PRT vehicles to do what ordinary cars do for any particularly sharp turn, which is to slow down. But the faster they were going, the more time is spent in a transition speed. I would note that even with the fixed speed systems, there are always transition speeds anyway, such as entering or leaving a station or creating a slot for a merging vehicle. Longer, smoother transitions generally mean a more comfortable and energy efficient ride, something left out of the “line-speed” paradigm.
There is a trade-off that exists between speed and system efficiency and the nausea prone stomachs of a small but significant portion of the ridership. In a heavy traffic situation, there is only one choice. Slow everybody down to a point where the ride is acceptable to the vast majority and just let the rest be uncomfortable. With variable speed, however, if there are no motion sickness prone passengers on a track segment, everyone could go faster. The information for this could easily be gathered at the point of payment or stored in the form of account information.
Another advantage to variable speed has to do with inertia. Heavily loaded vehicles will tend to take longer to accelerate and decelerate, and should have longer headway distances. This might influence the how the vehicle behaves in merges and turns. These effects also become more profound with greater speeds. For example, why waste the energy quickly accelerating a 2 AM delivery? Even with regenerative braking, it would still be advantageous to coast to a stop if time and traffic allows. Everyone who drives knows that the acceleration/deceleration profile that is best for energy efficiency is not the same as for getting somewhere in a hurry.
Finally, it would be more efficient if the PRT behaviors included a bit of opportunism. Ever get on a freeway entrance ramp and realize that if you hurry you can slip into a spot without making anyone squeeze you in? In a PRT system, there could easily be very limited merging opportunities onto a busy track, and since relative positions would be known well in advance, the merging vehicle could “step on it” for a very long time to catch such a fleeting slot. This is essentially the “step forward” maneuver that Anderson envisioned but with many steps forward by a single vehicle rather than many vehicles all stepping back one step. This maneuver, again, involves straying from line-speed for an extended period of time.
In the end I think it will just be simpler, more comfortable, cheaper, easier to manage, and more energy efficient to program the PRT vehicles with behaviors that take into account the same sort of factors that influence drivers every day. How is traffic? Who (if anyone) is my passenger? Will I hold everyone up if I drive slowly? Will I benefit merging traffic if I speed up? Should I drive more conservatively because my vehicle is loaded down? Is this an emergency? Can I get through downtown before rush hour starts?
In the end, it all comes down to the PRT equivalent of intelligently using the gas and brake pedals. Any system that fails to address acceleration/deceleration properly is going to be uncomfortable to the rider and will constrain the options available to the track designer. The other option is to just go slow.
Will faster, longer range PRT simply promote more suburban sprawl?
In the U.S., the dream of affordable home ownership, a culture that celebrates the freedom of cars and unfettered free enterprise, (wherever it leads) and a well-oiled system for expanding highways has led to the phenomena known as suburban sprawl. Part of the problem has been that as traffic increased on freeways we have been quick to add lanes. This in turn makes the commute out of town faster and therefore more attractive again, so development resumes with renewed vigor farther out of town. This, in turn, creates still more traffic, which creates more lanes, which creates more out of town development, and so forth. It is a vicious cycle. Will PRT, if extended out to the suburbs, exacerbate, or even amplify this trend? I have been a proponent developing PRT systems that have utility outside of the city centers, systems capable of higher speeds and longer distances. I want PRT to serve the suburbs. Am I proposing a “solution” that will, in the end, be counterproductive? That’s a question worth asking.
Once upon a time, in the old days before superhighways, cities had to mix residential, commercial, industrial and entertainment centers much more closely out of necessity. There simply wasn’t the option of dumping a whole bucket of gasoline into your gas tank to make a 15-mile journey home in under a half hour. Now many of us are addicted to it. Ironically, the farther you drive, the more appealing gas-guzzlers get, because they usually offer greater comfort. A bucket in the morning, and maybe another at night, made to seem benign by silent, odorless, high-speed gasoline pumps and cavernous gas tanks. One remedy would be to simply tax gasoline to the point where people would be forced to live closer in. Or simply ignore the traffic and never expand the roads. In the U.S. we have all seen the “urban decay” that was the result of the flight to the suburbs. Is it time now to institute policies that will result in “suburban” decay and flight to urban areas? I think not. Those suburban homes are the American families’ nest eggs, and real estate has taken enough of a beating already. But nudging ourselves back toward urban life is a must, because energy and environmental costs are just to high to do otherwise.
Above is a picture I snapped the other day through my windshield. Six miles from downtown, this road was widened less than 5 years ago. It makes my head spin to think about all of the gas and productivity that is wasted when traffic slows like this from just a sprinkling rain. But consider this: None of these people care that they are going somewhere where nothing is within walking distance. They have their cars. All of these people are on their way to congest some other area. What if some of them were to arrive without cars? Those people would then want to have their needs met much closer their to destination. That, my friends, is the seed of a community. I can think of very little else that could revitalize cities as much as piping in the suburbanites as pedestrians instead of as drivers.
And what about the on the suburban end? Won’t this just make it that much easier to live far from town? Well it will make it more affordable, efficient, and earth-friendly, that’s for sure. But contribute to further expansion of the sprawl? Maybe a bit. Keep in mind that on the suburban end there are subdivisions full of homes that are not within walking distance of anything, and no one can seriously suggest PRT for every residential street. Unless we’re talking about bulldozing, these people are going to use their cars. But to where? Typically every big residential area has a nearby supermarket, drugstore, bank, etc. In other words, the seeds of a town. These need not, currently, be in close proximity to each other. Would PRT become the glue that would turn a suburban “strip” into a walkable “Main Street?” It wouldn’t hurt. After all PRT, by definition, delivers pedestrians, not cars. Would new, more rural developments be encouraged by PRT’s proximity? Although presumably a developer could request PRT service from the inception of a project, PRT deployment will generally lag WAY behind road development, so this fear seems misplaced. After all, there are other remedies for sprawl that we just haven’t used. Like the tax codes. After all, if there were a smaller spread between the value of undeveloped and developed land, developers would look elsewhere for profits. If we undervalue the earth as nature made it, we can only expect more of the same regardless of transportation method. There is already precedent for this, in tax law as it now stands, but nearly every time I see a piece of raw land for sale it has been recently bulldozed, so it can be viewed more easily, I suppose. Clearly the tax penalty for this behavior is not a sufficient deterrent.
This is a road construction site I pass often, and I just had to get out and snap a picture. I must say it is truly massive. I fret about differences in track size in the inches, but a section of that PRT track laid down on this expanse would be absolutely lost. I added the map to show how this relates to sprawl, and I’m not sure I have drawn any conclusions. The first thing to note is that it is not a road leading out of town, but rather the final segment of a loop. But look at the undeveloped green space around the area. That won’t last. Also notable is the proximity to the airport, (between Humble and Aldine, to the left of the arrow) the 8th busiest in the country. Behind the arrow is name Atascocita, which, it turns out, is the 44th fastest growing community in the country, at 8% per year. The North/South road leading into town is new and wide, making the area just minutes from downtown, with relatively little traffic, yet. One point worth mentioning is that sprawl is greatest in the fastest growing cities. Cities like Phoenix, Dallas, Houston and Atlanta all grew over 23% during the 90s. ttp://en.wikipedia.org/wiki/Table_of_United_States_Metropolitan_Statistical_Areas
It’s hard to absorb that many people in the city center in that length of time. High-rises for over a million in a decade? I don’t think so. If there is an opinion I’ve formed, mulling all of this over, it is that satellite communities are probably unavoidable, but all communities, large and small, need to shrink in landmass to become more efficient, functional, and livable. People’s jobs change often, and moving rather than commuting is often not practical. I tentatively maintain my stance that higher speed PRT has a positive role to play in the mix. What do you think?
I would love to hear from you. I might even include your thoughts in a future post. (Only with your permission of course) Just email me- danverhoeve@gmail.com.
Want to download editable copies of the designs pictured in this blog? These (generally done in Google’s free 3D program“SketchUp”) are now available at our design collaboration site,http://code.google.com/p/openprt/Instructions for sharing, improving and updating designs via SVN are also posted there, under “Downloads.”
ABOUT THIS BLOG
Everyone knows that automobiles, as we know them, cannot continue to be the primary way the world commutes forever. There is the emergence of an enormous commuting class in the developing world, but it’s not just that there will not be enough fuel. The cost will be so high as to humble the world’s great powers, and be the cause of future wars. The impact on Global warming will be catastrophic. The health effects for residents of large cities is already significant. The lost productivity caused by grid-locked traffic currently takes a big bite out of our standard of living that we don’t even recognize. It will only get worse. Clearly something needs to be done. The problem is that there is, currently, no alternative. The car now offers the only real transportation system which has a prayer of offering a traveler a nearly straight line, nearly non-stop, essentially door-to-door journey. (I am leaving out bicycles and motorcycles, and scooters and Segways, etc. because they can all be problematic in bad weather, for older persons, etc.) Enter the PRT, or PERSONAL RAPID TRANSIT. . Though promising in theory, this concept has failed to deliver, and I think I know why. The problem is that the PRT systems developed thus far were developed not to solve this great world problem, but rather to create a business. This bias toward profit has poisoned the decision making process and created products with limited usefulness. I am not against profit. It is just that there has been too little emphasis on what a city wants and too much on what the corporation wants to offer. The system needs to be designed as a versatile, practical set of solutions, not as a product offering that reflects the strength and weaknesses of the company offering it. Proprietary or patented specifications and single source suppliers can only discourage a city government from taking the leap of faith needed to make PRT a reality. Enter this blog. This is but a timid first step on what could be a world-changing journey. What if the complete specifications for a working PRT system were developed and continually improved via posting online? What if the system was modular, with all of the various parts and pieces being individually ready to be out-sourced to the lowest bidder? What if the next company interested in being a PRT provider didn’t have to re-invent the wheel? What if the next city government considering PRT could have easy access to the thoughts and experiences of their peers in other cities? What if all the concerns - environmental, macro- and micro-economic, political, technical, fiscal, legal, even psychological- could be so completely vetted that cities world-wide could institute PRT programs with confidence and competence? So get on board, spread the word…and let’s change the world!
