Investor Engineering Discussions

[MC3OZ]

Update on 4680 ramp progress:-

 

[Cosmacelf]

Update on 4680 ramp progress:-

It isn’t really an update on the ramp. More like a rehash of what happened in the past and using that to finally conclude that Tesla might be able to get to 100 GWh of 4680 cells by the end of 2023.

 

[Discoducky]

For my difficult/interesting/odd oddities, I have some new data. NOTE: Outside of weird lane changing, the current build of 10.69.2.2 is pretty great...the below are the 'rough edges' of the code that I'm trying to figure out...

The weird stopping is still occurring, but now the data seems to support that bad map data is still the root cause, but for another reason. I had to take video and play it back to spot the weirdness, but it does NOT occur in the same place, which points to dynamic traffic being the root and it wasn't until a car was pulling into the adjacent lane that it looks like the bad map data could be that it is feeding the real-time system that it is only a SINGLE lane (as opposed to two lanes of travel in the same direction) and the car will stop in its lane if a car is attempting to make a right turn in the lane to the right. Super weird to experience as my car came to a complete stop to let a Model S make a right into the adjacent lane.

The roundys also have new data as it seemingly will do completely different things given the same variables. Sometimes it wants to be in the left lane, sometimes the right, sometimes it tries to change lanes in the roundy, sometimes not, but it is always a bit different. At first, I dismissed this as the AI just doing what it thought was best, but then remembered that the map data could be off as the new lanes near the roundy's were MOVED about 30 feet or so and I think that the car is most likely using bad map data which has the lanes now off center AND when it snaps (Guaussian probability distribution) to a lane, it is sometimes picking one or the other, but gets too far off and it thinks it is departing the road so suddenly puts it back into the bad map data lane. I could describe this further, but this explanation is already too long...

My obtuse UPL does NOT get a creep wall and is thus still unsafe. It sucks as all my other UPLs are at 90 degrees and get a creep wall thus they have all been safe.

I have a new issue with an acute UPR and a 1 way bridge here, which it used to do well, but now will only complete if I set the speed to 20MPH or less. If it is set to more than that, it will not see the Stop sign, rolls it, completes the acute UPR, then speeds up to much to detect the red traffic light and tries to run the red light.

View attachment 856176

My roundy's were a disaster today, did 14 in total and it only succeeded once. A few times it was completely frozen and wouldn't proceed after a few cars went by. I let it sit there for about 30 seconds both times and then gently pressed the throttle and it proceeded.

I have yet another place where it slows down, but at this spot it isn't a full stop. My guess is that since I have it set to speed limit +4MPH, that it momentarily slows to the speed limit and then goes back to the max speed.

Another weirdness that I only tried once, by accident, was going through a roundy without a route, it took the first exit (effectively a left turn) perfectly with traffic present. Hasn't done this before, so I'll try the roundy's tomorrow without a route as a shot in the dark test.

I have another guess as to why roundy's and my oblique/obtuse intersections are not working. I think Tesla may have only focused/trained on 90 degree turns for the 2.2 build. I've seen some videos where there are 'near' 90 turns that get the creep wall and proceed well, but mine are much closer to either 40 or 150 degrees. So, maybe that is why roundy's aren't working either. Maybe this release was to nail Chuck's left with the creep wall and median box. Guess time will tell.

 

[MC3OZ]

It isn’t really an update on the ramp. More like a rehash of what happened in the past and using that to finally conclude that Tesla might be able to get to 100 GWh of 4680 cells by the end of 2023.

I agree.

But there was a minor update about Austin production rates.

 

[mongo]

Note for @hobbes : see how the time cancels out in the above metric so the units are computes/energy even though you're normalizing by power.

Yeah, ops/energy is a valid figure of merit, but watt is power so it's a bit off...

Watts/(Ops/sec)=wattSeconds/op

 

[hacer]

Yeah, ops/energy is a valid figure of merit, but watt is power so it's a bit off...

Watts/(Ops/sec)=wattSeconds/op

Your own analysis shows it's good. Watt-Second = Joule
So your units (reciprocal of the figure of merit @Singuy and I were using) is Joules/Op, a valid figure of merit.

Unless by "ops" above you mean Operations-Per-Second. In that case ops/energy is not (IMHO) a valid figure of merit. Consider that we have a mathematical problem to solve. It takes 1e22 mathematical operations to perform. It is rational to ask: "what is the cost (energy) to perform this calculation?" The answer is 1e22 / my-figure-of-merit. If "ops" is operations/second then you can't use ops/energy to answer the question; you would also need to know how fast you performed it which ops/energy provides no guidance for. If we are only interested in the speed of the computation, that figure is just operations/second by itself, which is another (different) valid figure of merit for a different property of the system.

I was trying to get @Singuy to understand that total cost (energy) of a computation is not the only figure of merit worth considering, that in fact pure fpos (or similar) might be more important, as could other types of figures of merit.

 

[mongo]

Your own analysis shows it's good. Watt-Second = Joule
So your units (reciprocal of the figure of merit @Singuy and I were using) is Joules/Op, a valid figure of merit.

Unless by "ops" above you mean Operations-Per-Second. In that case ops/energy is not (IMHO) a valid figure of merit. Consider that we have a mathematical problem to solve. It takes 1e22 mathematical operations to perform. It is rational to ask: "what is the cost (energy) to perform this calculation?" The answer is 1e22 / my-figure-of-merit. If "ops" is operations/second then you can't use ops/energy to answer the question; you would also need to know how fast you performed it which ops/energy provides no guidance for. If we are only interested in the speed of the computation, that figure is just operations/second by itself, which is another (different) valid figure of merit for a different property of the system.

I was trying to get @Singuy to understand that total cost (energy) of a computation is not the only figure of merit worth considering, that in fact pure fpos (or similar) might be more important, as could other types of figures of merit.

Right, wattSeconds is the unit, not watts.
Any yeah ops was operations, not op/s
As long as the FoM uses the same units, the actual units aren't important for comparison, but to convert to cost of calculation, they matter.

 

[hacer]

Right, wattSeconds is the unit, not watts.

I am confused. Your original post seemed to be trying to correct a mistake I made, but I don't see any mistake. Are you claiming that somewhere in my original post I should have used Joule (or Watt-second) where I used Watt? If so, I can't find it.

Uh, yeah the time it takes to process is the performance. The amount of energy to do such a thing is the watt.

So it's true that @Singuy was way wrong trying to explain it. The "performance" numbers he was comparing (for multiple posts) had computations/second units (not seconds as he misspoke above), and then he bizarrely equated power with energy. He's used to thinking of a figure of merit as performance/Watt (which is correct) but can't seem to remember what those things actually mean - which just further proves he's not able to think from first principles.

My aside to @hobbes was just trying to point out that it was/is legitimate to normalize the "performance" figures (operations per second) for the different hardware by power even if @Singuy doesn't know why that's the case.

 

[Singuy]

I am confused. Your original post seemed to be trying to correct a mistake I made, but I don't see any mistake. Are you claiming that somewhere in my original post I should have used Joule (or Watt-second) where I used Watt? If so, I can't find it.


So it's true that @Singuy was way wrong trying to explain it. The "performance" numbers he was comparing (for multiple posts) had computations/second units (not seconds as he misspoke above), and then he bizarrely equated power with energy. He's used to thinking of a figure of merit as performance/Watt (which is correct) but can't seem to remember what those things actually mean - which just further proves he's not able to think from first principles.

My aside to @hobbes was just trying to point out that it was/is legitimate to normalize the "performance" figures (operations per second) for the different hardware by power even if @Singuy doesn't know why that's the case.

I believe you are correct that what I said is incorrect, or at least came out incorrect.

I do understand that a D1 chip uses 27w seconds to compute 54peta-brain floating points. That's the performance/watt.

 

[MC3OZ]

Development bot HW - Tesla is showing this is progressing very well. Their in-house actuators are super impressive and the power requirements are going to drastically improve with each iteration moving to production. I expect at least one more development bot prior to a larger batch build of 100 to 1000.

Do you see any advantage in making another 2-3 physical copies of the current design?

They could tinker with different aspects on each bot:-

• Optimus 1- hardware improvements.
• Optimus 2- walking.
• Optimus 3 - factory tasks.

People mentioned the high cost of constructing a bot, but if Tesla did small trial production runs to produce the actuators and some of the other components, then making a bot or more or less an hand built assembly task.
So I don't understand estimates of $1 Million to build a bot, not when you have a standard design.
I understand $1 Million in R&D for the first 100% hand built prototype.

In any case, they need to try making the components.

Is it too early to make any moulds and dies?

I like the idea of MVP - Minimal Viable Product - they can always improve the hardware, but being able to actually build a standard bot relatively quickly is a big advantage.

 

[petit_bateau]

Do you see any advantage in making another 2-3 physical copies of the current design?

They could tinker with different aspects on each bot:-

• Optimus 1- hardware improvements.
• Optimus 2- walking.
• Optimus 3 - factory tasks.

People mentioned the high cost of constructing a bot, but if Tesla did small trial production runs to produce the actuators and some of the other components, then making a bot or more or less an hand built assembly task.
So I don't understand estimates of $1 Million to build a bot, not when you have a standard design.
I understand $1 Million in R&D for the first 100% hand built prototype.

In any case, they need to try making the components.

Is it too early to make any moulds and dies?

I like the idea of MVP - Minimal Viable Product - they can always improve the hardware, but being able to actually build a standard bot relatively quickly is a big advantage.

and @Discoducky

I am sure there will be well over a dozen full and part v2 bots so as to parallel development.

I suspect that we will see a lot more semantics development. In the same way that they have had to go from 2D to 3D vector space I think they will need to go at least one further level in semantic space. That will really be pushing the frontiers of generalised AI forwards.

At (say) $60k for an 80kWh car that is $750/kWh of revenue. At (say) $20k for a 3kWh (2.3kWh usable) bot that is $6,666/kWh of revenue. Approx an order of magnitude difference. So assuming they are pricing both to yield 30%GPM it is sensible decision making to be working on a bot at this time given that the real constraint is cell capacity, and given that both ultimately align with the transformation mission.

Just imho.

 

[Discoducky]

Do you see any advantage in making another 2-3 physical copies of the current design?

Yes and no.

Yes, in that they will make many changes to individual parts and try them on the frame.

No, in that the overall skeleton or backbone is meant for major changes. The major changes happen fast enough as the engineers have to learn what worked and what didn't with smaller changes they make to their individual parts. Then, they can plan for the big structural/design change for major changes. All the while, they are focused on reducing part counts, increasing manufacture-ability and optimizing weight/performance ratios.

The lifting of the piano is a neat trick, but it is just a demonstration. They will save part weight where they can. Having that amount of capability usually means there is weight to be saved. And the more weight they shave off, means less battery requirements, which compounds to even more weight savings.

 

[Discoducky]

Is it too early to make any moulds and dies?

Yes, these are almost all being 3D printed I would guess for maximum velocity of change and then once they get to a larger build (>100) they might turn to soft tooling. The molds and dies could be considered hard tooling and for a run of >10000.

As an aside. If the engineers have a really strong focus on a really strong vision with a really small set of guiding principles (which I think they do as it is an Elon run company) then **IF** the AI portion starts to solve for the MVP, we could see some hard tooling in 2024 and limited production.

Right now, many are just focused on getting the bot to walk smoothly, confidently with higher and higher performance (less weight, less power requirements) on more surfaces. It can't wobble, fall down, stumble, trip, get caught, tangled...etc

 

[mongo]

Holy *sugar*, single stack vector space incoming! (NOTE: Vision cannot calculate the current sonar visualization for parking. The only way to park with vision is to do it in vector space with much higher accuracy). They MUST have high confidence in the vector space vision solution. Super cool!

It's very surprising that they didn't talk more about this on AI day.

Also, the all up cost for sonar in a Tesla is around ~$500 to $800 when you factor in cabling/harnesses, connectors, clips, packaging space, tooling to punch holes in the bumpers and fenders, manufacture time...etc

I can't wait to see new vehicles without the pucks!!! (NOTE: Model X has a couple of hidden sonars in the doors and those are way more expensive than flush mount; I'd assume these go away as well and could also be solved with vector vision)

Huh, cameras can't see directly in front of front bumper, seems like a bad blindspot unless it reverses to check first. Or they add another cam?

Falcon door sensors are also used for overhead collision prevention, seems like those would stay (much less impact on high $$$ car).

 

[petit_bateau]

Huh, cameras can't see directly in front of front bumper, seems like a bad blindspot unless it reverses to check first. Or they add another cam?

Falcon door sensors are also used for overhead collision prevention, seems like those would stay (much less impact on high $$$ car).

Interesting. I'd noticed they had reached centimetric accuracy, so it does make sense.

How do you solve the problem of something that wasn't there when you looked, but is there now ?

Your comment about the X-doors caused me to think about that issue. I guess it is common to (say) fwd or reverse parking by eye. As a human I look at the spot, then remember the volume and park. If something enters the space unseen in a blindspot and gets in the way, then if it is noisy I hear it, and if it is firm I sense the engine note/decelleration/rpm etc. But ultimately there is an increased risk in that situation and one day liability will enter the space.

 

[bkp_duke]

Interesting. I'd noticed they had reached centimetric accuracy, so it does make sense.

How do you solve the problem of something that wasn't there when you looked, but is there now ?

Your comment about the X-doors caused me to think about that issue. I guess it is common to (say) fwd or reverse parking by eye. As a human I look at the spot, then remember the volume and park. If something enters the space unseen in a blindspot and gets in the way, then if it is noisy I hear it, and if it is firm I sense the engine note/decelleration/rpm etc. But ultimately there is an increased risk in that situation and one day liability will enter the space.

Integrate cameras into future version of the headlight assembly or blinkers?

Just splitballing that one.

 

[mongo]

Interesting. I'd noticed they had reached centimetric accuracy, so it does make sense.

How do you solve the problem of something that wasn't there when you looked, but is there now ?

Your comment about the X-doors caused me to think about that issue. I guess it is common to (say) fwd or reverse parking by eye. As a human I look at the spot, then remember the volume and park. If something enters the space unseen in a blindspot and gets in the way, then if it is noisy I hear it, and if it is firm I sense the engine note/decelleration/rpm etc. But ultimately there is an increased risk in that situation and one day liability will enter the space.

That's true, humans see even less area in front of the bumper than cameras do. Our SUV has front cameras which are handy, but I think that is an 'off road' feature.
Low torque creep is a good option (unless wheels frozen to ground).
Ah, the joys if engineers looking for failure modes...

Integrate cameras into future version of the headlight assembly or blinkers?

Just splitballing that one.

Any new cameras need washer/wipers though. Can be done, but less cost effective.

 

[bkp_duke]

Any new cameras need washer/wipers though. Can be done, but less cost effective.

Aside from the 3 in the rear-view, there are no washer/wipers on the other cameras. I believe this is because there is significant redundancy built in.

 

[mongo]

Aside from the 3 in the rear-view, there are no washer/wipers on the other cameras. I believe this is because there is significant redundancy built in.

I should had added "front facing". Others are out of bug path.

Speaking of cameras, has the Infrared version of the interior canera been mentioned before?

 

[JRP3]

Aside from the 3 in the rear-view, there are no washer/wipers on the other cameras. I believe this is because there is significant redundancy built in.

I repeatedly get side pillar camera obstructed warnings on cooler days on the side facing the sun. When I check there is moisture inside the pillar plastic that eventually goes away.