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. 

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!