Monday, July 26, 2010

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…

14 comments:

Ryan Baker said...

Would the vehicle track all the vehicles around them? It's not sufficient in my mind for the vehicles to only track the leading/following vehicle. When stops/slowdowns or adjustments occur they should occur as a synchronized operation. That is, if the lead car is going to slow down, the car 20 back should start slowing down at the exact same moment, not after it notices the car in front of it started to slow, which occurs after that car noticed ... etc.

It's true with modern CPU's there isn't any reason that with a full set of data every vehicle couldn't perform independent calculations to find the same network plan. However, I think it's important that they all have the same plan, or at the least that there is some mechanism for collaboration.

The reasoning for centralizing some processing steps is not however limited to the idea that there wasn't sufficient processing power locally. There is the element of latency.

Reading some of this, it feels more to me like you envision independent decision making, which would not include some standard result. Independent decisions have to endure latency in their validation against other decisions. In the automobile world, this is very slow, i.e. one driver has to see the other driver start to change lanes, accelerate, etc in order to factor that in their decision making.

PRT would obviously do better than this by wireless communications, but it's impractical even with current technology to have every vehicle communicate with every other vehicle. It may be practical for one vehicle to communicate with it's 100 closest relatives, but something needs to help it find those relatives, and it should have information in a wider sense. For wider data the sensible approach is for aggregation. While it's perfectly possible to distribute this among vehicles and have aggregation dynamically shared, that is a complicated design to get right, and may not be the best choice for V1.

As to line speed, there's no need for this to be an absolute, but I think it is often going to be practical. Where there are low density segments, running fast and slow vehicles on the same line may provide some value, in high density segments it's going to have lower practical value for four reasons:

1. Congestion: If it's only 100ft to the next "slow" vehicle, then running fast gains little.
2. Distance: Speed is not so important when so much is close already.
3. Availability of multiple routes: If multiple speeds are desired, it is probably more practical to have slow track and fast track, than one fast/slow track.
4. Throughput: If full capacity is necessary an overly fast vehicle would harm that capacity. I guess one option might be for those wanting "fast" to pay more per mile and get shifted on the fast tracks.

I am going to leave with a reminder about latency. Consider this greatly, it is an unavoidable element, and worse, latency does not, in any significant way, decrease with technological progress. It takes virtually the same amount of time to get 1 bit of information from New York to San Fransisco as it did the first time a telegraph line from New York to San Fransisco existed. You may be able to shove 1 billion bytes behind it that will arrive within the time it would have took to send the next bit with the telegraph, but this is bandwidth, not latency. Many the software system has fallen prey to failing to consider the costs of latency.

Ryan Baker said...

I forgot to mention one thing. I'm not suggesting you don't want to have capabilities geared toward low density operations, but some of that design, at least in so much as it is excluding components harms high density operations.

As long as systems can relinquish some of their autonomy within a high density zone, I think both can work, and other than the burden on us poor software developers who must write both sides of that system, that seems a practical choice.

And yet one more final statement. I do hope that PRT will be used as a tool to bring things closer together, rather than farther apart. Even with the revolutionary capabilities and efficiencies of PRT, it is not sustainable to operate in the far flung fashion a large part of the United States chooses too. PRT has a great deal of flexibility which extends the outer boundaries of possibility in both directions. Living in a city would be much more convenient with PRT than without it, and many hassles would be eliminated or reduced. It also however makes the long commute less painful, which why simply cause more traffic, with longer commutes rather than real energy/time savings if individuals continue to make the same choices they've made for the past 50 years.

cmfseattle said...

we're all on the clock, here.

Dan said...

Dan The Blogger Responds-
Well, time is tight, that’s true, but I’m glad you took the time, Ryan. I think you frame the issues and nail down the other side of the argument very well. I agree with everything that you say. There are certainly trade-offs with my approach. My object is to create an architecture that is quickly extensible beyond the capability of any one company or community, one that does not hold a city hostage to the fortunes of a single PRT vendor, but rather enables competition over straight-forward, easily contractible and replicatible business opportunities. (OK that’s not a word, but should be..)This leads to a system that is admittedly imperfect, but in my view, good enough. If there are other means of control that fulfill this objective, I’m open to suggestions. I’m more interested in the ends than the means.

About latency – It may be that more following vehicles can be directly contacted by a lead vehicle than I have indicated, I really can’t say. I have a tendency to favor having different types of systems for primary and backup, and since my primary would be a bunch of networked computers, I reflexively favor simple signaling as a backup… “Vehicle number, RPMs, location.” repeat…over and over. I was shooting for a backup system for which no computers at all would be necessary to keep headways within parameters. My son, who is working on his Masters in computer science, believes everything I have ever conceived of in this vein is just a poor re-invention of reliable, easily available and understood Ethernet protocols, hardware or software. One of these days I’ll pin him down for some specifics. Anyway, it seems to me that if the first 5 cars all got the message in, say, .25 seconds, that would be good enough. The sixth through 10th vehicles could easily have a 2+ second latency, since they are certainly over 5 seconds back, and so forth, back from there.

Multiple speeds - Like autos, rush hour eliminates any choice of speed. I cannot believe that there won’t be voids in traffic ever, though. What about at night? Also, if PRT ever takes off and gets its fair share of transportation funds, routing won’t be confined to only the busiest routes. I wouldn’t want to be tied to a fixed speed system at that point. I could go with fixed speed initially if I didn’t think it would get “grand-fathered” in, and be difficult to change later.

Contributing to sprawl- I have worried about that as well. If it makes freeways go faster, and that makes commuting more attractive, that is bad, but it is offset by keeping great numbers of cars out of the city. I hate to think that the only way to fix something is to let it remain broken…and it’s surely better than the widening roads. My best guess is that it will tend to consolidate growth along the routes, just like subways, and those routes will always lag rural and suburban development significantly while making urban life better in comparison, an overall plus. I’d like to see tax codes that do more to discourage car dependent communities and encourage conservation, however.

cmfseattle said...

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?

Is there really going to be a situation where one vehicle will be going slowly enough to justify the complexity involved in an overtaking maneuver?

Maybe you and/or some of your readers could use Anderson's expired
Method and apparatus for controlling a vehicle patent as a starting point, and write the open-source code?

Ryan Baker said...

I indeed would recommend relying on off the shelf components or technologies. However, it's much more interesting writing and reading looking at novel approaches, and sometimes it's easier to discover a way to improve or make better use of the proven systems as a result of that thinking.

To the use question, i.e whether PRT will encourage more walkable communities, and shorter travel distance as well as time in development patterns here's some additional thoughts.

It is never (okay almost never) the right strategy to try and contain the genie, he always gets out. Maybe if your objective is to slow him down, then maybe. A more complete strategy is to make rub the lamp and make the genie do your bidding, but you have to be careful to make that happen. Build it and they will come isn't the game here.

Sometimes the mechanism for these things is laws and regulation. I'm not sure how that would apply to PRT. I can't see there being a "National PRT bill".

Another avenue is simply setting conventions that stick early. Much of what we're doing here is talking about those.

By the way, the word is "replicable". (Still not in Chrome's dictionary, but in the Merriam-Webster)

Andrew F said...

I'm not sure we should be overly concerned about PRT facilitating sprawl. The infrastructure is expensive enough that for people to be within comfortable walking distance, they will need to live at decent densities. This won't be so bad, because we can release some of the 30% of the surface areas of cities that are dedicated to roads, parking lots, etc.

Also, paying per km travelled I think is a good mental deterrent to travelling too far. People do this in cars because once you get a car, most of the cost of it is sunk. To justify the expenditure, they feel they need to use the car extensively. This is why I would be opposed to either a flat fare or unlimited monthly passes like you see in conventional transit. Both of these are antithetical to a cost-recovery PRT system.

Dan said...

Dan The Blogger Responds -
Hold that thought, guys. I've decided to devote the upcoming post to the spreading sprawl issue.

Dan said...

Oops! Sorry, cmfseattle. I missed your comment.
Great question. I can't believe I never really explained myself before!
I believe what is safe and what is comfortable are too very different numbers. I would rather let the customer decide, and that decision would probably change with improving vehicle design over the years. Apparently a significant, but not large proportion of passengers will have real problems with motion sickness. Why make them sick by going fast in the middle of the night? Also, perhaps right before rush hour, the roller coaster lover's convention lets out, and there are no admitted motion-sick-prone people on the route. Then it would be stupid to make everyone go slow. I think it makes sense to have the system remember people's profiles anyway, say for automatic billing, so why not give people the ride they want, all else being equal? As for the "overtake maneuver" I can imagine such a thing in merges, if a vehicle could speed up to catch a slot before the opportunity is lost. Maybe I'll post on this, because there's a lot more to say...

Andrew F said...

There's no reason not to allow vehicles to run at slower speeds/accelerations to accommodate those who are sensitive to motion, but I'd think those who want to use this functionality would have to pay for it with increased delays (taking a siding to allow a group of faster moving/accelerating traffic to pass, and perhaps wait for other pods with similar preferences and destinations to form 'trains').

This is actually a good argument for not necessarily spreading the vehicles out, but having them travel in 'clumps'. It makes such passing manoeuvres more practical, and might even simplify merging operations. This would be another argument for vehicles to run at variable speeds in order to catch up with the lead vehicle. It also enables you to get away from long acceleration/deceleration sidings at stations, as there will be gaps between groups of vehicles that allow vehicles exiting the station to perform part of the acceleration manoeuvre on the main guideway, just after one clump passes, but coming up to speed fast enough not to delay the approaching clump. And at peak times where there are few gaps between clumps, just slow the line speed so less time is required for acceleration. Of course, this is all just fiddly stuff and not really relevant.

Ryan Baker said...

It is important to be careful about overall effects on the system. For example.. what would happen if 20% of people opted for slow mode? I'd have to do analysis but my suspicion is there would be relatively little difference between this an 100% in average travel time because "fast" vehicles would be stuck behind slow so much.

Also in respect to using sidings or other diversions, it's important to balance their costs as well. Diverting to the siding creates some jerk, and if that diversion also requires an acceleration/deceleration to merge (or because you're reusing a station siding), then the overall comfort of slow mode could easily end up being worse than fast. Actually, I'm fairly certain it would be since speed will not affect comfort as long as speed does not cause vibration, which if it occurred would to me indicate you're operating too close to the track's theoretical maximum speed to be safe. I have a hard time believing that diverting onto a siding so that decelerate before you come back to the main to take a turn at lower speed rather than decelerating on the main will bring much advantage in comfort, capacity or average speed. It seems clear to me however that to meet those goals you would get definite benefits in all categories by separate lines optimized for high speeds, that would simply be avoided by those seeking comfort.

Andrew F said...

I think you're better off excluding the delicate than making the system so slow as to impair its utility. So if the choice comes down to slowing things down to accommodate those susceptible to motion sickness and having a system that is still useful, I'd go for the latter. But the people who can't handle moderate jerks and accelerations probably have a hard time already in cars. Nathan Koren said something about tolerances being much lower in PRT than cars because you can't observe driver intention. Seems to me the solution to that is to advertise vehicle intention to the occupant with a simple display or voice prompt ("turning right in 3...2...1..."). Slowing the whole thing down seems crazy and unnecessary.

Dan said...

Dan The Blogger responds-
Just a couple of points. First, any well designed vehicle will be capable of speeds that nobody would accept, comfort-wise, except thrill seekers. So it's not crazy to slow it down - it's just a question of how much. Maybe the real test will be drink spillage. How much of THAT is acceptable? BTW, I never mentioned the empties. If most traffic is going one way, the empties need to get back quick.
Also, I don't think too much should be made of this whole thing.. It's absolutely correct that there won't be a choice a lot of the time. It just happens that the control design I am working on gives some multi-speed and priority capability as sort of a byproduct. (at every merge either the left or right leg could ask to go first) Whether or how it is used would probably be mostly evolutionary.

I could imagine, however, a small pull-over lane here and there, similar to the extra lanes they provide on hilly country roads to let people get by trucks. This might be a station exit where the station can be bypassed. The track space could double as vehicle storage or staging.

Good point about clumps. I've thought a lot about how to make and size them.

Ryan Baker said...

Dan, you keep saying vehicles will have a speed to high for people to endure and I keep pointing out it's not speed that's the concern, it's g-forces, which are created via accelerating, decelerating or turning. The distinction is very important.