JupiterMan
Active Member
last winter I had ice/dirt/snow block my radar twice, meaning I had to wash the front of my Model 3 before it would work again.
Tesla Vision will remove this issue this winter.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
[uk] UltraSonic Sensors removal/TV replacement performance
- Thread starter randompixel
- Start date
Tesla Vision will remove this issue this winter.
Yes, because of course the cameras never get blocked or blinded.
Tesla will remove the issue this winter because the cameras won't work no matter what the weather is.
Tesla Vision ersetzt Ultraschallsensoren (USS) (Teil 1)
Guten Morgen, heute Nacht wurde mein Model Y Performance MJ 2023 ohne USS mit der neuesten Software 2022.40.4 geupdatet. Auch nach diesem Update ist von einer Einparkhilfe nichts zu bemerken. Ich habe wieder einige Bilder gemacht. Gegenüber den Bildern kurz nach der Auslieferung in der letzten...tff-forum.de
History tells us it'll be a server side switch, the software will be deployed first, then a limited trial in the wild, then rollout .
We've seem many examples on this forum, including with the radar switch off, whereby the enablement and release notes didn't align. Then at a later date, mysteriously going back and reading the release notes again, a new change entry appears.
Even the heated steering wheel has a server side switch.
Last edited:
Zilla91
Active Member
ACarneiro
Active Member
Problem is that with safety-of-life code (as the one in, say, cars), “breaking things” may be quite a literal thing…
SalisburySam
Active Member
Does this mean the cameras too will be removed? TV to change to AuraVision, basically driving with The Force?
It’s a side topic, but I agree, it’s going to be interesting to see how a regulator looks at self driving code, software updates, regression testing after an update, and non deterministic AI models (ie it’s not rules based) for all self driving solutions, not just Teslas, but the bugs we get now aren’t going to help the argument. Boeing has shown a manufacturer can not be trusted. But probably one for another day, or another thread.
I have a friend who does software for SCADA systems and he is always amazed at things like LaunchDarkly. Thank God!It’s this very annoying practice where anything and everything goes into the master/main branch and sits behind a feature flag even when it’s not complete.
Gone are the good old days where only production ready code goes into master…
Move fast and break things
rowedav
Member
Probably not scarcasm…he’s a buddy of Elons and a Tesla backer and investor…so no surprise he’s coming out with such a viewpoint
SalisburySam
Active Member
The owner probably added the curb feelers after borking the rims to preclude further damage.
MashinBenzin
Member
God ACC/lane following is so poor in Teslas. Another day of phantom braking, abrupt disengagements, refusal to accelerate as the lane ahead clears and harsh lane centring if engaged early. My wife never even noticed my Land Rover had this stuff when I used it, with the Tesla today she said “why are you even using that crap”.
Last edited:
Gone are the good old days where only production ready code goes into master…
Move fast and break things
The feature flags are there to prevent things from becoming broken. Large batches of change (ie feature branch merges) increase the risk of something going wrong due to delayed feedback and a larger surface area of stuff changing. Small, incremental changes with tests run on each and every commit reduce both the likelihood and impact of b0rk, and make any introduced regressions easier to manage. This approach arguably comes from vehicle manufacturing in the first place: long before Dave Farley and co wrote Continuous Delivery, Taiichi Ohno wrote about "autonomation" (automation combined with intelligence to tell whether the right thing was done, ie tests) in the Toyota Production System as a means of reducing lead times and improving the flow efficiency of a manufacturing system.
If anything we should be *happy* that they’re so feature flag heavy. I like the fact that someone can turn off a feature if there’s critical issues without the need for proper code changes.
Granted I’m going to be incredibly biased with my response but it can be all to easy to assume a lack of competence of those doing the work vs not being setup to succeed.
I’d bet good money that there’s incredible dev talent at Tesla, but there’s also no hiding the work ethic expectations. Do I think they take too many risks with quality? Hard to say. For all we know the active stack is full of decade old tech debt meaning that this talent spends all of their time fighting fires, most likely being forced to release work to ridiculous timescales. If all that happened without feature flags then this would be a far worse situation than it is. It’s all good and we’ll saying “the code should just work”, but when you don’t know the detail it’s hard to pass direct judgement.
Given all the above, do I trust their software releases? Absolutely not! Would I have the same explicit trust of my current parking sensors with a vision replacement? Absolutely not! Could that trust be built up? I bloody well hope so!
SalisburySam
Active Member
No, it isn’t hard at all. We judge based on what is delivered, what we’ve paid for, what marketing materials have said to set our expectations, and what we experience. Don’t give a whit about the behind-the-scenes stories, difficulties, challenges, talent, problems, methodologies, or costs. If it works to my expectations, I’m happy. If it doesn’t…I judge.
Amen. And good luck to us all.
Zilla91
Active Member
Doesn’t really work that way in practice as testing inevitably gets pushed to the back burner with a promise that they’ll be added later and then never done.
Having everything behind a conditional feature flag also makes testing near enough impossible as you end up with an impossible number of permutations and there’s no way you can confidently test every one of those permutations and that’s why there are so many bugs in the software
Another fun one is accidentally leaving something “off” because you aren’t keeping track of the flags.
You’d hope they don’t have crazy dependencies between features such that combinations cause issues, also pigs may fly. It could well be that level of craziness that causes the regular issues introduced by updates that people see today. I think I’d still prefer this approach to delivery over a much slower set of big bang releases; small iterative issues allow for the team to move forwards. Totally get the pros and cons with both approaches - but I will assume that many people would differ at this point depending on what their focus is on certain areas in life, and how badly bugs have impacted them before.
The bit I cannot wrap my head around, and that I feel *so* sorry for the responsible development team for, is the removal of USS before the feature is even ready; surely someone outside of their team forced that. If it was done within their team, however, then there is no defense for them! Imagine how differently we’d feel if they had developed the work, rolled it out to every car to work in parallel with USS, and then use that data to decide “we can remove the sensors”, whereas unfortunately I struggle to see how that is the case here given that the features such as park assist are gone until further notice.
Similar threads
