Summons Fail - Crashed - Body Shop Repair Estimate

[mongo]

Here's the problem with continuous press.

You need to send a signal to keep the car "pushing".

What if there is a bug where "push" = off, is still registered as ON, anywhere in the firmware, middleware, or application layer.

@voip-ninja and I gonna have to slap a fool if they using UDP instead of TCP for the summon feature.

Dropped packets is catastrophic here versus a telephone call.

Not sure what protocol they use. I trust EAP with my kids in the car, but I have NEVER enabled summon on any of my cars.

I do this stuff for a living. TCP > than UDP for this type of application, not TCP >= UDP. Stateful vs stateless protocols are different for a reason.

You want to swim in my pool you should bring bigger flippers.

I'm dual certified by NUMI and PADI, so I'll jump in.

(Some of this is background for people not familiar with networking)

TCP is a protocol that sits on top of Internet Protocol (IP) datagrams, UDP is a protocol which also uses IP datagrams. It is not a different type of packet, nor is not more likely to arrive.
TCP assures data gets there eventually and in the order sent (leaving the low level driver) assuming the connection still exists.
Using TCP does not mean the packet is guaranteed to get there, only that (due to the protocol) the sender will retry if it is not acknowledged. Any safety connection state information has to have a fail safe timer since there is nothing to send a "connection dropped" flag, if the connection drops (beyond the networking layer timeouts).

Summon gains nothing by using TCP. In fact, it would actually be worse since you could hit your max packet window waiting for an old 'forward' packet to get resent while you have 30 'STOP' packets in the buffer. Whereas with a UDP setup, every n mS a new packet with the currently desired direction would be sent (for paranoia, add a counter/ time stamp to avoid a delayed by routing packet from overwriting the real command). If the car does not get a new packet in max_delay time, it stops automatically.


If you want to send a document, use TCP.
If you want to send 200 bytes of data that replaces the 200 bytes of data you just sent, use UDP.
Using UDP with some features of TCP (which the counter is) is the best approach for summon.

 

[MXWing]

I'm dual certified by NUMI and PADI, so I'll jump in.

(Some of this is background for people not familiar with networking)

TCP is a protocol that sits on top of Internet Protocol (IP) datagrams, UDP is a protocol which also uses IP datagrams. It is not a different type of packet, nor is not more likely to arrive.
TCP assures data gets there eventually and in the order sent (leaving the low level driver) assuming the connection still exists.
Using TCP does not mean the packet is guaranteed to get there, only that (due to the protocol) the sender will retry if it is not acknowledged. Any safety connection state information has to have a fail safe timer since there is nothing to send a "connection dropped" flag, if the connection drops (beyond the networking layer timeouts).

Summon gains nothing by using TCP. In fact, it would actually be worse since you could hit your max packet window waiting for an old 'forward' packet to get resent while you have 30 'STOP' packets in the buffer. Whereas with a UDP setup, every n mS a new packet with the currently desired direction would be sent (for paranoia, add a counter/ time stamp to avoid a delayed by routing packet from overwriting the real command). If the car does not get a new packet in max_delay time, it stops automatically.


If you want to send a document, use TCP.
If you want to send 200 bytes of data that replaces the 200 bytes of data you just sent, use UDP.
Using UDP with some features of TCP (which the counter is) is the best approach for summon.

OR

We attach a wired remote to it and call it a day.

 

[voip-ninja]

Body repair - 2 Gs. Tesla will do the work. Being told 2-3 weeks.

Ouch. Well, I estimated $2500 so could be worse.

 

[S4WRXTTCS]

The way I interpret this is it's a clear warning to all of us owners that the continuous press options (which is enabled by default) doesn't work.

I might try to test it by quickly sliding my phone/hand into an RF shield bag to see what the car does while it's being summoned.

I'l pick some nice safe place to test it.

That feature is absolutely essential in preventing the car from running into something. There is a lot of evidence that summons doesn't always see things. Currently summons doesn't use the cameras at all. It just uses the ultrasonic sensors, and if things aren't lined up with the sensors it will just continue on.

So you have to have a way of overriding it.

When I had my Model S I used to play around with various ways of stopping it. Like the door handles or just getting in front of one of the sensors. I haven't had a chance to do that in my 3.

Hopefully in a future version of summons they add gesture recognition.

As to the Beta tag, I wouldn't put too much stock into that. Even the AP1 cars with summons still have the Beta tag. It really doesn't mean much as it's supposed to be verified/validated by Tesla, and it's really inexcusable to release something that doesn't work. I can certainly understand caveats.

But, in this case there were multiple failures (continuous press, and sensors).

 

[voip-ninja]

I'm dual certified by NUMI and PADI, so I'll jump in.

(Some of this is background for people not familiar with networking)

TCP is a protocol that sits on top of Internet Protocol (IP) datagrams, UDP is a protocol which also uses IP datagrams. It is not a different type of packet, nor is not more likely to arrive.
TCP assures data gets there eventually and in the order sent (leaving the low level driver) assuming the connection still exists.
Using TCP does not mean the packet is guaranteed to get there, only that (due to the protocol) the sender will retry if it is not acknowledged. Any safety connection state information has to have a fail safe timer since there is nothing to send a "connection dropped" flag, if the connection drops (beyond the networking layer timeouts).

Summon gains nothing by using TCP. In fact, it would actually be worse since you could hit your max packet window waiting for an old 'forward' packet to get resent while you have 30 'STOP' packets in the buffer. Whereas with a UDP setup, every n mS a new packet with the currently desired direction would be sent (for paranoia, add a counter/ time stamp to avoid a delayed by routing packet from overwriting the real command). If the car does not get a new packet in max_delay time, it stops automatically.


If you want to send a document, use TCP.
If you want to send 200 bytes of data that replaces the 200 bytes of data you just sent, use UDP.
Using UDP with some features of TCP (which the counter is) is the best approach for summon.

As you said the use of UDP requires the use of timers since there is no acknowledgement at the protocol level that packet x has arrived.

The only downside I see of doing it with TCP is you would have to build some flow control into the application so that you don’t get hammered with retransmissions.

The problem I have with UDP in the summon use case is that your RT time can be high due to internet latency and the timers have to be minuscule to prevent a missed communication because you are literally driving a 2 ton car around with the stop/go commands going via the Internet.

With TCP you can simply drive it at the application layer that if you miss an ack and retransmit a couple of times you stop the car until communication is reestablished.

I would prefer doing it with TCP and haven't said it couldn't be done with UDP I just think TCP is better in this situation.

I suppose another mechanism that could help the UDP usage would be to use RTCP as a means to estimate connection quality and if it looks like, via RTCP data that the connection is deteriorating you could take an action before you waited for a timer to expire. Same outcome different mechanism.

 

[mongo]

As you said the use of UDP requires the use of timers since there is no acknowledgement at the protocol level that packet x has arrived.

The only downside I see of doing it with TCP is you would have to build some flow control into the application so that you don’t get hammered with retransmissions.

The problem I have with UDP in the summon use case is that your RT time can be high due to internet latency and the timers have to be minuscule to prevent a missed communication because you are literally driving a 2 ton car around with the stop/go commands going via the Internet.

With TCP you can simply drive it at the application layer that if you miss an ack and retransmit a couple of times you stop the car until communication is reestablished.

I would prefer doing it with TCP and haven't said it couldn't be done with UDP I just think TCP is better in this situation.

I suppose another mechanism that could help the UDP usage would be to use RTCP as a means to estimate connection quality and if it looks like, via RTCP data that the connection is deteriorating you could take an action before you waited for a timer to expire. Same outcome different mechanism.

So fun to geek out.

Am I correct in that your are using TCP to give a fast retry on lack of acknowledgement without requiring sending packets at that rate continuously?

We may both be overkilling the problem. With a 25 mS ping, and 50 mS reaction time, there is only time for one retry.

If you have a packet with the current command, a counter, and a check sum that fits in one datagram/ UDP packet. Then the car sends an ACK with the counter number, the phone side can send the current command at a high rate (1/round trip time) until the command is acknowledged/ echoed, then wait the command period to send the next one. Most of TCP, but without old packet retransmission that would only be stale commands.

Or send commands at 50mS rate (retry time), since that is the fastest TCP would do it anyway and skip the acknowledge.

 

[Blikblik]

Get those boxes out of the garage. Make more room for your Tesla

Yes sir . That’s the plan. Fun Sat.

 

[woodisgood]

If you received a jury summons, could you summon your car there using Summon?

 

[PhaseWhite]

I have been way too chicken sh*t to use summon and this thread provides validation for my fears. There just appear to be too many problems. If I understand correctly summon is actually using the internet to communicate between the car and your phone.... I have no idea why it wouldn't simply use Bluetooth to maintain the continuous connection needed unless it's a range issue.

I could see maybe using it to pull my car out of a really tight spot if someone boxed me in but other than that, nope.

I also don't understand how summon, under ANY circumstances will drive right into something when it has ultrasonic sensors that tell it that it is within centimeters of a solid object.

Yes it's using internet when you use the phone app and it sucks. On the Model S the key-fob uses a direct connection which offers a way better Summon experience. I struggled today with my Model 3 since it switches over to WIFI in the driveway but the signal is weak so it prevents summon from working until I manually disable WIFI and force it on LTE again... It's just such a pain compared to using the fob with the Model S. I hope the Model 3 key-fobs come soon. For summon and for anyone who wants/needs to valet their car regularly they will be a must.

 

[John Beans]

Surprised no one asked about what the boxes looked like. Can we see a picture to compare to our boxes in our garages?

 

[voip-ninja]

So fun to geek out.

Am I correct in that your are using TCP to give a fast retry on lack of acknowledgement without requiring sending packets at that rate continuously?

We may both be overkilling the problem. With a 25 mS ping, and 50 mS reaction time, there is only time for one retry.

If you have a packet with the current command, a counter, and a check sum that fits in one datagram/ UDP packet. Then the car sends an ACK with the counter number, the phone side can send the current command at a high rate (1/round trip time) until the command is acknowledged/ echoed, then wait the command period to send the next one. Most of TCP, but without old packet retransmission that would only be stale commands.

Or send commands at 50mS rate (retry time), since that is the fastest TCP would do it anyway and skip the acknowledge.

Well you’ve made a valid point that TCP has a bottom end time for total RTO that might be as high as the theoretical mechanism used in a UDP delivery.

 

[halfricanguy]

OP: I don’t know what channels of communication you’ve had with Tesla regarding this situation, but if you submit a comment to them on your MyTesla account page, there’s a box you can check to mark it for executive review. Maybe it can’t hurt to try.

 

[Blikblik]

OP: I don’t know what channels of communication you’ve had with Tesla regarding this situation, but if you submit a comment to them on your MyTesla account page, there’s a box you can check to mark it for executive review. Maybe it can’t hurt to try.

Appreciate the direction. I’ll give it a shot.

 

[eprosenx]

I'm dual certified by NUMI and PADI, so I'll jump in.

(Some of this is background for people not familiar with networking)

TCP is a protocol that sits on top of Internet Protocol (IP) datagrams, UDP is a protocol which also uses IP datagrams. It is not a different type of packet, nor is not more likely to arrive.
TCP assures data gets there eventually and in the order sent (leaving the low level driver) assuming the connection still exists.
Using TCP does not mean the packet is guaranteed to get there, only that (due to the protocol) the sender will retry if it is not acknowledged. Any safety connection state information has to have a fail safe timer since there is nothing to send a "connection dropped" flag, if the connection drops (beyond the networking layer timeouts).

Summon gains nothing by using TCP. In fact, it would actually be worse since you could hit your max packet window waiting for an old 'forward' packet to get resent while you have 30 'STOP' packets in the buffer. Whereas with a UDP setup, every n mS a new packet with the currently desired direction would be sent (for paranoia, add a counter/ time stamp to avoid a delayed by routing packet from overwriting the real command). If the car does not get a new packet in max_delay time, it stops automatically.


If you want to send a document, use TCP.
If you want to send 200 bytes of data that replaces the 200 bytes of data you just sent, use UDP.
Using UDP with some features of TCP (which the counter is) is the best approach for summon.

Yes, without question summon is a feature that should be implemented with UDP.

Or rather, I would use TCP to setup and start the summon session (get a crypto token too for authorizing the session), but then I would use UDP for indicating to the car if the forward / reverse button continues to be held down (inside of each packet would be a sequence number and it would be likely crypto signed somehow with the access token from before so nobody could MITM it and drive your car into a wall).

I would have the car start moving upon receiving the first properly signed UDP packet. I would have the app send a UDP packet every say 25ms while the button was held down. It would have a sequence number in it. The car would ignore any packet with an older sequence number than the highest received packet (so out of order delivery gets discarded). Then the car would immediately stop if it did not receive any valid packets in the last 100ms. I probably also would send several packets telling summon to stop upon the user stopping pressing the button, but these would not be mandatory to receive since if they got dropped the car would stop in 100ms max.

No fancy flow control is needed. Just fire and forget. TCP would just result in pain since it mandates in order delivery. If a packet is dropped you just let the next subsequent packet with the same (or updated) data overwrite the state from the dropped packet. No waiting for TCP to realize there was a drop and resend.

 

[Garlan Garner]

Yes, without question summon is a feature that should be implemented with UDP.

Or rather, I would use TCP to setup and start the summon session (get a crypto token too for authorizing the session), but then I would use UDP for indicating to the car if the forward / reverse button continues to be held down (inside of each packet would be a sequence number and it would be likely crypto signed somehow with the access token from before so nobody could MITM it and drive your car into a wall).

I would have the car start moving upon receiving the first properly signed UDP packet. I would have the app send a UDP packet every say 25ms while the button was held down. It would have a sequence number in it. The car would ignore any packet with an older sequence number than the highest received packet (so out of order delivery gets discarded). Then the car would immediately stop if it did not receive any valid packets in the last 100ms. I probably also would send several packets telling summon to stop upon the user stopping pressing the button, but these would not be mandatory to receive since if they got dropped the car would stop in 100ms max.

No fancy flow control is needed. Just fire and forget. TCP would just result in pain since it mandates in order delivery. If a packet is dropped you just let the next subsequent packet with the same (or updated) data overwrite the state from the dropped packet. No waiting for TCP to realize there was a drop and resend.

Tesla should make their cars communication out of testosterone instead of packets.

Seems to be plenty of that flowin.

They developed Summon and I believe its a great thing. If something works 99% of the time then....all they need is data for the 1%. They have access to it...so...… lets just watch and wait for the results.

 

[ngogas]

I wonder why they just don’t use Bluetooth for communications.

 

[mongo]

I wonder why they just don’t use Bluetooth for communications.

It's not easy to get bluetooth on Apple.
Android will let you, but device to device variances can be a pain.
BLE (bluetooth low energy) makes things easier, and I think the fobs use it.

 

[Knightshade]

The fact it didn't stop as soon as it lost

It's not easy to get bluetooth on Apple.
Android will let you, but device to device variances can be a pain.
BLE (bluetooth low energy) makes things easier, and I think the fobs use it.

Eh?

Apple has supported BLE for years

Bluetooth - Apple Developer

 

[b_ack51]

I have been way too chicken sh*t to use summon and this thread provides validation for my fears. There just appear to be too many problems. If I understand correctly summon is actually using the internet to communicate between the car and your phone.... I have no idea why it wouldn't simply use Bluetooth to maintain the continuous connection needed unless it's a range issue.

I could see maybe using it to pull my car out of a really tight spot if someone boxed me in but other than that, nope.

I also don't understand how summon, under ANY circumstances will drive right into something when it has ultrasonic sensors that tell it that it is within centimeters of a solid object.

It is scary to use when there are objects around but last night was first time I truly had to use summon.

I went inside to grab a bite to eat with the gf. Come outside and someone parks next to me over the line leaving no more than 5-6 inches between my drivers door and his passenger side. Of course it’s raining, so I pull up summons and continous press reverse it out of the spot. Then take picture of license plate just in case.

Glad it worked for that situation.

 

[mongo]

The fact it didn't stop as soon as it lost



Eh?

Apple has supported BLE for years

Bluetooth - Apple Developer

My understanding is the MFi program for getting devices approved for the Apple ecosystem is non-trivial. (Any effort being more than the zero certification needed for Android accessories,but I'm biased)