FSD Beta 10.69

[EVNow]

I guess since I extracted a beer from you already I should just go along and go with this bet on 10.69.1 as well (do you want to bet on one at a time?). Or we can stick with just 10.69.2, but that gives me a chance to bail…. Conditions:

I believe that FSD Beta 10.69.2 will have less than or equal to 90% success on Chuck’s UPLs described below:

1) Attempts with no traffic at all on the visualization in the relevant directions during the decision phase don't count.
2) Car has to go at the first opportunity when a decent human driver would go, when there is a 5-second opening or greater. No honking allowed from other drivers (failure for that).
3) The car cannot cause any other car to slow down or react at any point in the maneuver (by creeping too far, moving forward at the wrong time, etc.) Including if it stops halfway through in the median - it cannot result in any car slowing or yielding to it (for good cause), or anything like that. Prudent defensive driving by other drivers when the vehicle is stationary and in the correct spot is allowed; we can’t help other drivers being courteous or cautious.
4) The car can't do anything incorrect, like stopping in the first lanes of traffic (even if there is no one coming) to wait for traffic from the other direction. No stuttering, sticking partially into lanes, and if median is used, must properly sit in the median with correct buffer zones (no lane position changes performed by passing traffic), etc.
5) Interventions including accelerator application count as failures.
6) All unprotected left attempts count.
7) Must be greater than 10 attempts. Roof-mounted video from Chuck of car surroundings must be provided (there were a few dark videos done last time which we ignored).

I’ve to say a lot of humans would have a success rate of less than 90% - even on easier ULTs.


Turns will regularly cause changes in the behavior of other cars. Just think how many times you have to slow down because someone is turning in front of you.

 

[Silicon Desert]

I’ve to say a lot of humans would have a success rate of less than 90% - even on easier ULTs.

Alright, you have obviously seen me driving, but do you have to tell the whole world about me

 

[Daniel in SD]

I’ve to say a lot of humans would have a success rate of less than 90% - even on easier ULTs.


Turns will regularly cause changes in the behavior of other cars. Just think how many times you have to slow down because someone is turning in front of you.

I actually asked Chuck to put up a camera to measure the human success rate. He responded that he's not aware of there ever being a collision at that turn. Obviously that's way different than @AlanSubie4Life's definition of success.
People rarely think about all the times they don't have to slow down when someone is turning in front of them. It would be an interesting exercise though. Count how many ULT you do a day and how many times you need to brake or swerve to avoid a collision with someone doing an ULT.

 

[sleepydoc]

My many years developing systems has taught me that anyone who claims something is trivial either does not understand the problem or is not responsible for the implementation.

...and has pointy hair!

 

[sleepydoc]

I could be a minority, but I do prefer to keep FSD on, and just scroll down the max speed for these occasions, rather than turning FSD off all together. When max speed changes again, it will pick it up automatically, so it's just one-off action. I can live with it, until they fix it.

I guess I too will report this moving forward in hope that this will boost priority.

The problem is, scrolling down still slows down far too slowly.

I had a case today where I was driving up hill and the speed limit dropped from 55 to 40. Not only did FSD not slow down in a timely fashion, the energy bar increased into the black meaning it was using the motors to maintain speed. This is clearly a flaw in the FSD algorithms. The problem is it's a flaw that can lead to getting ticketed. I've taken to disengaging FSD then reengaging once it's at the target speed. It's baffling that TACC does a better job of slowing down than FSDb does.

 

[Silicon Desert]

The problem is, scrolling down still slows down far too slowly.

I had a case today where I was driving up hill and the speed limit dropped from 55 to 40. Not only did FSD not slow down in a timely fashion, the energy bar increased into the black meaning it was using the motors to maintain speed. This is clearly a flaw in the FSD algorithms. The problem is it's a flaw that can lead to getting ticketed. I've taken to disengaging FSD then reengaging once it's at the target speed. It's baffling that TACC does a better job of slowing down than FSDb does.

Amen, which is why it is less effective to me unless I scroll down the speed at least a hundred miles before I want it to take effect

 

[MrTemple]

My many years developing systems has taught me that anyone who claims something is trivial either does not understand the problem or is not responsible for the implementation.

Your glibness aside, the context of the discussion is about the relative triviality in deciding how the car should act within a known vector-space scenario compared to the orders-of-magnitude more difficult and more compute-intensive work in creating that vector-space in realtime and decent frame-rate from the cameras and sensors in question.

This is trivial. This is WELLLL into the domain of wholly and completely known software development and implementation techniques for competent engineers in the industry.

That doesn't mean (as I've repeated) that it is easy or fast to determine what it is you want to implement.

I get you may just be making a joke (as opposed to spreading FUD about the development ahead), but this is obvious to anybody with experience in software.

Will a heuristic decision implementation for a given driving scenario take 3 days? 30 days? Who knows. There is standard relatively 'known unknown' uncertainty in every new implementation on an architecture.

Is it fully achievable with the techniques and architectures already in place? Absolutely.

And the Tesla team has demonstrated it is knocking down these situations repeatedly and successfully over the past 11mo especially.

 

[JulienW]

The problem is, scrolling down still slows down far too slowly.…

Pet peeve of mine. I want it to offer some regen instead of responding like an automatic coasting down hill.

 

[Silicon Desert]

Your glibness aside, the context of the discussion is about the relative triviality in deciding how the car should act within a known vector-space scenario compared to the orders-of-magnitude more difficult and more compute-intensive work in creating that vector-space in realtime and decent frame-rate from the cameras and sensors in question.

I had to read this about 4 times to understand, and finally asked the wife to translate. She says "I think it means 4 words... it can be done"

 

[MrTemple]

I had to read this about 4 times to understand, and finally asked the wife to translate. She says "I think it means 4 words... it can be done"

The discussion is a bit more complex than those (and their wives) trying to participate without reading it.

What did Walter say to Donny about the movies?

 

[JohnB007]

The problem is, scrolling down still slows down far too slowly.

I had a case today where I was driving up hill and the speed limit dropped from 55 to 40. Not only did FSD not slow down in a timely fashion, the energy bar increased into the black meaning it was using the motors to maintain speed. This is clearly a flaw in the FSD algorithms. The problem is it's a flaw that can lead to getting ticketed. I've taken to disengaging FSD then reengaging once it's at the target speed. It's baffling that TACC does a better job of slowing down than FSDb does.

Must be a Canada thing, or even a Ontario thing.

Here, there is a first sign that warns you that the next sign will change (go down). If I manually scroll down at the time when I see the first "warning" sign, it just happens that the car slows down just enough to match the next sign speed...

I know, not even close to being ideal...

 

[sleepydoc]

Must be a Canada thing, or even a Ontario thing.

Here, there is a first sign that warns you that the next sign will change (go down). If I manually scroll down at the time when I see the first "warning" sign, it just happens that the car slows down just enough to match the next sign speed...

I know, not even close to being ideal...

I’ve tried that and at best it still acts like thr car is in neutral coasting and still takes far too long to slow. You just start the process earlier. If the sign happens to be ¼ mile ahead you’ll be ok but here they’re usually a few hundred feet.

Since your technically required to be at the required speed at the sign (as opposed to starting to slow down at the sign) FSD should really start slowing down (and not just coasting) at the warning sign, not at the reduced speed limit sign.

 

[Supcom]

Your glibness aside, the context of the discussion is about the relative triviality in deciding how the car should act within a known vector-space scenario compared to the orders-of-magnitude more difficult and more compute-intensive work in creating that vector-space in realtime and decent frame-rate from the cameras and sensors in question.

It's a shame that Tesla won't spend a little time on a few of the 'relatively trivial' things like figure out how to get the car to not stop in the middle of an intersection when way is clear or not gyrate the steering wheel wildly back and forth to make a 'relatively trivial' right hand turn.

I don't doubt that there are certain functions of the software that are much harder than others. Since I am not on Tesla's FSD team, I wouldn't try to guess at which items are more 'relatively trivial' vs less 'relatively trivial' to accomplish. Maybe you are and know and are secretly giving us insight into their development. But trivial is not the term that I would assign to any of the FSD features that I have been testing.

 

[OxBrew]

The architecural challenges of implementing driving policy are essentially nil.

Bu-----.

Signs get obstructed by trucks. Run over. Vandalized.

Yet, people still slow down for speed bumps, more often than not without signs.

Being able to read all manner of signs is not going to solve this. The car needs to be able to do the right thing without any signs.

Same goes for any "architectural" rules. There's no magic pill that will make everything perfect, now you flip the switch, voila, done.

 

[MrTemple]

It's a shame that Tesla won't spend a little time on a few of the 'relatively trivial' things like figure out how to get the car to not stop in the middle of an intersection when way is clear or not gyrate the steering wheel wildly back and forth to make a 'relatively trivial' right hand turn.

I don't doubt that there are certain functions of the software that are much harder than others. Since I am not on Tesla's FSD team, I wouldn't try to guess at which items are more 'relatively trivial' vs less 'relatively trivial' to accomplish. Maybe you are and know and are secretly giving us insight into their development. But trivial is not the term that I would assign to any of the FSD features that I have been testing.

You replied to a comment you didn’t understand because I did not say what you seem to be trying to disagree with.

 

[Dan D.]

You replied to a comment you didn’t understand because I did not say what you seem to be trying to disagree with.

I understood @Supcom's reply even if it was somewhat tangential to your comment.

You might forgive us for having a difficult time parsing your research-level writing style. If I might suggest, try conversing in a simpler way. I believe you're overestimating your audience here. I think you have important things to say but I'm having a tough time understanding your points.

 

[MrTemple]

Bu-----.

Signs get obstructed by trucks. Run over. Vandalized.

Yet, people still slow down for speed bumps, more often than not without signs.

Being able to read all manner of signs is not going to solve this. The car needs to be able to do the right thing without any signs.

Same goes for any "architectural" rules. There's no magic pill that will make everything perfect, now you flip the switch, voila, done.

Yeah, you came late to the party and completely missed the point where I said capturing the world into the vector-space is the hard part.

Once the car can recognize a speed bump (without signs obviously, come on are you even following the discussion ), then implementing driver policy as to what to do is trivial.

Both those aspects of FSD are at very different stages of progress. Both take a lot of time for VERY different reasons.

The vector-space problem is heinously difficult to implement. Three years ago 95% of experts in the industry would have said it was impossible with the sensors Tesla is using.

But it is working better than anybody could have guessed at this point in its incredibly short development lifecycle (since the clean-slate NN architecture rewrite).

The hardware and software architecture is achieving it now. And the areas where it is failing are the expected NN edge-case detection and training situations.

These aren’t cases where the architecture built isn’t capable of doing it yet, but where the architecture hasn’t yet been trained to do it.

VERY different statements when it comes to the capability limits of a Neural Net system.

—

The driver policy heuristic as to what to do once the car is presented with a situation in vectorspace is absolutely trivial to implement.

But it takes time to recognize and define and logic-out the brazillion different ‘rules of the road’.

These require difficult decisions on unique logical problems but simple code.

—

This is a challenging thing to understand, because the two trains are running on the same track, and both affect FSD’s current achievement level, but are COMPLETELY different software problems.

 

[MrTemple]

I understood @Supcom's reply even if it was somewhat tangential to your comment.

You might forgive us for having a difficult time parsing your research-level writing style. If I might suggest, try conversing in a simpler way. I believe you're overestimating your audience here. I think you have important things to say but I'm having a tough time understanding your points.

I think you’re right.

 

[johnm]

There was a time when Elon liked to use the word superhuman to describe [future] Autopilot abilities. If only the speed limit database wasn't horrible, it would be so easy [I assume] to have the car do perfect superhuman deceleration approaching a reduced speed limit.

 

[OxBrew]

Yeah, you came late to the party and completely missed the point where I said capturing the world into the vector-space is the hard part.

Once the car can recognize a speed bump (without signs obviously, come on are you even following the discussion ), then implementing driver policy as to what to do is trivial.

Both those aspects of FSD are at very different stages of progress. Both take a lot of time for VERY different reasons.

The vector-space problem is heinously difficult to implement. Three years ago 95% of experts in the industry would have said it was impossible with the sensors Tesla is using.

But it is working better than anybody could have guessed at this point in its incredibly short development lifecycle (since the clean-slate NN architecture rewrite).

The hardware and software architecture is achieving it now. And the areas where it is failing are the expected NN edge-case detection and training situations.

These aren’t cases where the architecture built isn’t capable of doing it yet, but where the architecture hasn’t yet been trained to do it.

VERY different statements when it comes to the capability limits of a Neural Net system.

—

The driver policy heuristic as to what to do once the car is presented with a situation in vectorspace is absolutely trivial to implement.

But it takes time to recognize and define and logic-out the brazillion different ‘rules of the road’.

These require difficult decisions on unique logical problems but simple code.

—

This is a challenging thing to understand, because the two trains are running on the same track, and both affect FSD’s current achievement level, but are COMPLETELY different software problems.

Thanks, got it.

Assuming they have vector space worked out, that makes sense. Big assumption.

Simple to code does not mean the effort to implement is trivial. What to implement is always the question.

Once you have the answer, yeah it's easy to do it the next time, you already know what to do.

So still not sure what the point is. But yeah, ok, we agree on where the hard part is.

(sorry, I checked out for 2 days, thought I caught back up, must not have).