-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
It's not a case of any piece of code receiving a single "command" that might get corrupted in the manner you are positing. The physical accelerator pedal position is being sampled at a very high rate. I would bet a large amount of money that it is at least 10Hz, possibly as high as 100Hz. The position data is sent over a CAN bus to a processor that is both checking the data for validity (I.e. bit flips cause parity errors that get detected, transient spikes in analog values converted to digital values get thrown out due to filtering), and also consistency (I.e. pedal cannot physically reverse direction multiple times per second).
All these pedal position measurements are stored over time in the log, at least the last N seconds of data. Any data that the auto pilot software is generating related to applying acceleration or braking is a separate data stream, also at a high rate and being stored in the log.
The log file is a smoking gun. If the telemetry in the log file says the pedal was being pressed, then the pedal was being pressed. Period.
Any control system designed around the safety of human beings has taken all your possibilities into account, and dozens more, to insure that at a minimum it is capable of accurately recording what is happening. Just like the black boxes on commercial airplanes.
Can the control system malfunction? Sure, but it is also generating high rate telemetry that is logged, one item being whether it is actually engaged or not. If the telemetry says the auto pilot was not engaged, then it was not engaged.
RT
ccutrer
Active Member
From someone with such an apt username, I'm surprised at your misunderstanding of the concept of logging and interpreting logs. I've spent my fair share of time poring through gigabytes of logs from hundreds of systems trying to figure out what was the cause, and what was the effect (in my case it's usually something like database A is reporting memory issues, while the application hitting it is reporting slower queries). I'll give you the benefit of the doubt and address my following explanation to those without such a background, and not directly to you.Are you being funny or just not getting it? I'm having a hard time figuring it out since this is just text, after all. It seems there's more than logs going in circles here. (conversations too)
Assume for a moment that this was a software or hardware fault and nobody pressed the accelerator. Unlikely, but humour me for a moment.
So, in this hypothetical scenario, of course the logs would agree! Feel free to point out something that could, but I can't think of any type of logging that could actually prove that this was user error short of a dash cam aimed at the pedals. The log is getting its info from the same place the inverter is getting its signal ... the accelerator pedal and accompanying firmware.
- Somehow (mangled bits, huge noise spike, er, DC level on throttle lines, mishandled exception, you name it) the inverter receives a command to pick.it.up -- all the way.
- Software dutifully notes the command sent (100% throttle applied.)
- Other software carries out the command.
- Still other software notes that command was carried out. (Yes, we're speeding up.)
Replace the first bullet with a user stomping the pedal and you get the same net result -- logs in agreement.
Whenever analyzing logs, it totally depends on their verbosity, and when correlating between multiple systems both the precision (seconds? ms? microseconds?) and accuracy (how in sync) of their clocks. You can log both inputs you've read, actions you're about to take, and actions you have already taken. And of course hopefully you thought ahead of time which of those three choices, if any, would be most beneficial to later ascertain what happened in an event you may not have anticipated. If you didn't choose right, you can often match up preceding and following log lines with the code to infer what that data must have been if you would have been prescient enough to log it.
Anyhow, in this case, I imagine the logs look something like this:
Speedometer reporting 30mph
Brake pedal reporting 10%
TACC canceled due to brakes
Brake pedal reporting 0%
Speedometer reporting 15mph (likely logged once every second or so, maybe less, maybe more depending on other events)
Accelerator reporting 0%
Initiate regen at 75%
Speedometer reporting 6mph
Accelerator reporting 100%
Checking traction control - reporting full traction
Tell motor to torque to 100%
Traction control still reporting 100%
Collision detected
Deploying air bags A through C
Of course the logging could not report the input of the pedals, or not the commands to the motor. Or not lots of things. So if the log looks like the following, then yeah it would be circular reasoning:
Speed 6mph
Throttle 100%
Speed 20 mph
Collision!
But given how much Tesla is working on autopilot, I very much doubt they are not explicitly logging the inputs from the pedals, and the reason for output changes to the motor, and any adjustments initiated by autopilot.
All of this does not rule out that the sensor reading the accelerator pedal was malfunctioning, but it's doubtful both brake and accelerator were malfunctioning (and assuming logs show brake not pressed, and accelerator floored).
It also does not rule out Tesla not being truthful about the contents of the logs, but that would seem to be pretty risky thing, cause if they're ever found out doing that...
To int32_t
No I wasn't being funny. A circular argument says since A then B then A so therefore A is true or something like that. You find that truth is an implied assumption. I haven't seen anything implying a circular argument. Furthermore I seriously doubt there is anything forcing consistent logs. If this was a hardware failure I would expect an inconsistency. The same would be true for software. For example you might have a routine which outputs a command saying INITIATE ACTION A which got through a gating block that is set to disable the passing of the input i.e. ACTION A shouldn't be sent but the controller downstream reports receiving the command INITIATE ACTION A. Oops!!!! Bug in system. I don't know but highly suspect that no such inconsistency will be found.
Your statement that the logs are circular argues that the logs self generate consistency and that there is an A->B->C->D->A type of loop. I can't imagine either being true. The logs are just reporting points that record different system states.
I was being nice and trying to suggest that the term to be used for the logs was consistent rather than circular. Since you seem upset over this and clearly feel the logs present a circular argument then please detail where the circular nature exists. A list of things such as:
THROTTLE POSITION = A
RPM = B
BATTERY VOLTAGE = C
and so on has nothing circular about it nor does a stream showing data bus states vs time such as:
BUSA 1f,1f,1f,52,52,52,...
No I wasn't being funny. A circular argument says since A then B then A so therefore A is true or something like that. You find that truth is an implied assumption. I haven't seen anything implying a circular argument. Furthermore I seriously doubt there is anything forcing consistent logs. If this was a hardware failure I would expect an inconsistency. The same would be true for software. For example you might have a routine which outputs a command saying INITIATE ACTION A which got through a gating block that is set to disable the passing of the input i.e. ACTION A shouldn't be sent but the controller downstream reports receiving the command INITIATE ACTION A. Oops!!!! Bug in system. I don't know but highly suspect that no such inconsistency will be found.
Your statement that the logs are circular argues that the logs self generate consistency and that there is an A->B->C->D->A type of loop. I can't imagine either being true. The logs are just reporting points that record different system states.
I was being nice and trying to suggest that the term to be used for the logs was consistent rather than circular. Since you seem upset over this and clearly feel the logs present a circular argument then please detail where the circular nature exists. A list of things such as:
THROTTLE POSITION = A
RPM = B
BATTERY VOLTAGE = C
and so on has nothing circular about it nor does a stream showing data bus states vs time such as:
BUSA 1f,1f,1f,52,52,52,...
int32_t
Tesla Spotter
Thanks for the details on how logging works. In my defense I spend the vast majority of my time programming at a rather low level, so I know little about higher-level techniques and theory -- that includes logging.
Given the hypothetical data you present, it sounds like this debate really comes down to whether the brake or the accelerator was pressed, not whether nothing or the accelerator was pressed. For some reason that didn't occur to me before and it makes more sense given the situation ...
I thought it was that the vehicle was pulling into a parking spot and the driver wasn't touching anything and the vehicle suddenly went crazy, whereas it's more likely the driver was trying to press the brake. I'm on the same page now.So then if the log reports the wrong pedal was pressed and the resultant action was correct (but obviously not desirable for the driver!) then the car is in the clear and it kind of (by which I mean absolutely and without question) condemns the driver. Coming from this angle it isn't a circular argument at all.
I'm not upset, just trying to point out what looked like a bit of flawed logic, and I did try to clarify what I perceived as the circular portion. However, it turns out that's not what the argument is about, so it's totally moot anyways. Thanks for bearing with me.
systemcrashed
Please Reboot
The pure power and performance of this car is no joke. Some new owners might need a "check flight" before taking it out on their own. This accident shows all the signs and symptoms of a flustered new owner jumping the curb and hitting the accelerator by mistake, thankfully it only resulted in property damage and they are ok.
goneskiian
Active Member
Like Elon said regarding making full AP legal and common, perhaps we need to make it harder to get a drivers license. It is NOT a RIGHT, it is a PRIVILEGE and should require more skill than is commonly displayed.
Todd Burch
14-Year Member
CuriousG
Active Member
Honestly was not aware it was the same car until this morning when I pulled the autopilot camera EDR data.
ccutrer
Active Member
I'm glad to have a third party confirm Tesla's narrative, but I do have privacy concerns. When you use the reset functionality on the MCU (as you should do when disposing of a vehicle), does it wipe the logs and camera data? I hope so, and that this vehicle had just never been reset.
NathanWolf
Member
Wow, small world- that is pretty incredible
I imagine Tesla gets these snapshots when they pull log data? I'd be curious to know, maybe you could share it with them.
Wow, small world- that is pretty incredible
I imagine Tesla gets these snapshots when they pull log data? I'd be curious to know, maybe you could share it with them.
According to the logs.... they already downloaded the logs.
NathanWolf
Member
Ha- well mainly I didn't know if the AP camera memory was part of the logs, or if that was a separate thing fetched by other means.
int32_t
Tesla Spotter
There aren't that many smashed Teslas out there to choose from.Wow, small world- that is pretty incredible
...
NathanWolf
Member
There aren't that many smashed Teslas out there to choose from.
Let's hope it stays that way!
Also, @wk057 you're famous?
Several Tesla owners claim Model X accelerated/crashed on its own but everything points to user error
Similar threads
