cowtowner
Line Up and Wait
- Joined
- Oct 7, 2009
- Messages
- 599
- Display Name
Display name:
Cowtowner
RADAR, not LiDAR.When Tesla used Lidar, did it recognize an obstacle, even if it was something uncommon?
Probably the guy who continued to hold the "Summon" button down without watching where the car was going like he was supposed to.Who pays???
Probably the guy who continued to hold the "Summon" button down without watching where the car was going like he was supposed to.
Tesla’s lawyers probably already convinced the engineers to keep detailed logs of user input for precisely this reason.I’m sure the Tesla lawyers would be able to win without irrefutable proof that you stopped summoning and the car ran amok on its own, even if that actually happened, how would you prove it?
You're saying the opposite I am. If I am the user and use summon and let go of the button, but the car keeps going, there's virtually no way I could prove that I let go of the button. Logs could only work against Tesla. And there aren't going to be logs that prove the phone didn't glitch and give the app bad data.Tesla’s lawyers probably already convinced the engineers to keep detailed logs of user input for precisely this reason.
I’m sure the Tesla lawyers would be able to win without irrefutable proof that you stopped summoning and the car ran amok on its own, even if that actually happened, how would you prove it?
That does not prove when you lifted your finger off your phone.The time data that records when and for how long the summons was active, overlaid on the GPS and accelerometer indications of when the impact occurred. Tesla knew that info not long after the robot car assault happened.
That does not prove when you lifted your finger off your phone.
Exactly. Lots of limitations and caveats noted here:
https://www.tesla.com/ownersmanual/modely/is_is/GUID-6B9A1AEA-579C-400E-A7A6-E4916BCD5DED.html
Warning
Smart Summon may not stop for all objects (especially very low objects such as some curbs, or very high dollar objects such as a multi-million dollar private jet) and may not react to all traffic. Smart Summon does not recognize the direction of traffic, does not navigate around empty parking spaces, and may not anticipate crossing traffic.
You’re missing something. It’s the users fault if he’s still holding the summon button. It’s teslas fault if the user is not holding the button. In either case the summon would be active from the cars logs. Tesla never claims to assure avoiding striking an obstruction. Quite the contrary. They make it clear the cameras can’t see everything and that you are responsible and must be in line of sight.Perhaps you didn't read my response correctly. The vehicle's data log records when and for long the summons was active. That information is available to Tesla via data link to their cars. The impact was similarly recorded. A time log makes coincidence of the summons and impact quite simple to interpret.
You're assuming that the logs are telling the truth, which may or may not be the case.Perhaps you didn't read my response correctly. The vehicle's data log records when and for long the summons was active. That information is available to Tesla via data link to their cars. The impact was similarly recorded. A time log makes coincidence of the summons and impact quite simple to interpret.
You’re missing something. It’s the users fault if he’s still holding the summon button. It’s teslas fault if the user is not holding the button. In either case the summon would be active from the cars logs. Tesla never claims to assure avoiding striking an obstruction. Quite the contrary. They make it clear the cameras can’t see everything and that you are responsible and must be in line of sight.
You're assuming that the logs are telling the truth, which may or may not be the case.
Multiple? I only know of one which involved an older Model S. That bug was fixed many years ago. What were the others?just like the multiple eighteen wheeler trailers that Teslas have struck while on autopilot.
Except that there is no way for a user to prove when they released the button, so no way to prove its Teslas fault. This is what I’ve been trying to say.Multiple? I only know of one which involved an older Model S. That bug was fixed many years ago. What were the others?
In my view, the fault lies with the details of the incident. If the Summon feature was working as designed then it was the operator, who was holding the summon button on the app, who is at fault. If the operator released the summon button, but the car continued to move into the airplane, then it's Tesla's fault.
...It’s the users fault if he’s still holding the summon button. It’s teslas fault if the user is not holding the button. In either case the summon would be active from the cars logs...
Is the summon button state recorded in the logs or is it not?Except that there is no way for a user to prove when they released the button, so no way to prove its Teslas fault.
You're saying the opposite I am. If I am the user and use summon and let go of the button, but the car keeps going, there's virtually no way I could prove that I let go of the button. Logs could only work against Tesla. And there aren't going to be logs that prove the phone didn't glitch and give the app bad data.
Frankly, the technology isn't there yet. There's a reason why most of this type of thing is done with locked down devices not iOS apps.
As a user, you really are taking a lot of risk using summon. Tesla has very little liability, whether or not it was their fault. The user agreements make that pretty clear. Unless there's a huge rash of Tesla's crashing into stuff on summon, they ain't gonna be paying.
This seems to imply that a phone app is actually used (iOS or Android not specified).Smart Summon works with the Tesla mobile app when your phone is located within approximately 6 meters of Model Y.
Reading through your posts, I think I understand what you are trying to say- that the car logs can only record when it receives the "push" or "release", not whether the phone actually sent the commands in a timely fashion.Except that there is no way for a user to prove when they released the button, so no way to prove its Teslas fault. This is what I’ve been trying to say.
Always anticipate when you need to stop Model Y. Depending on the quality of the connectivity between the phone and Model Y, there may be a slight delay between when you release the button and when the car stops.
Probably, but if the app locked up or ios sent bad data to it they would be “lying”Is the summon button state recorded in the logs or is it not?
Nauga,
and a little onboard data
See my last post.I'm sorry, but I don't understand the highlighted comment in light of how Smart Summon purportedly works.
https://www.tesla.com/ownersmanual/modely/is_is/GUID-6B9A1AEA-579C-400E-A7A6-E4916BCD5DED.html
This seems to imply that a phone app is actually used (iOS or Android not specified).
Reading through your posts, I think I understand what you are trying to say- that the car logs can only record when it receives the "push" or "release", not whether the phone actually sent the commands in a timely fashion.
You are making assumptions in what is or isn't logged. For example, there's no reason that the button press and release commands can't also include a time stamp that can be logged with the time the car actually received and acted on the commands. There's no reason the app itself doesn't have a log file. As the citation above indicates the feature is still in beta testing, it wouldn't surprise me the app keeps a log as well, which is compared to the car's log.
Quoted for the citation above, this may well be what happened:
Does every potential failure mode where the car continues to move include the app locking or ios sending bad data? While I agree it's *possible* that the logs would be in error, I do not agree that it's a certainty.Probably, but if the app locked up or ios sent bad data to it they would be “lying”
If there's a bug which allows the car to continue moving without receiving a constant signal from the app, that can be determined and fixed. The logs (presumably) kept by the car will show if it was receiving a "go" signal. If it stopped receiving that signal, but continued moving, that's a software bug (design or implementation) and would be the cause.Except that there is no way for a user to prove when they released the button, so no way to prove its Teslas fault. This is what I’ve been trying to say.
Incorrect data recorded in log files has long preceded the invention of AI.I didn't know AI has progressed to the point where computers can decide to tell lies. That Elon guy is almost like Jesus.
I think so too. All I’m trying to say is that as a user, I can’t prove I let go of the button at x point of time. The touch screen can fail, the os can fail, without Tesla being at fault. Unless you try to claim the system is inherently unsafe because they are using commodity hardware and os, which have the described issues. But that argument wouldn’t go far unless there is a rash of incidents.If there's a bug which allows the car to continue moving without receiving a constant signal from the app, that can be determined and fixed. The logs (presumably) kept by the car will show if it was receiving a "go" signal. If it stopped receiving that signal, but continued moving, that's a software bug (design or implementation) and would be the cause.
I would think that the most likely explanation is that the operator wasn't paying enough attention but a software issue is also possible.
I'm sorry, but you still aren't making yourself clear. I've written simple phone apps, as well as much more complicated programs on computers, so I don't see the "computation limitations" related to whether a control is pressed or not.See my last post.
the “lag” is because of latency in wireless transmission as well as computation limitations.
I think so too. All I’m trying to say is that as a user, I can’t prove I let go of the button at x point of time. The touch screen can fail, the os can fail, without Tesla being at fault. Unless you try to claim the system is inherently unsafe because they are using commodity hardware and os, which have the described issues. But that argument wouldn’t go far unless there is a rash of incidents.
Computers always have limitations. They don’t scale infinitely. I only added that to cover other possibilities. The physical OSI layer is certainly the most likely place to introduce latency, but the other layers that run on the phone and the car can also run out of memory and cpu resulting in latency.I'm sorry, but you still aren't making yourself clear. I've written simple phone apps, as well as much more complicated programs on computers, so I don't see the "computation limitations" related to whether a control is pressed or not.
I can't remember if summon works through the phone and car's cellular data connection or if it's through Bluetooth. I know that one of the complaints about the feature is that you have to be relatively close to the car but that still seems like it might be out of Bluetooth range.As for "latency in wireless transmission"- I assume this mean the latency of the network that gets the data from the phone to the car. I can see that happening.
Yeah. BT spec is minimum ten meters, though I've experienced situations where it was effectively more or effectively less. So some other wireless tech. Hey, there's latency in controlling my home's thermostats.I can't remember if summon works through the phone and car's cellular data connection or if it's through Bluetooth. I know that one of the complaints about the feature is that you have to be relatively close to the car but that still seems like it might be out of Bluetooth range.
Very simply, too many apps running or too much data stored. More likely the phone than the car, unless there's a "memory leak" on one of the car's programs.Computers always have limitations. They don’t scale infinitely. I only added that to cover other possibilities. The physical OSI layer is certainly the most likely place to introduce latency, but the other layers that run on the phone and the car can also run out of memory and cpu resulting in latency.