Tesla tried for the moonshot - They wanted a consumer car with cheap sensor hardware to perform the job. Trusting that computing "smarts" could solve the rest of the problem.
I'm in Atlanta where Waymos have started popping up left and right - the sensor bank on these things is HUGE. You can spot 'em from way far off... Giant sensors on top. Big sensors on the front wheel wells back wheel wells, big sensors on both front and back. Big sensors basically all over them.
I'm of the opinion now that Tesla was just way, WAY off base about what sort of requirements exist for sensing, and that they don't, in fact, have much more real world training data because their data is just garbage from the cameras.
Waymo is winning because Waymo accepted the actual requirements early. Tesla is off in lala land with a dead end solution. Lots of great marketing from tesla... but very little progress now in years. They really seem stuck in a local optimum with the camera-only approach, and it's not close to delivering the promised experience.
Except, they took even that out because a certain someone leading the company thought they don’t need the sensors. It’s like someone trying to figure out how to make a bicycle balance itself and they decide to take the wheels off.
Have you looked at their financials? They're terrible.
My feeling is that Waymo has the data advantage.
Tesla can scale by simply adding vehicles.
Between Elon having personally alienated voters in cities and Tesla's continued reliance on remote drivers, Tesla's ability to produce these vehicles seems low on the list of scaling constraints.
This is a crippling disadvantage. Consider what it takes to evaluate a single software release for a robotaxi.
If you have a simulator, you can take long tail distribution events and just resimulate your software to see if there are regressions against those events. (Waymo, Zoox)
If you don't, or your simulator has too much error, you have to deploy your software in cars in "ghost mode" and hope that sufficient miles see rare and scary situations recur. You then need to find those specific situations and check if your software did a good job (vs just getting lucky). But what if you need to A/B test a change? What if you need to A/B test 100 changes made by different engineers? How do you ensure you're testing the right thing? (Tesla)
And if you have a simulator that _sucks_ because it doesn't have physics-grounded understanding of distances (i.e. it's based on distance estimates from camera), then you can easily trick yourself into thinking your software is doing the right thing, right up until you start killing people.
Another way to look at it is: most driving data is actually very low in signal. You want all the hard driving miles, and in high resolution, so that you can basically generate the world's best unit testing suite for the software driver. You can just throw the rest of the driving data away -- and you must, because nobody has that much storage and unit economics still matter.
This is to say nothing of the fact that differences between hardware matter too. Tesla has a bunch of car models out there, and software working well one one model may not actually work well on another.
In reality, just shovelling data into a box is not sufficient.
https://x.com/niccruzpatane/status/1928477936845226469
https://x.com/TeslaCamera/status/1929167075731239226
https://x.com/friscolive415/status/1881181885445063041
https://x.com/LAMultiBroker/status/1885370114054512921
https://x.com/ananayarora/status/1808679192432927153
https://x.com/niccruzpatane/status/1929590206488883246
https://x.com/TheTrailerDan/status/1934618081881370766
https://x.com/JeffTutorials/status/1778188663253574035
https://x.com/ScannerPacific/status/1935016023536844960
https://x.com/greggertruck/status/1864836542402797812
https://x.com/neil_csagi/status/1803229926033858746
I could post these all day ...