Hardware 3.0 Increase Non-EAP/FSD Features?

[Knightshade]

But, we can agree that EAP should recognize speed limit signs right? Or at the very least it's database of speed limit signs should be significantly improved. In my experience the navigation system has a really bad database of speed limits, and it's constantly wrong.

Sure, I'd agree with that.

We're pretty far along in the development of HW2/HW2.5, and they still don't have speed limit sign recognition. But, it's been claimed that Tesla has working sign recognition with NN's running on HW3.

I thought that was stop signs he was talking about?

Anyway- I'd be pretty surprised if they don't have the ability to add reading speed limits with HW2 as well but it's been lower priority than things like Nav on Autopilot. I mean, AP1 did it and the AP2 computer is more capable than that one.

The dashcam isn't a "hard" feature to write- and that's a pretty recent addition too.... (with Sentry mode coming next week allegedly to do more).

They don't have infinite programmers.

So it seems doubtful to me that we'll see any kind of speed sign recognition with HW 2.X, and instead Tesla will try to get sign recognition within HW3 as quickly as possible.

Again I don't think that's true- there's no technical reason HW2 can't do it, they just have had higher priorities.

That way it can be released to fleet of HW3 vehicles (once they start making them) where it can also be used to improve Tesla's database of speed limit signs to improve the situation for people with HW 2.X.

That's certainly also a possibility if they decide the programming resources are better spent elsewhere- I'm just saying there should be no technical reason AP2.x can't do it.

EAP and FSD being separate code bases doesn't support the approach Tesla is taking to FSD. Despite how they sold them they're taking an incremental approach.

In my own experience with NN's it's pretty painless to have separate ones depending on the needs of it, and the capability of the hardware that's running the neural network. It's not like having separate code bases for an application.

I see no reason at all to have a separate codebase for FSD. Instead it's simply going to be growing the EAP code base, and HW 2.x cars will just get left behind. Maybe a neutered version of it.

So I see

Simplified NN on HW2.X that will largely be in maintenance mode.
Advanced NN on HW3 that will be under active development

The disappearance of any kind of separation between EAP/FSD from within the codebase on a HW3 vehicle. Now I'm not saying that Tesla won't monetize some kind of FSD feature like limited L3 driving on the freeway. But, it's only going to be a SW enable flag.

It's also going to disappear because FSD has always been a false promise. This pie in the sky thing that the car is simply not capable of doing. So it makes way more sense to me to abandon that approach entirely, and to leverage the fleet of vehicles to improve the entire Autopilot frame work gradually.

Go to a single codebase with HW3
Improve NoA (an EAP feature) to where it's basically L3 capable, but only allow L3 to people who pay specifically for it (like FSD owners today). Try to get it within 2019 so we're not beat by other car companies.
Add rear radar with the Model Y (to augment the cameras)
Add more and more things to the database of stuff the car can recognize.

Certainly possible- though I think from a business perspective having EAP and FSD as separate products, once FSD actually does exclusive things, is a better idea.

More importantly though- they kind of have to do that to avoid owing free HW3 upgrades to EAP buyers like they do FSD buyers.