A research team from MIT built a self-driving car to operate on rural roads, without the need for high-definition maps. HD maps are one of the big limiting factors for self-driving cars, which need the maps in order to localize themselves on the road with near-exact precision.

Unfortunately, HD maps are super-expensive to build and maintain, so any progress on this front is a big deal.

The MIT project, MapLite, uses a combination of open-street map data and lidar data to navigate through unmapped environments. Instead of trying to build a map as it goes (a technique known as “simultaneous localization and mapping”), the vehicle merely uses lidar to identify flat, drivable surfaces, and then identifies a viable trajectory to reach its next waypoint.

All of this seems pretty straightforward, but what really struck me was a seemingly obvious thing they mention in the PR writeup.

“I imagine that the self-driving cars of the future will always make some use of 3-D maps in urban areas,” says [MIT graduate student Teddy] Ort. “But when called upon to take a trip off the beaten path, these vehicles will need to be as good as humans at driving on unfamiliar roads they have never seen before. We hope our work is a step in that direction.”

I had always kind of assumed that vehicles relying on HD maps would be a stuck within their geofences, but of course that’s not necessarily the case. A vehicle could use HD maps in urban areas, and then a non-HD map system in other areas. And of course there could be segments of the world in which neither approach is viable and thus those areas would be completely off-limits (until the mapping gets done, say).

Totally obvious when I write it down, but not something I had ever quite pieced together on my own.

I am excited to travel to India for the first time tomorrow! I’ll be visiting Bangalore, Mysore, Chennai, and Delhi.

My colleagues at Udacity India are helping us to host two student events while I am in India.

On Sunday, May 6, we will be holding a Self-Driving Car Networking Event at 91springboard in Bengaluru from 11am to 1pm. Please come to say hello!

And on Friday, May 11, there will be another Self-Driving Car Networking at the Udacity India office in Delhi.

If you are a Udacity student or graduate, I hope to see you at one (or both, if you are ambitious!). And I am excited to experience India!

Update: I had the day of the week wrong for our event in Bengaluru. That will be on Sunday, not Monday.

Lyft is serious about self-driving cars. Last fall, they announced they were funding 400 scholarships for Udacity’s Intro to Self-Driving Cars Nanodegree Program, with a focus on increasing diversity in the autonomous vehicle industry.

Today, Lyft and Udacity announced the Lyft Perception Challenge to identify top Udacity students to interview for positions on Lyft’s Level 5 self-driving car team.

The project requires students to use computer vision techniques to identify and locate vehicles on the road. These are the same skills taught in the Udacity Self-Driving Car Engineer Nanodegree Program. We are excited to see what students develop even above and beyond what we teach in class!

Udacity Self-Driving Car students and alumni are invited to participate. The top 25 students with US work authorization will earn interviews with Lyft’s team. The top 150 candidates from around the world will be invited to special interview preparation workshops with Udacity’s Career Services team.

Our goal on the Udacity Self-Driving Car Team is to help connect as many students to jobs as possible. We are excited to be working with Lyft to achieve that goal and make self-driving cars a reality for everyone.

Supply & Demand Chain Executive (I confess I did not previously know such a publication existed — did you?) has a brief story that the military is interested in autonomous vehicles.

No surprise there. After all, it was the DARPA Grand Challenge that kicked off the autonomous vehicle revolution.

But this line struck me:

“According to [Undersecretary of Defense Michael] Griffin, 52 percent of casualities in combat zones are attributed to military personnel delivering food, fuel and other logistics.”

The post doesn’t break out what portion of those causalties come from logistics personal who are attacked, versus just plain old vehicle collisions. But it’s plausible that a lot are due to collisions that don’t involve troops being directly under attack.

It’s kind of like the statistic that more Civil War soldiers died from disease than enemy combat. Sometimes it’s the things we don’t think about that are the most dangerous.

My friends and former colleagues at Voyage have released their self-driving car testing process as an open-source repository on GitHub.

Their website also includes concise explanations of the core features:

• Scenario Testing
• Functional Safety
• Autonomy Assessment
• Testing Toolkit

The framework is currently modest, as expected for a first release, but helpful. And the point of the exercise is to engage the self-driving car community in building out a robust, open-source solution to autonomous vehicle testing.

What gets me really excited about this is the potential to create a path toward test-driven development for autonomous vehicles.

The Ruby on Rails world, which was my world for years, is fanatical about testing. They love testing so much. One of Rails’ engineers most beloved development principles is Test-Driven Development.

TDD is the process of designing and developing your code using tests first. The mantra “red-green-refactor” is familiar to any Rails engineer, as TDD requires:

• Writing a test case
• Verifying that the application fails the test case (red)
• Writing the application code to pass the test case
• Watching it pass (green)
• Fixing and improving the application code (refactor)
• Verifying that the application code still passes the test case

Rinse and repeat.

I loved this cycle as a Rails engineer and I love the idea that a public testing framework for autonomous vehicles could provide a red-green-refactor cycle for autonomous vehicle developers.

Take a self-driving car scenario. Watch the virtual driver software fail. Write the code to pass the scenario. Watch the virtual driver pass. Refactor. Verify that the virtual driver keeps on passing that test case forever.

Of course, we don’t need a public, open-source testing framework to do this. Any self-driving car engineer anywhere can use TDD by themselves. But a public test suite would take a lot of the work out of TDD, by pre-specifying the hurdles that developers need to clear.

Hopefully that would lead to safer self-driving cars, sooner.

Didi Chuxing (a Udacity partner, ahem) has been in the news on a few fronts this week, and will probably show up a few more times with the upcoming Beijing Motor Show this week.

On the more traditional, human-driven, ride-hailing front, Didi is moving into Mexico, with a new office in Toluca. This seems ever-so-close to the lucrative US market, currently dominated by Uber and Lyft.

In the world of self-driving cars, Didi recently made two big announcements: they are developing “purpose-built” autonomous vehicles, and they are forming the Didi Auto Alliance (“D-Alliance”) to “ develop a full-capacity vehicle operator platform”.

Building a self-driving car from scratch seems like a pretty big deal to me. Tesla is famously struggling with the challenges of manufacturing a car, and even automotive manufacturers like GM/Cruise are basically re-purposing existing vehicles into self-driving cars.

By contrast, Didi believes:

“…current mainstream cars are heavily “overspecced” — packed with equipment most drivers do not need such as engines and other technologies that allow them to go as fast a 150 mph (250 kmph).

Performance levels for ride-hailing and car-sharing service vehicles could be dialled down significantly, meaning they would not have to be so aerodynamic. Cars designed to carry just one or two people at a time to work or the shops could therefore be “boxier”, with fewer seats and more space for luggage.”

I’m excited to see what Didi comes up with for its “purpose-built” self-driving cars. Big risk, big reward.

The first Monday in April, California opened its doors to autonomous vehicles with no safety driver — truly “driverless” cars.

Only one company, that has not been named, expressed interest.

A few weeks later, a second company applied for a driverless permit, Waymo.

Waymo is working with a number of California cities to set up driverless tests, several of which appear quite enthusiastic to be working with the leader in self-driving cars.

“Autonomous vehicle technology “is going to be crucial in helping the Silicon Valley reach its safety and transportation goals,” said Los Altos Councilwoman Jeannie Bruins.

“Waymo has done extensive vehicle testing on our local streets with a good safety record,” Mountain View City Manager Dan Rich, said in a statement. He commended the company for committing to “transparency and information sharing.”

In Sunnyvale, Mayor Glenn Hendricks likewise said he looks forward to working with Waymo.”

One angle I found interesting is how Waymo will handle disengagements:

“If one of the cars encounters something it doesn’t understand, such as complicated road construction, the car will contact Waymo for help recognizing the situation. After human testers give it feedback, the car will then decide how to navigate the situation.”

I wonder what it means for a remote “human tester” to “give feedback” to a Waymo vehicle.

And don’t forget, from my old colleague Oliver Cameron: