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

Sudden Unexpected Acceleration today

This site may earn commission on affiliate links.
This happened a few hours ago near me. Model X barreled into the front of the bank. I bet the owner will claim unintended acceleration. I bet the logs will show the accelerator was pressed.
View attachment 299542

Geez, it's a pandemic! :eek:

Serious question: if the car glitched out and actually did accelerate without the driver pressing down the pedal, wouldn't the logs reflect that as well (intentional acceleration)? So any unintended acceleration would still be recorded as if the pedal was depressed? Does Tesla's logs record the physical movement of the accelerator/brake pedals as well?
 
  • Disagree
Reactions: EinSV
And I bet this will continue until we either change Driver behavior or find what’s really causing these misinterpreted pedals and clear the gremlins in our brains or the car. Why do we not see that there’s a pattern and there might be a burden or responsibility that has to be shared between drivers and car manufacturers?
If you think that there is some common design flaw in all cars that is causing this then you are certainly free to investigate it and come up with a solution. Since this is occurring across all car brands, including ICE, BEV, and hybrids, in cars, trucks and SUVs. There are only a few things that are common to all of them, the first and most obvious of which is human driver.
 
I’d be afraid of mapping the pedal power curve differently based in circumstances. There will be a time it doesn’t identify the parking spot appropriately and the pedal is pushed harder due to “parking mode” and result in an accident.

But they already do this for Ludicrous, for valet mode, for reverse, chill mode, etc. If the screen were to say parking mode then it's like an extreme valet mode in that power is simply limited. You shouldn't have to push harder or push the accelerator at all if you intend to hit the brake.

If you're dead set on hitting the accelerator then do as the driver requests... but with little power. Save the driver from themselves if they choose to enable the feature and hit the accelerator when trying to park.

Consider this, if it fails to detect that you're trying to park, then it wouldn't be any worse off than it is now if you were to slam on the accelerator. (plus if the screen doesn't confirm it, then you can safely assume it's not enabled per my original post suggesting a notification if they implemented such a feature)
 
Last edited:
But they already do this for Ludicrous, for valet mode, for reverse, chill mode, etc. If the screen were to say parking mode then it's like an extreme valet mode in that power is simply limited. You shouldn't have to push harder or push the accelerator at all if you intend to hit the brake.

If you're dead set on hitting the accelerator then do as the driver requests... but with little power. Save the driver from themselves if they choose to enable the feature and hit the accelerator when trying to park.

Consider this, if it fails to detect that you're trying to park, then it wouldn't be any worse off than it is now if you were to slam on the accelerator. (plus if the screen doesn't confirm it, then you can safely assume it's not enabled per my original post suggesting a notification if they implemented such a feature)
True. But those modes aren’t somehow auto-detected. And thus subject to either false positives or false negatives.
 
Ha, I guess that would be more desired! :p thanks for catching my faux pas..

This could be built into our cars along with the selfie cams.

BTW - most members here are of the opinion that this is just another case of pedal misapplication and I am hoping that is the case. However, has anyone here have looked at cross referencing what the ECU did vs. what the ACTUAL PHYSICAL pedal position was? Given all throttles are wired, a user does not need to press a pedal in order to control the accelerator - it is merely used as another input for driving a car.

Case in point - when we engage AP, we are not touching the accelerator or the brake and the pedals are not moving PHYSICALLY while the car drives on its own, slows down and speeds up. These actions are controlled by software with no required input from the driver except holding the steering wheel every so often (though folks have found a funny way of trivializing the seriousness of the driving with oranges). This leaves an open possibility of throttle by wire cars having software malfunctions not just in throttle position but braking, steering, engine speed etc. etc.

What if there are declarations of global variables that when initiated contain incorrect value and when certain conditions are met, are called by a subroutine resulting in incorrect data being send to the vehicles ECU resulting in erroneous behavior?

Do we have anyone on the forum who's done embedded programming for cars who can chime in? Also I do not know if Tesla uses MISRA guidelines and if they do - what SIL level have they adopted?
 
This could be built into our cars along with the selfie cams.

BTW - most members here are of the opinion that this is just another case of pedal misapplication and I am hoping that is the case. However, has anyone here have looked at cross referencing what the ECU did vs. what the ACTUAL PHYSICAL pedal position was? Given all throttles are wired, a user does not need to press a pedal in order to control the accelerator - it is merely used as another input for driving a car.

Case in point - when we engage AP, we are not touching the accelerator or the brake and the pedals are not moving PHYSICALLY while the car drives on its own, slows down and speeds up. These actions are controlled by software with no required input from the driver except holding the steering wheel every so often (though folks have found a funny way of trivializing the seriousness of the driving with oranges). This leaves an open possibility of throttle by wire cars having software malfunctions not just in throttle position but braking, steering, engine speed etc. etc.

What if there are declarations of global variables that when initiated contain incorrect value and when certain conditions are met, are called by a subroutine resulting in incorrect data being send to the vehicles ECU resulting in erroneous behavior?

Do we have anyone on the forum who's done embedded programming for cars who can chime in? Also I do not know if Tesla uses MISRA guidelines and if they do - what SIL level have they adopted?

You might want to reread the thread...


Tesla's accelerator pedal is actually the exact same drive-by-wire pedal used in several other manufacturer's vehicles. It's highly proven technology over decades. Nothing special at this point. No Tesla secret sauce here. Just two hall effect sensors with slightly different curves for redundancy and position validation. If they don't agree, the car doesn't move. If one has an issue, the car reduces power and gives an error. I've personally never seen one of these throttle assemblies have a problem because they're literally as basic as these things can get. It's plastic, a spring to return the pedal to rest, and two hall effect sensors for positioning. They're rock solid on reliability and used in millions of vehicles.

Tesla's side for sensing this goes even further to improve safety. They have two independent systems monitoring and logging the pedal sensors, isolated from one another. They both log the read position from both sensors. If anything doesn't exactly agree, the car doesn't move, gives an error, and reduces power to the point where you can barely do 0-60 in a minute.

Well we can't, since we don't have code access, but the industry has created specialized programs that test and verify code design to validate that there are no loose corner cases. Then the routines are wrapped in check calculations with shadow ECC memory and run on specially designed safety processors with dual cores in lock step. Hercules (processors) - Wikipedia
Airliners are fully fly by wire, that's the level of fault elimination that has been achieved.

If you are interested, the transcript from the Toyota UA case had lots of coverage of the technical aspects and where their SW failed to maintain redundancy, thus allowing for the possibility that the UA was SW induced.
 
  • Like
  • Helpful
Reactions: Lem89 and wk057
You all must be driving some slow automatic cars. The Model 3 is not exceptionally fast off the line. Every single make and model of car has unintended acceleration incidents...
The solution is to go back to manual transmissions! :p

Right, no one ever popped the clutch thinking it was in neutral or confused forward vs reverse ;)
Time to go single pedal hydrostatic with brake on the left side (of the tractor)!
 
  • Like
Reactions: MP3Mike and Olle
Right, no one ever popped the clutch thinking it was in neutral or confused forward vs reverse ;)
Time to go single pedal hydrostatic with brake on the left side (of the tractor)!
Touche. The difference is the car only goes a foot or two if you do that. I've never accidentally mixed up forward and reverse though. Also if you want to stop you instinctively press in the clutch.
It does seem like the best solution is to put a second brake pedal on the left side. I guess there's really no reason to brake with your right foot anymore.
 
You might want to reread the thread...

Mongo - Yes I had read your thread regarding ISO 26262 safety standard and Jason's excellent explanation of the throttle body operation. I can understand that the physical pedal did not have a malfunction in its operation i.e. no spring jam, no lockup etc. and also the way the HW processor redundancy eliminates false positives when it does not agree with current signal from the throttle.

What we don't know is what you called out in your thread regarding the lack of code access to know what and how Tesla has implemented it's SW and what HW is being used to control the vehicle operation? All I hear about is NVIDIA processors but they are more for processing visual data from the cameras to help apply Neural Net algo. to AP. There's a significant amount of black hole when it comes to knowing how the AP algorithms interface with vehicle operation algos.

This issue aside - some folks here have reported that the car suddenly decelerated or shifted lanes while operating on AP. Hence, any undesirable outcome from a HW/SW control should be investigated.
 
Mongo - Yes I had read your thread regarding ISO 26262 safety standard and Jason's excellent explanation of the throttle body operation. I can understand that the physical pedal did not have a malfunction in its operation i.e. no spring jam, no lockup etc. and also the way the HW processor redundancy eliminates false positives when it does not agree with current signal from the throttle.

So then why this question:
However, has anyone here have looked at cross referencing what the ECU did vs. what the ACTUAL PHYSICAL pedal position was? Given all throttles are wired, a user does not need to press a pedal in order to control the accelerator - it is merely used as another input for driving a car.

This is exactly what Jason is referring to ( I assume you meant throttle pedal, not body) . The two pedal sensors, as reported by two different ECUs, show a physical movement of the pedal. AP/TACC input occurs in a separate part of the code from the sensor monitoring.

What we don't know is what you called out in your thread regarding the lack of code access to know what and how Tesla has implemented it's SW and what HW is being used to control the vehicle operation? All I hear about is NVIDIA processors but they are more for processing visual data from the cameras to help apply Neural Net algo. to AP. There's a significant amount of black hole when it comes to knowing how the AP algorithms interface with vehicle operation algos.

The drive unit control is handled by the processors in the drive unit inverter. Nothing to do with the Nvidia system. Jason also posted his attempts to bypass the safety systems.