Submitted by brad on Fri, 2009-10-30 14:39.
While giving a talk on robocars to a Stanford class on automative innovation on Wednesday, I outlined the growing problem of software recalls and how they might effect cars. If a company discovers a safety problem in a car’s software, it may be advised by its lawyers to shut down or cripple the cars by remote command until a fix is available. Sebastian Thrun, who had invited me to address this class, felt this could be dealt with through the ability to remotely patch the software.
This brings up an issue I have written about before — the giant dangers of automatic software updates. Automatic software updates are a huge security hole in today’s computer systems. On typical home computers, there are now many packages that do automatic updates. Due to the lack of security in these OSs, a variety of companies have been “given the keys” to full administrative access on the millions of computers which run their auto-updater. Companies which go to all sorts of lengths to secure their computers and networks are routinely granting all these software companies top level access (ie. the ability to run arbitrary code on demand) without thinking about it. Most of these software companies are good and would never abuse this, but this doesn’t mean that they don’t have employees who can’t be bribed or suborned, or security holes in their own networks which would let an attacker in to make a malicious update which is automatically sent out.
I once asked the man who ran the server room where the servers for Pointcast (the first big auto-updating application) were housed, how many fingers somebody would need to break to get into his server room. “They would not have to break any. Any physical threat and they would probably get in,” I heard. This is not unusual, and often there are ways in needing far less than this.
So now let’s consider software systems which control our safety. We are trusting our safety to computers more and more these days. Every elevator or airplane has a computer which could kill us if maliciously programmed. More and more cars have them, and more will over time, long before we ride in robocars. All around the world are electric devices with computer controls which could, if programmed maliciously, probably overload and start many fires, too. Of course, voting machines with malicious programs could even elect the wrong candidates and start baseless wars. (Not that I’m saying this has happened, just that it could.)
However these systems do not have automatic update. The temptation for automatic update will become strong over time, both because it is cheap and it allows the ability to fix safety problems, and we like that for critical systems. While the internal software systems of a robocar would not be connected to the internet in a traditional way, they might be programmed to, every so often, request and accept certified updates to their firmware from the components of the car’s computer systems which are connected to the net.
Imagine a big car company with 20 million robocars on the road, and an automatic software update facility. This would allow a malicious person, if they could suborn that automatic update ability, to load in nasty software which could kill tens of millions. Not just the people riding in the robocars would be affected, because the malicious software could command idle cars to start moving and hit other cars or run down pedestrians. It would be a catastrophe of grand proportions, greater than a major epidemic or multiple nuclear bombs. That’s no small statement.
There are steps that can be taken to limit this. Software updates should be digitally signed, and they should be signed by multiple independent parties. This stops any one of the official parties from being suborned (either by being a mole, or being tortured, or having a child kidnapped, etc.) to send out an update. But it doesn’t stop the fact that the 5 executives who have to sign an update will still be trusting the programming team to have delivered them a safe update. Assuring that requires a major code review of every new update, by a team that carefully examines all source changes and compiles the source themselves. Right now this just isn’t common practice.
However, it gets worse than this. An attacker can also suborn the development tools, such as the C compilers and linkers which build the final binaries. The source might be clean, but few companies keep perfect security on all their tools. Doing so requires that all the tool vendors have a similar attention to security in all their releases. And on all the tools they use.
One has to ask if this is even possible. Can such a level of security be maintained on all the components, enough to stop a terrorist programmer or a foreign government from inserting a trojan into a tool used by a compiler vendor who then sends certified compilers to the developers of safety-critical software such as robocars? Can every machine on every network at every tool vendor be kept safe from this?
We will try but the answer is probably not. As such, one result may be that automatic updates are a bad idea. If updates spread more slowly, with the individual participation of each machine owner, it gives more time to spot malicious code. It doesn’t mean that malicious code can’t be spread, as individual owners who install updates certainly won’t be checking everything they approve. But it can stop the instantaneous spread, and give a chance to find logic bombs set to go off later.
Normally we don’t want to go overboard worrying about “movie plot” threats like these. But when a single person can kill tens of millions because of a software administration practice, it starts to be worthy of notice.
Submitted by brad on Mon, 2009-10-26 14:42.
Saturday saw the dedication of a new autonomous vehicle research center at Stanford, sponsored by Volkswagen. VW provided the hardware for Stanley and Junior, which came 1st and 2nd in the 2nd and 3rd Darpa Grand Challenges, and Junior was on display at the event, driving through the parking lot and along the Stanford streets, then parking itself to a cheering crowd.
Junior continues to be a testing platform with its nice array of sensors and computers, though the driving it did on Saturday was largely done with the Velodyne LIDAR that spins on top of it, and an internal map of the geometry of the streets at Stanford.
New and interesting was a demonstration of the “Valet Parking” mode of a new test vehicle, for now just called Junior 3. What’s interesting about J3 is that it is almost entirely stock. All that is added are two lower-cost LIDAR sensors on the rear fenders. It also has a camera at the rear-view mirror (which is stock in cars with night-assist mode) and a few radar sensors used in the fixed-distance cruise control system. J3 is otherwise a Passat. Well, the trunk is filled with computers, but there is no reason what it does could not be done with a hidden embedded computer.
What it does is valet park itself. This is an earlier than expected implementation of one of the steps I outlined in the roadmap to Robocars as robo-valet parking. J3 relies on the fact the “valet” lot is empty of everything but cars and pillars. Its sensors are not good enough to deal well with random civilians, so this technology would only work in an enclosed lot where only employees enter the lot if needed. To use it, the driver brings the car to an entrance marked by 4 spots on the ground the car can see. Then the driver leaves and the car takes over. In this case, it has a map of the garage in its computer, but it could also download that on arrival in a parking lot. Using the map, and just the odometer, it is able to cruise the lanes of the parking lot, looking for an empty spot, which it sees using the radar. (Big metal cars of course show clearly on the radar.) It then drives into the spot.
read more »
Submitted by brad on Wed, 2009-10-21 17:31.
Some time ago I proposed the “School of Fish Test” as a sort of turing test for robocars. In addition to being a test for the cars, it is also intended to be a way to demonstrate to the public when the vehicles have reached a certain level of safety. (In the test, a swarm of robocars moves ona track, and a skeptic in a sportscar is unable to hit one no matter what they do, like a diver trying to touch fish when swimming through a school.)
I was interested to read this month that Nissan has built test cars based on fish-derived algorithms as part of a series of experiments based on observing how animals swarm. (I presume this is coincidental, and the Nissan team did not know of my proposed test.)
The Nissan work (building on earlier work on bees) is based upon a swarm of robots which cooperate. The biggest test involves combining cooperating robots, non-cooperating robots and (mostly non-cooperating) human drivers, cyclists and pedestrians. Since the first robocars on the road will be alone, it is necessary to develop fully safe systems that do not depend on any cooperation with other cars. It can of course be useful to communicate with other cars, determine how much you trust them, and then cooperate with them, but this is something that can only be exploited later rather than sooner. In particular, while many people propose to me that building convoys of cars which draft one another is a good initial application of robotics (and indeed you can already get cars with cruise control that follows at a fixed distance) the problem is not just one of critical mass. A safety failure among cooperating cars runs the risk of causing a multi-car collision, with possible multiple injured parties, and this is a risk that should not be taken in early deployments of the technology.
My talk at the Singularity Summit on robocars was quite well received. Many were glad to see a talk on more near-future modest AI after a number of talks on full human level AI, while others wanted only the latter. A few questions raised some interesting issues:
- One person asked about the insurance and car repair industries. I got a big laugh by saying, “fuck ‘em.” While I am not actually that mean spirited about it, and I understand why some would react negatively to trends which will obsolete their industries, we can’t really be that backwards-looking.
- Another wondered if, after children discover that they nice cars will never hit them, they then travel to less safe roads without having learned proper safety instincts. This is a valid point, though I have already worried about what to do about the disruption to passengers who have to swerve around kids who play in the streets when it is not so clearly dangerous. Certain types of jaywalking that interfere with traffic will need to be discouraged or punished, though safe jaywalking, when no car is near, should be allowed and even encouraged.
- One woman asked if we might become disassociated with our environments if we spend our time in cars reading or chatting, never looking out. This is already true in a taxicab city like New York, though only limos offer face-to-face chat. I think the ability to read or work instead of focus on the road is mostly a feature and not a bug, but she does have a point. Still, we get even more divorced from the environment on things like subways.
As expected, the New York audience, unlike other U.S. audiences, saw no problem with giving up driving. Everywhere else I go, people swear that Americans love their cars and love driving and will never give it up. While some do feel that way, it’s obviously not a permanent condition.
Some other (non-transportation) observations from Singularity Summit are forthcoming.
BTW, I will be giving a Robocar talk next Wednesday, Oct 28 at Stanford University for the ME302 - Future of the Automobile class. (This is open to the general Stanford community, affiliates of their CARS institute, and a small number of the public. You can email firstname.lastname@example.org if you would like to go.)
Submitted by brad on Wed, 2009-10-14 14:30.
This press release describes a European research project on various intelligent vehicle technologies which will take place next year. As I outline in the roadmap a number of pre-robocar technologies are making their way into regular cars, so they can be sold as safer and more convenient. This project will actively collect data to learn about and improve the systems.
Today’s systems are fairly simple of course, and will learn a lot from this. This matches my prediction for how a robocar test suite will be developed, by gathering millions and later billions of miles of sample data including all accidents and anomalous events, over time with better and better sensors. Today’s sensors are very simple of course but this will change over time.
Initial reaction to these systems (which will have early flaws) may colour user opinion of them. For example, some adaptive cruise controls reportedly are too eager to decide there is a stopped car and will suddenly stop a vehicle. One of the challenges of automatic vehicle design will be finding ways to keep it safe without it being too conservative because real drivers are not very conservative. (They are also not very safe, but this defines the standards people expect.)
Submitted by brad on Mon, 2009-09-21 14:40.
Two events I will be at…
Tonight, at 111 Minna Gallery in San Francisco, we at EFF will be hosting a reading by Randall Monroe, creator of the popular nerd comic “xkcd.” There is a regular ticket ($30) and a VIP reception ticket ($100) and just a few are still available. Payments are contributions to the EFF.
In two weeks, on Oct 3-4, I will be speaking on the future of robot cars at the Singularity Summit in New York City. Lots of other good speakers on the podium too.
See you there…
Submitted by brad on Wed, 2009-07-08 15:29.
I have mostly written about 3 and 4 wheeled Robocars, even when the vehicles are narrow and light. Having 3 or 4 wheels of course means stability when stopped or slow, but I have also been concerned that even riding a 2 wheeled vehicle like a motorcycle requires a lot of rider participation. It is necessary to lean into turns. It’s disconcerting being the stoker on a tandem bicycle or the passenger on a motorcycle, compared to being a car passenger. You certainly don’t imagine yourself reading a book in such situations.
On the other hand 3/4 wheeled vehicles have their disadvantages. They must have a wide enough wheelbase to be stable because they can’t easiliy lean. In addition, for full stability you want to keep their center of gravity as low as you can. The extra width means a lot more drag, unless you have a design like the Aptera Motors entrant in the Progressive 100mpg X-prize, which puts the wheels out to the sides.
I recently met Chris Tacklind, who has a design-stage startup called Twill Tech. They have not produced a vehicle yet, but their concepts are quite interesting. Their planned vehicle, the Twill, has two wheels but uses computer control to allow it to stay stable when stopped. It does this by slight motions of the wheels, the same way that pro cyclists will do a track stand. They believe they can make a 2 wheeled electric motorcycle that can use this technique to stay stable when stopped, though it would need to extend extra legs when parked.
This is intended to be an enclosed vehicle, both for rider comfort and lower drag. The seat is very different from a motorcycle seat, in that you do not sit astride the vehicle, but in a chair similar to a spacecraft’s zero-G chair.
In addition, the vehicle is designed to have the rear wheel on a lever arm so that it can stand almost upright when stopped and then slope down low, with the rider reclined, at higher speeds. The reclined position is necessary for decent drag numbers at speed — the upright human creates a lot of the drag in a bicycle or motorcycle. However, the upright position when slow or stopped allows for much easier entry and exit of the vehicle. As everybody knows, really low cars are harder to get in and out of. Twill is not the first company to propose a vehicle which rises and lowers. For example the MIT CityCar plan proposes this so the vehicles can stack for parking. Even without stacking, such designs can park in a much smaller space. read more »
Submitted by brad on Tue, 2009-05-26 16:23.
One of the questions raised by the numbers which show that U.S. transit does not compete well on energy-efficiency was how transit can fare so poorly. Our intuition, as well as what we are taught, makes us feel that a shared vehicle must be more efficient than a private vehicle. And indeed a well-shared vehicle certainly is better than a solo driver in one of todays oversized cars and light trucks.
But this is a consequence of many factors, and surprisingly, shared transportation is not an inherent winner. Let’s consider why.
We have tended to build our transit on large, heavy vehicles. This is necessary to have large capacities at rush hour, and to use fewer drivers. But a transit system must serve the public at all times if it is to be effectively. If you ride the transit, you need to know you can get back, and at other than rush hour, without a hugely long wait. The right answer would be to use big vehicles at rush hour and small ones in the off-peak hours, but no transit agency is willing to pay for multiple sets of vehicles. The right answer is to use half-size vehicles twice as often, but again, no agency wants to pay for this or to double the number of drivers. It’s not a cost-effective use of capital or the operating budget, they judge.
The urban vehicle of the future, as I predict it, is a small, one-person vehicle which resembles a modern electric tricycle with fiberglass shell. It will be fancier than that, with nicer seat, better suspension and other amenities, but chances are it only has to weigh very little. Quite possibly it will weigh less than the passenger — 100 to 200lbs.
Transit vehicles weigh a lot. A city bus comes in around 30,000 lbs. At its average load of 9 passengers, that’s over 3,000lbs of bus per passenger. Even full-up with 60 people (standing room) it’s 500lbs per passenger — better than a modern car with its average of 1.5 people, but still much worse than the ultralight. read more »
Submitted by brad on Thu, 2009-02-05 15:36.
Here’s a short new robocar essay, on Robocars helping bring about flying cars.
The thesis of the essay is simple. The quest for flying cars has always had to deal with the very difficult compromise between a vehicle that flies and one that drives. It’s just really hard to make one vehicle to do both.
The robocar (or rather robotaxi) solution is to not try to do both in one vehicle, but adapt to the idea you can hire a robotaxi to zip you right to your plane, and another one will be waiting on the taxiway when you land for a quick transition. It’s not the “take off from your house” vision, though. Of course, independently, the planes themselves could become computer-flown, as is almost the case today. If this happened, and the planes were able to do short takeoff and landing, and do it quietly (perhaps hybrid engines which use battery just for takeoff and landing) the world might accomodate airstrips in much more convenient places, even old stretches of road that don’t have overhead wires.
And don’t forget, I’ll be giving a robocar talk at BIL in Long Beach this weekend.
Submitted by brad on Wed, 2009-01-28 15:13.
Here’s a nice story about the Kiva warehouse delivery robot now being used by major retailers like The Gap. Factory floor robots have been around for some time, and the field even has a name “automated vehicle guidance systems” but these newer deliverbots kick it up a notch, picking up shelves and bringing them to a central area for distribution, finding their way on their own with sensors.
We’re also seeing more hospital deliverbots, which — very slowly — take things around hospitals, roving the same corridors as the people. When a robot goes very slowly, people are willing to allow it to travel with them. The technological question is, how hard it is it to raise that speed and stay safe, and make people believe that they are safe.
Some applications care little about speed, and the slow robots already have a market there. We would not tolerate super slow robots on our streets, getting in the way of our cars, regularly.
One answer may be “extremely deferential” behaviour. Consider a deliverbot trundling down a low-volume street at 10 kph (6mph). It would be constantly checking for a vehicle coming up behind it, using radar, lasers and cameras. With LIDAR it would get about 90 meters of warning, with other sensors perhaps more. Say it detects a car coming behind it at 50 km/h (30mph). It has 8 seconds, during which it will will cover 22 meters. If it’s a small robot — and we might limit the robots to make them small — odds are reasonable that it might find a place in which to duck, such as a driveway. These robots aren’t parking, so they can move into driveway entrances, fire hydrant locations and many small non-parking spaces along the road.
Indeed, it need not find a place to pause on its own side of the road. If there is no immediate oncoming traffic, it could deek to the other side of the road for a hiding spot. Ideally it would be clever and not pick a driveway which has a moving car or even a car sensors reveal has the engine running.
Indeed, it’s not unreasonable for the deliverbot to simply move into the oncoming lane if it is clear, to let the human vehicle pass. This is a bit disconcerting to our usual sense of how things work — slow vehicles don’t move to the left for us to pass them — but there is no reason it could not be true. This is on urban streets where stopped vehicles, turning vehicles and even pedestrians are found in the middle of the street all the time, and drivers have plenty of time to stop for them. Nobody is going to hit such a vehicle, just get annoyed by it.
For the driver, they would see various slow deliverbots on the road ahead. But in all but unusual circumstances, by the time they got close to those robots, they would have pulled out of the lane, to pause in driveway entrances. The main risk is the driver might start to depend on this, and plow right into such a vehicle (at slow speeds) if there was no place for it to pull over. A deliverbot that doesn’t immediately see a place to pull over would probably start blinking a very obvious flashing light on the back, increasing the warnings if the vehicle does not slow down. It might also speed up a little bit, if safe to do so, to reach a spot to pause.
Why is this interesting? I think we’re much closer to building a vehicle that could go 10 kph on slow city streets, using LIDAR. If the vehicle is small and doesn’t weigh a great deal, it simply won’t be capable of doing much damage to people by hitting them. It could even be equipped with airbags on the outside should this ever become unavoidable. The main problems would be people hitting them, or being annoyed by them.
Once accepted, as safety technology improves, the speed can improve — eventually to a level where they don’t get in the way, other than in the sense that any other vehicle is in your way. There will always be those who want to go faster, and so the deference approach will always be useful.
Submitted by brad on Mon, 2009-01-05 22:37.
I’ve added a new concept to the notes section — the Robo Snow Plow. In the article I describe the value of plows that can patrol the roads frequently without need for staff. Since you don’t want to delay for recharging, these might be fuel-tank powered.
However, another interesting concept is offered, namely the repurposing of idle vehicles as temporary plows. The call would go out, and idle vehicles would travel to a depot where a plow or snowblower would be placed on them. Then they would go out and plow and clear light covers of snow. When done, or when needed shortly by their owner, they would return to a depot and drop off the plow unit.
Ordinary cars would be light and not able to plow heavy snow, but there are so many idle cars that you could get to all the streets before things got too heavy. If you didn’t, you would need to assign heavier vehicles and real plows to those areas. And everybody’s driveways would be kept clear by robot snow blowers too. Cars on the roads would give real-time reports of where snow is falling and how thick it’s getting. Cities might be able to clear all their streets, sidewalks and driveways without needing extra vehicles.
Submitted by brad on Thu, 2009-01-01 12:47.
I’ll be giving a talk on Robocars on Friday, January 16th at the Bay Area Future Salon which is hosted at SAP, 3410 Hillview, Building D, Palo Alto CA. Follow the link for more details and RSVP information. Reception at 6, talks at 7. Eric Boyd will also talk on efficiency of transportation.
While I gave an early version of the Robocar talk at BIL (the unconference that parallels TED) last year, I think I will do an update there as well, along with a talk on the evils of cloud computing.
Submitted by brad on Wed, 2008-11-19 23:35.
I gave a few visits to the RoboDeveloper’s conference the past few days. It was a modest sized affair, one of the early attempts to make a commercial robot development conference (it’s been more common to be academic in the past.) The show floor was modest, with just 3 short aisles, and the program modest as well, but Robocars were an expanding theme.
Sebastian Thrun (of the Stanford “Stanley” and “Junior” Darpa Grand Challenge teams) gave the keynote. I’ve seen him talk before but his talk is getting better. Of course he knows just about everything in my essays without having to read them. He continues (as I do) to put a focus on the death toll from human driving, and is starting to add an energy plank to the platform.
While he and I believe Robocars are the near-term computer project with the greatest benefit, the next speaker, Maja Mataric of USC made an argument that human-assistance robots will be even bigger. They are the other credible contender, though the focus is different. Robocars will save a million young people from death who would have been killed by human driving. Assist robots will improve and prolong the lives of many millions more of the aged who would die from ordinary decrepitude. (Of course, if we improve anti-aging drugs that might change.) Both are extremely worthy projects not getting enough attention.
Mataric said that while people in Robotics have been declaring “now is the hot time” for almost 50 years, she thinks this time she really means it. Paul Saffo, last weekend at Convergence 08, declared the same thing. He thinks the knee of the Robotics “S Curve” is truly upon us.
On the show floor, and demonstrated in a talk by Bruce Hall (of Velodyne Lidar and of Team DAD in the Darpa Grand Challenges) was Velodyne’s 64 line high resolution LIDAR. This sensor was on almost all the finishers in the Urban Challenge.
While very expensive today ($75,000) Hall believes that if he had an order for 10 million it would cost only hundreds without any great advances. With a bit of Moore’s law tech, it could even be less in short order.
Their LIDAR sees out to 120 meters. Hall says it could be tuned to go almost 300 meters, though of course resolution gets low out there. But even 120 meters gives you the ability to stop (on dry road) at up to 80 mph. Of course you need a bit of time to examine a potential obstacle before you hit the brakes so hard, so the more range the better, but this sensor is able to deliver with today’s technology.
The LIDAR uses a class 1 (eye-safe) infrared laser and Hall says it works in any amount of sunlight, and of course in darkness. He also says having many together on the road does not present a problem and did not at the Urban Challenge when cars came together. It might require something fancier to avoid deliberate jamming or interference. I suspect the military will pay for that technology to be developed.
This LIDAR, at a lower cost, seems good enough for a Whistlecar today, combined, perhaps with tele-valet remote operation. The LIDAR is good enough to drive at modest urban speeds (25mph) and not hit anything that isn’t trying to hit you. A tele-valet could get the whistlecar out of jams as it moves to drivers, filling stations and parking spots.
These forecasts of cheap, long-range LIDAR make me very optimistic about Whistlecars if we can get them approved for use in limited areas, notably parking lots, airports, gated communities and the like. We may be able to deploy this even sooner than some expect.
Submitted by brad on Tue, 2008-10-14 17:02.
This week, as part of a 3-part series on the future of driving, ARS Technica has written a feature article derived from, and covering my series on Robocars. While it covers less than I do here, it does present it from a different perspective that you may find of interest.
Due to their large audience, there is also a stream of comments. Frankly, most indicate that the commenter has not read my underlying articles and my FAQ section, but one commenter did bring up something interesting that I have incorporated into my section on Freedom.
Their point was this: Today, the police use traffic laws as a way to diminish the rule of law. Everybody violates traffic laws regularly, so the police can always find an excuse to pull over a vehicle that they wish to pull over for other reasons. In essence, this ability has seriously eroded our privacy and freedom while we travel on the roads. Generally, robocars would never offer the police an excuse to detain any random driver. They would have to observe something inside the vehicle, perhaps, in order to have the probable cause needed to stop it. It would be more akin to being in your house. Of course, the police can often still find a way if they try hard enough, but this should make that task a great deal harder.
This does not mean that robocars still don’t present lots of privacy and freedom risks. We must work to avoid those. But this is an upside I hadn’t thought of.
There are also a lot of diggs on the Technica article, with their own comments, even more removed from my base articles, which never got too many diggs on their own.
If you didn’t see it, back a few months ago, the series was also featured on slashdot with a lively thread.
Submitted by brad on Thu, 2008-10-02 20:36.
I’ve added a new Robocars article, this time expanding on ideas about how parking works in the world of robocars. The main conclusion is that parking ceases to be an issue, even in fairly parking sparse cities, because robocars can do so many things to increase, and balance capaacity.
One new idea detailed (inspired by some comments in another post) is an approach for both valet parking and multi-row triple-parked street parking. This algorithm takes advantage of the fact that all the robocars in a row can be asked to move in concert, thus moving a “gap” left in any line to the right space in just a few seconds. Thus if there is just one gap per row, any car can leave the dense parking area in seconds, even from deep inside, as the other cars move to create a gap for that car to leave.
But there are many more ideas of how parking just should not be an issue in a robocar world. That is, until people realize that, and we start converting parking lots to other uses because we don’t need them. Eventually the market will find a balance.
Read Parking and Robocars.
Submitted by brad on Thu, 2008-09-25 14:00.
Readers of this blog will know I used to talk a bit about Personal Rapid Transit (PRT) but have switched to a belief that it is now likely that robocars might fulfill the PRT vision before actual PRT can. To understand that, it is necessary to explore just why PRT has never really come about, in spite of being promoted, and possible for almost 40 years. The Morgantown Personal Rapid Transit has run since 1975, though it uses large vehicles and only has 5 stations, so it doesn’t realize the PRT vision of personal cars that go point to point in a network of stations. The ULTra system, with personal cars (which run on tires in a simple track) is being built at Heathrow airport.
I wrote an article on the reasons I have rejected classical, track-based PRT and then opened discussion on it in the Google transport-innovators group. The thread was quite vigourous. I had expected PRT fans to not welcome the concept, and to believe that robocars are still very distant science fiction, for indeed that is a valid objection.
I had not expected such a love of the general concept of shared transit that I would see people arguing that even if robocars were arriving soon, it would still be better to fill our streets with custom elevated guideways for a PRT system. Indeed, some advanced that we should not be building roads at all, that people would give up entirely on vehicle ownership in a PRT or robocar world and that providing garage to garage (or door to door) service was not necessary in the U.S. market, or could easily be done by just running PRT tracks to every house.
I understand the frustration in the PRT world. The ideas make a lot of sense, but no city will buy them. I contend that’s because municipal transit planners are highly averse to innovation. They are happy to buy 100 year old technology for their cities. They think farecards and web sites that can tell you when a bus will get to your stop are space-age innovations. Nobody wants to be the planner who bet on an untested technology that failed. That’s a career-ending risk. They would rather bet on old technology, and in spite of how well it is understood, see it go 100%, 200% or more over budget.
I predict that, once the technology becomes more real, robocars will win because they will be built bottom-up on a simple, already existing platform (roads) without any requirements to build infrastructure or run it. They will be bought by individuals, in particular by early adopters. Early adopters have money to burn on the latest hot new toys. They will happily waste it and buy the cooler model 8 months later. Cities don’t buy this way, they can’t. Cities buy technology that’s already obsolete before they even put it out for bid, and it’s very obsolete a decade later when it goes into operation.
Worse, transit requires monopolies. Either the city runs the transit as a monopoly, or it grants a franchise to a private company to build and run it. (That’s far more rare, since most transit runs with heavy subsidies in the USA.) Monopolies mean corruption (as they get large, they end up having more influence on the city officials than the customers do) and they mean monopoly-style customer service.
While robocars are still over a decade away, I fear that even though PRT could be built today, it will take it a decade to get over the marketing humps it has not managed to overcome in 40 years. By that time, robocars should be much closer to reality, and we’ll reach a point where even a transportation planner will realize the robocars will arrive soon enough to affect transit planning in the present.
Rather than being viewed as the enemy, robocars should be viewed as a way to realize the PRT vision without those deal-blocking new infrastructure requirements. But the PRT community is not yet ready to agree.
Read Robocars and PRT
Submitted by brad on Mon, 2008-06-23 15:01.
This special chapter in my series of essays on Robocars describes a fictional week in the Robocar world, with many created examples of how people might use Robocars and how their lives might change.
If you haven’t been following my essay on Robocars, this may be a good alternate entry to it. In a succinct way, it plays out many of the technologies I think are possible, more about the what than the how and why.
A Week of Robocar Stories
This ends this week-long series of postings on the Robocar essays. Though I have some new sidebars
already written which I will introduce later. I realize this set of essays has been more longer than one typically sees in the short-attention-span blogosphere, but I think these ideas are among the more important and world-changing I’ve covered. I hope I’ll see more comments from the readers as you get more deeply into it.
Submitted by brad on Mon, 2008-06-23 14:57.
You may have seen in earlier blog posts my discussion of the energy efficiency of U.S. transit. I started that investigation because as I learned how inefficient most transit systems are (due to light loads outside of rush hour,) I realized that ultralight electric cars, enabled by Robocars, are more efficient than any transit system. Who would take transit if a fast, comfortable, efficient vehicle will take you directly from A to B? This drives chapter eight, about:
The end of urban mass transit
(This one gets the people who think they love transit, rather than loving efficient transportation, in a tizzy.)
Submitted by brad on Mon, 2008-06-23 14:53.
For part seven of my series on Robocars, I now consider the adjunct technology I am calling Deliverbots — namely robot driven trucks and delivery vehicles, with no people inside. These turn out to have special consequences of their own. Read:
Submitted by brad on Mon, 2008-06-23 14:50.
For part six of my series on Robocars, consider:
When can robocars happen?
I discuss what predictions we can make about how long the Robocar future will take. While there are many technological challenges, the biggest barriers may be political, and even harder to predict.
We don’t seem to have the Jetson’s flying cars yet. What goes wrong with these predictions, and can we figure it out?
Submitted by brad on Mon, 2008-06-23 14:47.
For part five of my series on Robocars, it’s time to understand how this is not simply a utopian future. Consider now:
The Downsides of Robocars
Every good technology has unintended consequences and downsides. Here I outline a few, but there will be more than nobody sees today. I still judge the immense upsides to be worth it, but you can judge yourself.