106> Simple Circuits

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.

105> A Voice from the Woods!

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!

104> Pondering Infrared

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.

103> A little something...

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!

102> The PRT Business Model

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.

101> PRT Merge Control

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. 

100> One Hundred and Counting ...

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.

99> Pic of the Week

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!

 

98> SPEED UP! SLOW DOWN!

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.

97> PRT and Suburban Sprawl

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?

96> Control Issues, part II

Let’s demystify control with an overview. Background on this subject can be found in posts 75-77. I’ll start with navigation. Obviously the first choice in any navigation system is to simply go in a straight line. The mitigating factors are availability of track and traffic on it. If there is a possibility of some traffic being slower than other traffic, then that adds a third factor. Let’s start with the straight line. Imagine the network as a chessboard, with you at one corner and your destination at the other. It should be a simple matter to identify all squares directly between the two points and rate them highly. Squares less direct, but still nearly in the line would score a bit lower, and so forth. Now within those squares are actual tracks. Some go East/West, some North/South, or somewhere in between. Here again there can be a rating system based on how close the direction of a route segment comes to the direction that would be the optimum straight line. A final factor would be expected traffic and speed. Traffic can be derived from ticket data or real time reporting from the vehicles themselves. This data then is crunched, preferably by the vehicle, and it can set out. I say “preferably by the vehicle” because if the vehicle makes these decisions, the route can be refigured along the way. Every route is only a series of left or right turns separated by a straightaway. At each diverge point, the whole fastest route strategy can be recalculated. This information would be available wirelessly, possibly even via standard internet means.

Let me back up a bit and clarify the concepts of speed and traffic. I do not like the concept of line speed, except perhaps at merges. While line speed will probably be the inevitable result of having vehicles not holding each other up or rear-ending each other, there are arguments for allowing vehicles to decide their own speed where possible. If we are designing a control architecture from scratch, let’s start with a wish list and see if those wishes can be fulfilled. Personally, I like fast. I drive fast, and if I haven’t arrived yet, then I’m probably in a hurry. Hazard of years of self-employment, I guess. I want all timid, motion-sick wimps to get out of the way! Hey, I’m on the clock here! PRT can, and should be, fun, sexy and exiting. Why not? Also, one way to keep a track segment free of traffic congestion is for the people in front to speed up and make room for those bringing up the rear.

The stations, it seems to me, should talk to each other as the first level of traffic management. This would be where the vehicles would get information about expected traffic and speeds, and where they would report their prospective routes. Getting the OK, (or rather a confirmation that the trip is doable in a reasonable timeframe and the destination station is able to receive the vehicle) they would leave the station and drive themselves autonomously. If conditions change, they would be capable of changing routes, but since this would be a rare occurrence, the central system would generally be pretty accurate. This is after all, essentially a traffic reporting function, not so different than the morning “Jam Cam” on local TV.

A second system could be vehicle-to-vehicle communications, sort of like a trucker’s CB radio. (“Breaker Breaker, good buddy!”) Such a system would keep track of the positions and speeds of all vehicles within a relevant range. The most important aspect of this function would be at merges. Vehicles would negotiate for precise time-based “reservations” for crossing the merge point. Especially important would be communications between the vehicles equidistant from the merge that must adjust themselves to each other to avoid conflict. Early upstream communications between many vehicles would enable the traffic to be “shaped” so as to maximize throughput. For example, if track A has twice the vehicles as Track B and they are to merge, the best way to “shape” the traffic would be to get Track A’s vehicles in evenly dispersed groups of 2.

There must be a backup system for this. One idea is to enable a vehicle on track A to disable the power to the corresponding section of track B. The frontrunners would always get preference. This could be built into the track with a few Reed switches and relays, and would not tend to wear out because they would be switching off sections of track that are not supposed to have any power draw anyway. (When vehicles lose track power they slow to walking speed.) A final, emergency backup solution would be to slow everybody down and just take turns, the PRT equivalent of a malfunctioning traffic light. “Treat it as a four way stop.”

The vehicles’ headway control would work by each car reading its position on the track (optical bar codes, magnetic markers or RFID tags) and reporting its velocity by broadcasting it wirelessly through ordinary wireless LAN protocols. The position sensing would be enhanced and checked by counting wheel rotations. A back-up system would be to use a pair of overlapping wave guides, perhaps a hundred meters in length. (I am counting Leaky coaxial cable as one type of wave guide.) The limited length would limit communications to relevant traffic only, and would eliminate demultiplexing of many extraneous communications streams. In closer ranges optical or ultrasonic methods would be added. (The chip they use in cameras is under $50.)



So that’s pretty much it. It’s not a particularly difficult to avoid driving into a vehicle in front of you, nor taking the correct turn, nor maintaining a speed to cross a merge at an exact (to the second) time. So I say let the vehicles control themselves. That way control will automatically get updated as vehicles wear out and are replaced, except for station controls, which can be monitored and serviced very easily and need WiFi and line power for the kiosks anyway. Almost any task that can be done by a central wayside computer can be done by combining the computing resources of vehicles connected by a wireless LAN. In this architecture all control decisions come from the vehicles, although zone and station traffic is monitored and shared. The exception is the power scheme for merge points that I mentioned.

This architecture is designed for an open source system. It presumes that vehicles are designed and continually improved by a nonprofit organization (NPO) but built by independent contractors. The track and station construction would be contracted to locals, and the station communications and kiosks would be Open Source (NPO developed) but installed and maintained by local contractors. The role for a PRT company is minimized. I think this is a good thing, because no PRT companies have a long-term track record anyway. This is fundamentally different than having a PRT company design, build and operate an integrated system, which can blur control responsibilities between vehicles, stations, zone controllers, and even control room operators. No customers for anything want to be locked into a single vendor.

The other emphasis is on extensibility. Whereas the ordinary PRT model would have the vendor needing to quickly add staff and production capabilities to service a growing demand, this model minimizes these problems, which would only, in the end, make city officials look bad when they are forced to explain delays and problems to the public. In this model skill sets are organized in a way that allows much more rapid growth with minimal growing pains. The brains are in the cars, more than the track and stations. This is also a more familiar model just on its face, because it is more like traditional roads and automobiles. Hopefully this will make PRT somewhat easier to embrace. The last aspect to mention is that the model is nearly unbreakable. There are no parts that can malfunction that can affect whole groups of vehicles, except the merging track deactivation that I mentioned, and hopefully a better (in-vehicle) fail-safe can be devised.

That’s it. Oh! My laptop has recovered famously from yesterday’s surgery. Thanks for asking…

sorry folks,

My laptop has just been through a very long day of surgery. I just had to solder in a new power jack, and its after 11 pm. I'll be posting soon, but this computer problem has set me back a few days. I still have a blown diode somewhere in the battery charging system, so I'm writing this with a small short circuit which may melt my handywork or kill the power brick at any time. Too bad. This has been a good computer...Time to start shopping...

95> Call the Cable Guy!

Whenever I see an artist’s conception of something futuristic I always have to muse at the attributes they give the materials of the future. While up at the cabin, I stumbled on this old magazine. Note the total lack of support for the track of the main vehicle. (I won’t even get into the giant ULTra vehicles)

While this is common practice, it’s pretty tough to compete with designs made out of super alloys straight out of science fiction. In the case of PRT advocacy, the main job is to sell the concept of a whole new infrastructure, overlaid on the existing one. This is obviously much easier to do if it is minimalized. On the other hand, there is also a credibility issue here. If the system you are sold on bears no resemblance to what you are really going to get, how can any further claims by a PRT advocate (or vendor) be trusted?

I have given a lot of thought to PRT trusses, and I just want to make an observation. I have never seen any system meant to carry people that is more than about 35 times as long as it is high. Box beams, I beams, trusses, whatever. They rarely approach this mark and are usually much less. There is some pretty good reading on the subject in the Wikipedia entries on beams, bridges and trusses.

The bottom line is that PRT needs to have as skinny a support structure as possible, much more so than any other application I can think of. In other situations, generally, something needs to be built and the buyer has little choice but to take the recommendations of the architect or engineer. Here they can just decide not to involve themselves with PRT in the first place. 

Next time you pull down your wooden attic stairs or have a wooden stepladder handy, note how they reinforce the steps. You will see that they have a thin metal rod beneath each step that can be tightened, squeezing the step end-to-end. The step then becomes a compression member resting on a tension member, resulting in a very strong “beam”. Tension members (cable) are also employed to great effect on pre and post-tensioned concrete in a very similar way. Below are some drawings of cables that are integrated into a traditional truss. I am quite confident that this type of addition would increase span substantially, beating that 35 to 1 ratio.  

 

Fig. 1 shows geometry similar to a suspension bridge. Support points can be had by periodic attachment along the length of a stretched cable. In a Suspension bridge secondary cables can hang straight down to support the bridge decking. Suspension bridges must have the ends of the cables be anchored to the ground, however, although multiple spans can attach together instead. Pulling the cable tighter makes the decking arch upward. Figs. 2 and 3 show how cable could be stretched within a truss and terminated in a spool, which could be tightened. Tightening both spools equally (with a BIG torque wrench) would be essential, or the support would be pulled over. Straight runs would need to terminate by ground anchoring, just like a suspension bridge. The cable could also be continuous. (Between ground anchors) Fig. 4 shows how cable-stayed bridges differ from suspension bridges. Instead stretching a cable from two ground anchors and hanging a bridge off of the cable, the cable-stayed design balances cantilevered loads on a support column. At these slight angles there would obviously be a lot of compression put on the truss itself, pushing it toward the support posts. What is interesting to me though, can be seen in FIG. 5. Note that the truss also becomes a tension member, because the cables work to pull the structure in opposite directions in the middle of the span. This gives it characteristics similar to the continuous cable in Fig 3.

Finally, to really confuse the reader, figure 6 is a full crossbreed. Depending on how the cables are tensioned, this can be either a suspension or a cable-stayed design. Confused? I know I am. But I have used similar techniques to make impossibly long and thin unsupported shelves with great success, and even took the sag out of a roofline once. I know it would work to some degree. Also, never underestimate the wisdom and practicality of the farmer. They use cable to keep stuff from sagging all the time, like this irrigation system. 

 One final photo. It is nearly impossible to down a single telephone pole, since they are all cabled together at the top. I have seen them broken in half by trucks, and the snapped pole just hangs there. Such a quality would seem to be ideal for PRT from a safety point of view. By the way, cable is, relatively speaking, dirt-cheap. Each half-inch steel cable has a tensile strength of over 20,000 lbs. It would sure make ME feel better in an earthquake!

94> Say Cheese!

Sometimes consumer technologies march forward and open possibilities in completely unrelated fields. Such a situation seems to exist with the problem of position and distance sensing as it might apply to PRT. Traditional technologies include SONAR, LADAR, (similar to sonar but with lasers instead of sound) as well as magnetic position sensors and RFID tags. Meanwhile, digital photography has taken off, and computing speed has made interpreting camera information essentially instantaneous. The following is a brief exploration of the possibility of using ordinary “webcams” for this purpose. This is made possible by the relatively controlled lighting conditions in an enclosed track. The following assumes a light on the front and a hollow square reflector on the back of each bogie. My sample webcam has been simplified to the point of having almost no resolution, with only 100 pixels. In real practice the light sources and cameras would be in pairs, offering redundancy.     

 

Here you can see the reflected square as captured by the camera. I have made it off-center to simulate an approaching curve in the track downward and to the left. Because of curves in the track the camera will not always be aimed directly at the leading vehicle. There can even be blind turns, an issue I’ll avoid for now.

In the example above, the pixels 52-55, 62, 65, 72, 75, and 82-85 are activated. It would be a simple matter for the computer to recognize the patterns, since the horizontal lines are characterized by consecutive numbers and the vertical lines are characterized by incrementing by tens. In either case, (up & down or across) the count is four. 

 

In the second picture the longest string of numbers (consecutive or by tens) is three digits, not four. The box is smaller, as it would appear if the lead vehicle were further away. 

Here is a nearly blind turn. In this case the only information that the computer can use is that the pixels 30, 40, 50, 60, and 70 are red. The computer would rightly interpret this as a five. Now it is apparent why a chose a hollow square reflector. As long as there is at least one straight line with a beginning and an end, the distance to the lead vehicle can be determined.

The example above is a very primitive, I know, but it would work about the same with a higher resolution system. For example, the lowest resolution “webcam” that I found online was 640 by 480 pixels, about a third of a megapixel. I found a “two-pack” of 1-megapixel cameras for $33. (U.S.)

Consider how such resolution would apply to distance determination. Assuming a bit of edge-blur from the optics of, say, 3 pixels, that would still differentiate over two hundred different sizes/distances. Again, this is with the very least available resolution.

Video is commonly captured at 30 frames per second, so this gives you an idea of the sampling speed. Were a vehicle to be stalled, for example, such sampling would establish a possible problem by the second frame, confirm it by the third, and double check the results by the fourth, activating a braking routine. I would assume that such cameras would also be able to receive track location information as well, perhaps by simple shape or pattern recognition, like a bar code. 

But these handy little cameras do even more. They can also serve as a WDM style demultiplexer. WDM stands for “Wavelength Division Multiplexing” and is a method of cramming multiple simultaneous data streams into a single fiber optic cable. As long as each stream has it’s own frequency, (color) the streams can be unscrambled at their destination. In our case different colors could simply mean different things, just like the way traffic lights communicate with red, yellow and green. Since the computer is already equipped to recognize color information from the camera, there can be many input “channels” that can be utilized, all with their own color. Of course this is all still very primitive, especially because 30 frames per second is too slow for meaningful serial communication. Yet between simple shape recognition, color differentiation, and the (painfully slow) serial transmission, this gives an autonomous redundancy/backup capability to vehicles otherwise directed by more complex and capable wireless communication methods. And it’s hard to beat the price!

93> In Search of PRT’s “Killer App”

I want to dust-off a topic I have posted on before, and add some new thoughts I have had on the matter. The subject, or perhaps the question, regards what kind of routing layout PRT is best suited for, or should start with. Unfortunately I need to get down to some greasy details to make my point.

First I want to point out something about PRT control. In the very early days of PRT, back in the days of the Aerospace Corporation’s involvement, sensor, computer and communication technologies were in their infancy. The logical approach to vehicle control was to have a big computer manage all of the cars like one big machine. That way not much was required in the way of sensors or computing power on board. (Now, of course, we have more computing power in our cell phones than their whole system had.) Merges were conceived in terms of vacant or occupied spaces that were all moving at the same speed, something that can clearly be seen in the video. This required a uniform “line speed.” I am not sure about Vectus, (seems like someone told me it has dynamic speed control) but I believe everyone else pretty much assumes this sort of set speed. (If my information is dated, please correct me!) The going wisdom seems to be that to be financially viable, the track needs to be packed at all times, and so the system must be confined specific, highly urbanized areas. Therefore the routing involves close distances and so the system doesn’t need to go fast.

Then there is the matter of headway limitations. There is a notion out there that vehicles can only go so fast, because the headway requirements increase as the speed increases. Therefore, more cars can pass a point traveling slowly and close together than by going fast and being more spread out. There is a formula that “proves” this. Unfortunately this has led some to conclude that PRT, as a rule, can only go so fast. I have heard specific speeds mentioned.

I believe the arguments listed above are wrong-headed. First, about the packed track/financial viability thing…Perhaps the reason the track needs to be packed is because it is downtown, moving slow, has many stations, only short trips, etc. This all jacks up cost or constrains revenue. Amortizing this cost requires either high fares or a packed track. The per mile/kilometer cost estimates for PRT generally include several elevated stations, assume many long spans across streets, high construction costs because of traffic, buried utilities, etc. Has anyone, ever, given a quote to go across an empty field? Of course not. PRT is too slow to be useful for long haul, and it is too expensive to go anywhere where the track won’t be filled. See where I’m going with this? It’s a circular argument. Maybe it’s expensive because it is downtown and is downtown because it is expensive.

Let’s go back to, before moving on, to that argument about top speed and headway, since nobody is going to trade a 45-minute car ride for a 65 minute PRT ride. It, too, is a false choice. This is because the numbers going into the formula can be changed by simply designing the vehicle differently, and then the answer changes as well. I looked at the formula and found that the variables that must be entered refer to common sense considerations like braking efficiency, response time, and crashworthiness. Therefore any suggested optimal speed or headway distance is the result of plugging in numbers for a particular system’s capabilities. Nobody, (including me, so far) has plugged in the numbers for a system like I have proposed, but I guarantee that the safe headway would be way, way less than for a system where the first part of the vehicle to make contact in a collision is the passenger compartment itself, which is the case all of the systems currently on the market, yet need not be. They don’t need crashworthiness because they don’t go fast, because of, well… more circular arguments.

As far as the controls go, the technology for dynamic speed control is really not an issue anymore. Thousands of calculations can be done in thousandths of a second and transmitted and received with similar speed, although some intrepid programmers need to step forward and write an open-source version of the control software. An example of a demonstrated system (That even works with truly antique computers and sensors) is the PATH program. Insofar as at least some of it was funded by taxpayer money, I sort of hoped that they would at least respond to my requests for the code they used, but, alas, I’m just a lowly blogger…Anyway, with variable speed, another of the factors holding back PRT from being a commuting tool will have fallen.

One note, however… There is the matter of controlling vehicles that run on simple pavement, like ULTra and 2getthere. There is definitely a slippery pavement issue when it comes to going fast for these guys. None of my arguments apply to them. They really do need to keep to routes appropriate to more limited speeds, at least for the time being.

There is the matter of motion sickness, but again, with dynamic speed control, cornering speed would be based on factors including what is comfortable. The individual could (theoretically) even specify the kind of ride they prefer. So the last of the arguments against commuter PRT has been answered. Well, sort of… There is the matter of where to go on the suburban end.

Another thing that has changed since PRT’s inception is the proliferation of “Park & Ride” systems. These are essentially parking lot/bus stops in the suburbs, which are sometimes used in combination with HOV (High Occupancy Vehicle) lanes. The commuter can take the bus or carpool to bypass the clogged freeways. These lots are ready-made outlying destinations for PRT. But why not just take the bus? Because if there is no HOV lane, the bus gets just as stuck in traffic as the rest of the commuters. If there IS an HOV lane, it too, will become clogged over time, when (in some cases) it will magically morph into a toll lane. (Funny how that happens!) Also, upon exiting the HOV lane, the bus cannot take passengers to all of their respective destinations efficiently. And HOV lanes are usually one-way. (reversible) The buses face ordinary traffic on the return trip. Anyway, these Park and Ride lots are generally on inexpensive land that is very close to the freeway and would be cheap to connect to. True, the passengers would have had to drive to these lots, but don’t forget, the downtown traffic comes from somewhere. Typically, the first part of a morning commute goes pretty fast. It is the last five miles or so where the traffic gets really bad. This is nipping it at the bud. Otherwise the ironic alternative might be that the traffic downtown is from people looking for a place to park so they could use the great PRT system! That is one aspect of “short-haul” PRT that has always puzzled me – What does it really save if the passengers have to commute in to use it? (But then again I live in a city where almost nobody lives downtown)

It was recently remarked that PRT needed a network to be effective, that a simple loop or straight line would be a waste. Whereas this is largely true, especially compared to a large network, it is should be pointed out that even on a two-way straight-line configuration travel time can be improved by PRT’s off-line stations, meaning you can go non-stop to your destination, and the fact that PRT is available on demand. This cuts travel time to a fraction of light rail and a fraction of a fraction of bus travel time. In the case limited routing outlined above, though, many passengers would undoubtedly still need further transportation. The Achilles heel of buses is the many stops they must make, both for passengers and for stoplights. But even a very simple PRT loop could eliminate a huge portion of this wasted time. Personally, I wouldn’t like taking a five-minute bus ride to finish my commute, but I would do it if I had already saved enough time getting to the downtown area in the first place. If the last part of the journey were to be taken from a downtown terminal, however, (where an express bus would drop you off) that last leg might be and agonizing 20 minutes instead. I guess I am suggesting a possible symbiotic relationship between the downtown and commuter legs of system.

Finally I want to point out that the cheapest configuration for routing on freeway medians would be actually be a bottom supported design like Skyweb Express, because it would be so easy to construct low-rise track. This is not all that different from the cost/structural dynamics that enabled the spread of traditional railroads. For example, such track could be supported with gravel instead of deeply anchored supports. It is hard to imagine such a configuration costing very much more than a million dollars per mile. In most cases the Park and Rides have structures in place that could be converted into the required elevated boarding areas. In defense of hanging systems, I think they would be much preferred for these very large parking lots since they could pretty much come to your car.

Amortizing a million dollar a mile track is much, much easier than the inner city routes on which it would depend. (OK, it would probably be more, but I like round numbers) Consider amortizing the track over 10 years, with 33 cents per mile going to this purpose. Payoff is 3 million trips, 300,000 per year, or 822 trips per day. That is 34 trips per hour (averaged over 24 hrs) or about one every two minutes. Obviously they are mostly during rush hour, but equally obvious is that Holy-Grail benchmarks like two-second headways probably need not be reached here. More to the point is that a comparable HOV lane costs 5 times as much, and also the size of the parking lot needs to be considered. This may not be PRT’s “killer app” but keeping that many cars out of city center in the first place certainly seems like a worthwhile goal.

Finally, to my friends in the U.S… Happy Independence Day! This is a time when we can all come together and enjoy the sights and sounds that result from the enormous, ultimate, instantaneous release of CO2! :o) Oh well, be Happy. It’s the 4th of July!