Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Musk: V10 wide release "hopefully end of august" after early access

This site may earn commission on affiliate links.
I am definitely in the camp that is more interested in AP/FSD progress than these miscellaneous features. But if I am not mistaken, Elon added "hungry" and "lucky" mode because tesla owners asked him on twitter. So there are tesla owners who wanted them.

Not to be overly "flippant," but really? :eek: Just think about your statement. Yes, I'm sure people ask for all kinds of things, but do you really think more people asked Elon for these parlor tricks/gimmicks, than say these more substantive requests; fixing the dancing cars, releasing Enhanced Summon/v10, removing "beta" tags from existing released Beta features, AWD to M3P- upgrade, fix bugs, etc., etc.??? :confused: I doubt more people asked for more farts variants, "hungry mode" and "lucky mode" functionality (more so than substantive requests), such that Elon prioritized these parlor tricks/gimmicks over substantive stuff. Do you really believe that? o_O

Many thousands of people have been asking for these more substantive things, and nothing (yet).
 
Last edited:
Not to be overly "flippant," but really? :eek: Just think about your statement. Yes, I'm sure people ask for all kinds of things, but do you really think more people asked Elon for these parlor tricks/gimmicks, than say these more substantive requests; fixing the dancing cars, releasing Enhanced Summon/v10, removing "beta" tags from existing released Beta features, AWD to M3P- upgrade, fix bugs, etc., etc.??? :confused: Many thousands of people have been asking for these more substantive things, and nothing. I doubt more people asked for farts, hungry mode and lucky functionality (more so than substantive requests), such that Elon prioritized these parlor tricks/gimmicks over substantive stuff. Do yo really believe that? o_O

Tesla is working very hard on the big features like Enhanced Summon and FSD. Tesla is devoting their entire AP teams to working on them. Tesla is not ignoring AP and FSD just to do these "parlor tricks". Obviously, AP and FSD take longer since they are massive projects. We will get all those big things that we want. Elon is not prioritizing these small features over AP or FSD. These small features take very little development time compared to FSD and do provide some value. It's no sweat to release some small features that add a little value to customers while the main teams continue working on the big stuff.
 
  • Like
Reactions: mrmage
Tesla is working very hard on the big features like Enhanced Summon and FSD. Tesla is devoting their entire AP teams to working on them. Tesla is not ignoring AP and FSD just to do these "parlor tricks". Obviously, AP and FSD take longer since they are massive projects. We will get all those big things that we want. Elon is not prioritizing these small features over AP or FSD. These small features take very little development time compared to FSD and do provide some value. It's no sweat to release some small features that add a little value to customers while the main teams continue working on the big stuff.

Could be, not sure what the thought process is, I can only comment on the results of said process. I would refer you back to my earlier post (#150). Using these gimmicks to provide entertainment/cover during the otherwise extended substance delayed/postponed release period (e.g., v10, Enhanced Summon, etc.)

Musk: V10 wide release "hopefully end of august" after early access
 
Last edited:
Could be, not sure what the thought process is, I can only comment on the results of said process. I would refer you back to my earlier post (#150). Using these gimmicks to provide entertainment/cover during the otherwise extended substance delayed/postponed release period (e.g., v10, Enhanced Summon, etc.)

Musk: V10 wide release "hopefully end of august" after early access

Would it be better if there were no “gimmicks” whatsoever, yet no improvement in FSD timeline? In fact, maybe the FSD timeline *slows down* if there were no “gimmicks”?

What people don’t get is that engineers are not fungible in the slightest. There could be a handful of brilliant machine learning devs in Tesla that are key to making FSD work, but hiring typical engineers beyond supporting the core FSD team will not help.

What *will* help is finding the next brilliant engineer. What do you think brilliant engineers are attracted to besides interesting projects? If you said flashy and cool and fun things, you’d be right. If you said boring features that have been done a thousand times before, you would be 100% wrong.

Although a good game dev won’t help the FSD team, they can raise the visibility and coolness of Tesla. Or maybe they can help with the graphics of FSD UI, but port some games over in their spare time. Regardless, what’s wrong with adding something shiny and cool if it’s not going to impact FSD?

US automakers spend billions in advertising. Tesla spends none. Tesla adds cool, new features for hundreds of thousands or millions, that get more press than billions in advertising and attract brilliant people to work there for less. That is nothing to complain about.
 
Could be, not sure... I would refer you back to my earlier post (#150). Using these gimmicks to provide entertainment/cover during the otherwise extended substance delayed/postponed release period (e.g., v10, Enhanced Summon, etc.)

Musk: V10 wide release "hopefully end of august" after early access

I agree the features provide entertainment in between releases of big AP/FSD features. But I don't think there is anything wrong with that. For example, there was about 6 months between NOA with confirmation and NOA without confirmation. Why not fill that time with some smaller fun updates, even a couple games, to keep owners entertained?

I do make a distinction though between the games/easter eggs and miscellaneous features like "hungry" mode in the nav. Games and fart sounds provide some silly entertainment maybe. They are more amusing than anything else. But a feature like "hungry" mode in the nav actually does provide some value. "Hungry" and "Lucky" mode give owners a destination when they want to go on a road adventure. So it does make road trips more interesting. The feature actually relates and enhances the driving experience in a way that games do not.
 
Last edited:
I agree the features provide entertainment in between releases of big AP/FSD features. But I don't think there is anything wrong with that. For example, there was about 6 months between NOA with confirmation and NOA without confirmation. Why not fill that time with some smaller fun updates, even a couple games, to keep owners entertained?

I do make a distinction though between the games/easter eggs and miscellaneous features like "hungry" mode in the nav. Games and fart sounds provide some silly entertainment maybe. They are more amusing than anything else. But a feature like "hungry" mode in the nav actually does provide some value. "Hungry" and "Lucky" mode give owners a destination when they want to go on a road adventure. So it does make road trips more interesting. The feature actually relates and enhances the driving experience in a way that games do not.

No quarrel with that. Your earlier logic, I think, was that these recent gimmicks were released because "people asked for them," and not as a strategy for keeping people entertained while substance delays persist. My observation, and subsequent comments, sum up to the fact that most of what we have seen, in the past six months or so, have been these, "keep the animals entertained - it's going to take us longer to get the meat delivered" parlor tricks and gimmicks, as the real substance gets regularly pushed further and further to the right without much discussion (e.g., look how long v9 and Enhanced Summon were/are delayed - and now v10... These frequently released gimmicks try to keep people's (customers, investors, etc.) attention focused on the gimmicks rather than the performance delays, and reasons behind them - kind of like a stall tactic. That's what post #150 was about. I would love to hear more about what challenges the development team are facing, and plans for tackling them - This is how it usually works in the aerospace industry, that I spend my career in.
 
Last edited:
  • Helpful
Reactions: diplomat33
He's saying that while mainstream folks are using AP version 20.x, he's testing version 28.x which is obviously far ahead.

New software variations (branches) are derived from a main variation at time X. A new AP variation is developed independently from the main variation for testing and development, so changes to main variation don't cause bugs in the new AP variation and vice versa, because both variations can be updated independently as necessary.

If it takes a long time to test the new AP variation, the main variation can undergo many changes from where it was at time X, when the branch occurred.

This means the changes in the latest AP variation (based on main X) and latest main are hard to merge, because latest main is so different from main X.

It may not be worth merging them yet. Or maybe it was never the intent to merge them. Sometimes branches are created just to test something out.
True, however that is not best practice software development anno 2019. It was 10 years ago. Not unless it's more or less a complete rewrite like that 2018.10.1 release anyway.

What one should do is breaking the next big feature into lots of sub-dependencies. And gradually implement each dependency, test them and merge them into the main branch continuously. So the master branch is never more than 2 weeks behind the latest development. You just feature-flag it off until ready. Then you release all the time, so you can catch production issues and regressions early while nobody notices them.

There's lot of evidence Tesla works this way, such as frequent seemingly similar releases as well as things like stop sign recognition showing up behind the scenes feature-flagged off.

In general the modern strategy works better, because large changes tend to delay for a long time, and introducing them to production is high risk. Sometimes it grows so big they get scrapped before they go out. With lots of smaller changes each designed to make the software better, that is not a problem, plus you are much more agile to change direction fast if your business requires so.
 
And for the other 99.925% of us that actually use our cars for a car and not an extension of an x-box / PlayStation etc....we just want what a Elon / Tesla has either publicly stated and or currently has on their web site in plain text. I don’t ever find opportunity to just “sit in my car to play games”. Maybe I will find some merit when FSD allows it but for now it’s more of a sticking point than a benefit to more of us than not.
 
  • Like
Reactions: am_dmd and kavyboy
True, however that is not best practice software development anno 2019. It was 10 years ago. Not unless it's more or less a complete rewrite like that 2018.10.1 release anyway.

What one should do is breaking the next big feature into lots of sub-dependencies. And gradually implement each dependency, test them and merge them into the main branch continuously. So the master branch is never more than 2 weeks behind the latest development. You just feature-flag it off until ready. Then you release all the time, so you can catch production issues and regressions early while nobody notices them.

There's lot of evidence Tesla works this way, such as frequent seemingly similar releases as well as things like stop sign recognition showing up behind the scenes feature-flagged off.

In general the modern strategy works better, because large changes tend to delay for a long time, and introducing them to production is high risk. Sometimes it grows so big they get scrapped before they go out. With lots of smaller changes each designed to make the software better, that is not a problem, plus you are much more agile to change direction fast if your business requires so.

I was explaining what TMeister said in response to a non-technical poster, who wanted a layman's explanation. If you feel my explanation misrepresented what he said, feel free to correct.

But while we're on the subject.. small things like traffic sign recognition can be incrementally added without side effects. However, my sense is that the core of Tesla's FSD needs to be a complete rewrite, and not just a series of incremental changes. The wide gulf between the tech day demos and the current EAP implies that FSD is a completely different animal.
 
I was explaining what TMeister said in response to a non-technical poster, who wanted a layman's explanation. If you feel my explanation misrepresented what he said, feel free to correct.

But while we're on the subject.. small things like traffic sign recognition can be incrementally added without side effects. However, my sense is that the core of Tesla's FSD needs to be a complete rewrite, and not just a series of incremental changes. The wide gulf between the tech day demos and the current EAP implies that FSD is a completely different animal.

Some incremental changes might be enough to accomplish the functionality shown in the demo day videos, see these videos from June coming from a slightly hacked version of the firmware at the time: Tesla Hacking - YouTube

There are a bunch of examples of all the features shown on demo day, other than the on-screen visualizations. The NoA shown on city streets is not very good in that particular public build but IMO the gulf isn't *that* wide, especially for a build from 4 months ago (I forget the version number).

Like when it miscalculates a left turn here around the 3:04 mark, this is a public build which isn't meant to take such turns anyway, but there are some videos today floating around of newer firmwares making occasional left turns even without hacking:
 
  • Informative
Reactions: jebinc
Some incremental changes might be enough to accomplish the functionality shown in the demo day videos, see these videos from June coming from a slightly hacked version of the firmware at the time: Tesla Hacking - YouTube

There are a bunch of examples of all the features shown on demo day, other than the on-screen visualizations. The NoA shown on city streets is not very good in that particular public build but IMO the gulf isn't *that* wide, especially for a build from 4 months ago (I forget the version number).

Like when it miscalculates a left turn here around the 3:04 mark, this is a public build which isn't meant to take such turns anyway, but there are some videos today floating around of newer firmwares making occasional left turns even without hacking:

That is a very promising video, especially considering it was back in June. I'd be happy to be proven wrong by having Tesla deliver any kind of FSD that's a leap up from what I see now within this year. IMO, this is what could move the needle.
 
Last edited:
True, however that is not best practice software development anno 2019. It was 10 years ago. Not unless it's more or less a complete rewrite like that 2018.10.1 release anyway.

What one should do is breaking the next big feature into lots of sub-dependencies. And gradually implement each dependency, test them and merge them into the main branch continuously. So the master branch is never more than 2 weeks behind the latest development. You just feature-flag it off until ready. Then you release all the time, so you can catch production issues and regressions early while nobody notices them.

There's lot of evidence Tesla works this way, such as frequent seemingly similar releases as well as things like stop sign recognition showing up behind the scenes feature-flagged off.

In general the modern strategy works better, because large changes tend to delay for a long time, and introducing them to production is high risk. Sometimes it grows so big they get scrapped before they go out. With lots of smaller changes each designed to make the software better, that is not a problem, plus you are much more agile to change direction fast if your business requires so.
Yeah, OK I'm just old school. But...

The evidence suggests Tesla is too. Why would early access users get such an old release with many features missing that are already on main? If it were just feature flag methodology there would be no reason to disable current main features and send a release to EA users. That's' negative progress for those users. This is what has happened. The current EA release did not have features that were released from main at the same time. I really do think Tesla is trying to isolate the EA features so they can be tested in a relative vacuum.

Still, today EA users are on 2019.20.4.6 sent out the second week of July. If we believe Tesla's release labeling this release was branched from main in May and took another two months to get to end users.

If feature enabling were the rule, releases would come much quicker and with less incremental implementation. Now we wait for V10 to go to EA users. I'm gonna go out on a limb and say that it will be labeled 2019.28 or so since it was likely branched off main in mid-July and will take until sometime in September to get out to users.
 
However, my sense is that the core of Tesla's FSD needs to be a complete rewrite, and not just a series of incremental changes.

My professional SW career goes back to the mid 90s so I’ve seen quite a few projects in my life, some of them in fairly large (300+ SW engineers) teams.

Complete rewrites of complex software are almost always the result of catastrophic failure of SW architecture or personnel management or extreme spec changes or a combination of these.

It’s rarely a good sign and comes with its own huge risks.

If Tesla’s FSD core needs a complete rewrite then you can stick a fork in it for the next three years, given that we are talking about something cutting edge and not a new version of existing tech.
 
  • Like
Reactions: kavyboy
I was explaining what TMeister said in response to a non-technical poster, who wanted a layman's explanation. If you feel my explanation misrepresented what he said, feel free to correct.

But while we're on the subject.. small things like traffic sign recognition can be incrementally added without side effects. However, my sense is that the core of Tesla's FSD needs to be a complete rewrite, and not just a series of incremental changes. The wide gulf between the tech day demos and the current EAP implies that FSD is a completely different animal.

Aside from the investor day, I don't think we've seen the FSD core at work yet.

eAP on AP3 cars is still said to be running adapted versions of the low resolution AP2.5 neural networks.

Those are already remarkably good at what they do, but they clearly fall well short of FSD. My expectation is that one of these firmware updates, they'll upload the FSD core that they've been working on for a few years now to the FSD enabled HW3 cars, and we'll see them suddenly become more capable at the existing tasks as they start to roll out the new ones.

Until that happens - until they give us a network natively designed to run on HW3 and at full resolution, I don't think we can judge their progress effectively or decide if they are on the right track.
 
My professional SW career goes back to the mid 90s so I’ve seen quite a few projects in my life, some of them in fairly large (300+ SW engineers) teams.

*Complete rewrites of complex software are almost always the result of catastrophic failure of SW architecture or personnel management or extreme spec changes or a combination of these.*

It’s rarely a good sign and comes with its own huge risks.

If Tesla’s FSD core needs a complete rewrite then you can stick a fork in it for the next three years, given that we are talking about something cutting edge and not a new version of existing tech.

I’ve got a decade on you in sw dev and management, but software changes so much that only the last 5 or 10 years counts. This has been a constant: challenging tasks always slip and the unknown is harder than what people expect.

I have only seen Tesla (in videos) handle small numbers of miles on arbitrary local traffic between disengagements. On the order of 10 miles or less, but it needs to be millions of miles. It’s off by 5 or 6 orders of magnitude. It needs to go from 90% to 99.9999%, which is more likely a stack change than incremental tweaks.

I would not be surprised if the ML stack is reconfigured and rearchitected frequently on the navigational part (eg advanced summon), which I consider the FSD core. I don’t lump discrete functions like speed limit or traffic light recognition as part of that. Those are like device drivers. Important, exacting, and time consuming, but low risk.

My go-to analogy for general, non-map based, machine navigation is machine speech recognition. Prior to neural networks circa 2010, the accuracy of speech recognition was dismal. NN replaced every speech recognition algorithm because it was more accurate by orders of magnitude, but even then, orders of magnitude improvement took awhile.

Looking at the curve in the graph, Tesla looks closer to pre 2010 than post 2010 relative to reaching 5 or 6 more digits improvement in the general case. Ie pretend the vertical scale is log than linear.

http://pavel.surmenok.com/wp-content/uploads/2016/02/va2016-1.png

At the risk of repeating myself:

A sufficiently advanced summon is indistinguishable from FSD.
 
Last edited: