Complex software systems are almost always nondeterministic. That means that they don't all behave identically. It also accounts for why a single car doesn't always have a given bug occur every single time (eg sometimes the screens go black, sometimes they are fine). It'd be very surprising if every Gravity displayed the exact same set of problems.
This is not true for UI software, which is 100% deterministic, otherwise all mobile apps would be constantly glitching and hallucinating like AI chatbots.
Even though I want to agree with you, the reality is most gravity owners on this forum are reporting similar or the exact same issue. In fact when I went to the service center three weeks ago, the service center was full fully aware of all issues. They even mentioned that a software update was coming.
I don’t think I’ve attacked you, or anyone else, but if you have specific examples, please point those out and I will gladly apologize. Attacking anyone is never my intent.
Again - I wasn’t attacking you. That wasn’t meant as an ad hominem. It was my reading of what you wrote.
See, there’s nothing wrong with this post. Opinions are stated as such, and not everyone needs to be happy all the time.
Deterministic, yes, assuming all other things are equal. And that’s a big assumption. There are many variables; different hardware, many possible states, etc. It is entirely possible for those variables to combine in a way that creates bugs for only some vehicles, as those are the ones with differing variables.
Not all car software is a FSM. Some might be, for example an alarm or seatbelt warning system, but much isn’t. Infotainment definitely isn’t, for example.
Which indicates that those vehicles having problems appear to have similar problems. What it doesn’t indicate is how many vehicles have problems. There are (I’m guessing) a dozen, maybe two, Gravity owners here? Of (again, guessing) hundreds of deliveries?
In principle of course I agree with everything you said. If we were in the Alpha stage of development all of this would apply and always does in such complex projects.
I hear you. I am not suggesting their QA/QC is where I’d want it.In principle of course I agree with everything you said. If we were in the Alpha stage of development all of this would apply and always does in such complex projects.
But there is a limit to the kind of bugs which make it to even a first public release, assuming the company wants to stay in business.
My car cannot possibly be that unique, even if it differs from yours. Whatever combination of approved manufacturing variations exist in my car must have been documented and tested for, prior to public release. Yes, some bugs will be missed in the initial QC cycles, but there was a whole "gosh darn" year, 300+ work days, give or take, where someone could have noticed that many UI functions are scrambling randomly and raised a red flag all the way to CEO if neccessary.
Any basic QC test team would find almost immediately that sometimes buttons don't respond or respond with random delays, both physical and touch screen variety.
I will never ever agree with you that such glaring defects can be missed in a basic QC program.
So, how in the world a QC manager signs off on a public release when "gosh darn" buttons don't work reliably in a "gosh darn" vehicle?
P.S. Trying to keep my language soft, out of respect for you and the public forum
P.P.S. Anticipating a rebuke about 300+ days where perhaps only the last update brings new bugs while fixing old ones.
It took me less than one hour of using the car after 3.3.2 was installed to notice multiple glaring UI bugs.
After reading the forum I learned that many of those bugs were present from day one, yet a multi-billion dollar company decided it's OK to ship cars with those bugs.
All hope was dashed when freshly minted 3.3.5 did not address any basic UI bugs, while seemingly adding new ones.
Again, none of my grief is about the key fob, which is understandably difficult, but still not excusable for release.
However, I could not believe my eyes when Lucid admitted in the 3.3.5 public release notes that root cause is basically unknown, because they state the issue is "reduced", not "resolved", despite 2nd firmware update in the fob itself. This smells rotten, possibly an unfixable design level issue they don't want to admit to.
Reduced issue means some kind of software kludge which attempts to catch and bypass some unexpected or unknown event or state, but can't guarantee success and doesn't stop it in the first place.
Thank you, but I also wanted to add that often people dismiss bugs related to "infotainment" system as not critical, at least not at first.I hear you. I am not suggesting their QA/QC is where I’d want it.
I was referring solely to the idea that these bugs were “impossible to only exist on some cars and not others.”
I agree with you QA should have caught it.
Look at that - common ground! Thanks for engaging.
I don't disagree with what you're saying in principle but if you look at many reviews of EV's in particular, software issues seem to plague all of them, some worse than others. I haven't read too much on it but the impression I'm getting on the Volvo EX90 is that it's a disaster. Rivian owners are also complaining about bugs and some even wish that Rivian would focus less on Halloween gimmick updates and actually fix bugs that have been in the system for some time.In principle of course I agree with everything you said. If we were in the Alpha stage of development all of this would apply and always does in such complex projects.
But there is a limit to the kind of bugs which make it to even a first public release, assuming the company wants to stay in business.
My car cannot possibly be that unique, even if it differs from yours. Whatever combination of approved manufacturing variations exist in my car must have been documented and tested for, prior to public release. Yes, some bugs will be missed in the initial QC cycles, but there was a whole "gosh darn" year, 300+ work days, give or take, where someone could have noticed that many UI functions are scrambling randomly and raised a red flag all the way to CEO if neccessary.
Any basic QC test team would find almost immediately that sometimes buttons don't respond or respond with random delays, both physical and touch screen variety.
I will never ever agree with you that such glaring defects can be missed in a basic QC program.
So, how in the world a QC manager signs off on a public release when "gosh darn" buttons don't work reliably in a "gosh darn" vehicle?
P.S. Trying to keep my language soft, out of respect for you and the public forum
P.P.S. Anticipating a rebuke about 300+ days where perhaps only the last update brings new bugs while fixing old ones.
It took me less than one hour of using the car after 3.3.2 was installed to notice multiple glaring UI bugs.
After reading the forum I learned that many of those bugs were present from day one, yet a multi-billion dollar company decided it's OK to ship cars with those bugs.
All hope was dashed when freshly minted 3.3.5 did not address any basic UI bugs, while seemingly adding new ones.
Again, none of my grief is about the key fob, which is understandably difficult, but still not excusable for release.
However, I could not believe my eyes when Lucid admitted in the 3.3.5 public release notes that root cause is basically unknown, because they state the issue is "reduced", not "resolved", despite 2nd firmware update in the fob itself. This smells rotten, possibly an unfixable design level issue they don't want to admit to.
Reduced issue means some kind of software kludge which attempts to catch and bypass some unexpected or unknown event or state, but can't guarantee success and doesn't stop it in the first place.
I don’t think I’ve ever said that. I wouldn’t agree with that either.
While modern software often has components that are deterministic, it's rarely true that the whole app is. For example, mobile apps typically have multiple threads, and minor timing differences between the threads introduces non-determinism. Good engineering practices and quality control are important regardless of the level of determinism, as you can have extremely buggy or extremely stable software regardless of the level of determinism.
Sure, we all know that the Gravity has some bugs which are widespread. My comment wasn't making any excuses for Lucid engineering. I was just pointing out that it's unreasonable to say that every vehicle owner's experience is identical, and imply that people reporting less problems are merely shilling for Lucid.
the climate screen however is really unreliable; it changes from auto to manual every time I get into the car, randomly turns on rear air and one side that I had turned off, etc.
I am not sure I understand the seat control comment. When my infotainment screens have gone black, but the main dash/cockpit over squircle is working and I can drive, I can adjust my seat using the physical controls on the seat which appear to work independently from infotainment adjustments. Is that not the case with you? Also, my seats have never randomly moved while I have been sitting in them. Curious as to whether there’s a different bug relationship out there…
Yeah, I chose not to mention that but had the same question. I suspect it was just a bad example; Homelink or something might be a better one, perhaps.
Right. This has been the standard for pretty much all cars, EV or ICE, for some time now; the computer systems that control the car's driving experience should be and is completely separated from the infotainment functionality. You can tell—when there's a black screen or a infotainment system crash, it only affects the right ⅓ of the cockpit screen and the pilot screen and the car itself is completely drivable with the left ⅔rds of the pilot screen performing as expected. In fact, pretty much all cars have redundant systems for critical controls (e.g., steer by wire) because it's so important to passenger safety.
