Sunday, March 15, 2009

23> Podcar Control part 2

I would like, first of all, to thank alert reader Mr. Grant for sharing this paper by J. Edward Anderson, who is truly an authority on the subject of PRT. Unfortunately the material seems somewhat dated. Although there is a date on the PDF, (2003) I suspect the paper was actually written a few years earlier.

Although I completely agree with most points in this article, (in fact most of it is a MUST READ) I have to say that there are a few points I disagree with as well. Since a monologue on my take on this article may be a bit more than many readers would want to wade through, I will include those as a comment on this post.

Anyway, I would suggest, as a guideline, to make traffic control decentralized, and make the individual “podcars” behave much like good drivers, I.E. following road signs, not tailgating, but seeking shortcuts and less trafficked routes. This begs the question, however, of how to achieve a redundancy of control to safeguard against malfunctions

Another missing piece of the control puzzle is exactly how communications reach a “podcar” (I still hate that term, but if it gets us noticed…) Anyway, I guess the problem is as follows: There is a constantly updating traffic map wherein stations and track segments are self-reporting their status. Their reports would probably be little more than a segment/station number, and a condition number, (like a scale of one to ten) This simple communcation needs to have a success rate that is near absolute. This communication could be optically/electrically/mechanically/wirelessly redundantly reproduced at intervals along the track so a passing “podcar” gets an update every so many feet/meters. Redundancy creates a multiplier effect in terms of reliability, and enables faulty components to be replaceable on a maintenance schedule

There is one other VERY important communication, which can take place from the track to the podcar. That is a report of having been just traveled upon by another podcar. If a PRT vehicle is to react much like a human driver, it needs to see ahead and slow down when necessary. If there is any aspect of this system that needs 99.999% reliability it’s the system that prevents “rear ending “ the vehicle ahead. This means redundant, separate reporting means so that anything less than complete agreement between sensing systems results in an immediate cautionary response. As part of such a system the track could inform a trailing vehicle that there is another “podcar” just ahead. Here is an example of how it could work. Imagine a little line of lights in the track illuminate when they sense the passing of a “podcar”, only to dim and go out over the next couple of seconds. (Imagine the tail of a comet) A light sensing, following podcar would know, by measuring the light intensity, how far ahead the first vehicle is. Why not just use taillights on each vehicle? Because of the problem of seeing around curves. What about Bluetooth, GPS or other wireless technologies? I, frankly, don’t know. This is where a small army of alert readers would help. Don’t feel like posting a comment? As always, I can be contacted at danverhoeve@gmail.com.

6 comments:

Dan said...

Dan the Blogger's take on the paper by J Edward Anderson

I question the consensus for the need for lead times between vehicles to be as low as a half second. That’s over 7000 podcars per hour. If that were a highway, it would be a pretty main artery. That’s not to say that short lead times aren’t good, but I suspect that their technical/business model had gotten so out of whack that this kind of traffic density would be needed to cover costs. (This would bring in $720.per hour at 20 cents/mile) I believe in holding down costs to the point that an extensive network is affordable and there are many alternative routes a podcar can take.

I also question the role of the central computer as illustrated in his explanation of how PRT vehicles would diverge into differing routes. He describes a centrally generated “switch table” like a train, yet the taxi 2000 design called for switchless track, with the switching to be done in the vehicle. (I have an illustration of this in an earlier post) So why have a constantly updated switch table for every vehicle which is maintained outside the vehicle and then communicated to it? I would suggest that there be a route segment traffic report instead, so that the vehicle could decide on it’s own whether to go right or left at each branching point.

This decentralized intelligence is, in general, a divergence from the computing philosophy of the times in which, I believe, Dr. Anderson wrote this paper. Although he pays lip service to the concept of decentralization under the section on Vandalism and Sabotage, I think that the cost, size and reliability of computers made the vehicle autonomy, which I suggest, impractical at the time.

I also suspect he had linear motors in mind, which have many advantages, perfect vehicle spacing control being one of them. This is, however, a side effect of having a completely uniform cruising speed, which I would argue is a disadvantage.

Anonymous said...

Just a quick note to say 'Hi' & that I find this a fascinating site

How about a link to Dr Anderson's paper so we can follow along at home.

Keep up the good work.

Dan said...

Dan the Blogger responds..
Oops! I think the post is fixed now with the link. Thanks, Anonymous.

resonance said...

In my conception of PRT most of the status communication would be through radio signals (WiFi, cell, or something else, whatever is appropriate). Vehicles would know their location either from RFID tags or other signals embedded in the track, from radio triangulation, or from GPS (or all of these). Whether this solution is more or less expensive than running all the information through cables in the track is something you'll have to do the math to find out.

As for centralized vs. decentralized control, I think it should be a mix. Part of the benefit of PRT over independent human drivers is that there is opportunity to optimize traffic routing automatically; for example, a centralized system would likely be able to avoid situations such as those that arise in Braess' paradox, where the actions of independent self-interested agents (be they man or machine) give rise to a suboptimal routing result. At the same time, the system should be designed such that cars can operate as independantly as possible without causing major traffic issues both to reduce the workload of the central controllers and communication bandwidth necessities, as well as to ensure safe and effective travel if and when communication with the central control is unavailable, such as areas where there is poor radio reception or when there is a power outage. Speaking of which, it's important to have some sort of backup energy source on board in case of power outages, especially with systems that utilize hanging pods.

Providing the ability for pods to sense obstructions in front of them dynamically should actually be relatively easy to do, since the technology is already available on some newer automobiles.

Dan said...

Dan the Blogger Responds-
I basically agree with everything you said here, Resonance.

Mina said...

I like E. Anderson's description of the trip ticket, but I envision something a little different:

People seem to envision walk-up traffic from one-time users most, but someday when the system is pretty robust and goes everywhere, I think people will have pass cards that link them to a user account where information such as billing and favorite destinations is stored. The user could then select one of their usual destinations or enter in a new one, and the system could just bill their account and even provide a statement later if needed. I'm also guessing they may sometimes want to change plans mid-trip, and the system should be ready to accommodate them.

I expect the earliest installations will be on large campuses and business parks, where most trips will be subsidized by some entity like the university or the mall owner. However, as connections are made and the system expands, who pays the costs of a trip that spans cities is likely to become a concern.

We need to consider not just who pays (walk-up customer swipes card or inserts coins), but also who receive the revenue.

Maybe I should back-up a little and suggest that since one of the biggest benefits of PRT is that you can have much more track and really saturate a city, allowing people to get much closer to where they want to go, it seems that at some point you're going to wind up having to negotiate rights between two different owners who want to connect track but retain revenue and control over how their section is used.

If LA wants to charge .05$/ mile and Orange County wants to charge .25$/mile how is that trip revenue distributed? What if LA takes a long time to return OC's cars? What if LA's cars are crappy and old and cause undo wear and tear on OC's guideways? What if Pasadena decides that they don't have the bandwidth to handle pass-through trips and refuses all traffic going anywhere else?

I envision a control system intelligent enough to divide the costs fairly among all the track owners along the route and allow them to provide discounts & penalties to users based on how they use the system.

This would require the control system to handle a great deal of information, but I still think it's pretty doable. The main thing is to define realms of control and responsibility, sort of like how the ethernet seven-layer model defines more layers than we actually use, but it provides incredible flexibility.