Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register
This site may earn commission on affiliate links.
The next big milestone for FSD is 11. It is a significant upgrade and fundamental changes to several parts of the FSD stack including totally new way to train the perception NN.

From AI day and Lex Fridman interview we have a good sense of what might be included.

- Object permanence both temporal and spatial
- Moving from “bag of points” to objects in NN
- Creating a 3D vector representation of the environment all in NN
- Planner optimization using NN / Monte Carlo Tree Search (MCTS)
- Change from processed images to “photon count” / raw image
- Change from single image perception to surround video
- Merging of city, highway and parking lot stacks a.k.a. Single Stack

Lex Fridman Interview of Elon. Starting with FSD related topics.


Here is a detailed explanation of Beta 11 in "layman's language" by James Douma, interview done after Lex Podcast.


Here is the AI Day explanation by in 4 parts.


screenshot-teslamotorsclub.com-2022.01.26-21_30_17.png


Here is a useful blog post asking a few questions to Tesla about AI day. The useful part comes in comparison of Tesla's methods with Waymo and others (detailed papers linked).

 
Last edited:
I received HW4 2023.7.15 11.4.3 three days ago, since then 4gb of data has been downloaded and 28gb uploaded. I assume the uploads are data from the cameras and maybe my disengagement notes, any thoughts on the download though? No version numbers that I am able to view have changed since the initial download of 11.4.3. The 4gb was measured after the update and does not include the firmware data.
 
I received HW4 2023.7.15 11.4.3 three days ago, since then 4gb of data has been downloaded and 28gb uploaded. I assume the uploads are data from the cameras and maybe my disengagement notes, any thoughts on the download though? No version numbers that I am able to view have changed since the initial download of 11.4.3. The 4gb was measured after the update and does not include the firmware data.



I would expect esp on a HW4 car they're uploading a LOT of campaign trigger stuff to those cars (this is the stuff that tells it to look for X and then save/upload what the car saw/did then X happened, but there's a myriad of things/conditions/combos that can be X)--because the data from em will be different than HW3 cars--- which I wonder if that's going to the Ryzen computer instead of the driving one since it's got WAY more storage and is easier to change contents on anyway and is already tied into the cameras.

Tagging @verygreen since doubtless he's got a lot better idea than I on the most likely cause of 4GB of downloads between map/AP firmwares
 
  • Like
Reactions: FSDtester#1
And, fundamentally, neural net systems are all about feedback. And some of those feedback loops can certainly modify weights in the NN's, if allowed to.
No arguments about what you said. But.. "works bad one week, works tons better the next" sounds awful suspicious.

My opinion: Never underestimate the inventiveness of a bunch of CS types.
No need to touch NNs, driving code, or anything else checksummed.
No one disagrees with the concept that Tesla could set it up any way they choose, nor that they're smart enough to consider options of learning within the car perimeter file updates or whatever. But as adventurous as FSD is on a macro level, they probably exercise due caution regarding self-modifying or self learning code in the context of this relatively immature technology and code-base

It became fairly obvious during the months of 10.69 and 11.3.6 testing, that people were noticing Behavior changes week to week. Observations that could not really be dismissed as variations of traffic, weather conditions or even the catch-all of humans' famously unreliable and bias-prone perception andrecollection.

We debated the idea of a server-downloadable parameter set that Tesla could experiment with. I still think this is a possibility, though verygreen thinks not based on is much more detailed understanding of the software architecture. A twist of the idea, requiring no server intervention, would be a pre-programmed sequence of parameter swap-outs to take place at predetermined timestamps - i.e. pre-defined Design of Experiments.

However, when verygreen explained his discovery of the map updates, not actually a new capability but a newly emphasized one, this became the best working theory for us outsiders to explain the observed behavior. The often-mentioned Occam's razor explanation.

Our community is constantly struggling to understand and explain what Tesla is doing in the guts of the machine. It's interesting and a continually thought-provoking exercise for me. I wish that Tesla would have an ongoing Q&A with the engineers every quarter or so.

As it is, we wait for maybe annual Autonomy day or AI day presentations, and if we're lucky we get an offhand comment in a PowerPoint or in the Q&A session that addresses something everyone wondered and debated. In between those opportunities, Elon nay wrap a cryptic comment in an ambiguous Tweet, usually not closing the issue but maybe adding a new dimension to the speculation.
 
Sure, it's solved I'd guess around 10% of the city driving. The other 90% is the edge cases of which we encounter a veritable plethora of times every drive, and where FSDj tries to kill you.
I would say it solved over 90% of city driving in 90% of cities, with less than 10% of remaining edge cases or simply unimplemented items on a to-do list.

Of course, this doesn't at all mean that the timeline is 90% completed. Nor does it mean that the development path is currently understood for the unsolved cases.
 
If you own a model S like me, you know that Tesla has the capability to remember the locations of your Suspension height settings and automatically raise or lower your suspension when you revisit the specified locations. I wonder if Tesla is also using this capability to record special properties of map locations to help FSDb.
Yes, though this location memory, and corresponding adjustments, are understood to be taking place at the Mothership. To the point of your last sentence, this centralized database response has the extremely important side effect of helping everyone in the fleet who travels on the same streets.

It also allows a kind of voting or confirmation system, in which they can decide how many auto-reported incidents of rough roads, potholes, and fenerally new and/or temporary deviations from the stored map, are needed before they will propagate the adjustment to all users.

As ever, I implore Tesla to implement an offline report generation system allowing interested and capable users to upload helpful map details directly. Perhaps known and trusted users would find their reports have a quicker effect, and perhaps this would include initial testing of the proposed changes on the next drives of the reporting users themselves. This would allow us to squash annoying repeated bugs more quickly for ourselves, while allowing Tesla to vet the information before widespread deployment.
 
Today longer drives tell me - planning and route changes are back to normal on freeways with 11.4.4. Still struggling in the city where it prefers left lane. In one instance - I had a right turn and then a quick left turn, with two left turning lanes. The right turn was wide and the car went directly to the outer / second turn lane. Then changed two lanes to the straight lane and then changed back to inner / first turn lane. No train - so I let play out.

So, maybe the new lane NN is buggy ?
 
I’ve totaled 4 cars, been in 17 accidents and had my license suspended twice. The best accident I had was in I-75 in ‘82 when we were racing backwards. Trooper had clocked me at 87mph when a deer ran in front, er I guess behind me, got hung up in the rear drive and the car rolled over a couple times. That one was cool.
Impressive! But have you ever turned right on red?
 
FWIW the pretty recently discovered "each drive gets real time updated map data" - especially HIGHLY DETAILED map data, down to exact locations of crosswalks, # and type of lane, etc removes a LOT of that suspicion to my mind.

In fact it even makes it make MORE sense the degree of "improvement" varies by location too, since the amount of newer/better map data will vary by location for any given drive.

Also consider the degree of behavior change you can manage with JUST map data.

For example, say you want to, I don't know, have every FSD car stop 2 feet closer to the intersection at stop signs... Just send a global map update moving all mapped stop lines forward 2 feet.

No need to touch NNs, driving code, or anything else checksummed.
You make great points, but as @Tronguy points out it is possible to change NN weights or other constants based on real time learning. One way would be to have two copies of the NN weights (or other calibration constants) that each include a flag to indicate if it is the active copy, or not. While driving the software could alter constants in the non-active copy. During the vehicle shutdown process it would change the flags to indicate the other copy as the active one. Each of these copies would be in a separate block of flash memory, to allow erasing (and re-writing) one without changing the other. Each copy would have its own CRC checksum.

I don't know if Tesla is doing something like this or not, but I do believe it is technically possible.

GSP
 
You make great points, but as @Tronguy points out it is possible to change NN weights or other constants based on real time learning. One way would be to have two copies of the NN weights (or other calibration constants) that each include a flag to indicate if it is the active copy, or not. While driving the software could alter constants in the non-active copy. During the vehicle shutdown process it would change the flags to indicate the other copy as the active one. Each of these copies would be in a separate block of flash memory, to allow erasing (and re-writing) one without changing the other. Each copy would have its own CRC checksum.

Except that's literally impossible because the entire firmware is flashed as a single block, and checksummed that way.

You can't change "part" of it and survive a reboot.

Now, could Tesla entirely change the way they secure and verify the AP computers code to ALLOW what you describe?

Sure.

Does it work that way NOW? No.
 
Except that's literally impossible because the entire firmware is flashed as a single block, and checksummed that way.

You can't change "part" of it and survive a reboot.
do we have educated guesses on what the downloaded phantom data could be? things I can demonstrate: 4gb in 2ish nights and 100% change in stop sign behavior. There could be other less noticeable changes or something I didn’t test yet, but those two I know for certain. Based on what I'm reading, Tesla didn’t send me 4gb to be lost during a reboot, and assuming they didn’t waste resources sending 4gb of empty files for nothing, what are we thinking? could it be the next update (11.4.4 or part of it, then when they are ready for release, the last bit triggers the vehicle to prompt me for install when they are ready)?
 
do we have educated guesses on what the downloaded phantom data could be? things I can demonstrate: 4gb in 2ish nights and 100% change in stop sign behavior. There could be other less noticeable changes or something I didn’t test yet, but those two I know for certain. Based on what I'm reading, Tesla didn’t send me 4gb to be lost during a reboot, and assuming they didn’t waste resources sending 4gb of empty files for nothing, what are we thinking? could it be the next update (11.4.4 or part of it, then when they are ready for release, the last bit triggers the vehicle to prompt me for install when they are ready)?
The data could be related to the infotainment system, apps, or any microcontroller onboard other than FSD. As well as Knightshade's thoughts.

As far as performance difference with a given version of software that seems to be the norm given NNs are probabilistic, HW/SW event timelines likely have a substantial random component, and then those many bugs that might make things behave better at times. :)
 
Yes? I made one about a dozen posts before you asked again.
Sorry, I didn’t take that post as a specific response to my question. I feel like there was a better response to my question than what was perceived by me as a snarky tone that would have made the same point. If I misread, I apologize, otherwise I’ll ignore as every time a conversation relevant to the thread comes up, someone ultimately posts a reply that ends up derailing the thread for pages of attacks back and forth making discussion about the topic impossible at worst, and a chore at best.