FSD Beta 10.69

[willow_hiller]

Employee rollout today, should see wide rollout next week.

I like your optimism.

 

[YNoVA]

I like your optimism.

Definitely optimistic but historically the public version went out a week after the employee's received it.

 

[AlanSubie4Life]

Maybe I’m reading this wrong, but could this be smoother stopping and accelerating with a “lead” car? Maybe improvements to high jerk/high G friction braking?

Yes that is what it sounds like but we’ll see. Somehow they were not taking relative acceleration into account (and were just using distance and relative velocity presumably). It seems odd to not have also been accounting for relative slowing/accelerating already taking place in these calculations.

which improves lane topology error at intersections by 38.9%.

I'm hoping this will help solve what I just mentioned as my biggest source of error.

Maybe. Note that it only fixes 2 in 5 errors (at least that is how I interpret improving the error rate by 40% - there is a little ambiguity; I assume they are not quoting the delta % of the error rate).

 

[Jack Oak]

Looks like this vehicle is downloading 10.69.3 / 2022.36.15? TeslaFi.com Firmware Tracker

View attachment 869719

Does that mean 10.69.3 will be available to more people, especially those that upgraded to 2022.28 and higher?

 

[Zane Liu]

2022.36.15 Tesla Update Debuts FSD Beta 10.69.3 for Employees - TeslaNorth.com

Tesla on Monday evening released its 2022.36.15 software update, which includes the anticipated Full Self-Driving (FSD) beta version 10.69.3 for employees. According to @Teslascope, this FSD beta 10.69.3 update is being released to Tesla employees in Canada and the USA, based on vehicles in its...

teslanorth.com

Looks like 10.69.3 is utilizing 2022.36.* stack. Good to hear as I'm currently on 2022.28.*

Employee rollout today, should see wide rollout next week.

Same! Quite excited as well!

 

[scaesare]

It's just part of Tesla's design philosophy. First, see whether the direction of a lane can be intuited from the intersection geometry. If so, then you can drive just as well with lane markings as without. But it seems like they've come to the conclusion that lane direction cannot always be intuited from intersection geometry. At least now they've developed a fallback system for cases without markings, and going forward they'll have a system that can take advantage of them when they're present.

It seems this may also be speaking to improving the lane "continuity" by inferring lane path through an intersection using markings. if the intersection itself doesn't have lane lines (as they often don't) then the directional marking give a hint as to where the lane path should be... even if the connecting "destination" lane lines are occluded...

 

[scaesare]

Suggests they did have this in there after all, though unclear if they do have grammar for intersections, as discussed on AI Day. Not clear it is the same thing.

Are you speaking to vector-space lane representation determined in real time?

 

[AlanSubie4Life]

Are you speaking to vector-space lane representation determined in real time?

No the language/grammar stuff at intersections they spent some time on. Somewhat related but not exactly the same. How they piece together how intersections work.

Still not clear to me it is all in there.

 

[Mardak]

Note that it only fixes 2 in 5 errors (at least that is how I interpret improving the error rate by 40% - there is a little ambiguity; I assume they are not quoting the delta % of the error rate)

Not sure if this data for "parked vehicles at turns" accuracy helps or adds to the confusion:


There have been a few release notes mentioning improvements to "parked" (not just at turns):

• 10.11 (March): Reduced vehicle “parked” attribute error rate by 17%, achieved by increasing the dataset size by 14%
• 10.12 (May): Improved precision of the "is parked" attribute on vehicles by adding 41k clips to the training set. Solved 48% of failure cases captured by our telemetry of 10.11
• 10.69.3 (November): Converted the NonVRU Attributes network to a two-stage network, which reduced latency, reduced incorrect lane assignment of crossing vehicles by 45%, and reduced incorrect parked predictions by 15%

It does seem to make sense to report on the improvement in remaining errors, e.g., 95% -> 97% accuracy is the same as 5% -> 3% error with 2 percentage point improvement from 5%, so that's 40% improvement?

Although that graph shows increasing evaluation set, so if Tesla's data engine is looking for these challenging cases to feed into training and test sets because the current network is confused, then the error rate would at least temporarily drop between releases as more of test is known failures.

 

[BBTX]

Don't get your hopes too high of an imminent 10.69.3 for existing or especially new testers this weekend. It may be 10.69.3.1 or even .2 before we see it go out more-broadly.

 

[sleepydoc]

Improved decision making for short deadline lane changes

One of the issues I've had with the current FSD is the quick right-left (or left-right) turn scenario where you essentially need to turn across more than one lane to make the next turn. The algorithm dictates you make a 'legal' turn into the nearest lane and then needs at least half a block per lane before it will change lanes instead of doing like a human does and Hopefully this improves it.

 

[Dewg]

One of the issues I've had with the current FSD is the quick right-left (or left-right) turn scenario where you essentially need to turn across more than one lane to make the next turn. The algorithm dictates you make a 'legal' turn into the nearest lane and then needs at least half a block per lane before it will change lanes instead of doing like a human does and Hopefully this improves it.

I routinely drive a route where I make a left onto a 6 lane street (3 lanes each side), and then have to make the next right (1 block). Beta has almost always made the right turn by aggressively changing lanes to the right. The instant the left turn is complete, the car has the right blinker on and starts the move to the right. Once that lane change is done, it essentially keeps the turn signal on and makes the next lane change. If there are cars, it slows down a bit to get behind them. Though recently it sped up, which surprised me, to get in front of a car before the right turn.

 

[Mardak]

The algorithm dictates you make a 'legal' turn into the nearest lane and then needs at least half a block per lane before it will change lanes instead of doing like a human does

I've noticed with 10.69.2 that for a specific left turn from an off-ramp to go under the interstate overpass, it correctly avoids the left-most lane (of 3 potential destination lanes) that turns back onto the interstate. Before, it would incorrectly get into the really short 200' turn lane and have trouble getting out as basically all other drivers correctly avoid the lane.

So FSD Beta algorithm does allow for avoiding the nearest lane, and I believe this is somewhat controlled by the Lanes network prediction of forks. This is technically a fork as my particular lane could go straight or any of the 3 left turn destinations. Maybe 10.69.3's "recall of forks by 51.1%" will help with these situations.

I do realize some states do legally require turning into the nearest lane, but practically nobody follows that in certain situations, and I think there isn't strict enforcement in those cases and FSD Beta doing it might be okay.

 

[Mardak]

Does that mean 10.69.3 will be available to more people, especially those that upgraded to 2022.28 and higher?

Yeah, Tesla typically avoids "downgrading" from newer versions, e.g., 2022.28.x -> 2022.20.x, so FSD Beta 10.69.3 as 2022.36.15 should mean anybody on the current latest wide release production firmware of 2022.36.6 should be "actually eligible" for getting added to FSD Beta.

However, even though some "employees" have gotten this latest version, it might not become available to the rest of the fleet nor new additions for a week or two or more. There is 2022.40.1 currently available, and upgrading to that could result in needing to wait even longer for FSD Beta.

 

[sleepydoc]

I routinely drive a route where I make a left onto a 6 lane street (3 lanes each side), and then have to make the next right (1 block). Beta has almost always made the right turn by aggressively changing lanes to the right. The instant the left turn is complete, the car has the right blinker on and starts the move to the right. Once that lane change is done, it essentially keeps the turn signal on and makes the next lane change. If there are cars, it slows down a bit to get behind them. Though recently it sped up, which surprised me, to get in front of a car before the right turn.

I've never had that happen - even when the section of road is completely empty it will turn on the blinker but keep driving and thinking until it's to late and it's missed its chance.

 

[sleepydoc]

I've noticed with 10.69.2 that for a specific left turn from an off-ramp to go under the interstate overpass, it correctly avoids the left-most lane (of 3 potential destination lanes) that turns back onto the interstate. Before, it would incorrectly get into the really short 200' turn lane and have trouble getting out as basically all other drivers correctly avoid the lane.

So FSD Beta algorithm does allow for avoiding the nearest lane, and I believe this is somewhat controlled by the Lanes network prediction of forks. This is technically a fork as my particular lane could go straight or any of the 3 left turn destinations. Maybe 10.69.3's "recall of forks by 51.1%" will help with these situations.

I do realize some states do legally require turning into the nearest lane, but practically nobody follows that in certain situations, and I think there isn't strict enforcement in those cases and FSD Beta doing it might be okay.

Yeah, in that situation the nearest lane is a turn lane, not a driving lane so the legal and 'correct' course is to turn into the 2nd lane which is the first non-turn lane. As you say, there are other cases where you need to make another turn within a 100 feet or so. In these cases you end up making sure all the lanes are clear before you make the turn and then going across in one continuous maneuver.

 

[diplomat33]

It's just part of Tesla's design philosophy. First, see whether the direction of a lane can be intuited from the intersection geometry. If so, then you can drive just as well with lane markings as without. But it seems like they've come to the conclusion that lane direction cannot always be intuited from intersection geometry. At least now they've developed a fallback system for cases without markings, and going forward they'll have a system that can take advantage of them when they're present.

This is where I don't quite agree with Tesla's design philosophy. They seem to start with the bare bones and then work up based on what they need. I would prefer if they just started with what they need for a robust system from the start. Sure, it would be great if vision-only could intuit direction of lane without road markings but that is not going to happen 100% all the time. And if you are going to need to add road markings anyway, then why not add it from the start? To me, it makes more sense to add road markings and other things to have that robust system from the start rather than have an unreliable system that eventually becomes more reliable when you finally add what you should have added sooner.

 

[EVNow]

Maybe. Note that it only fixes 2 in 5 errors (at least that is how I interpret improving the error rate by 40% - there is a little ambiguity; I assume they are not quoting the delta % of the error rate).

We have this ambiguity in all the % improvements they note.

Let us say out of 100, they now have 50 errors. A 40% improvement could mean
- From 50% accuracy to 90%
- From 50% to 70% (40% of 50% reduction)

ps : My guess is their interpretation is the latter.

 

[EVNow]

This is where I don't quite agree with Tesla's design philosophy. They seem to start with the bare bones and then work up based on what they need. I would prefer if they just started with what they need for a robust system from the start.

There was some discussion about this in the Lex / Andrej interview as well.

The point was - shouldn't sensor set be such that the solution can be scaled worldwide to every road that humans use now. In which case, the argument is Waymo and others who use HD Maps and LiDAR are being short sighted.

 

[AlanSubie4Life]

We have this ambiguity is all the % improvements they note.

Let us say out of 100, they now have 50 errors. A 40% improvement could mean
- From 50% accuracy to 90%
- From 50% to 70% (40% of 50% reduction)

Yes, I assume the latter since that would be a 40% reduction in the error rate (which is what they seem to refer to). But yes, I suppose ambiguous.

The former would also mean that they have had some very bad results up until now, and the numbers would need to start to get very small soon.

The latter they can keep reporting significant % improvements in error rate indefinitely.