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:

China recently released some basic guidelines for self-driving car development. As an American, I don’t always fully comprehend the line in China between private companies and the government. How much guidance to self-driving car developers in China get from published laws and regulations, and how much comes from internal communication with the relevant government agencies?

Here are the public guidelines:

“The rules lay out requirements that vehicles must first be tested in non-public zones, that road tests can only be on designated streets and that a qualified person must always sit in the driver’s position, ready to take over control.”

As best I can tell from English translations, that is the extent of the rules. Presumably there must be more, but I don’t know if the rest is available in Chinese, or if you have to be in the industry there and know the right people to figure it out.