Here’s a nice graphic showing traffic deaths around the world. Of course, all these numbers are going to drop over the next 10 years thanks to various collision avoidance and accident survival technologies in cars, and eventually, we hope, robocars.
I was recently approached by a programmer named Keith Curtis, formerly at Microsoft and now a FOSS devotee. He wants to develop a driving simulator for testing robocar systems. I think this is a very worthwhile idea — sort of a “Second Life” for robots. We have a head start — the world of racecar video games has already done a lot of the legwork to simulate driving, and there are two open source car racing systems.
A good simulator would bring some tremendous benefits to robocar development.
- Anybody, even a solo hacker in their basement, could develop and test robocar software on the cheap, and with no cost and risk from crashes. Small teams, perhaps working in car-less garages, could contribute greatly to the field.
- Testing could go faster, and include regular exposure to extreme situations not often found in the real world, like crazy drivers, strange hazards, map errors, sensor failures and more.
- Simulator testing allows the creation of new sensors which are plausible, but too expensive or too far in the future to work with in the real world. It allows teams to say, “What if we had 1cm accurate GPS? What if we had 180 line LIDAR to 100m?” and see if they can build robocar controls to use it.
- Robocar contests could be held in simulation, on the cheap and with no physical risk. The winners could then get funding to build real-world vehicles to race for a bigger prize.
- The simulator APIs for car controls and sensors can become prototype APIs for real-world interfaces, allowing easy testing and switching.
Of course, robocar simulation is nothing new. Several teams in the DARPA challenges built simulators to try out ideas. These remained proprietary efforts. Road simulation is also frequently used for traffic simulators. An open simulator would be shared, and the community (and not just the robocar development community) could contribute terrain, streets, sensors and simulators for elements such as pedestrians, human driven cars, blowing trash and new sensors, to name just a few.
Our wonderful new fast GPUs will be able to generate camera views anywhere in the 3D world for those working on machine vision. Simulating LIDAR, radar, ultrasound, odometry, accelerometers etc. is not yet done in car racing games but these things should not be hard to add. Indeed, any company selling a sensor would be well advised to build a simulated version of it. And people hacking at home love to make 3-D maps of terrain. Existing real terrain models could be imported, or new ones made by driving around with LIDAR on real streets.
To explore this more I have written a new article on how to build a robocar driving simulator where I also point to an up and coming open source simulator called “Rigs of Rods” which actually simulates the vehicles at the physics level, treating them as a network of many connected parts.
The robocar world needs somebody ready to fun the kick-starting of such a simulator, and possibly some contests within it.
Tomorrow, I will be speaking on pre-Robocar technology at BIL an unconference that parallels the famous and expensive TED conference. This is in Long Beach, CA. Unconferences are fun, cheap and often as good as expensive conferences. I will also be attending a reception at TED tonight for Singularity University, which I lecture at, so I may see you if you’re at TED as well.
Last night’s EFF bash was a great success. Thanks to Adam Savage and all the others who made it go so well.
This weekend is the Foresight Institute conference on molecular nanotechnology and AI. I am on the board of Foresight Institute and will be speaking on the latest developments in robocars at the conference, along with a raft of great speakers. If you are interested in futurist issues around AI, nanotech and other accelerating technologies, this is the longest running conference in the field and the place to be. The whole conference is just $175 and you can register for it here.
I will also be doing my general Robocar talk on Wednesday, February 24th at the “Homebrew Robotics Club” of Silicon Valley. This is a great group of people who hack robotics as a hobby, and it meets at the CMU building at NASA Ames Research Center. This event is free and open to the public.
Finally, in 2 weeks I will be attending the DLD 10 conference in Munich Germany, and may try to make my way into some parties at the World Economic Forum in Davos while doing a little Alpine road trip after DLD.
Note for those who can’t attend the Foresight conference, you can watch it stream live
You may have seen it already but it’s amusing to watch this encoding of a 1958 Disney show on the highway of the future:
This highway features a mixture of human driven cars, robocars and PRT style robocars on private guideways. Much of it is typical of ancient predictions of the future, with an expectation of remarkably cheap and strong materials and portable atomic power, but some of it is on the mark (like urban sprawl.) The roles of mom and dad don’t change in 50 years. It is always humbling to go back into the past and see how futurists have got it wrong, and wonder where you are going wrong in your own predictions. (I’ve learned you should never predict dates for things because while you might have a sense about how long it would take to develop the technology, you can’t as easily predict how markets and governments will react.)
However, I will be prognosticating again next week, giving my Robocar talk in the Google “Tech Talk” series at Google HQ in Mountain View on Dec 14 at 11am. While not generally open to the public, I can bring in guests if they all come in at around 10:30am. Contact me if this is of interest. They will put the talk up on Google Video when done. Of course, if you are a Googler, I hope to see you there.
It’s amusing to note that many of the vision seen in the movie “Minority Report” are found in this Disney video from much earlier.
I struck a nerve several years ago when I blogged about the horrible beep-beep noise made by heavy equipment when it backs up. Eventually a British company came up with a solution: a pulsed burst of white noise which is very evident when you are near the backing up vehicle but which disperses quickly so it doesn’t travel and annoy people a mile away as the beeps do.
Now I am seeing more and more suggestions that electric cars, which run quite silently when slow, make some noise for safety. This is fine, but there are also suggestions that there will be music and vanity noises, like ringtones or “cartones.” I can certainly see why this would appeal to people. (Already many think that their car is the place to play mind-numbing bass to announce musical taste to all others on the street.) There are even proposed laws.
While the cartones would be quieter than the backup beep or the heavy bass, I really fear that people will overdo what they think is the purpose — being attention grabbing. They will want to distract, and that will create a cacophony on the roads. It’s hard to make sounds that are meant to be attention grabbing (or vanity oriented) not travel beyond the range that you need them for safety.
I don’t want to imagine what it might be like living as I do with a 3-way stop outside my window, with each car singing a different tune or strange noise every time it slows down and starts up again. Who will want to live near intersections or parking lots?
I have a few proposals:
- Like the beep-beep solution, use white noise that just doesn’t travel very far, but is easily noticed when close.
- Use natural sounds, like waves crashing, birds chirping, wind blowing. We are tuned to hear those sounds in an otherwise silent environment, but our brains also can easily ignore them in background form.
- Do indeed tune the volume based on ambient noise. This is suggested in the O’Reilly article linked above. They propose it to be loud enough. It should also be quiet enough.
- Don’t do it at a speed where the tires and wind and electric motors are making enough noise already.
- As robocar sensors become more common, such as LIDAR and radar, only make the noise when there are people who might come in contact with the vehicle. Otherwise, be silent.
- Since robocars will not hit people in any normal operation, even people who don’t know they are there, such vehicles need not make any noise. HOwever, if they see a human or anything else on a collision course, let them make a more loud and useful noise that really gets attention, like a burst of white or pink noise, or even a horn if they ignore that. Start quiet, get louder if it is not reacted to in a human reaction time.
Let’s not give up on this opportunity to return peace to our public spaces as electric cars and robocars become popular.
A proposal is being floated in Europe for computerized convoys or road trains within the next decade. This is a proposal for a system where cars can hand over control to a lead car and follow in a train or convoy, without physical connection.
This idea comes up a lot as an early robocar technology. It is particularly common because it’s much easier to do — a human driver still is in charge, and the robotic control is limited to a very limited and simple environment. It’s safe to say that we could make this work very quickly if we wanted to. There is no navigation or vision required, no recognition of obstacles, no choice of speeds or turns. Cars that come together in a convoy can draft to get a serious boost in fuel efficiency, and of course the un-drivers can now relax and read or work on the trip.
As a robocar booster, people are surprised when I say I am not too thrilled about this idea, at least as an early technology. Rather I think it’s a great idea for later. In spite of the enthusiasm with which I write, the robocar problem is not a simple one. This much simpler problem is tempting but has some snags.
First of all, if you have a bug in a standalone robocar system, it may cause an accident, and that may injure or kill the occupants of the robocar, and perhaps one or two other cars. Death is less likely at urban speeds of course. A problem with a computerized convoy could have terrible results, involving scores of cars. Since most people want this for the highway, the problem would also occur at lethal speed. Convoys are just not the first place we want to test our systems and have our first accidents.
Secondly, forming convoys requires a critical mass of suitably equipped cars. Of course, you don’t need a dozen full robocars to make a train, all you would need is cars with drive-by-wire and some much simpler control circuitry. But even so, the incentive to get a car with this feature has to get over a critical mass hump if it’s going to be worthwhile. It’s not quite as bad as fully ad-hoc trains, since you can have scheduled trains, lead by a bus or truck driver, and cars can see such a lead vehicle and get in behind it. But at first, the odds of many cars all finding one another at the same time is low. If the train is going faster than regular traffic in a carpool lane, as we hope it would, it will not be easy to join a train that moves past you on the highway. If it moves slower than traffic, it is easy to slow down and join it, but then it has to move slower, with all the attendant problems.
Computerized convoys have advantages and disadvantages over physical ones. Physical ones probably can only be formed while stopped, and probably only unformed that way too. One could see the last car in a physical convoy undocking while moving, so with correct ordering it might work out, but it’s a far cry from a virtual convoy which allows anybody to join and leave at any time.
Physical convoys however can transmit power. This is useful if you expect people to be driving short-range electric cars. They would take their short range car and join a convoy, and be powered by the lead locomotive while operating, and even be recharging a bit. After dispersion, the vehicles would only need to go a short destination to their target and back to the evening train.
Physical coupling makes it harder for one car to leave the train due to a failure. On the other hand it means that if the lead car wants to change lanes, all cars must do so. If the lead car leaves the road, they all do. Jack-knifing is a real worry, which is one reason that today even cargo road trains are limited to 2 trailers in urban areas, and 3 trailers in rural areas, if they are allowed at all.
Physical coupling requires specially modified vehicles. This is even more the case if the locomotive will actually be towing the vehicles physically rather than providing them with electricity for their motors and batteries. Either of these is a major modification, while virtual coupling only requires a drive-by-wire car and a small matter of programming.
Even full robocars probably should not form convoys right away. We should wait until our confidence is even higher, in spite of the fuel savings. If one car goes bad, or its occupants try to take over and move to manual driving, the consequences could be nasty in any convoy. And of course, the first robocars on the road will never get to join convoys as they will not meet the others. That’s why you need to solve the solo navigation problem first, and then you get enough on the road to work on the cooperation problems.
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 as well.
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.)
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.)
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…
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 »
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 »
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.
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.