Sounds like a heart attack to me.
Well, it couldn’t have been too bad, since the driver posted the results. Falling asleep or being distracted by a phone seems more likely. Maybe they had their arm resting on the left spoke of the steering wheel, and eventually it overrode the torque sensor.
I’m confused by your comment. The data says the brakes were manually applied twice. Once for about 1/4 second and again a second+ later for about 3/4 of a second.
The initial brake application aligns in time with the beginning of the deceleration.
Now one interpretation of the data is that as the car was crashing the inertia of the driver carried their foot forward onto the brake pedal. And as they were thrashing aroound in there as the car stopped their foot again was against the brake.
I am surprised the brake pedal data is just “brake pressed” or “brake not pressed”. Certainly the car has to read the amount of pedal travel or force applied just to make the brakes operate at all. Whether they log that info or not is a separate question. I’d bet so, and they’re just not sharing it in this simplified report.
The dotted line is the time of the impact. I wasn’t counting anything to the right of that since, as you say, it could just be the inertia of their foot or them scrambling to get out. I was taking about the ~1.5 s period between when the car started veering at ~40:29.1 and when the car first detected an impact at 40:30.6.
I do find it interesting that the speed goes down somewhat gradually. But it’s almost a philosophical question: what’s the speed of a car that’s in the process of crashing? The first inch of the car is stopped and the last inch is still moving at full speed…
Are you saying that with FSD enabled, those reports will always show (relatively) flat lines for steering angle and torque? Even if the car is turning and the steering wheel is turned?
Torque will be flat unless the user is manually applying force. Steering angle will be correct. The wheel moves normally when FSD has control.
Gotcha.
If that was an unskillful panic maneuver, say to avoid a deer, I can certainly see swerving without braking. Many drivers reflexively brake for anything, even while changing radio channels. Others are a little better and might not brake just because they’re surprised.
There’s about 1.5 seconds from first steering input to start of impact. Not a lot of time to correct an initial overreaction. But plenty of time to do a panic brake-stomp.
As to the speed of a crashing car:
Such fun with physics. It went 40mph to 0 in ~1.5 sec. Which is roughly 1.2G, so not too horrific.
I wonder if the speed is somehow derived inertially, or are they measuring wheel speed(s)?
For sure if their data rate is only 1Hz, all those nice continuous lines should instead be depicted as a series of disconnected dots with empty space between. They’re in effect displaying false precision.
The reality of a 1.5 second deceleration can’t be accurately recorded when you’re only going to get 1 or maybe 2 data points in the dynamic time region between steady state before and steady state after. Dr. Shannon will not be denied.
There was an issue uncovered during the investigation of this little oopsie: American Airlines Flight 587 - Wikipedia wherein some of the data channels getting to the flight data recorder were being run through a Kalman filter before being recorded at umpteen Hz. What looked nice and smooth on the record was actually probably much more dynamic in reality.
The certification regs require that only raw unfiltered data make it into the flight recorder. Which led to some challenges re-working some of the Airbus flight control system to surface that raw data farther upstream in the processing. They’d initially just picked the most convenient place in the pipeline to expose / extract that data, and nobody had noticed the problem with that decision. Oops.
I mention this story only to point out that there are a lot of ways for data logging to appear Oracular when the truth is less rosy.
Every car has a speed sensor on every wheel for ABS… and with a pretty high time resolution (probably 40+ Hz). I just don’t know what they’re using on that particular chart. I’d agree that it’s probably gone through a few filters (or may even be from some other source entirely, like the drivetrain speed or GPS). It does look a little too clean.
Not to give Elon a break, but I’d like to see of the video that snippet was taken from. The skid marks in the vicinity make me think there were other tests, perhaps where they changed the parameters, that the car might have passed.
Mark Rober has a much longer video where he tests whether a Tesla with its optical cameras is better than a LiDAR-equipped auto at detecting a kid in the roadway. Skip to 8:20 to get past where he explains what LiDAR is and how he used it to map out the Space Mountain track plan. Also stick around to the end for the final test, a Wile E. Coyote wall with an open road image on it.
Just to add to this a bit, the Model 3, like virtually all cars on the road (except the Cybertruck!), has a mechanical link between the steering wheel and the steering rack. Unless something breaks, it’s mechanically impossible for the steering wheel angle to not correspond to the degree of steering. And so you could not tell, from the steering angle alone, whether FSD or the driver is providing inputs.
A few weeks after that video was made, Luminar, the company providing the LIDAR support in that video, put out this press release:
Mr. Ricci’s appointment follows the resignation of founder Austin Russell as President and CEO of the company and as the Chairperson of the Board, effective immediately, following a Code of Business Conduct and Ethics inquiry by the Audit Committee of the Board of Directors.
That’s the same Austin Russell that previously donated to Mark Rober’s ocean cleanup campaign:
Some very suspicious things going on here.
Nor could you tell whether steering torque was applied by the front wheels or the steering wheel. Or, for that matter, by the electric power steering motor. You’d have to measure the torque on the shaft and then subtract that applied by the motor. And I can’t find any evidence that that’s what that chart shows.
You have some confusion about the sensor but I can’t tell what it is.
The sensor is on the input to the steering rack. The whole point is to sense if the user is providing active input. If not, the steering wheel turns free and the torque will always be flat independently of what the power steering motors are doing (aside from small friction/momentum effects).
And we can be highly confident that this is the sensor we have data for because it’s also the one that’s maximally exculpatory for Tesla. They want, above all, to be able to say “the torque sensor shows that the user turned the wheel manually at time T, thus disabling FSD”.
And to add one more thing, the torque sensor in question is almost certainly the same one that the power steering rack already has/needs for its own purposes (I checked the Tesla parts catalog and couldn’t find any place for one independent of the rack). It, again, is at the input to the rack. On a car with electric power steering but no FSD, it’s simply used as part of the control loop to amplify the input torque. With FSD, where the steering motor is being controlled by the FSD system, they can simply say “if torque is non-zero, then the user wants to override FSD”.
I wouldn’t say I’m confused, but I certainly don’t know how how Tesla collects steering torque data. I’m not convinced you do either, though.
I do know how steering systems work. Jack up the front of the car and turn the wheels and the steering wheel will spin inside the car. Mechanically, there’s no difference. A sensor on the input to the steering rack doesn’t know which end of the system is supplying the torque.
Maybe they have strain gauges at various spots on the column. Or they have a pressure sensor in the splines between the steering wheel and the column. Realistically, I suspect there is no sensor like you describe and instead they use yaw sensors, power steering motor resistance and fancy software to estimate torque. And these reports only provide the estimate and not any of the raw values.
But I’m guessing. Absent a cite, it seems like there’s a lot of guessing going around.
Tesla uses basically an off-the-shelf steering rack. They may have demanded some extra redundancy and firmware but there’s nothing really special about it.
Again, every electric steering system has this kind of torque sensor:
https://www.caranddriver.com/features/a15122019/electric-vs-hydraulic-power-steering/
1 goes directly to the steering wheel through dumb metal rods. 2 should really be on the circular housing in their picture instead of the cables, but you get the idea. It’s in the input to the rack. If the steering wheel isn’t being held, it will always sense negligible torque.
The Model 3 rack is not meaningfully different:
It’s just that little box between the input shaft and the rest of the rack.
Unfortunately you can’t get more detail from the parts catalog since the rack is sold only as an integrated unit.
The argument here is that the driver yanked his own car into a tree while driving down a straight road, possibly accidentally, and doesn’t remember doing it or is lying about it. That’s an incredible claim that requires incredible evidence. Especially since the FSD sub has a half dozen examples of the same FSD version doing phantom swerving events.
Occam’s razor, ya know?
Given the extremely high fraction of these cases where it turned out that the user was in fact lying about it, Occam’s razor points in the other direction. Reddit especially is an astroturfed, bot-infested mess at this point.
Yes. If it the computer is turning the wheels using that big electric motor, the torque sensor is going to read it. Right?
No. If the user isn’t holding the wheel, it will only ever detect zero torque, no matter what the motor or wheels are doing.