Another unintended acceleration issue. Fortunately, no one was injured but the Cybertruck still crashed into a house.
This happened in a rich-enough area that it was filmed by someone’s doorbell camera. There’s apparently 50-foot long line of skidmarks.
Twitter user @bfreshwa claims his stainless-steel-clad machine accelerated unexpectedly after only 4 hours total on the road. In surveillance footage, the impractical pickup darted up a hill into a neighbor’s house with the rear wheels completely locked up. The owner stated that the throttle and steering were unresponsive as he held the brake pedal to the floor, putting down a pair of 50-foot-long skid marks. The owner claimed that a Tesla representative said during a phone call:
“We have reviewed logs and due to the terrain, the accelerator may or may not disengage when the brake is depressed. As far as the back tire locking we are reviewing.”
The accelerator might keep going when the brake is held down. That’s just quality car manufacturing right there. Hell Chevrolet quit making brakes entirely in the mid-70’s.
This story has been bouncing around for a couple days.
Lots of people were saying the reason this happened was the “cheetah launch” system that doesn’t do much except warm the battery and lower the suspension…
Which, all that is fine.
The issue is to initiate it you hold the brakes and then floor it.
A glitch may be causing that juvenile and unnecessary feature to halfway activate while driving.
What I’m interested in is this is at least the third different story of an issue happening right at 4 hours after driving. I’m wondering if its so buggy that it can’t run that long continuously, it sounds like there was a complete lack of long term testing, consumers might be the first one to run these for that long straight
4 hours sounds familiar. I used to work in network engineering and polled equipment via SNMP for statistics. Some counters were measured at high resolutions that would hit their max after just a few hours of runtime.
Take an unsigned 32-bit integer or uint32_t. It has a maximum value of 4,294,967,295. That may seem like a lot, but if you had an FPGA that took measurements and provided a timestamp as ticks since boot for each message it sends back, you’d hit the maximum value after just a few hours.
For example, imagine that they had a low-power FPGA running at 1MHz which increases the tick counter on every cycle. This would cause the counter to increase by 1,000,000 every second. You’d hit the max in just under 4,295 seconds, or roughly 71 minutes. To get closer to 4 hours we’d reduce the frequency by 4 to get 250KHz.
All of this is speculative. Could be that it’s not from a value failing to update but just a divide-by-zero error somewhere. Interested to see what the public is able to uncover as the core problem.
Interested to see what the public is able to uncover as the core problem.
I’d be a lot easier for the public to do that if the code were open-source – you know, so that the property owner could control their own property, as they have every right to be able to to do.
Usually these kinds of “can’t stop acceleration” are due to mixing up the brake and acceleration or the pedal getting stuck under a nom-OEM floor mat. I was gonna say maybe that’s the case here, but it seems pretty apparent that they were at least flooring the brakes, and I don’t imagine they switched the floor mats after 4 hours.
Also that $50k fee in the linked article is hilarious.