First: I will be speaking on robocars tomorrow, Tuesday Nov 9, at 6:30 pm for the meeting of the Jewish High Tech Community in Silicon Valley. The talk is at 6:30pm at the conference center of Fenwick and West at Castro & California in Mountain View. The public is welcome to attend, there is a $10 fee for non-members. This will be similar to my talk at Stanford 2 weeks ago, and a bit more extensive than the one in New York early in October, which Forbes said was the audience favorite at the event.
Volvo has built a brand around safe cars, and last year committed that nobody would die in a newer Volvo by 2020. They plan to do much of this with better passenger safety systems, akin to the work they have done on airbags and crumple zones. However, they also intend to use a lot of computerized technologies to make it happen. Other teams are pushing to expand the goal inside Volvo to also stop people from being killed by Volvos. To that end, next year’s Volvo S60 will come with a “Pedestrian Avoidance System” which uses a camera and machine vision to identify pedestrians and calculate if the vehicle is about to hit one. If it sees a potential pedestrian collision it will beep and alert the driver. If the driver does nothing, the car will brake.
Here is a video of the S60 in action:
It’s impressive, though pure machine vision suffers problems as lighting changes, which is one reason most work recently has been on LIDAR. It’s also interesting to see if they will be able to avoid making it too conservative. If the warning goes off all the time, even for a pedestrian who will (to the human eye) clearly slide by the side of the car at places like a crosswalk, drivers may learn to ignore the alarm, or get very annoyed and shut the whole system off it it brakes for them when they know an impact is not imminent. I’m hoping to learn more about Volvo’s efforts in the future. No other company has put as much effort into building a brand around safety, so we can expect Volvo, which has slipped in this status of late, to work very hard to maintain it and adapt robocar technologies to safer human driving and fully autonomous driving
Dense triple parking
I have written of a simple algorithm to allow dense Valet style parking of robocars, such as triple parking on the roadsides. In this algorithm, one gap is left in the outer lanes, and the Robocars are able to move together, as an entire row segment, to “move the gap” as quickly as a single car can move. That way, if a car needs to get out from an inner lane, it can signal, and if the gap is currently ahead of it, for example, all the cars from the one next to it to the gap can move forward one space (at the same time) to put the gap next to the vehicle that needs to leave. This can happen in all the other rows and is easy, quiet and efficient for electric cars. It does not even need radio communication, as robocars will sense a car moving behind them or ahead of them, and immediately move in reaction. This request will move up the chain of cars to the gap. Of course, if one car does not move, the car behind it will only move a very short distance before refusing to go further, which would stop the whole effort (or in the case of an error, cause a very slow impact if the car behind keeps coming) and signal a need for human attention.
It seems like this should be possible even without many gaps, as long as there is enough spare space to allow a vehicle to wiggle out of its space. If there is just one gap, and a bit of wiggle room in the other rows, any car can still get out, just a bit more slowly. This is probably better done with a protocol for communication to assure it works quickly.
In this case, a gap on the outside lane (where there must be at least one) can be temporarily moved to the inside, and then back out. Consider 3 lanes of cars, with a gap in the outer late (lane #3) and a car in lane #1 (the curb lane) wanting out. First the lane #3 cars would adjust to move the gap to the right place, a bit forward of our target car. Next, a car from lane #2 would move into this gap, leaving a gap in lane #2 into which our target car can move. This leaves a gap in lane #3 which can be filled by a car from lane #2 which is willing to move in, ideally right next to our target car. Likewise a car from lane #3 can now move into that gap, and the resulting gap in the outer lane #3 can be moved to allow exit by our target car.
This requires a great deal more car moving, though again with electric cars this may not be too expensive. If the cars can turn all their wheels, they can move horizontally as some concept cars can already do. Even without that, a robotic car can wiggle out without much room, and of course the gap would not be placed exactly in place with the target car, but probably slightly forward to allow transfer with fewer wiggles. The result is a whole valet lot with just one blank space needed to get any car reasonably quickly. Of course, this would only be done when the lot needed to be totally full. For any partially full lot, gaps would be left to minimize the car moves needed to get any car out. However, if space is at a premium — so much so as to justify the extra moving — it can be done.
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.
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.
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.)
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.)
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.
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 »
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 »
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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:
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: