4 ms·
Problem is, that greatly complicates the problem-solviing process for SD vehicles---you're now trying to build atop a model of the world provided by the vendor,
by fixermark 9y ago
Problem is, that greatly complicates the problem-solviing process for SD vehicles---you're now trying to build atop a model of the world provided by the vendor, with its own faults and quirks (and you probably need an agreement with the vendor to see their code / dissect their model, and now your release schedule depends on their release schedule, etc.). It also makes Uber dependent upon Volvo's buy-in on the project, and that arrangement is fraught in a world where we don't yet know if SD cars are going to damage the business of traditional auto manufacturers 50 years out---Uber wants to be in a place where if a vendor relationship sours, they can pack up and change chassis without a complete overhaul of the SD logic.
If your SD system is supposed to be solving 100% of the same problem anyway, it's best to gut the software you don't control and work with the hardware as directly as you can. The notion of building atop a lower-level abstraction makes for great academia but doesn't work with industrial realities.
- tzakrajs 9y agoThanks for the explanation and I agree that it won't be as easy to build SD for auto braking systems that change from chassis to chassis, but this is what I think people want. People want to have fail safes from different vendors.