Major Phantom Braking Issues

[TechSavySD]

I understand your power situation, yeah that is a tough one.

I'll make a couple more comments...

So braking events are highly variable and different people "feel" different ways based on various things. A phantom braking event to me is a slowdown based on thinking there was an object in the way when there is nothing around(in reality) to make the car think there is a reason to brake. Now this is different than the car reacting to a dynamic driving scenario like it thinking a car in an adjacent lane was about to merge or change into your lane whether that was based in reality or not. * my definition of PB is subject to change, haha. There are other scenarios that I would consider PB that don't fit my definition but I feel the written definition has to be well separated to avoid chaos and confusion.

With PB events, it could be a 5mph slowdown or a 20mph slowdown and the rate of deceleration can be variable. The biggest thing I see when people complain about PB events is that it was a sudden "massive" slowdown when after asking more questions it turns out either they don't know what the actual slowdown was or they come up with numbers that don't fit their "feeling". If you are around other cars and a PB event hits AND you aren't necessarily on point in your observation and paying attention, or you were momentarily distracted by changing an HVAC setting when the PB event hits, people will generally get more startled and "feel" like the PB event was worse than it was.

I think simply in your and other people's cases, I think it is easiest to say that you WILL have PB events but they aren't going to be random, and most likely not "frequent". They may "feel" random, but generally when no other traffic is around, the PB events will probably be repeatable and therefore predictable when driving the same route.

Now doing TACC on city streets is going to be a whole different ballgame...I would say you WILL have more "PB" events but they are generally not true PB events and are going to be error or indecision in the driving logic in the car based on navigation logic and map data....bad speed limit data, confused on path of travel, etc. You will also have general path logic errors that you have to be prepared to take over for.

Personally, I love my car and I love FSDb and it makes various errors on city streets, but I am ALWAYS prepared to take over in an instant and I love trying to analyze the failures and think about why I think the car made different decisions or errors.

If you are worried about Tesla specific issues you have heard/read about, then don't get the car. Get something else and deal with that manufacturer's and models own quirks and issues. You are an engineer, cutting edge technology isn't cutting edge without some kinds of issues. If all the bugs were worked out it wouldn't be cutting edge anymore.

Waiting for HW4 I don't think is really going to do much. I think the limits in the code are the code itself and the logic. There is a lot of headroom still in HW3 for development...unless there is a massive breakthrough in coding that blows through that overhead instantly(unlikely).

You can wait, and wait, and wait, there will always be another reason to wait, but right now there isn't really any major hardware reason to wait for.

Good luck in your decision making process...pro's and con's right? The funny thing is that it is just as easy to talk badly about the car as it is to talk good about the car. I try to be neutral when people seem to be having a tough time wrapping their head around this decision like you seem to be. But....I love my car, I have my small share of PB events and other driving logic issues but I am able to easily deal with them and I wouldn't get any other car.

I have decided I will pick up my M3LR, and make conclusions about the driving experience myself. There is nothing more to research other than a mysterious, brand new battery cell made by LG (LOL). Please no Chevy Bolt or Hyundai battery fire recall fiasco!

I did see one post this on 04/06 by acoburn73 Major Phantom Braking Issues, where they observed a reproductible braking event on a road trip in response to doing an update of a navigation route on the display. If that is indeed true, it suggests either a coding issue (process prioritization and interrupts) or there is a processing bandwidth problem.

Another posted that with FSDb, he believed that the dash cam writing to a full USB drive was some how negatively impacting the TeslaVision processor. He wasn't sure though. He just said things seemed better after re-formatting the USB drive. USB slave isn't going to throttle the software - there may be more re-sends of data. This I do not take stock in. I could not imagine that Tesla engineers would run this interface on the same processor or give it any other than the lowest priority.

 

[TechSavySD]

I don't think you can link the two as they are two completely different events with different triggers. Now maybe you can infer a small overlap in the software logic between the two but it isn't the same logic or you could have a PB event that acts like an AEB event that is not an AEB event which I don't think is going to happen. Even a "hard" PB is not the same as an AEB event. I have experienced a few AEB events, they are not the same in deceleration, physical braking action, or screen alerts.

Going on a different line of semantics....a PB event is not a false positive AEB event, nor would a false positive AEB event be a PB event...based on the actual operation of AEB.

Is TACC therefor also a product of AEB? I think I would argue that PB is more a product of TACC logic than AEB.

PB is also a very broad term.

If TACC were a product of AEB, you would think that turning off AEB in AutoPilot config would make a difference. Obviously (based on post by others) it does not.

 

[TechSavySD]

Just another question, possibly related to TACC slow downs. I know that you can configure AP to set the speed when TACC is engage to either Current Speed limit or Current Cruising Speed. With Current Speed limit one can set a range or percentage for target speed above the recognized speed limit.

I understand that AutoPilot and/or TACC alone will update current speed limits from reading speed limit signs and/or speed limit information from Navigation maps. Is this true even if you engage TACC with the set to Current Speed option? Is there anyway to turn off reading local Speed Limit signs at all? I understand people have issues with this for signs picked up on side roads, school zones or signs on cross roads.

 

[TechSavySD]

AEB causes phantom braking but Tesla's issues are far more prevalent and pervasive than 'every car with AEB.' Yes, if you dig you can find reports in most other makes but if you dig you'll also find that no other make has as many people complaining about PB as often. Also, Tesla's phantom braking seems to be a combination of false AEB activations combined with poor TACC/vision implementation.

False AEB activations are generally accompanied by warning bells and hard braking (truly slamming on the brakes.) Many/most of the PB events Tesla owners experience are more akin to taking your foot off the accelerator and letting regenerative braking slow the car. It's a fairly rapid deceleration but not 'slamming on the brakes.' These slowdowns can be anywhere from 2 MPH to 50 MPH. I've had them occur on wide open areas as well as on a 3 lane freeway with traffic all around me. I've had some be predictable (e.g. every time I approach a specific underpass) as well as random.

For comparison, we also have a Subaru Forester with a vision based adaptive cruise (and lane keep assist and AEB.) In the last 25,000 miles we've had exactly zero phantom braking events in that car. No AEB activations and no issues with adaptive cruise. My brother in law has a Toyota Prius with adaptive cruise (I don't know about AEB.) In 8 years he's had zero PB events. I have yet to talk to someone who owns a non-tesla with adaptive cruise that has even experience PB much less has significant issues with it.

You say that hard braking AEB activations to false detections are "generally" accompanied by Chimes. Generally - that means sometimes there are not chimes? Just wondering if setting AEB warnings to Early gives any useful advance notice to cover the accelerator pedal or would be a true annoyance?

 

[OxBrew]

Just another question, possibly related to TACC slow downs. I know that you can configure AP to set the speed when TACC is engage to either Current Speed limit or Current Cruising Speed. With Current Speed limit one can set a range or percentage for target speed above the recognized speed limit.

I understand that AutoPilot and/or TACC alone will update current speed limits from reading speed limit signs and/or speed limit information from Navigation maps. Is this true even if you engage TACC with the set to Current Speed option? Is there anyway to turn off reading local Speed Limit signs at all? I understand people have issues with this for signs picked up on side roads, school zones or signs on cross roads.

ALWAYS use set cruising speed. Using any form of speed limit TACC/AP is total chaos, never works. It jumps randomly all over the place. Set Speed is really stable, compared to Speed limit mode. Madness.

So yeah, there are places the car slows dramatically every time I pass a certain place on a certain highway that was reconfigured last year. 75 down to 58 as fast as the regen will slow it, then back up to 65 very quickly. It's a low traffic area, so I entertain myself trying it out every time, just to try to catch the moment it heals itself.

I mean, go ahead and try speed limit mode, I give it one chance with most new updates. Have not lasted more than 30 seconds on it yet, ever. It's bad.

 

[derotam]

Just another question, possibly related to TACC slow downs. I know that you can configure AP to set the speed when TACC is engage to either Current Speed limit or Current Cruising Speed. With Current Speed limit one can set a range or percentage for target speed above the recognized speed limit.

I understand that AutoPilot and/or TACC alone will update current speed limits from reading speed limit signs and/or speed limit information from Navigation maps. Is this true even if you engage TACC with the set to Current Speed option? Is there anyway to turn off reading local Speed Limit signs at all? I understand people have issues with this for signs picked up on side roads, school zones or signs on cross roads.

Yeah I agree with OxBrew, however I can see how using set speed could be just as annoying to some people. I think the car changing speed incorrectly, or the driver having to adjust set speed manually for speed changes is kind of two sides to the same coin.

There are a few problems that can cause issues.
1. Incorrect GPS,
2. Bad map data,
3. The fact(my opinion based on non-convincing evidence to the contrary) that the current non-mobile eye cars do NOT actually read and apply speed limit sign data from visual observation. This is a very hard thing to actually test but so far all videos I have seen do not absolutely prove that the car currently can read and/or read and apply speed limit signs.

 

[derotam]

You say that hard braking AEB activations to false detections are "generally" accompanied by Chimes. Generally - that means sometimes there are not chimes? Just wondering if setting AEB warnings to Early gives any useful advance notice to cover the accelerator pedal or would be a true annoyance?

I would say that AEB activation's are ALWAYS accompanied by chimes.

AEB engages the brakes(physical) to rapidly slow down the vehicle while pushing a big red alert on the screen with audible chimes. An AEB even can ONLY be canceled by the following methods:
1. Car decided to end it
2. Driver presses on the brake pedal
3. Driver presses the accelerator pedal almost full down

#3 is not generally a good option in my opinion however, given the vehicles massive amount of instant torque and rapid acceleration capability.

Any AEB warnings would be better termed as Forward Collision Warnings(as per the manual), there are no "AEB Warnings".

Early FCW setting was annoying to me in stop and go traffic, I have mine to medium.

 

[derotam]

I have decided I will pick up my M3LR, and make conclusions about the driving experience myself.

Remember, it's not a car...it's an adventure! Haha

 

[sleepydoc]

Yeah I agree with OxBrew, however I can see how using set speed could be just as annoying to some people. I think the car changing speed incorrectly, or the driver having to adjust set speed manually for speed changes is kind of two sides to the same coin.

There are a few problems that can cause issues.
1. Incorrect GPS,
2. Bad map data,
3. The fact(my opinion based on non-convincing evidence to the contrary) that the current non-mobile eye cars do NOT actually read and apply speed limit sign data from visual observation. This is a very hard thing to actually test but so far all videos I have seen do not absolutely prove that the car currently can read and/or read and apply speed limit signs.

How Tesla sets the speed has also changed through various software versions. In the past it was primarily map data supplemented by vision. As an example there was road where the speed limit increased from 35 to 55 as it left a town. The car would see the 55MPH sign and start to accelerate then suddenly it would drop the speed down to 35 again with reason. This always happened and I also noted that the computer would set the speed to 35 when turning onto that section of road at another location. Clearly the map data was incorrect and it was overriding the sign it saw with the map data.

with the latest software version it no longer drops down to 35 after seeing the 55 sign but if I turn onto the road it will set the limit to 35, not 55. I’ve also noticed a significant increase in cases where the speed limit changes but the car doesn’t seem to see the sign so it continues at the last known limit. Essentially it seems to have changed how it prioritizes speed limit data between maps and vision.

 

[TechSavySD]

ALWAYS use set cruising speed. Using any form of speed limit TACC/AP is total chaos, never works. It jumps randomly all over the place. Set Speed is really stable, compared to Speed limit mode. Madness.

So yeah, there are places the car slows dramatically every time I pass a certain place on a certain highway that was reconfigured last year. 75 down to 58 as fast as the regen will slow it, then back up to 65 very quickly. It's a low traffic area, so I entertain myself trying it out every time, just to try to catch the moment it heals itself.

I mean, go ahead and try speed limit mode, I give it one chance with most new updates. Have not lasted more than 30 seconds on it yet, ever. It's bad.

I would prefer to set speed from my current speed when I engage AP or TACC only, as I would do for a conventional car cruise control. What I was getting at: In TACC mode when the vehicle slows down for whatever reason including following another car, does it return to the the initial engagement speed, or does it always adjust to what it thinks is the current road speed limit (from maps or reading speed signs)?

 

[DanDi58]

I would prefer to set speed from my current speed when I engage AP or TACC only, as I would do for a conventional car cruise control. What I was getting at: In TACC mode when the vehicle slows down for whatever reason including following another car, does it return to the the initial engagement speed, or does it always adjust to what it thinks is the current road speed limit (from maps or reading speed signs)?

I always set mine to use the speed I am travelling at. IME, it does the former from your statement above.

 

[derotam]

How Tesla sets the speed has also changed through various software versions. In the past it was primarily map data supplemented by vision. As an example there was road where the speed limit increased from 35 to 55 as it left a town. The car would see the 55MPH sign and start to accelerate then suddenly it would drop the speed down to 35 again with reason. This always happened and I also noted that the computer would set the speed to 35 when turning onto that section of road at another location. Clearly the map data was incorrect and it was overriding the sign it saw with the map data.

with the latest software version it no longer drops down to 35 after seeing the 55 sign but if I turn onto the road it will set the limit to 35, not 55. I’ve also noticed a significant increase in cases where the speed limit changes but the car doesn’t seem to see the sign so it continues at the last known limit. Essentially it seems to have changed how it prioritizes speed limit data between maps and vision.

Yeah there just seems to be so much variability in multiple people's observations to be able to even attempt to figure out the logic. In my opinion, speed limits getting set in the car shouldn't be so unpredictable. I see three ways for speed limits to be recognized:

1. Speed limit sign - I am not convinced any non-mobile eye vehicles are doing any reading at this time, well maybe better for me to say not using the visual data. This is based on my own observations, or non observations, as well as multiple videos attempting to show the opposite.

2. Map data - this can vary geographically if Tesla is using different sources geographically. There could also be the case that multiple sources are being referenced and they conflict.

3. Hard coded values based on assumed/mapped road type(or other info) - Car may have a hard coded value for a primary/secondary/tertiary/residential street that may be incorrect or in conflict with 1 or 2 above.

I think reading the speed limit signs accurately should be the primary goal and should in 99.9% of the cases override any other data source. I think there is some pretty simple logic(off the top of my head simple anyway) to take car of that other 0.1%(being fake AND incorrect speed limit signs). The car SHOULD be able to read signs generally(camera resolution vs distance vs text point size limited obviously), I just don't think they have gotten that code working for whatever reason.

 

[EVNow]

The car SHOULD be able to read signs generally(camera resolution vs distance vs text point size limited obviously), I just don't think they have gotten that code working for whatever reason.

Are you saying "working" or "working reliably" ? I see speed limit signs with speeds visualized all the time ...

 

[derotam]

Are you saying "working" or "working reliably" ? I see speed limit signs with speeds visualized all the time ...

I'm saying working period. Going to try and not get too deep into this again, there was another exchange I had with someone else on here where they provided a link to a video attempting to show sign reading and I did my on breakdown and analysis...

So there are a few problems when trying to test this. And a lot of it is you don't know what you don't know, and what you don't know can't really be assumed, too many variables and other unknowns...

There are a few actions that happen for speed limit sign acknowledgement, display and applying to the car. *There is a slight offshoot to this as well which is applying a speed limit when there is no sign which may or may not be hard coded

First the car has to know there is a speed limit sign some how, whether by seeing it, or by getting the GPS tagged location from some kind of dataset...*or by assumption...or by WAG(wild a$$ guess which is an offshoot of assumption)

Second, the car puts up a visualization on the display of the sign, with or without a speed limit shown. If it sees the sign, or "knows" the sign is there then there should be no reason NOT to visualize it.(this is one assumption that I personally make and it does affect certain testing scenarios).

Third, the car applies the speed limit to the road speed limit marker in the display AND/OR to the autopilot TACC set speed limit. I say AND/OR because again, in some videos I have seen, speeds sometimes change one but not the other.

These things are not inclusive of each other based on various videos. Sometimes the speed changes and no sign is visualized, sometimes a sign is visualized and no road speed limit visualization is updated...etc.

The other issue is that a lot of people go and say that they pass all these various signs but they end up all being the same speed limit...or if you do pass multiple signs of different speeds and they all visualize and update and you say that is proof they are being "READ", then I counter with I have 3 different signs that I can pass that DON'T visualize and don't update the speed limit...so then where are we...back in the unknown.

I have all kinds of theories but I don't have critical data sets to be able to account for, like map data. Some people say that they update TomTom data and that "eventually" fixes a certain sign they pass, but did it or was it something else...again not a lot of good written up analysis of what they did...multiple times, to really show a correlation.

Anyway...this is one topic that I actually love to discuss because from a written analysis standpoint it is an unanswered question but lots of people have strong opinions or "data" that they think prove their case but in reality there isn't enough testing parameters to come to a real conclusion. Even I have data that I think shows something, but I more think that it disproves certain other theories....and the game continually changes...map data changes, assumptions in code can change at every update, logic in code can change at every update...etc

I think I still have my three signs that don't visualize or react to though...I need to verify it again today since I recently had another FSDb update.

 

[EVNow]

I'm saying working period.

So, are you saying that feature is just not there - so FSD does not recognize 100% of the signs ? Because clearly there is ton of evidence to disprove that.

I think what you are saying is it doesn't work properly in all circumstances .. ?

 

[EVNow]

Like here yesterday ....

 

[sleepydoc]

I'm saying working period. Going to try and not get too deep into this again, there was another exchange I had with someone else on here where they provided a link to a video attempting to show sign reading and I did my on breakdown and analysis...

So there are a few problems when trying to test this. And a lot of it is you don't know what you don't know, and what you don't know can't really be assumed, too many variables and other unknowns...

There are a few actions that happen for speed limit sign acknowledgement, display and applying to the car. *There is a slight offshoot to this as well which is applying a speed limit when there is no sign which may or may not be hard coded

First the car has to know there is a speed limit sign some how, whether by seeing it, or by getting the GPS tagged location from some kind of dataset...*or by assumption...or by WAG(wild a$$ guess which is an offshoot of assumption)

Second, the car puts up a visualization on the display of the sign, with or without a speed limit shown. If it sees the sign, or "knows" the sign is there then there should be no reason NOT to visualize it.(this is one assumption that I personally make and it does affect certain testing scenarios).

Third, the car applies the speed limit to the road speed limit marker in the display AND/OR to the autopilot TACC set speed limit. I say AND/OR because again, in some videos I have seen, speeds sometimes change one but not the other.

These things are not inclusive of each other based on various videos. Sometimes the speed changes and no sign is visualized, sometimes a sign is visualized and no road speed limit visualization is updated...etc.

The other issue is that a lot of people go and say that they pass all these various signs but they end up all being the same speed limit...or if you do pass multiple signs of different speeds and they all visualize and update and you say that is proof they are being "READ", then I counter with I have 3 different signs that I can pass that DON'T visualize and don't update the speed limit...so then where are we...back in the unknown.

I have all kinds of theories but I don't have critical data sets to be able to account for, like map data. Some people say that they update TomTom data and that "eventually" fixes a certain sign they pass, but did it or was it something else...again not a lot of good written up analysis of what they did...multiple times, to really show a correlation.

Anyway...this is one topic that I actually love to discuss because from a written analysis standpoint it is an unanswered question but lots of people have strong opinions or "data" that they think prove their case but in reality there isn't enough testing parameters to come to a real conclusion. Even I have data that I think shows something, but I more think that it disproves certain other theories....and the game continually changes...map data changes, assumptions in code can change at every update, logic in code can change at every update...etc

I think I still have my three signs that don't visualize or react to though...I need to verify it again today since I recently had another FSDb update.

When one considers how the average driver sets their speed there are generally 3 means:

1. Visualized speed limit sign.
2. Knowledge of local laws (i.e. in MN all residential streets are 30 MPH unless otherwise marked) This does require some interpretation of surroundings, of course
3. Knowledge of the roads. (i.e. I know the speed limit changes from 35 to 30 MPH at a certain intersection so I slow down even if I don't see the sign.) This is the human equivalent of map data.

For Tesla, there is no question that it uses map data. When you turn onto a road it knows what speed limit to set even if there is no sign visible. Also see my example above. What is also clear is that the most recent software changes when and how the car uses map data.

It is also quite clear that the car uses vision data. The signs are rendered on the display, so we know the system 'sees' them in some capacity. In the current version I've had multiple locations where there is a speed limit sign that is sometimes followed and sometimes not. (I haven't looked to see how it's rendered on the display for these cases.) If the car were using map data it would change the limit whether it 'saw' the sign or not. Since it does not it must be relying on visual data.

 

[JB47394]

When one considers how the average driver sets their speed there are generally 3 means:

4. Does whatever everyone else is doing, with the assumption that they are locals and know what they're doing.

 

[derotam]

When one considers how the average driver sets their speed there are generally 3 means:

1. Visualized speed limit sign.
2. Knowledge of local laws (i.e. in MN all residential streets are 30 MPH unless otherwise marked) This does require some interpretation of surroundings, of course
3. Knowledge of the roads. (i.e. I know the speed limit changes from 35 to 30 MPH at a certain intersection so I slow down even if I don't see the sign.) This is the human equivalent of map data.

For Tesla, there is no question that it uses map data. When you turn onto a road it knows what speed limit to set even if there is no sign visible. Also see my example above. What is also clear is that the most recent software changes when and how the car uses map data.

It is also quite clear that the car uses vision data. The signs are rendered on the display, so we know the system 'sees' them in some capacity. In the current version I've had multiple locations where there is a speed limit sign that is sometimes followed and sometimes not. (I haven't looked to see how it's rendered on the display for these cases.) If the car were using map data it would change the limit whether it 'saw' the sign or not. Since it does not it must be relying on visual data.

Any human relationship is irrelevant to this discussion as I am not trying to say that Tesla should act more like a human in this case.

Yes, Tesla uses map data, but that map data may be incorrect or the speed limit part may be non existent

Yes the car uses vision data for all kinds of things, that is the main source of data for the driving capability. I never said that Tesla cannot see something, it sees everything but the code determines what it can recognize and what it chooses to display.

Whether you are correct or not and whether "common sense" may seem to indicate something, you are making assumptions not based on data. In your case of a sign sometimes being followed and sometimes not, you can probably infer that if there was map data that it would follow that speed change every time, I am mostly ok with making that inference, however, I am less likely to make the inference that because it doesn't follow the sign that it must be using visual data ONLY. Back to my comments about the possibility of the car making assumptions about road type in the absence of map data. If the assumptions aren't hard coded, which a lot of things are not with Tesla because it is using NN's to analyze the dynamic scenario, you can get different answers different times because of some variable that wasn't appropriately learned in the NN.

You even seem to acknowledge unknown variables with your scenario... Even if we say sure it MUST be using visual data ONLY...then why isn't it following that same speed limit sign EVERY time? What is the variable preventing it from reading that sign every time... THIS is my biggest question, what is the variable or variables that allow or prevent the car from reading speed limit signs? You yourself has a sign that is doesn't always follow, I have 3 known signs that it NEVER follows or displays...WHY? Answering that question can allow us to prove/disprove the visual sign reading capability, or at least better characterize it.

There are a lot of variables to look at with this and a lot of you don't know what you don't know. I have run lots of tests where I thought I had all the variables figured out in the lab but then when out in the real world things didn't work right because of something that either wasn't related enough to be "on the radar" for test planning, or was assumed to be a non relevant variable.

 

[derotam]

So, are you saying that feature is just not there - so FSD does not recognize 100% of the signs ? Because clearly there is ton of evidence to disprove that.

I think what you are saying is it doesn't work properly in all circumstances .. ?

My opinion can change...and my wording may not be the best at all times... I think I am saying that without knowing more variables, AND based on currently known(to me) testing scenarios and videos, we can't prove whether the car can read signs or not, or even that it can sometimes read them. I think in the videos I have seen there was so much variability in results that you get into the what am I missing category because you can't explain the variance, or the variance in test result was such that it cannot be explained as it seemed almost random.