110> Google's Robocars

First this note; I have recently been informed that this blog has twice triggered a virus alert for one reader. Has anyone other than this one reader had any malware alerts when visiting this site? I take this matter very seriously and have not been able to identify any malicious code. I have removed the “recent comments” feature from the sidebar, (again) since, in the Blogger forums, it has been suggested that such third-party “widgets” could be to blame, although no mention has been made of this (most popular) one specifically. Anyway, if you have received any alerts, please tell me about it, via email or the comments section. I am hoping it is a false alarm.

While I was out of touch last month, up at the cabin, an extraordinary thing happened that I just found out about. Apparently Google unveiled small fleet of driverless cars that had secretly logged 140 thousand miles of varied California driving with essentially no human assistance. It seems that the age of the Robocar is really here – at least as far as the science goes.

I am an unsuccessful contestant in a recent Google contest, which was about world-changing ideas. I can’t believe they picked the “Shweeb” concept over open-source, standards-based PRT. Now they have invested in Robocars. These people are no strangers to PRT, I just wish they would jump in with both feet. 

It seems to me that Google has “out-ULTra-ed” ULTra. After all, couldn’t Google’s modified Toyotas make the runs around Heathrow with ease? For that matter, it seems like they could just take you the rest of the way to your door. Back a few posts, I speculated that the real value proposition for a four-wheeled, pavement-driving designs like ULTra is really dualmode. Now it seems pretty clear that Google could clean their clock in that, and their present business too, if they wanted to.

In a way, my worst fears have come to pass. I believe that much (if not most) of the promise of PRT lies in the establishment of an alternative to roads, rather than making vehicles automatic. Regular roads are designed to carry huge loads, making them very expensive to elevate. Yet it is wildly inefficient to remain on the ground, where there are constant conflicts between people and cargo going different directions. There is also limited space. In most cities, well over 30% of the land is devoted to vehicles, either for roads or parking. This huge, paved landmass is an environmental nightmare, atmospherically, climatically, and hydrologically, not to mention a giant waste of very valuable real estate.

Because of the public’s resistance to having substantial overhead structures in front of their houses or businesses, it is essential for PRT track to have a minimalistic profile. This suggests something in the shape of a simple beam, and certainly not a wide, flat running surface, which would form an umbrella over the real estate below. (particularly at junctions)  Robocar makers may pay lip service to raised track, but practical realities say otherwise. Additionally, the removal of any way to “hook” into the track automatically makes travel in icy conditions something that just can’t be done at reasonable speeds.

With PRT being broadly defined to include four wheeled, steerable vehicles, advocates, (such as myself) are faced with the assumption, by many, that PRT is simply robocars on a designated roadway. This is defining PRT away from its original premise. Under the broadest definition the vehicles could even be gasoline powered. This is very, very far from the promise of PRT as envisioned by the early developers of such systems. No wonder people consider driverless cars as being an equally viable alternative to PRT. The PRT that they are familiar with has been stripped of most of its advantages. 

I just hope the good people at Google understand the unintended consequences that are inherent in their technology. Private driverless cars will encourage greater fuel consumption, because being free from driving will encourage other ways to pass the time, such as eating and drinking, watching TV, doing office work, etc. The resultant mobile office/living room will mean bigger, not smaller, vehicles. The comfortable and productive ride will encourage longer, not shorter commutes. It will encourage more pavement, not less.

Having robotic cars, especially with special lanes, may seem tantamount to a true PRT system to many, and this fact endangers PRT adoption. You can’t morph private cars on roads into PRT. PRT is meant to replace the need for more cars and roads. It is, at its core, efficient public transportation, which, in turn, encourages the building of truly efficient communities, leading to reduced environmental impact and greater prosperity.

Robocars will only help alleviate traffic, without cutting down on driving. It will make private car ownership even more desirable in emerging countries like India and China. This will eventually encourage even MORE driving and consequently MORE sprawl, just as faster highways have ended up doing across the U.S.  And mark my words, if they are privately owned, they will be BIG, powerful and very comfortable. I’ll take the camper!

109. Harnessing "Anti-Gravity" for PRT Control

Recently astute reader Ken MacLeod suggested that we consider certain computer-generated steering behaviors for merging PRT vehicles, and included this link.When I looked at them, (He specifically referred to the queuing example) I was first reminded of a thought I expressed in post 41, where I touched on the possibility of flocking or schooling behavior to help alleviate traffic, although I really didn’t know what it was called at the time. And so I responded by saying that the behaviors seemed more suited to traffic management. Now I get it, however.

Flocking (and the other related behaviors) is actually extremely relevant to PRT because of how it is generated. It is the interaction of imaginary gravity and antigravity between objects in motion. Specifically, it happens when there is very strong close-range anti-gravity and weaker, longer-range gravity. The gravity creates a group or “flock” and the antigravity keeps the “birds” from hitting each other. A favorite demonstration of this is “Boids,” which, as it sounds, supposedly came from the word “birds” combined from someone’s strong (New York area?) accent. In this example, the programmer periodically changes the parameters, (number of fish) leading to stronger schooling or flocking (gravity) forces. Anti-gravity is localized to the area immediately around each fish.

When we drive our cars there is a similar effect going on, except that it is highly linear. The anti-gravity part is dominant and stems from driver reluctance to follow a vehicle too closely. The closer you get, the faster and harder you are likely to apply the brake. When you follow at a safe distance, you are liable to maintain an equilibrium between braking and accelerating. When you see the gap getting larger, you are free to apply the gas petal, discounting other factors like speed limit. In auto traffic, there is no appreciable gravity effect, however, as there is no benefit to clumping cars together, (with the possible exception of convoys of speeders.)

Note that the “anti-gravity” at extremely close range (like actually touching) can be set to infinity. Therefore brakes are applied to maximum extent possible to avoid touching bumpers. In PRT, it seems that something similar is almost unavoidable. The question is whether collision avoidance through some kind of proximity sensors should be an add-on for redundancy or emergencies only, or integrated directly into the control processes.

As I mentioned in the beginning of this post, it has been suggested that such algorithms could be used in PRT for merging as well as headway control. In such a scenario a computer could consider where, in a line of vehicles, the merging vehicle would be expected to eventually fit, and then gradually apply more and more anti-gravity to that spot. Thus it is like a ghost vehicle slowly materializing and repelling the vehicles around it. It increases this short-range anti-gravity toward mathematical infinity until it has forced a space for the merging vehicle. This is an interesting approach because all decision-making can be localized to the vehicles involved. It also doesn’t need too much or particularly fast communications. Each vehicle simply responds to the proximity-induced repelling forces while trying to maintain forward speed.

One problem with this approach, however, is that it lacks intelligence in the choosing of where, in a line of vehicles, a merging vehicle should be placed. For example, what if a single merging vehicle is near the front of a group of 15 vehicles with plenty of space in front of the group. It seems like it shouldn’t split them up, but rather speed up and merge in front them, if there is time. At least it should delay as few vehicles as possible. But then again perhaps the anti-gravity could be set so that the group collectively repels the single car into such a choice. Or perhaps the group is self-dispersing, because the anti-gravity’s range is sufficient to “de-clump” the 15 vehicles in the first place.

In such a system there is no problem controlling traffic in the event that a section of the system becomes “over-booked.” The traffic would simply slow down. In an earlier post I outlined a control method based on precisely synchronized timing, where vehicles could “book” a split-second “reservation” to go through a merge point without conflict. The system begins with fuzzy time estimates at the point of departure, and but reschedules with more and more precision as the vehicle nears a merge-point and utilizes track markers to time itself.  Such a system has automatic traffic control; it can be set to never allow overbooking of a route. It becomes more problematic, however, as fast and heavy traffic pushes the limits of communications and reduces the margin for error. Perhaps the two methods can be combined. Thanks again, Ken. You’ve reminded me again that many heads are better than one!

108> Putting a Foot Down for PRT

Here is omething to think about…  As I have previously pointed out, because of the boom in highway projects started in the 50’s, cities in the U.S. tend to be spread out.  Instead of one central business district, there are usually many little ones.  To get people to leave the car at home is to get people to travel many miles without it, and there is no predictable direction of travel, just the likelihood that where they are going isn’t far from a freeway.  Therefore I have tried to accommodate this need with my designs.

Building PRT along freeways follows a different logic than many of the systems that are out there today.  It is like creating “worm-holes” between the more traditional routing schemes.  Naturally the structural requirements are different for both track and vehicles.

The track can be much cheaper as I will show.

Urban track must not be too visually imposing and must be routed to minimize distance between stations.  This generally means one-way.  There is also a lot of interference of all kinds in terms of track support placement.  This includes driveways, corners, underground utilities, telephone poles, signs, and traffic issues during construction.  Freeway following track, on the other hand, can have more frequently placed posts, which means shorter (less expensive) spans.  It can have two-way traffic supported by each post. There is less of the double track associated with stations and “Y” interchanges.  (With two-way traffic this necessitates up to four tracks, something that would create an unwanted umbrella effect, hence the general adoption of one-way urban designs.) 

Freeway following track represents a real chance to highlight one of the advantages of PRT, which is the limited weight of the vehicles.  Freeways must support 18 wheel trucks, and this sturdy construction is overkill for commuting purposes.   When a highway becomes congested, the call goes out to estimate the cost of another lane.  Each new lane is expected to absorb a certain number of cars for a certain number of dollars. PRT vehicles can be substituted for cars in this equation.  I recently read a Houston Metro study, which was an evaluation of a HOV lane running parallel to a section of I-10 (the main East-West interstate across the southern U.S.) The project was evaluated as a success primarily on the number of vehicles diverted from the main road.  As most of us know, one lane of PRT equals many lanes of ordinary highway.  It would be hard to make such a clear-cut case in a typical PRT route of convoluted loops.  Of course PRT vehicles are not free to the city, like cars, which are supplied by the commuters.  But autos are not revenue producers either, unless it is a toll road.  With PRT there is also no increase in traffic congestion on either end of the highway leg.  It may be a complicated cost-benefit analysis, but I think it’s less so than most of the other route proposals I have seen.  They generally look like nightmares of compromise and contentious litigation.

And so I have devoted some time to the problem and have come up with this.  In the picture above, the need for excavating has been eliminated by creating a support structure with a “foot.”  It occurred to me that the weight of concrete traffic dividers could be utilized along with a wide base to create a system that could be placed in the breakdown lanes.  Such a structure could not be made with just concrete and rebar because the edges must taper to nothing, so that vehicles’ tires can roll onto it freely.  Therefore there must be some clever integration of steel plate into the design. In addition to its shear weight, (about a ton per running foot) the base can be further immobilized by pinning it into holes drilled into the concrete.

Such track could be installed cheaply and rapidly by being pre-fabricated and trucked to the job site.  Sections of the concrete lane-divider would be interlocking or connected by steel splines, so that individual sections cannot be tipped or moved by impact.

Hopefully I will be able to figure out a realistic cost estimate in the near future, since estimating labor and materials appears to be a pretty straightforward job. I do not think I would go with the previously shown truss design, though, because it is for long spans, not cheap and easy construction. Anyway, my guess is that we will be pleasantly surprised.