Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tesla reports another Robotaxi crash

electrek.co

Post reply on HN
Print view View original

81–90 of 165 posts

Re: Tesla reports another Robotaxi crash

#81

Post by fragmede »

karlgkk wrote: post #50
guywithahat wrote: post #43

Earlier quoted context omitted.

What I've heard out of Elon and engineers on the team is that some of these variations of sensors create ambiguity, especially around faults. So if you have a camera and a radar sensor and they're providing conflicting information, it's much harder to tell which is correct compared to just having redundant camera sensors. I will also add in my personal experience, while some filters work best together (like imu/gnss)…

Counterpoint: Waymo > solid engineering defense for moving towards just computer vision COUNTERPOINT: WAYMO

We don't know enough about the internals of either one of them to make a judgement. The only one that is, is Comma.ai.

Re: Tesla reports another Robotaxi crash

#82

Post by jauntywundrkind »

TheAmazingRace wrote: post #4

When you have a CEO like Elon who swears up and down that you only need cameras for autonomous driving vehicles, and skimping out on crucial extras like Li-DAR, can anyone be surprised by this result? Tesla also likes to take the motto of "move fast and break things" to a fault.

I just find it distracting to pretend like we know exactly what albatross to hang around the neck of the problem here. While I do tend to think lidar is probably useful, I also think this isn't a solved shut knowable case where the lidar absolutely is essential & makes all the difference. Making assertions like this rests more assurity than I think can be granted, and harms the overall idea: that Tesla doesn't seem to have serious proof that their things are getting better, that they are more trustworthy.

The data is just not there for us outsiders to make any kind of case, and thats the skimping out crucial baseline we need.

Re: Tesla reports another Robotaxi crash

#83

Post by bulbar »

guywithahat wrote: post #15
TheAmazingRace wrote: post #4

When you have a CEO like Elon who swears up and down that you only need cameras for autonomous driving vehicles, and skimping out on crucial extras like Li-DAR, can anyone be surprised by this result? Tesla also likes to take the motto of "move fast and break things" to a fault.

The more I've looked into the topic the less I think the removal of lidar was a cost issue. I think there are a lot of benefits to simplifying your sensor tech stack, and while I won't pretend to know the best solution removing things like lidar and ultrasonic sensors seem to have been a decision about improving performance. By doubling down on cameras your technical team can remain focused on certain sensor technolo…

Sure, but Tesla is already losing the race. They were ahead a few years ago, but not anymore. They bet in getting autonomous driving done with cameras only that are cheap and have a simple and will understood tech stack and ecosystem.

It didn't work out though and now multi sensor systems are eating their lunch.

Re: Tesla reports another Robotaxi crash

#84

Post by mmooss »

kstenerud wrote: post #78

There's a lot of editorializing going on. Now that the title has been restored, hopefully things calm down a bit. Ultimately, Tesla has two problems going on here: 1. Their crash rate is 2x that of Waymo. 2. They redact a lot of key information, which complicates safety assessments of their fleet. The redactions actually hurt Tesla, because the nature of each road incident really matters: EVERY traffic incident must…

The redactions also indicate they are hiding something and deprioritize safety below (whatever they are hiding). That is, it makes Tesla not trustworthy with something that risks life and limb.

Re: Tesla reports another Robotaxi crash

#85

Post by bulbar »

guywithahat wrote: post #43
_aavaa_ wrote: post #25

Earlier quoted context omitted.

Having multiple sources of data is a benefit, not a problem. Entire signal processing and engineering domains exist to take advantage of this. Even the humble Kalyan filter lets you combine multiple noisy sources to get a more accurate result than would be possible if using any one source.

What I've heard out of Elon and engineers on the team is that some of these variations of sensors create ambiguity, especially around faults. So if you have a camera and a radar sensor and they're providing conflicting information, it's much harder to tell which is correct compared to just having redundant camera sensors. I will also add in my personal experience, while some filters work best together (like imu/gnss)…

Your logic is correct, however these challenges can be solved and then you get synergy effects from using different sensors.

Re: Tesla reports another Robotaxi crash

#86

Post by mmooss »

_ea1k wrote: post #74

I spent a little bit of time poking at Gemini to see what it thought the accident rate in an urban area like Austin would be, including unreported minor cases. It estimated 2-3/100k miles. This is still lower than the extrapolation in the article, but maybe not notably lower. We need far higher quality data than this to reach meaningful conclusions. Implying conclusions based upon this extrapolation is irresponsible.

I don't understand how Gemini's fabrication has any validity. What is it based on?

Re: Tesla reports another Robotaxi crash

#90

Post by goosejuice »

xp84 wrote: post #59
goosejuice wrote: post #53

Earlier quoted context omitted.

Nevermind the Waymos rolling by stopped school busses. https://www.npr.org/2025/12/06/nx-s1-5635614/waymo-school-bu...

This seems solvable, no? Not saying it isn’t really damn important, but those have stop signs and flashing lights. It seems like they can fix that.

Solvable yes, but it's a perfect example of it not being solved yet despite this person's anecdotes.

Engineering problems aren't limited to a single solution anyhow. Anyone ruling out a camera based solution has very little imagination.

Post reply on HN