The future of computer-driven cars and deliverbots
California published its summary of all the reports submitted by vendors testing robocars in the state. You can read the individual reports -- and they are interesting, but several other outlines have created summaries of the reports calculating things like the number of interventions per mile.
I generally pay very little attention when companies issues a press release about an "alliance." It's usually not a lot more than a press release unless there are details on what will actually be built.
Earlier I posted my gallery of CES gadgets, and included a photo of the eHang 184 from China, a "personal drone" able, in theory, to carry a person up to 100kg.
Whether the eHang is real or not, some version of the personal automated flying vehicle is coming, and it's not that far away. When I talk about robocars, I am often asked "what about flying cars?" and there will indeed be competition between them. There are a variety of factors that will affect that competition, and many other social effects not yet much discussed.
There are two visions of the flying car. The most common is VTOL -- vertical takeoff and landing -- something that may have no wheels at all because it's more a helicopter than a car or airplane. The recent revolution in automation and stability for multirotor helicopters -- better known as drones -- is making people wonder when we'll get one able to carry a person. Multirotors almost exclusively use electric motors because you must adjust speed very quickly to get stability and control. You also want the redundancy of multiple motors and power systems, so you can lose a rotor or a battery and still fly.
This creates a problem because electric batteries are heavy. It takes a lot of power to fly this way. Carrying more batteries means more weight -- and thus more power needed to carry the batteries. There are diminishing returns, and you can't get much speed, power or range before the batteries are dead. OK in a 3 kilo drone, not OK in a 150 kilo one.
Lots of people are experimenting with combining multirotor for takeoff and landing, and traditional "fixed wing" (standard airplane) designs to travel any distance. This is a great deal more efficient, but even so, still a challenge to do with batteries for long distance flight. Other ideas including using liquid fuels some way. Those include just using a regular liquid fuel motor to run a generator (not very efficient) or combining direct drive of a master propeller with fine-control electric drive of smaller propellers for the dynamic control needed.
Another interesting option is the autogyro, which looks like a helicopter but needs a small runway for takeoff.
Some "flying car" efforts have made airplanes whose wings fold up so they can drive on the road. These have never "taken off" -- they usually end up a compromise that is not a very good car or a very good plane. They need airports but you can keep driving from the airport. They are not, for now, autonomous.
Some want to fly most of their miles, and drive just short distances. Some other designs are mostly for driving, but have an ability to "short hop" via parasailing or autogyro flying when desired.
NHTSA released the report from their Office of Defects Investigation on the fatal Tesla crash in Florida last spring. It's a report that is surprisingly favorable to Tesla. So much so that even I am surprised. While I did not think Tesla would be found defective, this report seems to come from a different agency than the one that recently warned comma.ai that:
Recently we've seen two essays by people I highly respect in the field of AI and robotics. Their points are worthy of reading, but in spite of my respect, I have some differences of course.
The first essay comes from Andrew Ng, head of AI (and thus the self-driving car project) at Baidu. You will find few who can compete with Andrew when it comes to expertise on AI. (Update: This essay is not recent, but I only came upon it recently.)
CES has become the big event for major car makers to show off robocar technology. Most of the north hall, and a giant and valuable parking lot next to it, were devoted to car technology and self-driving demos.
Earlier I posted about many of the pre-CES announcements and it turns out there were not too many extra events during the show. I went to visit many of the booths and demos and prepared some photo galleries. The first is my gallery on cars. In this gallery, each picture has a caption so you need to page through them to see the actual commentary at the bottom under the photo. Just 3 of many of the photos are in this post.
To the left you see BMW's concept car, which starts to express the idea of an ultimate non-driving machine. Inside you see that the back seat has a bookshelf in it. Chances are you will just use your eReader, but this expresses and important message -- that the car of the future will be more like a living, playing or working space than a transportation space.
The main announcement during the show was from Nissan, which outlined their plans and revealed some concept cars you will see in the gallery. The primary demo they showed involved integration of some technology worked on by Nissan's silicon valley lab leader, Maarten Sierhuis in his prior role at NASA. Nissan is located close to NASA Ames (I myself work at Singularity University on the NASA grounds) and did testing there.
Their demo showed an ability to ask a remote control center to assist a car with a situation it doesn't understand. When the car sees something it can't handle, it stops or pulls over, and people in the remote call center can draw a path on their console to tell the car where to go instead. For example, it can be drawn how to get around an obstacle, or take a detour, or obey somebody directing traffic. If the same problem happens again, and it is approved, the next car can use the same path if it remains clear.
I have seen this technology a number of places before, including of course the Mars rovers, and we use something like it at Starship Technologies for our delivery robots. This is the first deployment by a major automaker.
Nissan also committed to deployment in early 2020 as they have before -- but now it's closer.
You can also see Nissan's more unusual concepts, with tiny sensor pods instead of side-view mirrors, and steering wheels that fold up.
Several startups were present. One is AIMotive, from Hungary. They gave me a demo ride in their test car. They are building a complete software suite, primarily using cameras and radar but also able to use LIDAR. They are working to sell it to automotive OEMs and already work with Volvo on DriveMe. The system uses neural networks for perception, but more traditional coding for path planning and other functions. It wasn't too fond of Las Vegas roads, because the lane markers are not painted there -- lanes are divided only with Bott's Dots. But it was still able to drive by finding the edge of the road. They claim they now have 120 engineers working on self-driving systems in Hungary.
You may have seen a lot of press around a dashcam video of a car accident in the Netherlands. It shows a Tesla in AutoPilot hitting the brakes around 1.4 seconds before a red car crashes hard into a black SUV that isn't visible from the viewpoint of the dashcam. Many press have reported that the Tesla predicted that the two cars would hit, and because of the imminent accident, it hit the brakes to protect its occupants. (The articles most assuredly were not saying the Tesla predicted the accident that never happened had the Tesla failed to brake, they are talking about predicting the dramatic crash shown in the video.)
The accident is brutal but apparently nobody was hurt.
The press speculation is incorrect. It got some fuel because Elon Musk himself retweeted the report linked to, but Telsa has in fact confirmed the alternate and more probable story which does not involve any prediction of the future accident. In fact, the red car plays little to no role in what took place.
Tesla's autopilot uses radar as a key sensor. One great thing about radar is that it tells you how fast every radar target is going, as well as how far away it is. Radar for cars doesn't tell you very accurately where the target is (roughly it can tell you what lane a target is in.) Radar beams bounce off many things, including the road. That means a radar beam can bounce off the road under a car that is in front of you, and then hit a car in front of it, even if you can't see the car. Because the radar tells you "I see something in your lane 40m ahead going 20mph and something else 30m ahead going 60mph" you know it's two different things.
Thursday night I am heading off to CES, and it's become the main show it seems for announcing robocar news. There's already a bunch.
The California DMV got serious in their battle with Uber and revoked the car registrations for Uber's test vehicles. Uber had declined to register the cars for autonomous testing, using an exemption in that law which I described earlier. The DMV decided to go the next step and pull the more basic licence plate every car has to have if based in California. Uber announced it would take the cars to another state.
For a few months, Uber has been testing their self-driving prototypes in Pittsburgh, giving rides to willing customers with a safety driver (or two) in the front seat monitoring the drive and ready to take over.
When Uber came to do this in San Francisco, starting this week, it was a good step to study new territory and new customers, but the real wrinkle was they decided not to get autonomous vehicle test permits from the California DMV. Google/Waymo and most others have such permits. Telsa has such permits but claims it never uses them.
Google's car project (known as "Chauffeur") really kickstarted the entire robocar revolution, and Google has put in more work, for longer, than anybody. The car was also the first project of what became Google "X" (or just "X" today under Alphabet. Inside X, a lab devoted to big audacious "moonshot" projects that affect the physical world as well as the digital, they have promoted the idea that projects should eventually "graduate," moving from being research to real commercial efforts.
Robocars are broadly going to be a huge boon for many people with disabilities, especially disabilities which make it difficult to drive or those that make it hard to get in and out of vehicles. Existing disability regulations and policies were written without robocars in mind, and there are probably some improvements that need to be made.
I believe we have the potential to eliminate a major fraction of traffic congestion in the near future, using technology that exists today which will be cheap in the future. The method has been outlined by myself and others in the past, but here I offer an alternate way to explain it which may help crystallize it in people's minds.
Today many people drive almost all the time guided by their smartphone, using navigation apps like Google Maps, Apple Maps or Waze (now owned by Google.) Many have come to drive as though they were a robot under the command of the app, trusting and obeying it at every turn. Tools like these apps are even causing controversy, because in the hunt for the quickest trip, they are often finding creative routes that bypass congested major roads for local streets that used to be lightly used.
Put simply, the answer to traffic congestion might be, "What if you, by law, had to obey your navigation app at rush hour?" To be more specific, what if the cities and towns that own the streets handed out reservations for routes on those streets to you via those apps, and your navigation app directed you down them? And what if the cities made sure there were never more cars put on a piece of road than it had capacity to handle? (The city would not literally run Waze, it would hand out route reservations to it, and Waze would still do the UI and be a private company.)
The value is huge. Estimates suggest congestion costs around 160 billion dollars per year in the USA, including 3 billion gallons of fuel and 42 hours of time for every driver. Roughly quadruple that for the world.
This approach would exploit one principle in road management that's been most effective in reducing congestion, namely road metering. The majority of traffic congestion is caused, no surprise, by excess traffic -- more cars trying to use a stretch of road than it has the capacity to handle. There are other things that cause congestion -- accidents, gridlock and irrational driver behaviour, but even these only cause traffic jams when the road is near or over capacity.
Today, in many cities, highway metering is keeping the highways flowing far better than they used to. When highways stall, the metering lights stop cars from entering the freeway as fast as they want. You get frustrated waiting at the metering light but the reward is you eventually get on a freeway that's not as badly overloaded.
Another type of metering is called congestion pricing. Pioneered in Singapore, these systems place a toll on driving in the most congested areas, typically the downtown cores at rush hour. They are also used in London, Milan, Stockholm and some smaller towns, but have never caught on in many other areas for political reasons. Congestion charging can easily be viewed as allocating the roads to the rich when they were paid for by everybody's taxes.
A third successful metering system is the High-occupancy toll lane. HOT lanes take carpool lanes that are being underutilized, and let drivers pay a market-based price to use them solo. The price is set to bring in just enough solo drivers to avoid wasting the spare capacity of the lane without overloading it. Taking those solo drivers out of the other lanes improves their flow as well. While not every city will admit it, carpool lanes themselves have not been a success. 90% of the carpools in them are families or others who would have carpooled anyway. The 10% "induced" carpools are great, but if the carpool lane only runs at 50% capacity, it ends up causing more congestion than it saves. HOT is a metering system that fixes that problem.
There have been few postings this month since I took the time to enjoy a holiday in New Zealand around speaking at the SingularityU New Zealand summit in Christchurch. The night before the summit, we enjoyed a 7.8 earthquake not so far from Christchurch, whose downtown was over 2/3 demolished after quakes in 2010 and 2011. On the 11th floor of the hotel, it was a disturbing nailbiter of swaying back and forth for over 2 minutes -- but of course swaying is what the building is supposed to do; that means it's working.
Comma.ai, the brash startup attempting to make a self-driving system entirely from a neural network has announced it will cancel the "comma one" add-on box it has planned to sell to owners of certain Honda vehicles. The box stuck on the rear-view mirror and used the car's own bus commands to provide an autopilot similar to those offered by car makers, with lane-keeping and adaptive cruise control.
Of particular importance is the letter from NHTSA to comma.ai which I suggest you read. This letter creates several big issues:
To be clear, comma is a tiny company taking a radical approach, so it is not a given that what NHTSA has applied to them would have been or will be unanswerable by the big guys. Because Tesla's autopilot is not a pure machine learning system, they can answer many of the questions in the NHTSA letter that comma can't. They can do much more extensive testing that a tiny startup can't. But even so a letter like this sends a huge chill through the industry.
It should also be noted that in Comma's photos the box replaced the rear-view mirror, and NHTSA had reason to ask about that.
George's declaration that he's in Shenzen gives us the first sign of the new regulatory regime pushing innovation away from the United States and California. I will presume the regulators will say, "We only want to scare away dangerous innovation" but the hard truth is that is a very difficult thing to judge. All innovation in this space is going to be a bit dangerous. It's all there trying to take the car -- the 2nd most dangerous legal consumer product -- and make it safer, but it starts from a place of danger. We are not going to get to safety without taking risks along the way.
I sometimes ask, "Why do we let 16 year olds drive?" They are clearly a major danger to themselves and others. Driver testing is grossly inadequate. They are not adults so they don't have the legal rights of adults. We let them drive because they are going to start out dangerous and then get better. It is the only practical way for them to get better, and we all went through it. Today's early companies are teenagers. They are going to take risks. But this is the fastest and only practical way to let them get better and save millions.
This sentence, though in the cover letter and not the actual legal demand, looks at the question asked so much after the Tesla fatal crash. The question which caused Consumer Reports to ask Tesla to turn off the feature. The question which caused MobilEye, they say, to sever their relationship with Tesla.
The paradox of the autopilot is this: The better it gets, the more likely it is to make drivers over-depend on it. The more likely they will get complacent and look away from the road. And thus, the more likely you will see a horrible crash like the Tesla fatality. How do you deal with a system which adds more danger the better you make it? Customers don't want annoying countermeasures. This may be another reason that "Level 2," as I wrote yeterday is not really a meaningful thing.
NHTSA has put a line in the sand. It is no longer going to be enough to say that drivers are told to still pay attention.
Comma is not the only company trying to build a system with pure neural networks doing the actual steering decisions (known as "path planning".) NVIDIA's teams have been actively working on this, as have several others. They plan to make commentary to NHTSA about these element of the regulations, which should not be forbidding this approach until we know it to be dangerous.
It's no secret that I've been a critic of the NHTSA "levels" as a taxonomy for types of Robocars since the start. Recent changes in their use calls for some new analysis that concludes that only one of the levels is actually interesting, and only tells part of the story at that. As such, they have become even less useful as a taxonomy. Levels 2 and 3 are unsafe, and Level 5 is remote future technology. Level 4 is the only interesting one and there is thus no taxonomy.
I had hoped I was done ranting about our obsession with what robocars will do in no-win "who do I hit?" situations, but this week, even Barack Obama in his interview with Wired opined on the issue, prompted by my friend Joi Ito from the MIT Media Lab. (The Media Lab recently ran a misleading exercise asking people to pretend they were a self-driving car deciding who to run over.)
After my initial reactions and Overall Analysis here is a point by point consideration of second set of elements from NHTSA's 15 point certification list for robocars. See my series for other articles or the first half of the list.
In this section, the remind vendors they still need to meet the same standards as regular cars do. We are not ready to start removing heavy passive safety systems just because the vehicles get in fewer crashes. In the future we might want to change that, as those systems can be 1/3 of the weight of a vehicle.
They also note that different seating configurations (like rear facing seats) need to protect as well. It's already the case that rear facing seats will likely be better in forward collisions. Face-to-face seating may present some challenges in this environment, as it is less clear how to deploy the airbags. Taxis in London often feature face-to-face seating, though that is less common in the USA. Will this be possible under these regulations?
The rules also call for unmanned vehicles to absorb energy like existing vehicles. I don't know if this is a requirement on unusual vehicle design for regular cars or not. (If it were, it would have prohibited SUVs with their high bodies that can cause a bad impact with a low-body sports-car.)
This seems like another mild goal, but we don't want a world where you can't ride in a taxi unless you are certified as having taking a training course. Especially if it's one for which you have very little to do. These rules are written more for people buying a car (for whom training can make sense) than those just planning to be a passenger.
This section imagines labels for drivers. It's pretty silly and not very practical. Is a car going to have a sticker saying "This car can drive itself on Elm St. south of Pine, or on highway 101 except in Gilroy?" There should be another way, not labels, that this is communicated, especially because it will change all the time.
This set is fairly reasonable -- it requires a process describing what you do to a vehicle after a crash before it goes back into service.
This section calls for a detailed plan on how to assure compliance with all the laws. Interestingly, it also asks for a plan on how the vehicle will violate laws that human drivers sometimes violate. This is one of the areas where regulatory effort is necessary, because strictly cars are not allowed to violate the law -- doing things like crossing the double-yellow line to pass a car blocking your path.
After my initial reactions and Overall Analysis here is a point by point consideration of the elements from NHTSA's 15 point certification list for robocars. See also the second half and the whole series
Let's dig in:
These regulations require a plan about how the vehicle keep logs around any incident (while following privacy rules.) This is something everybody already does -- in fact they keep logs of everything for now -- since they want to debug any problems they encounter. NHTSA wants the logs to be available to NHTSA for crash investigation.
NHTSA also wants recordings of positive events (the system avoided a problem.)
Most interesting is a requirement for a data sharing plan. NHTSA wants companies to share their logs with their competitors in the event of incidents and important non-incidents, like near misses or detection of difficult objects.
This is perhaps the most interesting element of the plan, but it has seen some resistance from vendors. And it is indeed something that might not happen at scale without regulation. Many teams will consider their set of test data to be part of their crown jewels. Such test data is only gathered by spending many millions of dollars to send drivers out on the roads, or by convincing customers or others to voluntarily supervise while their cars gather test data, as Tesla has done. A large part of the head-start that leaders have in this field is the amount of different road situations they have been able to expose their vehicles to.
Recordings of mundane driving activity are less exciting and will be easier to gather. Real world incidents are rare and gold for testing. The sharing is not as golden, because each vehicle will have different sensors, located in different places, so it will not be easy to adapt logs from one vehicle directly to another. While a vehicle system can play its own raw logs back directly to see how it performs in the same situation, other vehicles won't readily do that.
Instead this offers the ability to build something that all vendors want and need, and the world needs, which is a high quality simulator where cars can be tested against real world recordings and entirely synthetic events. The data sharing requirement will allow the input of all these situations into the simulator, so every car can test how it would have performed. This simulation will mostly be at the "post perception level" where the car has (roughly) identified all the things on the road and is figuring out what to do with them, but some simulation could be done at lower levels.
These data logs and simulator scenarios will create what is known as a regression test suite. You test your car in all the situations, and every time you modify the software, you test that your modifications didn't break something that used to work. It's an essential tool.
In the history of software, there have been shared public test suites (often sourced from academia) and private ones that are closely guarded. For some time, I have proposed that it might be very useful if there were a a public and open source simulator environment which all teams could contribute scenarios to, but I always expected most contributions would come from academics and the open source community. Without this rule, the teams with the most test miles under their belts might be less willing to contribute.
Such a simulator would help all teams and level the playing field. It would allow small innovators to even build and test prototype ideas entirely in simulator, with very low cost and zero risk compared to building it in physical hardware.
This is a great example of where NHTSA could use its money rather than its regulatory power to improve safety, by funding the development of such test tools. In fact, if done open source, the agencies and academic institutions of the world could fund a global one. (This would face opposition from companies hoping to sell test tools, but there will still be openings for proprietary test tools.)
This section demands a privacy policy. I'm not against that, though of course the history of privacy policies is not a great one. They mostly involve people clicking "I agree" to things they don't read. More important is the requirement that vendors be thinking about privacy.
The requirement for user choice is an interesting one, and it conflicts with the logging requirements. People are wary of technology that will betray them in court. Of course, as long as the car is not a hybrid car that mixes human driving with self-driving, and the passenger is not liable in an accident, there should be minimal risk to the passenger from accidents being recorded.
The rules require that personal information be scrubbed from any published data. This is a good idea but history shows it is remarkably hard to do properly.
The recent Federal Automated Vehicles Policy is long. (My same-day analysis is here and the whole series is being released.) At 116 pages (to be fair, less than half is policy declarations and the rest is plans for the future and associated materials) it is much larger than many of us were expecting.
The policy was introduced with a letter attributed to President Obama, where he wrote:
There are always those who argue that government should stay out of free enterprise entirely, but I think most Americans would agree we still need rules to keep our air and water clean, and our food and medicine safe. That’s the general principle here. What’s more, the quickest way to slam the brakes on innovation is for the public to lose confidence in the safety of new technologies. Both government and industry have a responsibility to make sure that doesn’t happen. And make no mistake: If a self-driving car isn’t safe, we have the authority to pull it off the road. We won’t hesitate to protect the American public’s safety.
This leads in to an unprecedented effort to write regulations for a technology that barely exists and has not been deployed beyond the testing stage. The history of automotive regulation has been the opposite, and so this is a major change. The key question is what justifies such a big change, and the cost that will come with it.
Make no mistake, the cost will be real. The cost of regulations is rarely known in advance but it is rarely small. Regulations slow all players down and make them more cautious -- indeed it is sometimes their goal to cause that caution. Regulations result in projects needing "compliance departments" and the establishment of procedures and legal teams to assure they are complied with. In almost all cases, regulations punish small companies and startups more than they punish big players. In some cases, big players even welcome regulation, both because it slows down competitors and innovators, and because they usually also have skilled governmental affairs teams and lobbying teams which are able to subtly bend the regulations to match their needs.
This need not even be nefarious, though it often is. Companies that can devote a large team to dealing with regulations, those who can always send staff to meetings and negotiations and public comment sessions will naturally do better than those which can't.
The US has had a history of regulating after the fact. Of being the place where "if it's not been forbidden, it's permitted." This is what has allowed many of the most advanced robocar projects to flourish in the USA.
The attitude has been that industry (and startups) should lead and innovate. Only if the companies start doing something wrong or harmful, and market forces won't stop them from being that way, is it time for the regulators to step in and make the errant companies do better. This approach has worked far better than the idea that regulators would attempt to understand a product or technology before it is deployed, imagine how it might go wrong, and make rules to keep the companies in line before any of them have shown evidence of crossing a line.
In spite of all I have written here, the robocar industry is still young. There are startups yet to be born which will develop new ideas yet to be imagined that change how everybody thinks about robocars and transportation. These innovative teams will develop new concepts of what it means to be safe and how to make things safe. Their ideas will be obvious only well after the fact.
Regulations and standards don't deal well with that. They can only encode conventional wisdom. "Best practices" are really "the best we knew before the innovators came." Innovators don't ignore the old wisdom willy-nilly, they often ignore it or supersede it quite deliberately.
Some players -- notably the big ones -- have lauded these regulations. Big players, like car companies, Google, Uber and others have a reason to prefer regulations over a wild west landscape. Big companies like certainty. They need to know that if they build a product, that it will be legal to sell it. They can handle the cost of complex regulations, as long as they know they can build it.