Baidu is competing with the Udacity Open-Source Self-Driving Car 😛

I jest, of course. Baidu is going to release a “free” operating system for self-driving cars, although the news leaves unclear whether this will be “free, as in lunch” or “free, as in speech”.

But Baidu’s goal quite clearly seems to be commercialization, whereas Udacity’s project is primarily educational.

The article in the MIT Technology Review supposes that Baidu is undertaking this as a catch-up move in a race with the Silicon Valley giants. Perhaps by getting more companies on its operating system, it can get more data.

If so, this really does look like a repeat of the mobile phone wars, and Baidu might need to be prepared to spend a lot of money to support its free operating system.

In addition to being my boss, Sebastian Thrun is a legend in the field of autonomous vehicles.

We’ll be filming a Q&A with him this week about self-driving cars and the Udacity Self-Driving Car Nanodegree Program.

This is an awesome opportunity to pick the brain of the winner of the DARPA Grand Challenge, the founder of the Google Self-Driving Car Program, and the driving force between the Udacity Self-Driving Car Nanodegree Program!

Submit questions here: https://goo.gl/forms/I8Ik3n0g1EZjFneG2

Video posts on Friday!

Self-driving trucks have been a concept in mining operations for many years, because of the well-structured, private roads and dependable routes. Dump trucks basically drive the same route over and over, which makes them an ideal target for autonomous technology.

Diginomica has a good rundown of Caterpillar’s latest work on self-driving mining vehicles in Australia.

“Fortescue Mining Group’s Solomon Hub comprises the Firetail and Kings Valley iron ore mines in the Pilbara region of Australia’s North West which together have a production capacity of over 70 mega tonnes each year. When the project was scoped in 2010, the initial feasibility study called for 75 manned trucks but in July 2011 FMG ordered 12 autonomous 793F vehicles as a pilot. Now with the mines up and running, FMG operates 54 driverless dumpsters which alone results in a $100 million capital saving on twenty trucks.”

There’s also this:

“By replacing the drivers, Westrac and Caterpillar also found they can make further cost savings by eliminating some comfort and safety features on the trucks with weight savings of up to four tonnes per vehicle.”

I’ve had a few people come to me recently asking about how to get up and running in this industry. I’m not that knowledgeable about mining, but the fact that people are asking makes me think this isn’t yet a solved problem.

The California DMV reported this week that it had granted Apple a license to test three autonomous vehicles, and the Internet went wild.

Apple’s autonomous vehicle work has been an open secret for a few years, so I’m skeptical that this announcement will change much or lead the way to a more meaningful understanding of what Apple is working on.

Beyond just Apple, though, this has me back to thinking about the tradeoff between stealth and transparency.

Transparency in product development seems like an aggressive approach. By opening up about what they’re doing, companies hopes to attract the best talent, the best partners, the earliest and best customers.

Conversely, a stealth approach seems cautious. Companies developing products in secret seem nervous with competitors and the press. Competitors might steal key elements of a developing product, while the press might pressure a company to alter its schedule or pricing or go-to-market strategy.

All else equal, it seems more fun to be aggressive than cautious, but of course all else is never equal. A company is in a good position and has a lot to lose has a lot more reason to be cautious and stealthy. A company in poor position, with nothing to lose, is likely to act aggressively and transparently.

What gets interesting is when companies like Apple, which seems to have nothing to lose in the automotive industry, approaches product development secretively, perhaps because of its culture.

When GM announced its $1 billion acquisition of Cruise Automation, I was skeptical. Cruise was a San Francisco software startup; GM is a venerable American automotive company with a bureaucracy that I presume is optimized for rolling vehicles off the assembly line. It was not obvious that this was a match made in heaven.

But the acquisition is now over a year old and it seems to be working out really well.

The most recent news is that GM will be adding 1100 jobs to its San Francisco office over the next five years.

Self-driving Chevy Bolts are maybe not quite ubiquitous in San Francisco, but they’re normal enough to make me guess that GM is probably the number two tester of Level 4 autonomous vehicles in the Bay Area (and the world?), after Google.

Last fall, I went with some Udacity colleagues to a Silicon Valley Artificial Intelligence event that hosted a panel of speakers from startups in the world of self-driving cars.

One of the speakers was Austin Russell from a then-stealth company producing lidar. We asked his colleague about the name of the company and were told it was a secret.

Later in the event, the crowd started goading another attendee, George Hotz, into grilling the speakers. George rose to the occasion and asked Austin, “So, this all sounds great, but when is Luminar going to ship?”

So much for keeping the name secret.

This week, Luminar went public with all sorts of details about the company, their product, and the first-ever production run of sensors, starting this year.

Austin is a colorful and likeable character, and most of what I’ve read about Luminar quotes him stressing the superior performance of Luminar’s lidar sensors.

That’s awesome, but the main issue with lidar right now seems to be cost and volume, not performance.

Since Luminar has already talked about building 10,000 units, my question might be, what’s the cost?

Wired has a good article out about hacking autonomous vehicles, and about “autonomotive attack surfaces” in particular.

The article centers on Charlie Miller, who several years ago hacked a Jeep and took it over remotely while it was driving on the highway (don’t worry, it was a demonstration, not a malicious attack).

Miller talks about the interesting problem of securing vehicles from ride-sharing passengers. In a world where anybody can hail and hop into a self-driving Uber or Lyft, securing those vehicles from hackers who are physically in the car can be a huge challenge.

One example is a hacker who gets into a self-driving car, uses the OBD-II port to install software on the system, and then gets out. Later on, the hacker might use the latent software to take over the car when other riders are inside.

Gives a whole new meaning to “carjacking”.

Miller talks about the “attack surface” of vehicles, which encompasses any opening an attacker can use to hack a vehicle. A quick search for “automotive attack surface” led me to the graphic above, which comes from an academic research paper by Checkoway, et al.

“We discover that remote exploitation is feasible via a broad range of attack vectors (including mechanics tools, CD players, Bluetooth and cellular radio), and further, that wireless communications channels allow long distance vehicle control, location tracking, in-cabin audio exfiltration and theft.”

The further complication is that ridesharing companies are often layering their self-driving software and hardware on top of production automotive vehicles, built by somebody else. It creates a situation where the manufacturer may not design the car to be secure in the same ways that the after-market modifier (in this case, the ridesharing company) needs.