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.