News and commentary from AUVSI/TRB Automated Vehicle Symposium 2017


In San Francisco, I'm just back from the annual Automated Vehicle Symposium, co-hosted by the AUVSI (a commercial unmanned vehicle organization) and the Transportation Research Board, a government/academic research organization. It's an odd mix of business and research, but also the oldest self-driving car conference. I've been at every one, from the tiny one with perhaps 100-200 people to this one with 1,400 that fills a large ballroom.

Toyota Research VC Fund

Tuesday morning did not offer too many surprises. The first was an announcement by Toyota Research Institute of a $100M venture fund. Toyota committed $1B to this group a couple of years ago, but surprisingly Gil Pratt (who ran the DARPA Robotics Challenge for humanoid-like robots) has been somewhat a man of mixed views, with less optimistic forecasts.

Different about this VC fund will be the use of DARPA like "calls." The fund will declare, "Toyota would really like to see startups solving problem X" and then startups will apply, and a couple will be funded. It will be interesting to see how that pans out.

Nissan's control room is close to live

At CES, Nissan showed off their plan to have a remote control room to help robocars get out of sticky situations they can't understand like unusual construction zones or police directing traffic. Here, they showed it as further along and suggested it will go into operation soon.

This idea has been around for a while (Nissan based it on some NASA research) and at Starship, it has always been our plan for our delivery robots. Others are building such centers as well. The key question is how often robocars need to use the human assistance, and how you make sure that unmanned vehicles stay in regions where they can get a data connection through which to get help. As long as interventions are rare, the cost is quite reasonable for a larger fleet.

This answers the question that Rod Brooks (of Rethink Robotics and iRobot) recently asked, pondering how robocars will handle his street in Cambridge, where strange things like trucks blocking the road to do deliveries, are frequently found.

It's a pretty good bet that almost all our urban spaces will have data connectivity in the 2020s. If any street doesn't have solid data, and has frequent bizarre problems of any type, yet is really important for traversal by unmanned vehicles -- an unlikely trifecta -- it's quite reasonable for vehicle operators to install local connectivity (with wifi, for example) on that street if they can't wait for the mobile data companies to do it. Otherwise, don't go down such streets in empty cars unless you are doing a pickup/drop-off on the street.

Switching Cities

Karl Iagenemma of nuTonomy told the story of moving their cars from Singapore, where driving is very regulated and done on the left, to Boston where it is chaotic and done on the right. The short summary is that the switch was harder than they expected. At the same time, I feel that if a small company like nuTonomy can do it, it is not a big burden globally. That's important because it reflects on the question of whether we need one single set of regulations across the United States or Europe, or if it's better to have a patchwork with jurisdictional competition allowing innovation in how vehicles are regulated.

How much testing do vehicles need?

Nidi Kalra of Rand spoke about their research suggesting that testing robocars is an almost impossible task, because it would take hundreds of millions to a billion miles of driving to prove that a robocar is 10% better than human drivers.

This paper was published last year but I didn't comment on it. I will post a more detailed commentary on it (and the reaction to it) shortly.


Jonathan Petit presented interesting results previously at this meeting about his attacks on LIDARS. Tired of holding breakout workshops on security and nothing happening, he decided instead to just challenge the audience to E-mail him and others about their security concerns and plans. With 1,400 attendees, he got 4 responses. This crowd at least, is not taking security properly. Of course, only some portion of the room are actual developers of robocars. Most are researchers and academics and non-engineers. Still, the result is disappointing.


The breakout on "what happens after an accident" day #1 was off-the-record, but a few general observations:

  • The police representative didn't think there would be major changes in police investigations. They don't seem to think the full 3-D recordings of the accidents in the cars will be easy to get their hands on so they'll go about things the same way as before.
  • Trial lawyers argued about whether the standard of strict liability -- pay if you caused the accident -- rather than payment only when negligence is found, might become the norm.

Automakers are torn on this issue. On the one hand, who wants to pay if you weren't negligent? On the other hand, it is only with negligence findings that high liability can be found. The cost of discovering the reason for a robocar's error will be very high, with detailed code examination, and deposition of all programmers and expert witnesses. It may be simpler to pay every time than to have complex and costly lawsuits half the time, if you seriously reduce the number of accidents.

On the other hand, many states have liability caps on accidents which would preclude cases getting very expensive. If the max payout is $300,000 you aren't going to spend a million trying to get it, and you have no reason to refuse a settlement near that cap number.


The AVS has a lot of governmental people, and they're all very keen to imagine their role, which they see as making the infrastructure "ready" for robocars. There was a whole long session on the topic, and many people who imagine there is a lot to do.

This is the wrong impression. Robocars are being designed to handle the infrastructure we already have, and only low-skill robocar makers are suggesting we need to make significant changes to the infrastructure to enable these vehicles.

For example, some automakers, making very basic camera based lanekeeping systems which find the lanemarkers using various algorithms have complained that they are poor quality on many roads. But Google, who actually got cars on the road first, designed their system to not require any quality from the lane markers. In fact, Google's cars only need lane markers to be sure the humans know where to drive, and to know where to put the lanes in their internal maps. (They do want lane markers if the road has had new construction and has changed from the maps.)

Google's algorithms actually prefer badly painted lane markers, because they find their location by matching the texture of the road, which includes holes in lane markers, road repairs and many other factors. It's not a human way of driving, of course, but it doesn't expect the road to change to suit the car.

For almost any proposal I have seen for how we might make infrastructure "robocar ready" there is a far cheaper and faster-to-develop solution that involves having the cars get smarter. Infrastructure change is only needed if there is a compelling case for why a fix in software can't be found, or a case for why it can't be done in virtual infrastructure.

Indeed, almost all the activity of infrastructure maintainers should focus on maintaining the virtual infrastructure instead. They should work to make sure roads are changed without logging it in a database, that road signs are all logged in databases and new ones don't go into force until logged in the databases. Such logging isn't hard -- it's as simple as a mobile app on the phones of the crews who install new signs or make other changes, and strong rules requiring use of the app. For example, severe financial penalties for not logging changes in the app.

I continue to advance the proposition that "you don't change the roads to suit your cars, you improve your cars to deal with the roads we have." At least for the near future.


It's no surprise my favourite session was one I spoke at, the Shark Tank. We saw 4 proposals on how robocars will change the world, and we sharks got to debate the issues around them with the audience. I didn't just like the session because of my own participation as a shark. Unlike many sessions it also had a lot of audience involvement. The 4 propositions we tackled were:

  • Congestion will go away
  • Transportation agencies will shrink, and so will transit agencies
  • Trucking will be quickly revolutionized
  • Car ownership will end

Surprisingly, the proposal from the libertarian Reason magazine representative for the withering of these agencies got almost no opposition. While I have felt this is likely myself, I did not expect a room of others to agree. There was much more dispute around congestion. More were skeptical of my proposals that we might meter trips with smartphones to reduce congestion than I had hoped.


The event closed with a summary of various international efforts. This matched my impression from the recent conference in Germany -- in most of the rest of the world, government involvement is quite high, but also highly non-productive. The budget size of many of the EU and Japanese funded projects for example, far exceeded the budget of Google's early efforts, yet Google produced an impressive car while the EU projects produced only minor results.

Particularly popular all over the whole world these days is the forming of consortia and alliances which sound impressive but accomplish very little. I can't escape the feeling when I see the announcement of a new alliance or partnership which does not actually say what concrete thing will be done by the alliance that it's mostly for show, and not for real work.

Going forward

This conference began as the only self-driving conference and has grown. The problem with the growth is that most of the audience is new to the conference and the field. This pushes the sessions to be "dumbed down" with too much introductory background. While I am more informed than the average attendee, and will never get the perfect conference for me, I would like to see the sessions focus more on truly new things, things that are surprising. Companies who present have been told not to do marketing pitches or old news, the same has to apply to academics. This is challenging because academics spend a lot of time doing rigourous verification of things that are obvious. That's a worthwhile task, but not right for the main stage of a joint industry/academic event. That's why I liked the shark tank -- it had a focus on issues about which informed people disagreed. That guarantees that much of the audience will be surprised by what they learn.

Coming up this week: Testing durations, and a new satire on the NHTSA levels and other regulation.


You commented on the lack of interest in the ability to hack lidar or other sensors.
Another area of security that would seem to be crucial is for installing updates. If updates are automatic, then secure, authenticated connection are vital. Should we allow users to browse to download updates? Should we require an owner to physically visit a tecnician to install and verify the status. Software installation is in concept very simple, but in the real world made very complicated by version proliferation.
For safety critical software, paring back the proliferation of component versions and the environments the can be installed to is vital.
Of course communication is 2 way. Logging from vehicle to manufacturer must also be validated. I suppose a number of obvious filters could be on place evev if someone could send fake data. The scenario needin to obey the laws of physics could be one. Could go on, but typing from a crappy phone.

I have an upcoming article on this, with a fairly radical proposal. Stay tuned.

Related to the Shark subject, what do you think of the Rethinking Transportation paper published by RethinkX? Are you along the same lines?

Add new comment