Vendors push back on California Robocar regulations - plus Tesla and Apple news

California Hearings

Wednesday, California held hearings on the latest draft of their regulations. The new regulations heavily incorporate the new NHTSA guidelines released last month, and now incorporate language on the testing and deployment of unmanned vehicles.

The earlier regulations caused consternation because they correctly identified that nobody had sufficient understanding of unmanned vehicle operations to write regulations, but incorrectly proceeded to forbid those vehicles until later. Once you ban something, it’s very hard to un-ban it. The new approach does not ban the vehicles, but attempts instead to write regulations for them that are too premature.

Comment from developers of the vehicles reflected sentiment that all the regulations are premature. California worked together with NHTSA on their regulations, and incorporated them. In particular, while NHTSA’s regulations lay out a 15 point list of functional domains that creators of vehicles should certify, the federal regulations technically declare this certification to be optional. A vendor in submitting a report can explicitly state they decline to certify most of the items.

California suggests that this certification might be mandatory here. For all my criticism of NHTSA’s plan, they do have an understanding that it is still far too early to be writing detailed rules for vehicles that don’t yet exist, and left these avenues for change and disagreement within their regulations. The avenues are not great — I feel that vendors will be concerned that truly treating the regulations as voluntary will will be done at their peril — but at least they exist.

Several vendors also pointed out the serious problems with traditional regulatory timelines and the speed of development of computer technologies. The California regulations may require that a car be tested for a year before it is deployed. On the surface that sounds normal by old standards, but the reality of development is very different. Pretty much all the vendors I know are producing new builds of their vehicle software and testing them out on the roads the next day — with trained safety drivers behind the wheel. The software goes through extensive “regression testing,” running through every tricky situation the team has encountered anywhere, as well as simulated situations, but the safety driver is there to deal with any problem not found with that testing.

Vendors won’t release into production cars with only one night of testing, but neither can they wait a year. This is particularly true because in the early days of this technology, new problems will be found during deployment, and you want to get the fixes out on the road as quickly as is safe to do. An arbitrary timeline makes no sense.

This is just the start of the problems. While one may argue that it was always going to be hard for startups and tinkerers to develop these cars, these regulations (and the federal ones) put more nails in the coffin of the small innovator. The amount of bureaucracy, the size of the insurance bonds and many other factors will make it hard for teams the size of the DARPA challenge teams who kickstarted this technology and make it real to actually play in the game. The auto industry has a long history of allowing tinkerers to innovate, even at the cost of relaxing safety requirements applied to them. We may end up with a world where only the big players can play at all, and we know that this is generally not good at all for the pace of innovation.

Delivery Robots

The new regulations allowing unmanned vehicles might seem to open doors for delivery robots like we’re working on at Starship. Unfortunately they seem aimed primarily at large vehicles. Since California rules define the sidewalk as part of the street, these regulations might end up demanding a small, slow, light delivery robot still comply with the bulky Federal Motor Vehicle Safety Standards (which are meant for passenger cars) and is impossible without major exceptions being made. (More reading is needed to tell if this is truly how this will play out.)

Tesla says all future cars will have full sensor suite

Tesla has declared that all their future cars, including the lower cost Model 3, will include the full suite of radars, cameras and other sensors needed for self driving. That’s good news, though the Tesla sensor suite, lacking LIDAR, is not currently sufficient for a full self-driving car. Tesla is making a bet of sorts that by the time this becomes in play, cameras and radars will be sufficient to make an acceptably safe system. If not, they will have to stick with autopilot function on those cars. Since there is strong evidence that LIDAR will be inexpensive in a couple of years, I don’t believe anybody should plan to deploy their first (and riskiest) robocars without every sensor that’s at all affordable. Why make it less safe than you could just to save a few hundred dollars?

Today, Tesla can’t do that because no production low cost LIDAR is available. Most other teams are betting it will be. In the future, when cost becomes a bigger issue, vendors will decide to eliminate sensors based on cost.

Apple might have changed their plans

Apple hasn’t said anything official about their rumoured car project. All we know has come from leaks and from looking at who has been hired or who has departed. (I do know one secret thing about the Apple car — it will only work if you have a new iPhone.) Many rumours came out this week that Apple may have cancelled plans to actually make an Apple Car, and instead will take an approach more like Google — building the software and self-driving systems and letting others worry about car manufacture. That is a good strategy, so Apple is hardly out of the game, but it does mean it’s less likely the world will see a car with the particular Apple flair and marketing genius.

The relationship between powerful self-drive system developers (like Apple, Google and Uber) and car manufacturers will be an interesting one. Car makers are used to being in charge, owning the process and owning the customer. So are these hi-tech companies. But many companies will do “contract manufacturing” in auto. If Apple shows up with a purchase order for 100,000 cars to be built to their spec, there are many companies who will take the order, even if the high end Daimlers and Toyotas of the world won’t. So just as Apple doesn’t build the iPhone and gets Foxconn to do it, the fact that Apple will stick to the software systems doesn’t mean their design will not appear in a car.

Here is a summary of Apple car rumours.

NHTSA Regulations part 4: Crashes, Training, Certification, State Law, Operation, Validation and Autopilots

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.)

Consumer Education and Training

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.

Registration and Certification

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.

Post-Crash Behavior

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.

Federal, State and Local Laws

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.  read more »

NHTSA Regulations part 3: Data Sharing, Privacy, Safety, Security and HMI

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:

Data Recording and Sharing

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.  read more »

Detailed analysis of NHTSA robocar regulations: Overview

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.

What’s good?

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.  read more »

Critique of NHTSA's newly released regulations

The long awaited list of recommendations and potential regulations for Robocars has just been released by NHTSA, the federal agency that regulates car safety and safety issues in car manufacture. Normally, NHTSA does not regulate car technology before it is released into the market, and the agency, while it says it is wary of slowing down this safety-increasing technology, has decided to do the unprecedented — and at a whopping 115 pages.

Broadly, this is very much the wrong direction. Nobody — not Google, Uber, Ford, GM or certainly NHTSA — knows the precise form of these cars will have when deployed. Almost surely something will change from our existing knowledge today. They know this, but still wish to move. Some of the larger players have pushed for regulation. Big companies like certainty. They want to know what the rules will be before they invest. Startups thrive better in the chaos, making up the rules as we go along.

NHTSA hopes to define “best practices” but the best anybody can do in 2016 is lay down existing practices and conventional wisdom. The entirely new methods of providing safety that are yet to be invented won’t be in such a definition.

The document is very detailed, so it will generate several blog posts of analysis. Here I present just initial reactions. Those reactions are broadly negative. This document is too detailed by an order of magnitude. Its regulations begin today, but fortunately they are also accepting public comment. The scope of the document is so large, however, that it seems extremely unlikely that they would scale back this document to the level it should be at. As such, the progress of robocar development in the USA may be seriously negatively affected.

Vehicle performance guidelines

The first part of the regulations is a proposed 15 point safety standard. It must be certified (by the vendor) that the car meets these standards. NHTSA wants the power, according to an Op-Ed by no less than President Obama, to be able to pull cars from the road that don’t meet these safety promises.

  • Data Recording and Sharing
  • Privacy
  • System Safety
  • Vehicle Cybersecurity
  • Human Machine Interface
  • Crashworthiness
  • Consumer Education and Training
  • Registration and Certification
  • Post-Crash Behavior
  • Federal, State and Local Laws
  • Operational Design Domain
  • Object and Event Detection and Response
  • Fall Back (Minimal Risk Condition)
  • Validation Methods
  • Ethical Considerations

As you might guess, the most disturbing is the last one. As I have written many times, the issue of ethical “trolley problems” where cars must decide between killing one person or another are a philosophy class tool, not a guide to real world situations. Developers should spend as close to zero effort on these problems as possible, since they are not common enough to warrant special attention, if not for our morbid fascination with machines making life or death decisions in hypothetical situations. Let the policymakers answer these questions if they want to; programmers and vendors don’t.

For the past couple of years, this has been a game that’s kept people entertained and ethicists employed. The idea that government regulations might demand solutions to these problems before these cars can go on the road is appalling. If these regulations are written this way, we will delay saving lots of real lives in the interest of debating which highly hypothetical lives will be saved or harmed in ridiculously rare situations.

NHTSA’s rules demand that ethical decisions be “made consciously and intentionally.” Algorithms must be “transparent” and based on input from regulators, drivers, passengers and road users. While the section makes mention of machine learning techniques, it seems in the same breath to forbid them.

Most of the other rules are more innocuous. Of course all vendors will know and have little trouble listing what roads their car works on, and they will have extensive testing data on the car’s perception system and how it handles every sort of failure. However, the requirement to keep the government constantly updated will be burdensome. Some vehicles will be adding streets to their route map literally ever day.

While I have been a professional privacy advocate, and I do care about just how the privacy of car users is protected, I am frankly not that concerned during the pilot project phase about how well this is done. I do want a good regime — and even the ability to do anonymous taxi — so it’s perhaps not too bad to think about these things now, but I suspect these regulations will be fairly meaningless unless written in consultation with independent privacy advocates. The hard reality is that during the test phase, even a privacy advocate has to admit that the cars will need to make very extensive recordings of everything they can, so that any problems encountered can be studied and fixed and placed into the test suite.

50 state laws

NHTSA’s plan has been partially endorsed by the self-driving coalition for safer streets (whose members include big players Ford, Google, Volvo, Uber and Lyft.) They like the fact that it has guidance for states on how to write their regulations, fearing that regulations may differ too much state to state. I have written that having 50 sets of rules may not be that bad an idea because jurisdictional competition can allow legal innovation and having software load new parameters as you drive over a border is not that hard.

In this document NHTSA asks the states to yield to the DOT on regulating robocar operation and performance. States should stick to registering cars, rules of the road, safety inspections and insurance. States will regulate human drivers as before, but the feds will regulate computer drivers.

States will still regulate testing, in theory, but the test cars must comply with the federal regulations.

New Authorities

A large part of the document just lists the legal justifications for NHTSA to regulate in this fashion and is primarily for policy wonks. Section 4, however, lists new authorities NHTSA is going to seek in order to do more regulation.

Some of the authorities they may see include:

  • Pre-market safety assurance: Defining testing tools and methods to be used before selling
  • Pre-market approval authority: Vendors would need approval from NHTSA before selling, rather than self-certifying compliance with the regulations
  • Hybrid approaches of pre-market approval and self-certification
  • Cease and desist authority: The ability to demand cars be taken off the road
  • Exemption authority: An ability to grant rue exemptions for testing
  • Post-sale authority to regulate software changes
  • Much more

Other quick notes:

  • NHTSA has abandoned their levels in favour of the SAE’s. The SAE’s were almost identical of course, with the addition of a “level 5” which is meaningless because it requires a vehicle that can drive literally everywhere, and there is not really a commercial reason to make a car at present that can do that.
  • NHTSA is now pushing the acronym “HAV” (highly automated vehicle) as yet another contender in the large sea of names people use for this technology. (Self-driving car, driverless car, autonomous vehicle, automated vehicle, robocar etc.)

This was my preliminary report. More analysis can be found under the NHTSA tag.

Actually, 50 different state regulations is not that bad an idea

At the recent AUVSI/TRB conference in San Francisco, there was much talk of upcoming regulation, particularly from NHTSA. Secretary of Transportation Foxx and his NHTSA staff spoke with just vague hints about what might come in the proposals due this fall. Generally, they said good things, namely that they are wary of slowing down the development of the technology. But they said things that suggest other directions.

Secretary Foxx began by agreeing that the past history of automotive driving systems was quite different. Regulations have typically been written years or decades after technologies have been deployed. And the written regulations have tended to involve standards which the vendors self-certify their compliance with. What this means is that there is not a government test center which confirms a car complies with the rules in the safety standards. Instead, the vendor certifies they are following the rules. If they certify falsely, that can get them in trouble later with regulators and more importantly in lawsuits. It’s by far the best approach unless the vendors have shown that they can’t be trusted in spite of the fear of these actions.

But Foxx said that they were going to go against that history and consider “pre-market regulation.” Regular readers will know I think that’s an unwise idea, and so do many regulators, who admit that we don’t know enough about the final form of the technology to regulate yet.

Fortunately it was also suggested that NHTSA’s new documents would be more in the form of “guidance” for states. Many states ask NHTSA to help them write self-driving car regulations. Which gets us to a statement that was echoed by several speakers to justify federal regulation, “Nobody wants 50 different regulations” on these cars.

At first, that seems obvious. I mean, who would want it to be that complex? Clearly it’s simpler to have to deal with only one set of regulations. But while that’s true, it doesn’t mean it’s the best idea. They are overestimating the work involved in dealing with different regulations, and underestimating the value of having the ability for states to experiment with new ideas in regulation, and the value of having states compete on who can write the best regulations.

If regulations differed so much between states as to require different hardware, that makes a stronger case. But most probably we are talking about rules that affect the software. That can be annoying, but it’s just annoying. A car can switch what rules it follows in software when it crosses a border with no trouble. It already has to, just because of the different rules of the road found in every state, and indeed every city and even every street! Having a few different policies state by state is no big addition.

Jurisdictional competition is a good thing though, particularly with emerging technologies. Let some states do it wrong, and others do it better, at least at the start. Le them compete to bring the technology first to their region, and invent new ideas on how to regulate something the world has never seen. Over time these regulations can be normalized. By the time people are making 10s of millions of robocars, that normalization will make more sense. But most vendors only plan to deploy in just a few states to begin, anyway. If a state feels its regulations are making it harder for the cars to spread to its cities, it can copy the rules of the other state it likes best.

The competition assures any mistake is localized — and probably eventually fixed. If California follows through with banning unmanned operation, as they have proposed, Texas has said it won’t.

I noted that if the hardware has to change, that’s more of an issue. It’s still not that much of an issue, because cars that operate as taxi services will probably never leave their base state. Most of them will have limited operational zones, and except in cities that straddle state borders, they won’t even leave town, let alone leave the state. Some day, the cars might do interstate trips, but even then you can solve this by having one car drive you to the border and then transfer to a car for the other state. Annoying, but only slight, and not a deal-breaker on the service. A car you own and take on road trips is a different story.

The one way having different state regulations would be a burden would be if there were 50 different complex certification processes to go through. Today, the federal government regulates how cars are made and the safety standards for that. The states regulate how cars operate on the roads. Robocars do blur that line, because how they are made controls how they drive.

For now, I still believe the tort system — even though it differs in all 50 states — is the best approach to regulation. It already has all developers highly paranoid about safety. When the day comes for certification, a unified process could make sense, but that day is still very far away. But for the regulations of just how these cars will operate, it might make sense to keep that with the states, even though it’s now part of the design of the car rather than the intentions of a human driver.

In time, unified regulations will indeed be desired by all, once we’ve had the time to figure out what the right regulations should be. But today? It’s too soon. Innovation requires variety.

An alternative to specific regulations for robocars: A liability doubling

Executive summary: Can our emotional fear of machines and the call for premature regulation be mollified by a temporary increase in liability which takes the place of specific regulations to keep people safe?

So far, most new automotive technologies, especially ones that control driving such as autopilot, forward collision avoidance, lanekeeping, anti-lock brakes, stability control and adaptive cruise control, have not been covered by specific regulations. They were developed and released by vendors, sold for years or decades, and when (and if) they got specific regulations, those often took the form of “Electronic stability control is so useful, we will now require all cars to have it.” It’s worked reasonably well.

That there are no specific regulations for these things does not mean they are unregulated. There are rafts of general safety regulations on cars, and the biggest deterrent to the deployment of unsafe technology is the liability system, and the huge cost of recalls. As a result, while there are exceptions, most carmakers are safety paranoid to a rather high degree just because of liability. At the same time they are free to experiment and develop new technologies. Specific regulations tend to come into play when it becomes clear that automakers are doing something dangerous, and that they won’t stop doing it because of the liability. In part this is because today, it’s easy to assign blame for accidents to drivers, and often harder to assign it to a manufacturing defect, or to a deliberate design decision.

The exceptions, like GM’s famous ignition switch problem, arise because of the huge cost of doing a recall for a defect that will have rare effects. Companies are afraid of having to replace parts in every car they made when they know they will fail — even fatally — just one time in a million. The one person killed or injured does not feel like one in a million, and our system pushes the car maker (and thus all customers) to bear that cost.

I wrote an article on regulating Robocar Safety in 2015, and this post expands on some of those ideas.

Robocars change some of this equation. First of all, in robocar accidents, the maker of the car (or driving system) is going to be liable by default. Nobody else really makes sense, and indeed some companies, like Volvo, Mercedes and Google, have already accepted that. Some governments are talking about declaring it but frankly it could never be any other way. Making the owner or passenger liable is technically possible, but do you want to ride in an Uber where you have to pay if it crashes for reasons having nothing to do with you?

Due to this, the fear of liability is even stronger for robocar makers.

Robocar failures will almost all be software issues. As such, once fixed, they can be deployed for free. The logistics of the “recall” will cost nothing. GM would have no reason not to send out a software update once they found a problem like the faulty ; they would be crazy not to. Instead, there is the difficult question of what to do between the time a problem is discovered and a fix has been declared safe to deploy. Shutting down the whole fleet is not a workable answer; it would kill deployment of robocars if several times a year they all stopped working.

In spite of all this history and the prospect of it getting even better, a number of people — including government regulators — think they need to start writing robocar safety regulations today, rather than 10-20 years after the cars are on the road as has been traditional. This desire is well-meaning and understandable, but it’s actually dangerous, because it will significantly slow down the deployment of safety technologies which will save many lives by making the world’s 2nd most dangerous consumer product safer. Regulations and standards generally codify existing practice and conventional wisdom. They are very bad ideas with emerging technologies, where developers are coming up with entirely new ways to do things, and entirely new ways to be safe. The last thing you want is to tell vendors they must apply old-world thinking when they can come up with much better thinking.

Sadly, there are groups who love old-world thinking, namely the established players. Big companies start out hating regulation but eventually come to crave it, because it mandates the way they do things and understand into the law. This stops upstarts from figuring out how to do it better, and established players love that.

The fear of machines is strong, so it may be that something else needs to be done to satisfy all desires: The desire of the public to feel the government is working to keep these scary new robots from being unsafe, and the need for unconstrained innovation. I don’t desire to satisfy the need to protect old ways of doing things.

One option would be to propose a temporary rule: For accidents caused by robocar systems, the liability, if the system should be at fault, shall be double that if a similar accident were caused by driver error. (Punitive damages for willful negligence would not be governed by this rule.) We know the cost of accidents caused by humans. We all pay for it with our insurance premiums, at an average rate of about 6 cents/mile. This would double that cost, pushing vendors to make their systems at least twice as safe as the average human in order to match that insurance cost.

Victims of these accidents (including hapless passengers in the vehicles) would now be doubly compensated. Sometimes no compensation is enough, but for better or worse, we have set on values and doubling them is not a bad deal. Creators of systems would have a higher bar to reach, and the public would know it.

While doubling the cost is a high price, I think most system creators would accept this as part of the risk of a bold new venture. You expect those to cost extra as they get started. You invest to make the system sustainable.

Over time, the liability multiplier would reduce, and the rule would go away entirely. I suspect that might take about a decade. The multiplier does present a barrier to entry for small players, and we don’t want something like that around for too long.

California DMV regulations may kill the state's robocar lead

Be careful what you wish for — yesterday the California DMV released its proposed regulations for the operation of robocars in California. All of this sprang from Google’s request to states that they start writing such regulations to ensure that their cars were legal, and California’s DMV took much longer than expected to release these regulations, which Google found quite upsetting.

The testing regulations did not bother too many, though I am upset that they effectively forbid the testing of delivery robots like the ones we are making at Starship because the test vehicles must have a human safety driver with a physical steering system. Requiring that driver makes sense for passenger cars but is impossible for a robot the size of breadbox.

Needing a driver

The draft operating rules effectively forbid Google’s current plan, making it illegal to operate a vehicle without a licenced and specially certified driver on board and ready to take control. Google’s research led them to feel that having a transition between human driver and software is dangerous, and that the right choice is a vehicle with no controls for humans. Most car companies, on the other hand, are attempting to build “co-pilot” or “autopilot” systems in which the human still plays a fundamental role.

The state proposes banning Google style vehicles for now, and drafting regulations on them in the future. Unfortunately, once something is banned, it is remarkably difficult to un-ban it. That’s because nobody wants to be the regulator or politician who un-bans something that later causes harm that can be blamed on them. And these vehicles will cause harm, just less harm than the people currently driving are doing.

The law forbids unmanned operation, and requires the driver/operator to be “monitoring the safe operation of the vehicle at all times and be capable of taking over immediate control.” This sounds like it certainly forbids sleeping, and might even forbid engrossing activities like reading, working or watching movies.

Special certificate

Drivers must not just have a licence, they must have a certificate showing they are trained in operation of a robocar. On the surface, that sounds reasonable, especially since the hand-off has dangers which training could reduce. But in practice, it could mean a number of unintended things:

  • Rental or even borrowing of such vehicles becomes impossible without a lot of preparation and some paperwork by the person trying it out.
  • Out of state renters may face a particular problem as they can’t have California licences. (Interstate law may, bizarrely, let them get by without the certificate while Californians would be subject to this rule.)
  • Car sharing or delivered car services (like my “whistlecar” concept or Mercedes Car2Come) become difficult unless sharers get the certificate.
  • The operator is responsible for all traffic violations, even though several companies have said they will take responsibility. They can take financial responsibility, but can’t help you with points on your licence or criminal liability, rare as that is. People will be reluctant to assume that responsibility for things that are the fault of the software in the car they use, as they have little ability to judge that software.

No robotaxis

With no robotaxis or unmanned operation, a large fraction of the public benefits of robocars are blocked. All that’s left is the safety benefit for car owners. This is not a minor thing, but it’s a small a part of the whole game (and active safety systems can attain a fair chunk of it in non-robocars.)

The state says it will write regulations for proper robocars, able to run unmanned. But it doesn’t say when those will arrive, and unfortunately, any promises about that will be dubious and non-binding. The state was very late with these regulations — which is actually perfectly understandable, since not even vendors know the final form of the technology, and it may well be late again. Unfortunately, there are political incentives for delay, perhaps indeterminate delay.

This means vendors will be uncertain. They may know that someday they can operate in California, but they can’t plan for it. With other states and countries around the world chomping at the bit to get vendors to move their operations, it will be difficult for companies to choose California, even though today most of them have.

People already in California will continue their R&D in California, because it’s expensive to move such things, and Silicon Valley retains its attractions as the high-tech capital of the world. But they will start making plans for first operation outside California, in places that have an assured timetable.

It will be less likely that somebody would move operations to California because of the uncertainty. Why start a project here — which in spite of its advantages is also the most expensive place to operate — without knowing when you can deploy here. And people want to deploy close to home if they have the option.

It might be that the car companies, whose prime focus is on co-pilot or autopilot systems today, may not be bothered by this uncertainty. In fact, it’s good for their simpler early goals because it slows the competition down. But most of them have also announced plans for real self-driving robocars where you can act just like a passenger. Their teams all want to build them. They might enjoy a breather, but in the end, they don’t want these regulations either.

And yes, it means that delivery robots won’t be able to go on the roads, and must stick to the sidewalks. That’s the primary plan at Starship today, but not the forever plan.

California should, after receiving comment, alter these regulations. They should allow unmanned vehicles which meet appropriate functional safety goals to operate, and they should have a real calendar date when this is going to happen. If they don’t, they won’t be helping to protect Californians. They will take California from being the envy of the world as the place that has attracted robocar development from all around the planet to just another contender. And that won’t just cost jobs, it will delay the deployment in California of a technology that will save the lives of Californians.

I don’t want to pretend that deploying full robocars is without risk. Quite the reverse, people will be hurt. But people are already being hurt, and the strategy of taking no risk is the wrong one.

Issues in regulating robocars, and the case for a light hand

All over the world, people (and governments) are debating about regulations for robocars. First for testing, and then for operation. It mostly began when Google encouraged the state of Nevada to write regulations, but now it’s in full force. The topic is so hot that there is a danger that regulations might be drafted long before the shape of the first commercial deployments of the technology take place.

As such I have prepared a new special article on the issues around regulating robocars. The article concludes that in spite of a frequent claim that we want to regulate and standarize even before the technology has been out in the market for a while, this is in fact both a highly unusual approach, and possibly even a dangerous approach.


Regulating Robocar Safety : An examination of the issues around regulating robocar safety and the case for a very light touch

New regulations are banning the development of delivery robots

Many states and jurisdictions are rushing to write laws and regulations governing the testing and deployment of robocars. California is working on its new regulations right now. The first focus is on testing, which makes sense.

Unfortunately the California proposed regulations and many similar regulations contain a serious flaw:

The autonomous vehicle test driver is either in immediate physical control of the vehicle or is monitoring the vehicle’s operations and capable of taking over immediate physical control.

This is quite reasonable for testing vehicles based on modern cars, which all have steering wheels and brakes with physical connections to the steering and braking systems. But it presents a problem for testing delivery robots or deliverbots.

Delivery robots are world-changing. While they won’t and can’t carry people, they will change retailing, logistics, the supply chain, and even going to the airport in huge ways. By offering very quick delivery of every type of physical goods — less than 30 minutes — at a very low price (a few pennies a mile) and on the schedule of the recipient, they will disrupt the supply chain of everything. Others, including Amazon, are working on doing this by flying drone, but for delivery of heavier items and efficient delivery, the ground is the way to go.

While making fully unmanned vehicles is more challenging than ones supervised by their passenger, the delivery robot is a much easier problem than the self-delivering taxi for many reasons:

  • It can’t kill its cargo, and thus needs no crumple zones, airbags or other passive internal safety.
  • It still must not hurt people on the street, but its cargo is not impatient, and it can go more slowly to stay safer. It can also pull to the side frequently to let people pass if needed.
  • It doesn’t have to travel the quickest route, and so it can limit itself to low-speed streets it knows are safer.
  • It needs no windshield or wheel, and can be small, light and very inexpensive.

A typical deliverbot might look like little more than a suitcase sized box on 3 or 4 wheels. It would have sensors, of course, but little more inside than batteries and a small electric motor. It probably will be covered in padding or pre-inflated airbags, to assure it does the least damage possible if it does hit somebody or something. At a weight of under 100lbs, with a speed of only 25 km/h and balloon padding all around, it probably couldn’t kill you even if it hit you head on (though that would still hurt quite a bit.)

The point is that this is an easier problem, and so we might see development of it before we see full-on taxis for people.

But the regulations do not allow it to be tested. The smaller ones could not fit a human, and even if you could get a small human inside, they would not have the passive safety systems in place for that person — something you want even more in a test vehicle. They would need to add physical steering and braking systems which would not be present in the full drive-by-wire deployment vehicle. Testing on real roads is vital for self-driving systems. Test tracks will only show you a tiny fraction of the problem.

One way to test the deliverbot would be to follow it in a chase car. The chase car would observe all operations, and have a redundant, reliable radio link to allow a person in the chase car to take direct control of any steering or brakes, bypassing the autonomous drive system. This would still be drive-by-wire(less) though, not physical control.

These regulations also affect testing of full drive-by-wire vehicles. Many hybrid and electric cars today are mostly drive-by-wire in ordinary operations, and the new Infiniti Q50 features the first steer-by-wire. However the Q50 has a clutch which, in the event of system failure, reconnects the steering column and the wheels physically, and the hybrids, even though they do DBW regenerative braking for the first part of the brake pedal, if you press all the way down you get a physical hydraulic connection to the brakes. A full DBW car, one without any steering wheel like the Induct Navia, can’t be tested on regular roads under these regulations. You could put a DBW steering wheel in the Navia for testing but it would not be physical.

Many interesting new designs must be DBW. Things like independent control of the wheels (as on the Nissan Pivo) and steering through differential electric motor torque can’t be done through physical control. We don’t want to ban testing of these vehicles.

Yes, teams can test regular cars and then move their systems down to the deliverbots. This bars the deliverbots from coming first, even though they are easier, and allows only the developers of passenger vehicles to get in the game.

So let’s modify these regulations to either exempt vehicles which can’t safely carry a person, or which are fully drive-by-wire, and just demand a highly reliable DBW system the safety driver can use.

Commentary on California's robocar regulations workshop

Tuesday, the California DMV held a workshop on how they will write regulations for the operation of robocars in California. They already have done meetings on testing, but the real meat of things will be in the operation. It was in Sacramento, so I decided to just watch the video feed. (Sadly, remote participants got almost no opportunity to provide feedback to the workshop, so it looks like it’s 5 hours of driving if you want to really be heard, at least in this context.)

The event was led by Brian Soublet, assistant chief counsel, and next to him was Bernard Soriano, the deputy director. I think Mr. Soublet did a very good job of understanding many of the issues and leading the discussion. I am also impressed at the efforts Mr. Soriano has made to engage the online community to participate. Because Sacramento is a trek for most interested parties, it means the room will be dominated by those paid to go, and online engagement is a good way to broaden the input received.

As I wrote in my article on advice to governments I believe the best course is to have a light hand today while the technology is still in flux. While it isn’t easy to write regulations, it’s harder to undo them. There are many problems to be solved, but we really should see first whether the engineers who are working day-in and day-out to solve them can do that job before asking policymakers to force a solution. It’s not the role of the government to forbid theoretical risks in advance, but rather to correct demonstrated harms and demonstrated unacceptable risks once it’s clear they can’t be solved on the ground.

With that in mind, here’s some commentary on matters that came up during the session.

How do the police pull over a car?

Well, the law already requires that vehicles pull over when told to by police, as well as pull to the right when any emergency vehicle is passing. With no further action, all car developers will work out ways to notice this — microphones which know the sound of the sirens, cameras which can see the flashing lights.

Developers might ask for a way to make this problem easier. Perhaps a special sound the police car could make (by holding a smartphone up to their PA microphone for example.) Perhaps the police just reading the licence plate to dispatch and dispatch using an interface provided by the car vendor. Perhaps a radio protocol that can be loaded into an officer’s phone. Or something else — this is not yet the time to solve it.

It should be noted that this should be an extremely unlikely event. The officer is not going to pull over the car to have a chat. Rather, they would only want the car to stop because it is driving in an unsafe manner and putting people at risk. This is not impossible, but teams will work so hard on testing their cars that the probability that a police officer would be the first to discover a bug which makes the car drive illegally is very, very low. In fact, not to diminish the police or represent the developers as perfect, but the odds are much greater that the officer is in error. Still, the ability should be there.  read more »

What governments should do to help and regulate robocars

In my recent travels, I have often been asked what various government entities can and should do related to the regulation of robocars. Some of them want to consider how to protect public safety. Most of them, however, want to know what they can do to prepare their region for the arrival of these cars, and ideally to become one of the leading centres in the development of the vehicles. The car industry is about to be disrupted, and most of the old players may not make it through to the new world. The ground transportation industry is so huge (I estimate around $7 trillion globally) that many regions depend on it as a large component of their economy. For some places it’s vital.

But there are many more questions than that, so I’ve prepared an essay covering a wide variety of ways in which policymakers and robocars will interact.

Read: Governments, The Law and Robocars

Syndicate content