Hacker News new | ask | show | jobs
by DanFeldman 2277 days ago
Ah well, it was great while it lasted.

Most of the engineering team has spread throughout the AV industry, with most folks going to our neighbors and fellow YC company Cruise Automation. Some are at Waymo, Zoox, AutoX, and some purposefully exited the AV space entirely.

I joined Applied Intuition to help build out Simulation and Infra for other companies producing AVs/robotics.

There are a few folks I know of who are still looking for their next roles in the BizOps/PplOps side, which has been especially hard during COVID-19 season if anyone wants to do some linkedin stalking.

3 comments

Hey Dan, could I ask you a few questions about what you learned at Starsky? I have a robotics background and what they tried to do is very very interesting.
Also happy to answer questions (my username might sound similar to the name of the author ;) )
Hey Stefan it’s very nice to meet you! I spent many years at GRASP lab at UPenn and most of my friends from there are at Waymo/Nuro/Cruise now. I do not work at a self-driving car company, but I 100% agree with your sentiment regarding the importance of assessing safety, this has obvious implications in how these cars are insured, and therefore priced and financed. On a separate note, I met a long haul trucker/Russian immigrant in a hacker hostel in Mountain View, and his story was eye opening. He said it was the worst job he ever had, and he was “treated like an animal”. So alleviating his problem is very worthwhile in so many ways. As for questions:

1. Referencing page 5 of your VSSA (1), how were you able to quantify "When weather, traffic or other conditions made driving unsafe." It seems like a tricky problem because this region of the ODD is not discrete such as {warehouse, ramp, highway} but rather depends on the quality of your cv stack as well?

2. In hindsight and with the company behind you, do you think it make sense for each car companies to do self reporting? Or should there be some sort of government oversight/technical validation process done by external 3rd party?

3. I would love to chat more! It must be a very emotional time for you, so I would understand if you do not wish to speak about it. But if you do, could we set up a time at lingxiao@seas.upenn.edu?

[1] https://uploads-ssl.webflow.com/599d39e79f59ae00017e2107/5c1...

Answering these from easiest to hardest:

3) Sure! It isn't too hard to figure out how to email me, so send me a note or DM on twitter or LinkedIn or whatever.

2) AV has been a great testcase for federalism, and I think we've seen different regimes work differently. For the stage that industry is at, I think that insurance requirements is sufficient (insurance carriers have the sophistication to figure out if you're being unsafe). California's regime is overly-prescriptive in such a way that it confuses things more than it improves safety.

To be clear - if we were closer to deployment I'd advocate for a way tighter regulatory regime.

1) We figured out a programmatic way to measure ODD. Trying to specify all versions of ODD is a fools errand, and you're right that it would change a lot by how good you stack is.

ODD = Operational Design Domain. The conditions your system can drive safely in - rain, snow, sunshine, glare, high traffic, no traffic, pedestrians, etc ad infinitum

ok thank you! Sent you a message on Linkedin.
If you don't mind me hijacking this, you mentioned this in the article:

Nevertheless, we found an incredible amount of industry and investor resistance to our teleop-dependent approach.

Why was this the case? I can't see the harm in using teleop.

TBH - In the early days the "cool AV people" seemed to act as if teleop was an admission of bad engineering (your team isn't good enough to perfect L5). If everyone else is right on the cusp, and you're not trying, you must be some sort of loser.

There are still a number of folks who think that teleop can never be safe - surprisingly sophisticated people hold onto that dogma. We wrote a whitepaper about it for investors, and I'll share that at some point as I open up more and more of the Starsky vault.

Those sophisticated people were correct, at least for now (never say never). Teleoperation can work in some limited specific circumstances. But latency, reliability, and coverage of current wireless data networks are insufficient to allow for widespread teleoperation on public roads.
Lidars break. Radars fail. Cameras run into issues. Drive by wire systems malfunction. Computers vibrate to death.

All parts of an autonomous system break. Safety engineering is measuring those breakages, and designing a system that is safe when it inevitably breaks.

If you're the operator, you can choose to only drive on routes that should have sufficient connectivity. If your remote driver is only issuing high level commands (i.e. not responsible for safety) latency starts to stop mattering so much.

The problem here is the availability bias - you've seen your phone fail so you know that telecom links can fail. As a layperson you might not think about how the rest of the system suffers from the same limitations - but they do. You engineer around them.

Most of the engineering team has spread throughout the AV industry, with most folks going to our neighbors and fellow YC company Cruise Automation.

Sounds like most of the engineering team does not share the founder's perspective on the AV industry.

I've worked for 2 hopeless industries. It doesn't prevent me from collecting a paycheck.
Or, you know, all the skills they have from the industry makes it easier for them to get a job in it. Personally, as a lowly peon, I don't really care if my company is fundamentally unprofitable. I care that I get to develop the skills I want to develop.
As recently as February, the founder didn't share the (current) founder's perspective on the AV industry, considering they were trying to secure funding.
Are any of those folks thinking to launch a new robotics oriented start up? I’ve been wanting to get involved with that. (Email in profile)