Today I took my two month-old son to see the Cubs beat the Athletics 3–1 (yay!) at the Oakland Coliseum.

As usual, I parked in my secret parking spot on a street just outside the Coliseum lots and walked in, saving $20.

But man those parking lots are immense.

They stretch for hundreds of yards in almost all directions away from the stadium.

The A’s don’t actually draw that big a crowd, and although the Warriors sell out next-door Oracle Arena, that’s not the reason either. Basketball arenas, like Oracle, are relatively small.

The reason is football.

Oakland Coliseum is the last remaining shared football-baseball stadium in America, and football stadiums draw upwards of 60,000 people per game.

Most of those people need to park their cars. Hence the vast parking lots.

This is what network analysts call “peak load” — the highest level of demand for a service over a time period.

Peak load for the Oakland Coliseum comprises the eight home games the Oakland Raiders football team plays every year (more in the rare years they host a playoff game).

And yet this entire infrastructure, including parking lots, access roads, signs, and more, is built to support those eight Sunday afternoons.

How will self-driving cars change this?

For starters, imagine that most people use a transportation-as-a-service provider, instead of driving themselves.

The parking spaces won’t be necessary, but stadiums will need multitudes more drop-off locations for the beginning of games.

And image the game endings, with 60,000 people streaming out of the stadium, each looking for their own ride-share.

Maybe it will wind up like the airport taxi system, where only one provider is authorized to operate on stadium grounds, and everyone lines up for that stream of ride-shares.

Or maybe it will look similar to that, but with designated locations for multiple providers.

The biggest change might be optimizing for throughput instead of storage. Twice as many cars might have to come in and out, and people will be less tolerant of waiting. But none of those cars will stick around.

Anyhow, it’s kind of an interesting problem in traffic engineering.

Yesterday our VP of Engineering, Oliver Cameron, tweeted about our latest progress building out a self-driving car simulator.

https://twitter.com/olivercameron/status/761700019917377537

This is a project we started about a week ago, and it’s a lot of fun. We’re using the v-rep simulator package, because it comes with pre-built camera and radar objects that work nicely.

One of the surprises I encountered when we began working on this project was the lack of a standardized simulator platform in research or industry.

At Ford, we used a proprietary, in-house simulator.

In the public domain, there are a few simulator packages with moderate adoption, such as ROS and TORCS, but nothing that stands head and shoulders above the field.

There also exists the potential to build out a simulator using a game engine like Unreal, Unity, or Blender. But I worry we’ll spend too much time re-inventing the wheel if we go that way.

We’re taking a first pass with v-rep, and we’ll see how it goes, but if you’ve got a great solution for an automotive simulator, please let me know!

Big news of the day is that supplier Delphi Automotive will be launching a self-driving taxi service in Singapore in 2017. The service will start along fixed routes and evolve into a go-anywhere service by 2019.

This is big news for a couple of reasons.

1. This is faster than most people expected self-driving cars to launch, even accounting for the fact that Singapore is a pretty small geofenced area.
2. Delphi is a Tier 1 supplier that derives substantially all of its revenue from sales to OEMs like GM and Ford. By launching a self-driving taxi service, Delphi will be competing head to head with them.

Reports also indicate that the startup nuTonomy will be launching a taxi service simultaneously, although this has been news for several months and isn’t a surprise.

That Delphi is capable of launching this kind of service isn’t hugely surprising, either. Delphi built a self-driving car that traveled across the US autonomously a few years ago. They seem to be the most advanced supplier in terms of autonomous capability.

But from a business perspective this is a risky proposition for Delphi.

By placing autonomous vehicles in the market, they’ll be miles ahead of competitive suppliers in this space.

But it’s not clear if any of the OEMs will want to buy from them, if they view the revenue as financing a competitor.

I saw a headline this morning about a scientist in Australia who thinks self-driving cars will be mandatory by 2030. That sounds great, but color me skeptical.

More interesting to me was the venue at which he was speaking — the Australian Asphalt and Pavement Association.

Pavement is one of overlooked elements of the autonomous revolution, and I need to learn more about it. Mostly, we just talk about pavement as a problem because the US doesn’t maintain its roads well.

However, smart pavement seems like a big opportunity. An awful lot of the logic in an autonomous vehicle is dedicated to figuring out what’s going on with the pavement. If the pavement could communicate up to the car, that would obviate the need for a lot of sensors.

Beyond that, smart pavement provides revenue opportunities (per-mile tolls, perhaps), communication (data networks could be built into the pavement), traffic monitoring, and a host of other benefits.

Tim Sylvester, a reader and contributor here, has a company called Integrated Roadways in Kansas City that works on exactly this problem. They’re working with the Missouri Department of Transportation to turn road maintenance into a revenue-generation opportunity for the state.

I kind of suspect that’s the only way we’ll get better roads — if they become revenue centers instead of cost centers.

I just had lunch yesterday with a young engineer who works for a big SaaS software firm and would love to get a job working on autonomous vehicles. But, he asked, how hard is that to pull off without going to grad school?

Later yesterday I responded to some inquiries from potential Udacity students about jobs in the self-driving car industry. Same question: do I need a PhD to land a job in the industry?

At Udacity we are building a Self-Driving Car Nanodegree and we’re doing it because there’s a huge interest in this area and companies need to hire a lot of engineers! We wouldn’t be doing it if we thought you had to get a PhD to work on self-driving cars.

A lot of that demand for engineers, it turns out, comes from the transition of autonomous vehicles from research to production.

Until recently, autonomous vehicles were largely under the umbrella of the research divisions of large companies. Those research divisions are much smaller than production divisions, and they’re staffed by folks with sterling academic credentials — PhDs in computer vision and deep learning and robotics. They’re great at pushing the cutting edge.

What research divisions are less great at is pushing out products, because they’re not designed for that.

Production divisions tend to be staffed by terrific engineers who are focused on shipping code. These engineers are often not PhDs or cutting-edge researchers. They’re more oriented towards getting a product built, testing it, and scaling it.

There also tend to be a lot more engineers, just in absolute numbers, in production areas than in research.

The migration of autonomous vehicles from research to production is a big reason why this is a terrific time for engineers to move into the field of autonomous vehicles.

As my friend Jinesh from Ford said:

“It’s helpful to know C++ or to have experience with human-machine interaction. But being adaptable and a quick learner is more important since companies that design and build robotic cars may be using a different mix of technologies or applying them in different ways.”