Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Karpathy talk today at CVPR 2021

This site may earn commission on affiliate links.
You keep making up assumptions

Not at all.

I keep citing the facts Green actually provided.

You keep making up stuff he never said.


I agree someone ought stop, but it ain't me.



I was giving an example of what we've done in the past

And I gave a counter-example from my own work.

And also pointed out your own example didn't support your actual claim when applied to a physical device being added to the system.


To put it in more IT terms--- you can't really test a video card driver if you don't have the video card installed.

Or maybe more specific- you can't really test if updating a driver to support a NEW card works without the NEW card installed.

And- even more relevantly- you wouldn't release a PRODUCTION driver including support for the new card unless you intended to... put the new card into production.

What would be the point?

So someone seeing a new card in a build of a driver- and saying "Hey I noticed this new card in the driver- might be a thing that is coming out soon" is not "delusional"

it's in fact exceeding rational and fact based.

Unlike the counter-arguments you keep making trying to harm Greens credibility.
 
  • Disagree
Reactions: mikes_fsd
And also pointed out your own example didn't support your actual claim when applied to a physical device being added to the system.
Again, please stop making sh!t up.
You do not know if they tested the firmware against cars with the hardware or not. Assuming to much... there is a saying about that.

What would be the point?
For Tesla to test whatever Tesla needed to test... I know you have a hard time understanding that.

So someone seeing a new card in a build of a driver- and saying "Hey I noticed this new card in the driver- might be a thing that is coming out soon" is not "delusional"
His tweet was more along the lines of not IF but WHEN -- that is the delusional part that you seem to struggle with.

Unlike the counter-arguments you keep making trying to harm Greens credibility.
hahaha, green is doing a fine job harming his own credibility.
 
Again, please stop making sh!t up.

I'm not.

I'm pointing out your examples make no actual sense.

if that upsets you provide less delusional examples.


You do not know if they tested the firmware against cars with the hardware or not.

I know you don't put firmware support into production for hardware you have no intention of deploying to production

And despite being asked 3 times to give any reason you would do that you've been unable to provide any.



Assuming to much... there is a saying about that.

Yes- which describes much of what you have ASSUMED about what Green said, instead of the actual things he said and why he said them.



For Tesla to test whatever Tesla needed to test... I know you have a hard time understanding that.

I have a hard time understanding why you don't know you test in dev versions- not production.

You don't move to production until or unless you anticipate using the supported thing in production

That's part of the point of having dev versus production builds.

Alpha tests of totally speculative things don't go into PRODUCTION software.



His tweet was more along the lines of not IF but WHEN

Never is a when of course.

Do you also need time explained to you? :)




Anyway- all of this continues to get vastly far afield of the fact the current production firmware....(and production firmwares going back to at least mid-2020) have exceeded the available compute on a single node of HW3.

Meaning they can't run the nodes redundantly.

Meaning with the current architecture and compute needs of the system- HW3 can not support L3+ driving.


It's possible Tesla will toss most of the current stuff out and do Yet Another Rewrite of course. At which point we've no idea the compute needed or not.

It's also possible the current path turns out to be the right one, but the compute requirements are simply too high for HW3 single node (which we're already at)--- then the question is are they too high for HW3 using BOTH nodes or not.

If not, then everyone with FSD get a free upgrade to HW4 and we're done.

If the compute requirements ARE too high for both nodes of HW3 then... we're back having no real idea how much compute is needed...and no idea if HW4 will be able to run it single node or not....

(and even worse, for Tesla, that'd leave them with no idea how much compute they need to design HW5 for)

So ideal situation is they're able to get legit >L2 working within the confines of the two nodes on HW3.

In that case non-FSD folks can be left on HW3 and everyone else 4 fixes em right up.
 
Where is it stated that L3+ requires redundant compute resources? (There are so many single points of failure in a vehicle that it really doesn't make much sense to require that.)


I mean- Elon Musk appears to think it's important enough he explicitly cited it...

But what does he know compared to the TwoDisagreeingMikes right?

Elon Musk at Autonomy day said:
The general principle here is that any part of this could fail and the car will keep driving. So you could have cameras fail, you could have power circuits fail, you could have one of the Tesla FSD computer chips fail and car keeps driving


Except you can't have that if you need both of them running different code for the system to work- which is where we are today, with the code having exceeded the available compute on a single node some time ago.
 
  • Disagree
Reactions: MP3Mike
I mean- Elon Musk appears to think it's important enough he explicitly cited it...

But what does he know compared to the TwoDisagreeingMikes right?




Except you can't have that if you need both of them running different code for the system to work- which is where we are today, with the code having exceeded the available compute on a single node some time ago.
You still didn't answer the question, as Elon didn't say it was required. That was their plan, which may have changed.
 
  • Disagree
Reactions: Knightshade
You still didn't answer the question, as Elon didn't say it was required. That was their plan, which may have changed.
Obligatory "logs showed almost no usage" ;)
Of course redundancy is not required if the failure rate is low enough. How many autopilot collisions have been related to HW failure? It seems like getting the software to work is a higher priority. If by some miracle they get the software working it seems conceivable they could go back and optimize it to run on a single core.
 
I'm asking you why Tesla would add firmware support for a radar they never had any intention of using- you have no answer other than "to test on a production build" which makes zero sense.

They could be using it to validate their vision-based speed and distance. I know they were validating it against LIDAR. I'm guessing this is cheaper for their test vehicles. I could also see them deploying it on all of those employee-owned cars that are running the FSD beta, to serve as a sanity check in that context; they probably wouldn't want all of those cars to be running development builds.

Heck, they might even be slipping this into a small percentage of random cars that they ship out to customers, to do in-the-field validation. After all, it would be entirely hidden in the bumper, so it wouldn't be obvious if they put it in, and if they didn't use it to control behavior, then it wouldn't affect those customers in any way. :D


(apart from which, testing on a development build that is otherwise identical, but not released to the public, would provide the SAME validation... the ONLY reason to include it in PRODUCTION builds is for PRODUCTION use- which is the intent Green correctly pointed out).
I would be surprised if they were willing to run development builds on vehicles that aren't company-owned. FSD Beta is running on a bunch of vehicles that are owned by employees, I think. So yes, technically, the only reason is to run it on cars that are not configured for development, but that doesn't necessarily translate to "they plan to put it in cars shipped to the general public".


Possibly it didn't end up performing well. Possibly they decided vision-only was close enough. Possibly it was a supply issue (as some have suggested that as a cause for pulling radar at all so soon).
My guess is that it was a hedge against vision-only not being good enough, and that they rolled it out in production so that if the vision-only experiment on the existing fleet didn't work out, they could just drop them into the 10,000 cars waiting for RADAR units and have them ready to ship to customers without rolling new firmware builds and trying to update all of those thousands of cars. But it was good enough, so they didn't place the parts order. But who knows.
 
You still didn't answer the question, as Elon didn't say it was required. That was their plan, which may have changed.

No regulatory body in the world would approve an L3+ self driving system where a single kernel panic on a single core crashes the car.

The fact Tesla explicitly has been designing their self-driving hardware with dual independent nodes - a design that makes no sense other than for failover redundancy - and that CEO of the company during the announcement of the FSD computer explicitly brought up that redundancy- would also be a clue... but the regulatory stuff pretty much covers it.

They could probably still deploy in the handful of states it's generically legal now, but nobody else would let that fly (ESPECIALLY in the EU and likely not in CA and many other US states either)



They could be using it to validate their vision-based speed and distance. I know they were validating it against LIDAR.

Apart from the fact LIDAR is better for that exact task, there would, again be no reason whatsoever to put that in the production firmware if that was what they were doing. Dev code running on the test car would be all you need.

The LIDAR stuff was never put in, despite them doing such testing numerous times.


I'm guessing this is cheaper for their test vehicles. I could also see them deploying it on all of those employee-owned cars that are running the FSD beta, to serve as a sanity check in that context; they probably wouldn't want all of those cars to be running development builds.

Why?

They could literally upload a dev build that was exactly the production build plus extra radar support, specifically to those VINs.

Pushing that code to production, going wide to the fleet, is nonsensical if it's for a small group of internal-only testers.


My guess is that it was a hedge against vision-only not being good enough, and that they rolled it out in production so that if the vision-only experiment on the existing fleet didn't work out, they could just drop them into the 10,000 cars waiting for RADAR units and have them ready to ship to customers without rolling new firmware builds and trying to update all of those thousands of cars.

This new radar code showed up in fall of 2020.

6+ months before there were 10,000 cars waiting for radar on quality hold, and 6+ months before Tesla announced they were ditching radar.

So that can't be it.

(also "having to update all those thousands of cars" is literally a button press, thanks to OTA--- this isn't Volkswagen)
 
No regulatory body in the world would approve an L3+ self driving system where a single kernel panic on a single core crashes the car.

The fact Tesla explicitly has been designing their self-driving hardware with dual independent nodes - a design that makes no sense other than for failover redundancy - and that CEO of the company during the announcement of the FSD computer explicitly brought up that redundancy- would also be a clue... but the regulatory stuff pretty much covers it.

They could probably still deploy in the handful of states it's generically legal now, but nobody else would let that fly (ESPECIALLY in the EU and likely not in CA and many other US states either)

So again, no facts, just your opinion of what may happen. (Not to mention that there are already states that will approve it, as you mentioned yourself.)
 
  • Disagree
Reactions: Knightshade
Multiple facts. Including Elons own words.

You just keep ignoring them because they wreck your imaginary story.
He said they were going to have radar as a primary sensor too. They changed their mind and that is no longer the case. Just because he said that was their plan doesn't mean it is required.

Again: Can you provide a source for anything, like a law or regulation, that requires redundant computing resources for L3+?
 
  • Disagree
Reactions: Knightshade
He said they were going to have radar as a primary sensor too. They changed their mind and that is no longer the case. Just because he said that was their plan doesn't mean it is required.

Again: Can you provide a source for anything, like a law or regulation, that requires redundant computing resources for L3+?

Sure.

Because as throughout this entire thread, you're wrong and ignoring repeated facts.



EU regulations on self driving systems said:
32. The manufacturer shall in particular demonstrate that it has conducted a hazard and safety risk analysis for the automated system, its integration in the overall vehicle design and the broader transportation ecosystem and put in place adequate design and redundancy to cope with these risk and hazards


So where does it say redundancy is required?

Right there.

That's apart from Elons own words.

And the literal design of the hardware which makes no sense unless it's intended to be redundant-- that design is what is currently causing problems for Tesla because they're forced to use it in a way it was never intended to be used (providing extra compute to Node A from Node B)

That's also apart from the pretty obvious fact nobody that doesn't already have blanket "run whatever automated driving you want, we'll take your word for it" rules... which is only a small handful of US states and no place else, would approve a system that lacks enough redundancy to survive a kernel panic.

Which, BTW, often happens on the FSD computer.
(another fact Green among others has mentioned)
 
  • Disagree
Reactions: MP3Mike
So where does it say redundancy is required?

Right there.

It doesn't say what an adequate level of redundancy is or what requires any at all. What if an adequate level is none?

Otherwise no current Tesla could ever qualify:
  • A single cooling system: no redundancy.
  • A single power steering motor: no redundancy.
  • A single brake iBooster: no redundancy.
  • A single HV contactor: no redundancy.
  • A single set of HV wiring: no redundancy.
  • In RWD vehicles: a single drive unit: no redundancy.
  • In AWD vehicles: a single primary inverter which if it fails takes the other inverter offline: no redundancy.
  • The list goes on and on.
That's apart from Elons own words.
Where did Elon say it was required? Just because they were going to do it, or wanted to do it doesn't mean it is required.
 
  • Disagree
Reactions: Knightshade
I've no idea where the legislation is or if it exists, could be quite different between USA and Europe etc too.

But one thing is sure, the 'redundancy issue' was a stick tesla haters used to beat the company with right up until Elon walked out on stage at Autonomy day and said they had it covered. Multiple cameras, multiple power links, multiple data links, dual CPUs etc.

They are not and never have run identical copies of the 'system' on each CPU, they dont need too, they run collections of neural nets across both nodes, including voting/agreement etc.

If theres a hardware issue the system only requires enough capacity to out itself into a safe position.
 
  • Like
Reactions: rxlawdude
It doesn't say what an adequate level of redundancy is or what requires any at all. What if an adequate level is none?

As expected you're just gonna No True Scotsman fact after fact proving you wrong.


Otherwise no current Tesla could ever qualify:

[*]A single cooling system: no redundancy.

The car does not instantly lose the inability to drive if this fails though so it's a completely delusional, to coin a term, example.


[*]A single power steering motor: no redundancy.

Again, it's an ASSIST motor- the car does not instantly lose all ability to operate the vehicle if this fails, so again an irrelevant point.

[*]A single brake iBooster: no redundancy.

This one is just flat out false. One of the explicit benefits of the iBooster?


Bosch said:
Offering brake system redundancy that is required for automated driving


Oh look, Bosch ALSO knows you REQUIRE redundancy for self driving!

Why don't you?


[*]A single HV contactor: no redundancy.
[*]A single set of HV wiring: no redundancy.
[*]In RWD vehicles: a single drive unit: no redundancy.
[*]In AWD vehicles: a single primary inverter which if it fails takes the other inverter offline: no redundancy.
[*]The list goes on and on.

Does it ever get less pointless? Since again the car doesn't instantly turn into an unguided missile if any of those fail... but DOES if a non-redundant driving computer above L3 driving the car fails.



I mean, your posts have been increasingly desperate to find a way to be less wrong for a while now... but wow.
 
  • Disagree
Reactions: MP3Mike
Again, it's an ASSIST motor- the car does not instantly lose all ability to operate the vehicle if this fails, so again an irrelevant point.

Does it ever get less pointless? Since again the car doesn't instantly turn into an unguided missile if any of those fail... but DOES if a non-redundant driving computer above L3 driving the car fails.

Really? So if the assist motor fails how does AP steer the car. (Note: It can't.)

And if the FSD computer fails the car doesn't become an unguided missile, it would just stop. Just like if the motor fails.