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…

sorry folks,

My laptop has just been through a very long day of surgery. I just had to solder in a new power jack, and its after 11 pm. I'll be posting soon, but this computer problem has set me back a few days. I still have a blown diode somewhere in the battery charging system, so I'm writing this with a small short circuit which may melt my handywork or kill the power brick at any time. Too bad. This has been a good computer...Time to start shopping...

95> Call the Cable Guy!

Whenever I see an artist’s conception of something futuristic I always have to muse at the attributes they give the materials of the future. While up at the cabin, I stumbled on this old magazine. Note the total lack of support for the track of the main vehicle. (I won’t even get into the giant ULTra vehicles)

While this is common practice, it’s pretty tough to compete with designs made out of super alloys straight out of science fiction. In the case of PRT advocacy, the main job is to sell the concept of a whole new infrastructure, overlaid on the existing one. This is obviously much easier to do if it is minimalized. On the other hand, there is also a credibility issue here. If the system you are sold on bears no resemblance to what you are really going to get, how can any further claims by a PRT advocate (or vendor) be trusted?

I have given a lot of thought to PRT trusses, and I just want to make an observation. I have never seen any system meant to carry people that is more than about 35 times as long as it is high. Box beams, I beams, trusses, whatever. They rarely approach this mark and are usually much less. There is some pretty good reading on the subject in the Wikipedia entries on beams, bridges and trusses.

The bottom line is that PRT needs to have as skinny a support structure as possible, much more so than any other application I can think of. In other situations, generally, something needs to be built and the buyer has little choice but to take the recommendations of the architect or engineer. Here they can just decide not to involve themselves with PRT in the first place. 

Next time you pull down your wooden attic stairs or have a wooden stepladder handy, note how they reinforce the steps. You will see that they have a thin metal rod beneath each step that can be tightened, squeezing the step end-to-end. The step then becomes a compression member resting on a tension member, resulting in a very strong “beam”. Tension members (cable) are also employed to great effect on pre and post-tensioned concrete in a very similar way. Below are some drawings of cables that are integrated into a traditional truss. I am quite confident that this type of addition would increase span substantially, beating that 35 to 1 ratio.  

 

Fig. 1 shows geometry similar to a suspension bridge. Support points can be had by periodic attachment along the length of a stretched cable. In a Suspension bridge secondary cables can hang straight down to support the bridge decking. Suspension bridges must have the ends of the cables be anchored to the ground, however, although multiple spans can attach together instead. Pulling the cable tighter makes the decking arch upward. Figs. 2 and 3 show how cable could be stretched within a truss and terminated in a spool, which could be tightened. Tightening both spools equally (with a BIG torque wrench) would be essential, or the support would be pulled over. Straight runs would need to terminate by ground anchoring, just like a suspension bridge. The cable could also be continuous. (Between ground anchors) Fig. 4 shows how cable-stayed bridges differ from suspension bridges. Instead stretching a cable from two ground anchors and hanging a bridge off of the cable, the cable-stayed design balances cantilevered loads on a support column. At these slight angles there would obviously be a lot of compression put on the truss itself, pushing it toward the support posts. What is interesting to me though, can be seen in FIG. 5. Note that the truss also becomes a tension member, because the cables work to pull the structure in opposite directions in the middle of the span. This gives it characteristics similar to the continuous cable in Fig 3.

Finally, to really confuse the reader, figure 6 is a full crossbreed. Depending on how the cables are tensioned, this can be either a suspension or a cable-stayed design. Confused? I know I am. But I have used similar techniques to make impossibly long and thin unsupported shelves with great success, and even took the sag out of a roofline once. I know it would work to some degree. Also, never underestimate the wisdom and practicality of the farmer. They use cable to keep stuff from sagging all the time, like this irrigation system. 

 One final photo. It is nearly impossible to down a single telephone pole, since they are all cabled together at the top. I have seen them broken in half by trucks, and the snapped pole just hangs there. Such a quality would seem to be ideal for PRT from a safety point of view. By the way, cable is, relatively speaking, dirt-cheap. Each half-inch steel cable has a tensile strength of over 20,000 lbs. It would sure make ME feel better in an earthquake!

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!

93> In Search of PRT’s “Killer App”

I want to dust-off a topic I have posted on before, and add some new thoughts I have had on the matter. The subject, or perhaps the question, regards what kind of routing layout PRT is best suited for, or should start with. Unfortunately I need to get down to some greasy details to make my point.

First I want to point out something about PRT control. In the very early days of PRT, back in the days of the Aerospace Corporation’s involvement, sensor, computer and communication technologies were in their infancy. The logical approach to vehicle control was to have a big computer manage all of the cars like one big machine. That way not much was required in the way of sensors or computing power on board. (Now, of course, we have more computing power in our cell phones than their whole system had.) Merges were conceived in terms of vacant or occupied spaces that were all moving at the same speed, something that can clearly be seen in the video. This required a uniform “line speed.” I am not sure about Vectus, (seems like someone told me it has dynamic speed control) but I believe everyone else pretty much assumes this sort of set speed. (If my information is dated, please correct me!) The going wisdom seems to be that to be financially viable, the track needs to be packed at all times, and so the system must be confined specific, highly urbanized areas. Therefore the routing involves close distances and so the system doesn’t need to go fast.

Then there is the matter of headway limitations. There is a notion out there that vehicles can only go so fast, because the headway requirements increase as the speed increases. Therefore, more cars can pass a point traveling slowly and close together than by going fast and being more spread out. There is a formula that “proves” this. Unfortunately this has led some to conclude that PRT, as a rule, can only go so fast. I have heard specific speeds mentioned.

I believe the arguments listed above are wrong-headed. First, about the packed track/financial viability thing…Perhaps the reason the track needs to be packed is because it is downtown, moving slow, has many stations, only short trips, etc. This all jacks up cost or constrains revenue. Amortizing this cost requires either high fares or a packed track. The per mile/kilometer cost estimates for PRT generally include several elevated stations, assume many long spans across streets, high construction costs because of traffic, buried utilities, etc. Has anyone, ever, given a quote to go across an empty field? Of course not. PRT is too slow to be useful for long haul, and it is too expensive to go anywhere where the track won’t be filled. See where I’m going with this? It’s a circular argument. Maybe it’s expensive because it is downtown and is downtown because it is expensive.

Let’s go back to, before moving on, to that argument about top speed and headway, since nobody is going to trade a 45-minute car ride for a 65 minute PRT ride. It, too, is a false choice. This is because the numbers going into the formula can be changed by simply designing the vehicle differently, and then the answer changes as well. I looked at the formula and found that the variables that must be entered refer to common sense considerations like braking efficiency, response time, and crashworthiness. Therefore any suggested optimal speed or headway distance is the result of plugging in numbers for a particular system’s capabilities. Nobody, (including me, so far) has plugged in the numbers for a system like I have proposed, but I guarantee that the safe headway would be way, way less than for a system where the first part of the vehicle to make contact in a collision is the passenger compartment itself, which is the case all of the systems currently on the market, yet need not be. They don’t need crashworthiness because they don’t go fast, because of, well… more circular arguments.

As far as the controls go, the technology for dynamic speed control is really not an issue anymore. Thousands of calculations can be done in thousandths of a second and transmitted and received with similar speed, although some intrepid programmers need to step forward and write an open-source version of the control software. An example of a demonstrated system (That even works with truly antique computers and sensors) is the PATH program. Insofar as at least some of it was funded by taxpayer money, I sort of hoped that they would at least respond to my requests for the code they used, but, alas, I’m just a lowly blogger…Anyway, with variable speed, another of the factors holding back PRT from being a commuting tool will have fallen.

One note, however… There is the matter of controlling vehicles that run on simple pavement, like ULTra and 2getthere. There is definitely a slippery pavement issue when it comes to going fast for these guys. None of my arguments apply to them. They really do need to keep to routes appropriate to more limited speeds, at least for the time being.

There is the matter of motion sickness, but again, with dynamic speed control, cornering speed would be based on factors including what is comfortable. The individual could (theoretically) even specify the kind of ride they prefer. So the last of the arguments against commuter PRT has been answered. Well, sort of… There is the matter of where to go on the suburban end.

Another thing that has changed since PRT’s inception is the proliferation of “Park & Ride” systems. These are essentially parking lot/bus stops in the suburbs, which are sometimes used in combination with HOV (High Occupancy Vehicle) lanes. The commuter can take the bus or carpool to bypass the clogged freeways. These lots are ready-made outlying destinations for PRT. But why not just take the bus? Because if there is no HOV lane, the bus gets just as stuck in traffic as the rest of the commuters. If there IS an HOV lane, it too, will become clogged over time, when (in some cases) it will magically morph into a toll lane. (Funny how that happens!) Also, upon exiting the HOV lane, the bus cannot take passengers to all of their respective destinations efficiently. And HOV lanes are usually one-way. (reversible) The buses face ordinary traffic on the return trip. Anyway, these Park and Ride lots are generally on inexpensive land that is very close to the freeway and would be cheap to connect to. True, the passengers would have had to drive to these lots, but don’t forget, the downtown traffic comes from somewhere. Typically, the first part of a morning commute goes pretty fast. It is the last five miles or so where the traffic gets really bad. This is nipping it at the bud. Otherwise the ironic alternative might be that the traffic downtown is from people looking for a place to park so they could use the great PRT system! That is one aspect of “short-haul” PRT that has always puzzled me – What does it really save if the passengers have to commute in to use it? (But then again I live in a city where almost nobody lives downtown)

It was recently remarked that PRT needed a network to be effective, that a simple loop or straight line would be a waste. Whereas this is largely true, especially compared to a large network, it is should be pointed out that even on a two-way straight-line configuration travel time can be improved by PRT’s off-line stations, meaning you can go non-stop to your destination, and the fact that PRT is available on demand. This cuts travel time to a fraction of light rail and a fraction of a fraction of bus travel time. In the case limited routing outlined above, though, many passengers would undoubtedly still need further transportation. The Achilles heel of buses is the many stops they must make, both for passengers and for stoplights. But even a very simple PRT loop could eliminate a huge portion of this wasted time. Personally, I wouldn’t like taking a five-minute bus ride to finish my commute, but I would do it if I had already saved enough time getting to the downtown area in the first place. If the last part of the journey were to be taken from a downtown terminal, however, (where an express bus would drop you off) that last leg might be and agonizing 20 minutes instead. I guess I am suggesting a possible symbiotic relationship between the downtown and commuter legs of system.

Finally I want to point out that the cheapest configuration for routing on freeway medians would be actually be a bottom supported design like Skyweb Express, because it would be so easy to construct low-rise track. This is not all that different from the cost/structural dynamics that enabled the spread of traditional railroads. For example, such track could be supported with gravel instead of deeply anchored supports. It is hard to imagine such a configuration costing very much more than a million dollars per mile. In most cases the Park and Rides have structures in place that could be converted into the required elevated boarding areas. In defense of hanging systems, I think they would be much preferred for these very large parking lots since they could pretty much come to your car.

Amortizing a million dollar a mile track is much, much easier than the inner city routes on which it would depend. (OK, it would probably be more, but I like round numbers) Consider amortizing the track over 10 years, with 33 cents per mile going to this purpose. Payoff is 3 million trips, 300,000 per year, or 822 trips per day. That is 34 trips per hour (averaged over 24 hrs) or about one every two minutes. Obviously they are mostly during rush hour, but equally obvious is that Holy-Grail benchmarks like two-second headways probably need not be reached here. More to the point is that a comparable HOV lane costs 5 times as much, and also the size of the parking lot needs to be considered. This may not be PRT’s “killer app” but keeping that many cars out of city center in the first place certainly seems like a worthwhile goal.

Finally, to my friends in the U.S… Happy Independence Day! This is a time when we can all come together and enjoy the sights and sounds that result from the enormous, ultimate, instantaneous release of CO2! :o) Oh well, be Happy. It’s the 4th of July!