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?