Investor Engineering Discussions

[Knightshade]

Is there deterministic engineering evidence to support these statements? I'd love to see it. This thread is for engineering stuff, and so far, I've seen no engineering evidence to support the conclusion that the current system HW is not capable of L5.

I've only seen Green produce data that is assumed to come to these conclusions.

He's posted about his root access showing Tesla is using both nodes for a single instance of the entire system- because there's not enough compute to run it on a single one...and that over time the spillover to node B has only gotten worse.

They HAD run it on a single one until roughly mid 2020, then they starting having to use compute on the second node for the one instance of the whole system... and increasingly began needing to move more and more there, to the point they're about maxxed out on compute on both nodes now.

Further he mentioned (and just looking at the physical design it's obvious) that cross-node computing is painfully performance-harmful compared to being able to run everything on a single node (the cross-node connect is much slower and narrower for one thing)

None of this is even terribly surprising given Tesla has totally redone the design for FSD more than once since HW3 was designed due to hitting local maximums on the previous designs.


@verygreen is welcome to comment in more detail if he wishes, or you could PM him I suppose since he is a (vaguely) active member here.

Even Douma doesn't seem to deny they're out of compute, he just thinks they will *magic hand wave* somehow fit it all back into a single node eventually somehow with optimizing.

The CA DMV stuff, found here, page 26, shows that Tesla continues to work on L3+ features

"Please note that Tesla’s development of true autonomous features (SAE Levels 3+) will follow our iterative process(development, validation, early release, etc.) and any such features will not be released to the general public until we have fully validated them and received any required regulatory permits or approvals."

Right- and they also, specifically, say that FSDb (internally called city streets) is not L3 and will never be because it does have have an OEDR capable of it.

So the system that lacks stuff to even make it to L3, and is out of compute doing that, is insufficient HW for L3, let alone 5, is a pretty reasonable conclusion to draw.

City Streets’ capabilities with respect to the object and event detection and response (OEDR) sub-task are limited, as there are circumstances and events to which the system is not capable of recognizing or responding

They go on to conclude:

As such, a final release of City Streets will continue to be an SAE Level 2, advanced driver-assistance feature.

The FINAL release of city streets is L2, full stop, because it's not, by design, capable of more. They'll develop and release some future >L2 system (and will doubtless build on what is here now), but what we're testing in the beta (and now wide release) ain't it and wasn't intended to be.

And I'm happy to provide a video of my 2017 X working, without any material difference from perfect conditions, in rain with FSD without the windshield wipers as the hydrophobic coating allows the water to bead and thus not completely blind/obscure the forward camera.

If all the side cams remain entirely clear I'm sure that's true. Which they often, but don't always, do remain.

But that doesn't address the problems I mentioned when they're not.

Below is a recent fsdb drive in moderate rain--front visibility was fine. FSDb was not available due to bad weather anyway. Wiping the fender cams manually "fixed" it later though.

NOTE: I had the 2021 Model 3 driver fender camera replaced a few weeks ago and the car still reports that it is functioning poorly from time to time in perfect conditions. So, this demonstrates that there are separate issues which others might be experiencing that could be causing the system to not function as designed.

FWIW I had a B-pillar cam replaced under similar conditions a while back.

Now it only fails when the camera is dirty, or especially wet, or blinded by the sun-- the sun thing obviously happens in good weather but goes away as soon as the angle changes slightly.... the other 2 go away if I physically wipe the camera off (or just wait for drying in the case of wet)... which is as expected but not conducive to L5 driving with no human.

Regarding redundancy, this is not an aircraft that is inherently unstable/ needs active control. A stopped car has only other cars to worry about.

FWIW Tesla actually DID have redundant steering ECUs until the chip shortage forced them to remove it from some cars FWIW

Tesla cut a steering component from some cars to deal with chip shortage, sources say

Tesla omitted one of two electronic control units in the cars' electrical power assisted steering systems. Tens of thousands of cars are affected, sources say.

www.cnbc.com

The explanation they appeared to gave was since the most advanced public feature, FSDb is L2 only (and always will be) it's not needed....and they can also retrofit the chip back in if they do introduce an L3 or higher system in the future.


And on the original autonomy day showing HW3 they made a big point about redundant nodes in the HW3 computer with one being able to fully fail over to the other seamlessly-- something it clearly can not do today because they need both nodes worth of compute.


That said- a compute node tends to fail (or at least reboot, not necessarily completely permanently fail) far more often than say a power steering rack. And it's likely those authorities who will approve L5 systems will be expecting redundancy here--- the EU regs specifically call out adequate redundancy for the self-driving system for example.

Tack on the fact any car maker will assume liability for an L5 failure it seems likely redundancy here will Be A Thing moreso than worrying about if say a shock goes bad or something.

 

[mongo]

FWIW Tesla actually DID have redundant steering ECUs until the chip shortage forced them to remove it from some cars FWIW

Yah, but feeding one motor/ belt drive. Lose the motor and there goes steering control.

The FINAL release of city streets is L2, full stop, because it's not, by design, capable of more.

"by design" seems a bit strong:

"City Streets’ capabilities with respect to the object and event detection and response (OEDR) sub-task are limited, as there are circumstances and events to which the system is not capable of recognizing or responding"

Current lack of a capability does not imply lack of intent to develop it. Tesla's statement only acknowledges the SW doesn't handle 100% of expected situations.

@Discoducky , FYI plainsite is a Aaron Greenspan honeypot. That's the guy suing Omar Qazi & Elon.

 

[Knightshade]

Yah, but feeding one motor/ belt drive. Lose the motor and there goes steering control.

Don't you still have manual (heavy) control without that motor/belt?

DIY Steering Rack Replacement 2016 Model S

Just had my power steering fail on my 2016 Model S 85D. Car is now out of warranty and Tesla remote diagnostics suggest that a steering rack replacement may be required. Part alone with be £3,000. Following the Tesla recall and Steering Rack motor bolt replacement I had the clicking/popping...

teslamotorsclub.com

This is a guy describing a failure on his S and he was still able to manually drive anyway.

No idea how the FSD computer would deal with that of course.

"by design" seems a bit strong:

"City Streets’ capabilities with respect to the object and event detection and response (OEDR) sub-task are limited, as there are circumstances and events to which the system is not capable of recognizing or responding"

Current lack of a capability does not imply lack of intent to develop it.

I mean, the next line I quoted specifically says they have no such intent to add it to city streets and what's why it will always be L2.

a final release of City Streets will continue to be an SAE Level 2, advanced driver-assistance feature.

Then goes on to explain some future software will instead be what has that capability.... so yes city streets by design lacks it.... and as L2 doesn't need it.

 

[mongo]

Don't you still have manual (heavy) control without that motor/belt?

DIY Steering Rack Replacement 2016 Model S

Just had my power steering fail on my 2016 Model S 85D. Car is now out of warranty and Tesla remote diagnostics suggest that a steering rack replacement may be required. Part alone with be £3,000. Following the Tesla recall and Steering Rack motor bolt replacement I had the clicking/popping...

teslamotorsclub.com

This is a guy describing a failure on his S and he was still able to manually drive anyway.

No idea how the FSD computer would deal with that of course.





I mean, the next line I quoted specifically says they have no such intent to add it to city streets and what's why it will always be L2.




Then goes on to explain some future software will instead be what has that capability.... so yes city streets by design lacks it.... and as L2 doesn't need it.

Sure, manual steering, but topic was FSD redundancy. If people can take over, that's a moot point.

Twas commenting on whether Tesla was purposely not implementing features in city code "by design" versus just not yet having full coverage.
City code that could handle 100% can still be intended as L2 and implemented as such via nag and driver monitoring.

 

[Gigapress]

He's posted about his root access showing Tesla is using both nodes for a single instance of the entire system- because there's not enough compute to run it on a single one...and that over time the spillover to node B has only gotten worse.

Has the “because” part of this statement actually been confirmed or is that conjecture? I don’t know much about what they’re doing but maybe they’re either testing multiple versions or they haven’t bothered to optimize the compute budget since it’s not currently necessary due to human supervision providing the necessary redundancy.

My understanding is that neural nets can be bloated at first and then unnecessary computations leaned out after the architecture has been proven to work well. If so, Tesla may simply be exploiting the fact that they have the extra compute budget instead of wasting time on premature optimization. This might be what James Douma is trying to say.

 

[Discoducky]

He's posted about his root access showing Tesla is using both nodes for a single instance of the entire system- because there's not enough compute to run it on a single one...and that over time the spillover to node B has only gotten worse.

They HAD run it on a single one until roughly mid 2020, then they starting having to use compute on the second node for the one instance of the whole system... and increasingly began needing to move more and more there, to the point they're about maxxed out on compute on both nodes now.

Further he mentioned (and just looking at the physical design it's obvious) that cross-node computing is painfully performance-harmful compared to being able to run everything on a single node (the cross-node connect is much slower and narrower for one thing)

None of this is even terribly surprising given Tesla has totally redone the design for FSD more than once since HW3 was designed due to hitting local maximums on the previous designs.


@verygreen is welcome to comment in more detail if he wishes, or you could PM him I suppose since he is a (vaguely) active member here.

Even Douma doesn't seem to deny they're out of compute, he just thinks they will *magic hand wave* somehow fit it all back into a single node eventually somehow with optimizing.




Right- and they also, specifically, say that FSDb (internally called city streets) is not L3 and will never be because it does have have an OEDR capable of it.

So the system that lacks stuff to even make it to L3, and is out of compute doing that, is insufficient HW for L3, let alone 5, is a pretty reasonable conclusion to draw.




They go on to conclude:



The FINAL release of city streets is L2, full stop, because it's not, by design, capable of more. They'll develop and release some future >L2 system (and will doubtless build on what is here now), but what we're testing in the beta (and now wide release) ain't it and wasn't intended to be.





If all the side cams remain entirely clear I'm sure that's true. Which they often, but don't always, do remain.

But that doesn't address the problems I mentioned when they're not.

Below is a recent fsdb drive in moderate rain--front visibility was fine. FSDb was not available due to bad weather anyway. Wiping the fender cams manually "fixed" it later though.

View attachment 878799








FWIW I had a B-pillar cam replaced under similar conditions a while back.

Now it only fails when the camera is dirty, or especially wet, or blinded by the sun-- the sun thing obviously happens in good weather but goes away as soon as the angle changes slightly.... the other 2 go away if I physically wipe the camera off (or just wait for drying in the case of wet)... which is as expected but not conducive to L5 driving with no human.






FWIW Tesla actually DID have redundant steering ECUs until the chip shortage forced them to remove it from some cars FWIW

Tesla cut a steering component from some cars to deal with chip shortage, sources say

Tesla omitted one of two electronic control units in the cars' electrical power assisted steering systems. Tens of thousands of cars are affected, sources say.

www.cnbc.com

The explanation they appeared to gave was since the most advanced public feature, FSDb is L2 only (and always will be) it's not needed....and they can also retrofit the chip back in if they do introduce an L3 or higher system in the future.


And on the original autonomy day showing HW3 they made a big point about redundant nodes in the HW3 computer with one being able to fully fail over to the other seamlessly-- something it clearly can not do today because they need both nodes worth of compute.


That said- a compute node tends to fail (or at least reboot, not necessarily completely permanently fail) far more often than say a power steering rack. And it's likely those authorities who will approve L5 systems will be expecting redundancy here--- the EU regs specifically call out adequate redundancy for the self-driving system for example.

Tack on the fact any car maker will assume liability for an L5 failure it seems likely redundancy here will Be A Thing moreso than worrying about if say a shock goes bad or something.

I can also SSH into the AP computer, but I can't tell you what is running on each core at any given time, nor can I tell what was loaded into their respective memories. If @verygreen can, then would be happy to see it. If not, non-deterministic. It is also good engineering practice not to waste any clock cycles so packing all available cycles with test code is most likely why each is pegged/max'd (with applicable buffer).

"City Streets" is a phase of development, there's more to come!

Poor weather is being keyed off of wipers it seems. I've been trying to get it to display when wipers are not engaged on my X and I haven't been able to. I find that an interesting data point. The other data point is that on my 3, I can't disable wipers while on FSD (they are on Auto with no way to change the setting). I'm assuming my X's wiper ECU and EPAS ECU does not have a way to enable it without the explicit stalk mechanical setting.

 

[Doggydogworld]

I mean, the next line I quoted specifically says they have no such intent to add it to city streets and what's why it will always be L2.

I'm with you on most points, but this CA DMV thing is silly. FSD is obviously a "Level 4 design intent" system and by law Tesla imust report metrics such as disengagements. Musk refuses to report, so he paid some lawyers to lie prevaricate to the DMV.

 

[mongo]

I'm with you on most points, but this CA DMV thing is silly. FSD is obviously a "Level 4 design intent" system and by law Tesla imust report metrics such as disengagements. Musk refuses to report, so he paid some lawyers to lie prevaricate to the DMV.

A system with a feature set can be
L4 with safety driver
L2 with normal driver
Only differentiator is the manufacturer's declaration.

In the case of California, FSD as implemented fails the Autonomous technology definition due to nag and driver monitoring.
Also fails the Testing definition.

 

[Knightshade]

I can also SSH into the AP computer, but I can't tell you what is running on each core at any given time, nor can I tell what was loaded into their respective memories. If @verygreen can, then would be happy to see it.

I believe he can, because @verygreen posted often about various given items running on Node A, or on Node B, specifically. (for example campaign triggers only happen on Node A)--and has described specific NNs running and where they send their output to, etc... he's welcome to clarify but he definitely seems to have access to seeing many things you're saying you can't based on his remarks.

For example this statement would be flat out impossible to make if he didn't know what was running on each node:

now that they are out of compute they are trying to run different stuff in parallel and redundancy is out of the window even if it was originally planned.

"City Streets" is a phase of development, there's more to come!

Disagree. It's the name of what has commonly been called FSDb. It was called that internally originally, even in the code itself (and continually for a good while in development)- some of the DMV docs specifically call this out. As does Tesla intended to never add an OEDR capable of >L2 to that specific thing....and instead develop a further product in the future that will have that.

Citation from over 2 years ago of the relevant NNs being labeled City Streets in the actual code on the driving computer and getting renamed- coincidentally this is the same month it was released to anybody in the public iniitally (tiny group) and they stopped calling that.

https://twitter.com/x/status/1321950207920250881

Has the “because” part of this statement actually been confirmed or is that conjecture? I don’t know much about what they’re doing but maybe they’re either testing multiple versions or they haven’t bothered to optimize the compute budget since it’s not currently necessary due to human supervision providing the necessary redundancy.

My understanding is that neural nets can be bloated at first and then unnecessary computations leaned out after the architecture has been proven to work well. If so, Tesla may simply be exploiting the fact that they have the extra compute budget instead of wasting time on premature optimization. This might be what James Douma is trying to say.

I mean- I agree there'll eventually be SOME optimization... but I find it a dubious claim that there'll be SO MUCH of it they can not only shrink needed compute by roughly half to fit back in a single node- but they'll also be able to fit all the ADDED code that doesn't even exist right now (all the stuff needed for >L2, like a vastly more complex and capable OEDR) into that same shrunken space as well.

Again I'm not suggesting it's 1000% unpossible- but it seems a lot more magical/wishful thinking type of an argument than "tesla is already out of compute and still pretty far from the goal, therefor it's likely they will need more compute than they have to reach the coal is...

A system with a feature set can be
L4 with safety driver

L4, by definition, can not require a safety driver. It must be capable of safe operation with nobody in the drivers seat at all

That doesn't mean you can't have one sit there anyway, but you can't require they be there for the system to work, and can't require they DO anything even if they are there and have it still be L4.

Anything that requires a safety driver (but also does the DDT for any significant period of time) is L3 by definition in J3016.

AFAIK CA DMV requires reporting for L3 or higher- basically any time a non-human is doing the DDT on any sustained basis.

I'm with you on most points, but this CA DMV thing is silly. FSD is obviously a "Level 4 design intent" system and by law Tesla imust report metrics such as disengagements. Musk refuses to report, so he paid some lawyers to lie prevaricate to the DMV.

I mean, I think it's weird anybody believes Tesla will lie to government agencies under penalty of perjury and other sanctions as you suggest they're doing- but ALSO that everything they tell the public/customers (like FSDb being L4 intent in direct contrast to what they told the DMV) is 100% accurate. Esp. when to anybody using it it's pretty clear it's still quite far from L4.... and the fact Tesla heavily dialed back the definition of what you were buying with FSD in March 2019 to a degree only explainable by them wanting to limit their legal liability for refunds if they failed to deliver more than L2 to buyers.

 

[Artful Dodger]

Metal foam -- anybody know about it? I have an idea that Tesla and maybe SpaceX and Boring will use this material and I'm wondering if this is this crazy or not? I don't know much about metallurgy and die casting.

Yes, I've been talking about metal foam here at TMC for over 3 years (focusing on the potential for stainless steel metal foam a way to make a true structural battery).

Here's a link to my post history on Metal foam

 

[Artful Dodger]

talking about metal foam here at TMC

Here's a link (PDF) to a research paper on the topic of the usefulness of stainless steel metal foam: Paging @Gigapress

Ameli, A., Nofar, M., Saniei, M., Wang, S., & Park, C. B. (2016, March). Foam injection molding of polypropylene/stainless steel fiber composites for efficient EMI shielding. In AIP Conference Proceedings (Vol. 1713, No. 1, p. 100005). AIP Publishing LLC.​

I can see how both Tesla and SpaceX would be interested in this technology. It's radiation shielding properties alone make it an excellent choice for the Moon/Mars Rover version of Cybertruck.

Additionally on Mars, if expended Starships can be used as raw materials for radiation shielded structures, this would also be highly useful. Sounds like only electricity and CO2 are needed to drive this stainless steel metal foam injection manufacturing process.

That'll work on Mars.

Cheers!

 

[nativewolf]

Jason Hughes doesn't think Tesla FSD Level 5 will ever work on existing hardware

https://twitter.com/x/status/1594681099304796161

What I have thought too but I dont have his depth but it seems simple enough to figure out. Need new hardware and sensors but don’t post that in a he main thread you will be eaten alive.

 

[Gigapress]

It is also good engineering practice not to waste any clock cycles so packing all available cycles with test code is most likely why each is pegged/max'd (with applicable buffer).

Would you explain this more?

Are you saying that Tesla is packing the compute budget with test code that might not even be controlling the car in order to make faster development progress by exploiting excess compute capacity that would otherwise go to waste, and Green may be misinterpreting that as FSD Beta itself maxing out the FSD computer?

Is that essentially like running some neural nets in shadow mode even with FSD actively running?

Does there even exist any way to conclusively determine whether this is happening without inside information from Tesla's AI team?

 

[mongo]

L4, by definition, can not require a safety driver. It must be capable of safe operation with nobody in the drivers seat at all

That doesn't mean you can't have one sit there anyway, but you can't require they be there for the system to work, and can't require they DO anything even if they are there and have it still be L4.

Anything that requires a safety driver (but also does the DDT for any significant period of time) is L3 by definition in J3016.

AFAIK CA DMV requires reporting for L3 or higher- basically any time a non-human is doing the DDT on any sustained basis.

Sure? but I never claimed to be making an exhaustive list and was referring to the current Tesla configuration of a human in the seat specifically in response to:

FSD is obviously a "Level 4 design intent" system

I did not say anything about a safety driver being required, though in CA :

Autonomous Vehicles Terms and Definitions - California DMV
An autonomous test vehicles requires a human test driver or a remote operator to continuously supervise the vehicle’s performance.

Further, I called out an average Tesla owner would not qualify as one anyway.

To really pick the nits, a L4 system under test likely does require (strongly need?) a safety driver during its development (due to the whole testing thing). That doesn't make it non-L4 intent though.

 

[Knightshade]

Would you explain this more?

Are you saying that Tesla is packing the compute budget with test code that might not even be controlling the car in order to make faster development progress by exploiting excess compute capacity that would otherwise go to waste, and Green may be misinterpreting that as FSD Beta itself maxing out the FSD computer?

Is that essentially like running some neural nets in shadow mode even with FSD actively running?

Does there even exist any way to conclusively determine whether this is happening without inside information from Tesla's AI team?

I think I already covered this? Green can see (or at least claims he can see) which NNs are feeding outputs into other specific things and which are just there running but not actively doing anything.

The stuff that is actually "doing" things (ie actually part of the controlled-the-car systems both for perception and control and planning) are using compute on both nodes... something you would not want to ever do if you could avoid it due to that incurring a significant performance hit.


That doesn't mean 100% of used compute in both nodes is that.... but significantly more than 100% of either SINGLE node is that.

In short- they do not have enough compute to run everything needed for FSD in a single node, even if you turned off 100% of the "testing" code.


I suppose if you think Green is just making everything up you can read this all another way of course.

 

[verygreen]

I can also SSH into the AP computer, but I can't tell you what is running on each core at any given time,

you don't need to look at individual cores as all cores are node-local. You need to log into both nodes A and B to see they are splitting the load (check the AP task schedule, it outlines which nodes get scheduled for what core and what frames, pay attention to "Extended compute request" and how failure at it is now a fatal error. Also lately they got some NNs so "slow" they must run them on both nodes to get semblance of performace it looks like (see the "crossturbo" NNs added in recent releases).
Also don't look at the cpu load, it's the TPU load and latencies that are important metric (you can check those in collected statistic for every task that's part of the current scheduling plan (different plans for different modes of operation), you can also check overall processing latencies in SystemExecutionMetrics output)

(for example campaign triggers only happen on Node A)

This is no longer true, as of 2022.20.x releases they split this so now every trigger triggers on both nodes, but only part of the information comes from any individual node (they no longer run video collection from all cameras on Node-A only and don't store some other info there anymore - probably because they are starting to run out of memory there and those video buffers are sizeable)

 

[nativewolf]

you don't need to look at individual cores as all cores are node-local. You need to log into both nodes A and B to see they are splitting the load (check the AP task schedule, it outlines which nodes get scheduled for what core and what frames, pay attention to "Extended compute request" and how failure at it is now a fatal error. Also lately they got some NNs so "slow" they must run them on both nodes to get semblance of performace it looks like (see the "crossturbo" NNs added in recent releases).
Also don't look at the cpu load, it's the TPU load and latencies that are important metric (you can check those in collected statistic for every task that's part of the current scheduling plan (different plans for different modes of operation), you can also check overall processing latencies in SystemExecutionMetrics output)


This is no longer true, as of 2022.20.x releases they split this so now every trigger triggers on both nodes, but only part of the information comes from any individual node (they no longer run video collection from all cameras on Node-A only and don't store some other info there anymore - probably because they are starting to run out of memory there and those video buffers are sizeable)

Long story short...it seems likely that we'll need to see at least 1 if not 2 or more hardware iterations before we close in on a FSD (4/5) ?

Knightshade that was a good review of the sensor suite challenges. Wonder what Tesla will do?

 

[nativewolf]

It really is though.

There's no redundant cameras for most of the 360 view, there's blind spots close to the car with current # and placement, and there's no ability to clear most of the cameras in bad weather.

Auto lane change disables itself if there's a spot of dirt on one of the side cameras, or if there's too much sun glare on one of them.

NoA and FSDb shut down in even moderate rain here, let alone heavy rain (can't speak to snow, we rarely get it and don't drive in it when we do- but certainly that's not true of elsewhere).

Jury is still out on issue of b pillars being as far back as they are for obstructed intersections (Chuck Cook has a nice video of this where he has external cams at the b-pillar and front fender locations to show this issue-- I know I've personally had BOTH situations where it just never went because it couldn't see well enough at the creep limit- and cases where it DID go and should not have because the creep limit wasn't quite far enough but it thought it was)


The weather aspect BTW is one place I strongly disagree with removing radar... I get that it's a low res radar, and eliminating it for MOST uses is probably a net benefit.... but in bad weather it was still better than just vision- and better radar is pretty cheap now too.


I get the "humans are fine with vision so car should be too" argument-- I've made it myself.

But the humans eyes are behind glass, they have ways to clear most of that glass if obscured, and they can lean and turn their head as needed to see further around objects or out of direct line of the suns rays.

The 3 front cams arguably have 1 and 2 going for them- not so much the other cams, and the lack of lean/turn makes placement, esp without any redundancy, problematic for the car cams.



Further- I'd say HW is STILL the issue even if it -were- just an AI problem (which it's not as I mention above) because there's not enough HW compute on HW3 to do L5.

That point is arguable- though I feel the preponderance of what evidence we have available supports my view of it-- but I don't think there's ANY evidence to support the view that FOR SURE there's enough and HW is FOR SURE not an issue there either.


Ideally HW4 both sensors and compute fixes all this-- and more ideally is fully retrofittable to current cars (though seems less likely for cameras esp. if there's new number or location).

But we don't KNOW how much is needed for L5.

Neither does Tesla- which is why they've been wrong about it several times now. (HW2 was enough- then 2.5, then 3....now 4?... They even changed the color filters on the cams because the original HW wasn't sufficient-- and there's new cams coming soon too)

nobody knows how much HW is enough until it actually works.

This is exactly right, they are engineering by iteration. Just like NASA did with rockets and an attempt to get to the moon. 15 years of frantic missile research and then 14 years of frantic rocket development.

 

[verygreen]

Long story short...it seems likely that we'll need to see at least 1 if not 2 or more hardware iterations before we close in on a FSD (4/5) ?

nobody knows this for the obvious reason that nobody has ever reached L5, so it's not known what's needed there.
Limited L4 was reached by the likes of Waymo and Cruise, and reportedly both their compute and sensor requirements are much higher than Tesla and furthermore if you consider their approach as deficient, that means the superior approach is going to be even more (to an unknown degree obviously) compute and/or sensor intensive.
As such guessing about "1-2 iterations" is mostly unfounded speculation in my view, as far as I am concerned, there's entire layers missing in the Tesla approach (externally visible as "the driver is the ultimate fallback at all times") that don't let me even seriously consider Tesla as actually even foraying beyond L2. Moreover, the autopilot page describes a level3 system at best (because they declare there always must be a person in the driver's seat for it to be operational), so in a way it's even a stretch to assume they are even having a level4 as a serious engineering goal (marketing babble aside)

 

[Knightshade]

Long story short...it seems likely that we'll need to see at least 1 if not 2 or more hardware iterations before we close in on a FSD (4/5) ?

Knightshade that was a good review of the sensor suite challenges. Wonder what Tesla will do?

Well, it's going to depend on what they actually need to get to L4 or better.

I think more compute retrofittable to existing cars is fairly easy- they've already done that once.

Retrofitting better cameras (maybe with some magic nanotech that repels all water and dirt) in existing locations is probably pretty doable too-- they've already done that for some AP2 cars to get FSDb working on them.


The challenge comes if either of THESE are true:

They end up needing MCU3. Because apparently that's a VERY non-trivial swap (that AFAIK nobody has done successfully)... (and it appears even the current FSDb needs at least MC2, so the MCU is at least somewhat relevant)

and/or

They end up needing additional cameras in different locations. Because that requires body panel retrofits, and entirely new wiring (to my knowledge existing cam wiring is dedicated per camera to individual inputs on the computer, so could not easily be shared with new cams stuck other places).