FSD Beta v11.x

AlanSubie4Life · Aug 9, 2023

Dewg said:
and in my experience, current versions of FSD Beta could operate quite well in that exact same ODD.

Nope. It’s not sufficiently good when it comes to avoiding other people veering into lanes, cutting in front, etc. I bet unsupervised it would have preventable collisions at a rate far higher than humans.

We’ll know it is that good when Tesla rolls out an L3 product and accepts liability!

It’s not good enough, and the evidence (insufficient skill) is right in front of all of us. Though I wish I were wrong of course - limited L3 would be great!

Tronguy · Aug 9, 2023

fasteddie7 said:
https://twitter.com/x/status/1688951180561653760
interesting look at the view between HW3 and 4. Makes me wonder if 3 will ever be able to read signs, especially the illuminated construction ones.

Hm.. Interesting. I'm a-gonna put my semi-professional DSP hat on, though, and wonder about stuff.

First off: Take the instances of where HW-3 is seeing flickering red lights and side-of-the-road signs and HW-4 isn't.

First point: The flickering is For Real: That is, the red lights and the side-of-the-road signs really are flickering. The reason that humans don't see it is that we've got lots of rods and cones; they've all got a fixed time from when a photon strikes (and an electrical impulse is generated) and the time that said rod and cone is Ready To Do It Again. Further, said electrical impulse gets a ridiculous amount of post processing; I'm not positive, but there's probably some post-processing going on in and around the retina itself, and just over-the-top kinds of neural structures in the brain itself. Between all of this, our eyeballs tend to smear across time. Which is why we don't, ever, see the flickering with 15 Hz NTSC refresh rates on oldie TV sets and the much faster refresh rates on modern computers. Hm. Was just reading about bees (the insects) recently: Their compound eyes can keep up at what, for humans, would be ridiculous rates. Which probably means that computer screens would be completely illegible to them.

Next trick: The screen on the car shows flickering that we humans can see. Now, there was a previous discussion about this. If there's a flicker frequency and it gets to some multiple of the camera sample time, one can get beat frequencies (as in: LED in stop light goes off, the car samples (and sees off); time passeth by, the LED goes on, then off again, and, roughly at the time it goes off, the car samples again and sees off once more. Lather, rinse, repeat.) So, even though the red light might be on, I dunno, 80% of the time, the sample rate of the camera and the flicker rate of the LED mesh up, periodically, so it looks "off" enough long enough so that we humans see the "off" on the car's monitor screen.

But there's problems with this idea. First off, the car's monitor has its own refresh rate. How does that mesh with the camera and the LED? Two levels of indirection, yuk.

Second: By the time the signal from the camera has gotten to the chips implementing the video on the screen, it's very likely that there's been some post-processing (a la the Brain/Retina) of the raw camera signal. So, there's the possibility that, as far as the FSD-b fun is going, the video being processed by the FSD-b might not have any flickering at all; but the sub-sampled data being sent to the car's monitor very well might be.

Now, the last time we all discussed this, I had the idea that a particular stop light at a particular location seemed to result in the car, under FSD-b, attempting to run the red light. And I guessed, at the time, what with the possible flickering, that FSD-b thought that the light wasn't red, when it was.

But was that a problem with the FSD-b sampling rate? The screen sampling rate? The post processing algorithms, if any?

Fine. Open questions. Nobody but the developers know. But the fact that, in the videos above, there's no flickering on the car's screen, doesn't mean that there isn't flickering at the source: Just that the observed flickering has been compensated for by the car's computers and/or cameras.

But, now that that's in question, let's ask other, interesting questions. So, the cameras have yea many pixels. Um. But, whatever those pixels are, they have to get through the car's computers and whatnot before they get to the screen. So, at a bare minimum: Is this apparent reduction in resolution with HW3 a real reduction in resolution, or simply the displayed resolution on the screen? It's quite easy, with this kind of software, to reduce the number of pixels transmitted per second by, say, averaging across groups of pixels. Which might be fine for the car's screen and graphics, but might not be affecting the bandwidth seen by the FSD-b hardware/software.

Problem is, all of the above is pure speculation. But We Don't Have Facts. Which Makes Ruling Thing In or Out Hard. Darn it.

tmoz · Aug 9, 2023

jebinc said:
Yes, the v12 thead… that comes just before the v13 thread…

And don't forget, v13 will blow your mind, assuming v12 didn't blow it to smithereens (which I just had to look up because that is a strange word - found out it has Irish roots)

dacpdx · Aug 10, 2023

Tronguy said:
flickering with 15 Hz NTSC refresh rates on oldie TV sets and the much faster refresh rates on modern computers

actually those oldie tv sets refreshed at 60 Hz to match the mains frequency, although the frames were interlaced, so only every other line was drawn on each 1/60 s cycle. NTSC may have had its deficiencies (a British expat electronics engineer friend of mine insists it stands for “never twice the same color”) but flickering was not one of them- fascinating history the development of television (especially color) and really amazing what they were able to accomplish with the technology of the day

eli_ · Aug 10, 2023

dacpdx said:
actually those oldie tv sets refreshed at 60 Hz to match the mains frequency, although the frames were interlaced, so only every other line was drawn on each 1/60 s cycle. NTSC may have had its deficiencies (a British expat electronics engineer friend of mine insists it stands for “never twice the same color”) but flickering was not one of them- fascinating history the development of television (especially color) and really amazing what they were able to accomplish with the technology of the day

I thought they changed NTSC to 59.94hz so it explicitly wouldn't line up with the mains frequency, they were worried about audio interference or something.

Anyway, the LED flickering can be avoided by just making the exposure longer than the LED pulse, but then this oversaturates the pixels across the whole frame. So on these automotive cameras they have some "smart, patent-pending" flicker mitigation at the image processor level that tries to filter out flicker on a per-pixel basis. Otherwise you could mistake a steady light for a flashing one.

lascavarian · Aug 10, 2023

So I have had 11.4.4 for a number of weeks. Every week I do one particular drive where navigation intends to go straight through a controlled intersection. But there is an expanded right turn only lane as the intersection is approached.

Every week .4 would move into the incorrect ”right turn only” lane resulting in either an intervention OR a cringy late exit out of the “right turn only” (RTO) lane.

Last week AGAIN .4 moves into the RTO lane, gets stuck and unable exit the lane at intersection. I left a blistering message re chronic faulty lane selection as .4 navigated a long reroute to recover from the faulty lane change.

This week, .4 handled the intersection correctly as I watched in disbelief. Not a hint of wanting to move to the RTO lane.

How did this spontaneous improvement happen on the same code? The only difference was that navigation had to perform a reroute to correct the faulty lane selection (aside from my very frustrated message).

I will be interested to see how next week goes.

clydeiii · Aug 10, 2023

I've had FSDb "improve" while on the same version. I've also had it regress. I attribute it to map data but tbh no one knows.

willow_hiller · Aug 10, 2023

clydeiii said:
I've had FSDb "improve" while on the same version. I've also had it regress. I attribute it to map data but tbh no one knows.

I've thought it's also possible they are A/B testing different maps on those of us on v11.4. Because I've experienced the same thing, and I cannot think of another reason why map data would oscillate back and forth.

Some days, it takes the correct lane for an exit every time. Some days, it takes the incorrect lane every time. Tesla could be pushing slight variants of the maps to our cars on different days, and recording the aggregate number of disengagements.

Mike1080i · Aug 10, 2023

eli_ said:
I thought they changed NTSC to 59.94hz so it explicitly wouldn't line up with the mains frequency, they were worried about audio interference or something.

NTSC had a 60 Hz field rate (30 Hz frames) in the monochrome days. When RCA's monochrome compatible color system was selected, that required the change to the 59.94 interlaced field rate. It's common to have to change the CCD shutter rate (not the actual frame rate) of video cameras when a monitor or other flickering light source is on set to make it appear normal.

Dewg · Aug 10, 2023

I remember my old biology classes in high school telling us that the human eye has about a 60hz visual rate. Some people more and some less. It also explains why some people can see flickering when observing 60hz florescent lighting while others don't. Same for old CRT monitors.

swedge · Aug 10, 2023

eli_ said:
I thought they changed NTSC to 59.94hz so it explicitly wouldn't line up with the mains frequency, they were worried about audio interference or something.

The Wikipedia article on NTSC explains that it was chawed to minimize a dot pattern in the picture which results from intermodulation distortion between the 4.5 MHz audio carrier and the 3.579545 color subcarrier. They adjusted the scan line down from 15,750 Hz to 15,734.27 make it exactly 1/286 of the 4.5 MHz audio carrier. This integer multiple made the dot positions stable, and those in adjacent lines (alternating sub frames) opposite in intensity error, making them less visible. Something like that.

I first hear about this when I built a Heathkit color TV while in 9th grade. I did not understand it then, but did remember the basic issue.

From the wiki, (link):
In the black-and-white standard, the ratio of audio subcarrier frequency to line frequency is 4.5 MHz⁄15,750 Hz = 285.71. In the color standard, this becomes rounded to the integer 286, which means the color standard's line rate is 4.5 MHz⁄286 ≈ 15,734 Hz. Maintaining the same number of scan lines per field (and frame), the lower line rate must yield a lower field rate. Dividing 4500000⁄286 lines per second by 262.5 lines per field gives approximately 59.94 fields per second.

And here we thought the FSD was fiddly...

AlanSubie4Life · Aug 10, 2023

swedge said:
And here we thought the FSD was fiddly...

Way more fiddly! At least NTSC is a nice simple standard and easy to replicate.

sleepydoc · Aug 10, 2023

arnolddeleon said:
11.4.4

Did parameters get tweaked? It seems there might have been an over correction to car diving into turns lanes. The car now appears to be failing to enter turns lanes when it needed to turn. I say appears because I've disengaged and corrected. These seem to happen when I'm leaving home. When I heading home it seems to do better (quite nice actually). Almost certainly just coincidence.

Also noticed that occasionally the car will have "double vision" with stop signs. Same stop has also appeared a single. Is the system failing to integrate the multiple cameras into a single reality or is it map data not matching vision? I'm guessing it's more the former. This is because there stop sign at curving road near my house and the car gets "surprised" by it these days. I think in the past they might have used map data so it anticipated it back then. There is "stop ahead" sign but the car is clearly not "seeing" those.

I noticed that a while ago (think I may have posted about it?) First at an intersection that had temporary stop signs placed due to construction but I've noticed it at other places as well. I don't know why I didn't think of it before but I just completed a camera calibration. I haven't been back to the problem intersection yet but the few stop signs I've encountered have been visualized correctly so we'll see how it does.

Knightshade · Aug 10, 2023

lascavarian said:
How did this spontaneous improvement happen on the same code? The only difference was that navigation had to perform a reroute to correct the faulty lane selection (aside from my very frustrated message).

I will be interested to see how next week goes.

willow_hiller said:
I've thought it's also possible they are A/B testing different maps on those of us on v11.4. Because I've experienced the same thing, and I cannot think of another reason why map data would oscillate back and forth.

Some days, it takes the correct lane for an exit every time. Some days, it takes the incorrect lane every time. Tesla could be pushing slight variants of the maps to our cars on different days, and recording the aggregate number of disengagements.

Green explained this a while ago-- each time you enter a destination running FSDb the car gets a bunch of real-time map and route related stuff pushed to it by Tesla.

See thread here:

https://twitter.com/x/status/1641450299285209088

lascavarian · Aug 11, 2023

Knightshade said:
Green explained this a while ago-- each time you enter a destination running FSDb the car gets a bunch of real-time map and route related stuff pushed to it by Tesla.

I wonder if there is a difference in the quality of the data if the car has home WiFi available when the destination is resolved?

clydeiii · Aug 11, 2023

lascavarian said:
I wonder if there is a difference in the quality of the data if the car has home WiFi available when the destination is resolved?

That’s never seemed to matter for me.

lascavarian · Aug 11, 2023

I travel a road which has a national park walking trail that crosses the road. There is a pvc tube standing between the 2 lanes reminding to yield to pedestrians as well as crosswalk paint on the roadway.

FSD would regularly come to a complete stop with no pedestrians in sight. Very annoying to other traffic.

Last time 11.4.4 did not stop to my surprise. On passing the tube in the center of the road I noticed that there was a small image of a stop sign on the tube.

This small image may have been what was previously causing the erroneous stopping problem.

Scott Chapman · Aug 11, 2023

I really do wonder what is going on with FSDb releases at this point. Maybe it is just a nexus between having a ton more data to use for training and ramping up new training hardware?

willow_hiller · Aug 11, 2023

Scott Chapman said:
I really do wonder what is going on with FSDb releases at this point. Maybe it is just a nexus between having a ton more data to use for training and ramping up new training hardware?

In case you missed Elon's last tweet on the subject, work on v11 continues. Previously unknown v11.4.7 due next week, evidently.

https://twitter.com/x/status/1689948253532659712

jebinc · Aug 11, 2023

willow_hiller said:
In case you missed Elon's last tweet on the subject, work on v11 continues. Previously unknown v11.4.7 due next week, evidently.

https://twitter.com/x/status/1689948253532659712

“Mind blowing”

FSD Beta v11.x

Efficiency Obsessed Member

Active Member

S85D, Y LR, ex Prius PiP

Member

Member

little endian

Member

Well-Known Member

Member

Active Member

Member

Efficiency Obsessed Member

Well-Known Member

Well-Known Member

little endian

Member

little endian

Member

Well-Known Member

Well-Known Member

Similar threads