Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

I was skeptical...

This site may earn commission on affiliate links.
Here is a picture of Audi's idea of avoiding mode confusion: green strip means self-driving enabled.

audia7.jpg

I assume this would annoy some drivers and not others.

Wish this would have at least been a feature on the X (and S) with the ability to turn off for those who would have found it to be too much of a distraction.
 
  • Helpful
Reactions: AnxietyRanger
yes. And wouldn't there be an audible if TACC is activated? or would that be for AP only? because I didn't hear any audible.
There an audible chime when TACC is activated (at least there used to be as I haven't tried on the current FW) but not when going from AP to TACC and then your target/follow car moves out of your way/lane. This is the scenario Bonnie is talking about. This scenario is tantamount to engaging TACC as I too feel like I forget sometimes the car is going to accelerate up to set speed.
 
I don't recall any audio when TACC is enabled or disabled, but AP does make a remorable bong sound when enabled and disabled. Could of course be euro vs. U.S. difference as well or maybe I'm forgetting... anyway, the AP sound is very memorable and any TACC sound is not registering in my consciousness for whatever reason...
 
I couldn't agree more. I've thought this many times when a car gets out of my way and the car suddenly lunges forward. Most people don't drive like that unless they're in some kind of hurry or are exasperated. All automatic accelerations should be gradual. You're not always looking to go on 'Launch Mode' in normal driving. Probably asking for the moon here, but it would be nice to have an adjustment for 'resuming speed' situations, just like you have an adjustment for following length. Then everyone could pick what they're comfortable with.

AP will do 0-100km/h in around 20-22 seconds. More or less what a 1957 VW Beetle with 25 horsepower would be capable of (and quite different from what you could do, in terms of acceleration, with the 300+ horsepower which any S or X has). Letting my Tesla accelerate from a stoplight on AP, I often have the drivers of cars with very modest engines overtaking me and giving me very strange looks :).
 
I suppose it's Impossible to get tone and inflection out of text. Gives me more confidence... though still disagree with anxietyranger's conspiracy.

As for my sn, yes and no. Back in the day I bought a used Dragon Warrior game for NES. The prior owner named the main character Voltaren which I later learned was a drug when the drug company sued me because I owned voltaren.com. So, yes, I learned the hard way that it was a drug.:(
Which was created first, your .com or the drug? If you were first, how could they sue?
 
Agreed. I guess we can blame Mercedes in part (no pun intended) for that, however Tesla could and should change that.
Has everyone been making the complaint/request to Tesla? I have to admit it happened to me many times early on in my ownership, yet I haven't reported it myself.

The only reason it doesn't happen to me so often now, is that I've learned to hesitate and make sure I'm actually touching the turn signal stalk before I push up.
 
  • Helpful
Reactions: AnxietyRanger
I have the same issue. I refuse to use it on the streets of Palm Desert, where the speed is 55 mph with stop lights regularly spaced. It just accelerates too quickly. Often in Oregon, on longer stretches of 55 mph, I will decrease TACC to 35mph when I see trafic slowing due to a stop light and manually increase it back up to 55 mph in the 5 mph increments the stalk allows. I do a lot of "stalk" driving I would love a "calm driver" driving mode.
 
The TACC turning on at less than 5 mph also occurs in my 2017 MS 90D with AP 2. Yesterday I ran some tests and discovered how easy it would be to accidentally move the CC lever when turning the steering wheel. It is difficult to trick it to turn on the majority of the time, but when conditions are right, on it will go, and sets the speed to 18 mph!

Long ago I had a Tesla service technician check the Model X with AP 1 while slowly driving on their Service Center drivable pavement in Buena Park. It didn't take long to activate the cruise control at the slow speed. It was written up for repair to document the problem.
 
Last edited:
Sorry I've not followed the thread closely, but is your TACC set speed far above the speed you are going when the target car exits?

Yes it is - because I might be going 50 mph on the straight but slow down to 0-5 to make a right turn behind a car merging into another road. When that car ahead of me moves onto the new road (and thus off my radar), the TACC does not realize I am still waiting to merge myself and tries to rapidly accelerate back to 50. This is a unique scenario but many of us have encountered it. I think TACC should automatically turn off with autosteer when I hit my brakes and turn right. Better to have to reactivate both TACC and Autosteer once i am back on the new road than the current potentially unsafe alternative. I have to reactivate Autosteer anyways after the turn so one pull or two on the control stick is no big deal. With full autonomous driving and AP2 (I have AP1), Tesla will have to fix this anyways. I hope they do not forget us AP1 drivers since there is something they could do about this right now to help.

As before, the Tesla is working as intended but this might be an area they could tweak since it is not working for many of us drivers.
 
I wish this wasn't referred to as a 'user error'. The correct terminology is 'use error', which doesn't assign blame. A use error can be the result of a user error, an error in the design that makes it difficult for some users to do the right thing, or an implementation error.

I suspect (because maybe I know someone who has done it -ahem-) that when coming off AP by taking control of the wheel, people forget that they have not yet released TACC. And when the traffic ahead clears by virtue of turning or cars getting out of the way, the vehicle accelerates just as designed. And yes, the blue circle around the max speed is illuminated, so the user has been told ... but most of us are used to seeing the word 'cruise' somewhere near the speedometer, confirming that cruise is enabled.

This does not mean the implementation is wrong. I'm now able to spot that blue circle and know that TACC is operating. I don't want to see that change - so the idea of user configurable settings as to the rate of acceleration is a great one. Perhaps when taking the wheel back from AP, TACC should also be disabled. That way, IF I wanted TACC to continue, I'd have to enable it again. Which would be no big deal and ensure that I was well aware that I was still driving with TACC on.


I like this idea. I've only had my X for a little over a month (gen 1), and I don't like to use the cruise or autopilot for around town driving because of the rapid acceleration.
 
TACC does turn off when you hit the breaks. So, that condition already exists. I have observed the following conditions:
  • TACC will accelerate if the lead car slows below your speed setting and falls from view via radar or camera
    • Most common and personally experienced when making a 90 degree turn while following without disengaging
  • TACC will disengage when break is applied
  • TACC can only be engaged:
    • Above 18 MPH
    • At stop with lead vehicle detected and break hold engaged. I also noticed that it wouldn't engage until my foot was off the break and in break hold. I was unable to replicate conditions outside of these conditions including some of the conditions stated by posters on this thread.
I do get how a user could either inadvertently engage TACC or forget it is engaged creating potential unsafe conditions within the design specs. But, the car is operating as designed. The user created the unsafe condition inadvertently. My previous vehicle, Buick, had a similar feature and behaved in the same unsafe manner with the same conditions. At what point does the user take responsibility for creating the unsafe condition inadvertently or otherwise. IMO there is not an issue with the firmware, bug, that is causing the conditions. I would recommend that you take the time to understand the functionality and conditions where you need to manually intervene to avoid sudden acceleration. I would recommend practicing a bit with the TACC behaviors in safer environments before using frequently.

To state the obvious if you didn't look at my signature, I am on AP2.0 firmware version 17.17.4.
 
TACC does turn off when you hit the breaks. So, that condition already exists. I have observed the following conditions:
  • TACC will accelerate if the lead car slows below your speed setting and falls from view via radar or camera
    • Most common and personally experienced when making a 90 degree turn while following without disengaging
  • TACC will disengage when break is applied
  • TACC can only be engaged:
    • Above 18 MPH
    • At stop with lead vehicle detected and break hold engaged. I also noticed that it wouldn't engage until my foot was off the break and in break hold. I was unable to replicate conditions outside of these conditions including some of the conditions stated by posters on this thread.
I do get how a user could either inadvertently engage TACC or forget it is engaged creating potential unsafe conditions within the design specs. But, the car is operating as designed. The user created the unsafe condition inadvertently. My previous vehicle, Buick, had a similar feature and behaved in the same unsafe manner with the same conditions. At what point does the user take responsibility for creating the unsafe condition inadvertently or otherwise. IMO there is not an issue with the firmware, bug, that is causing the conditions. I would recommend that you take the time to understand the functionality and conditions where you need to manually intervene to avoid sudden acceleration. I would recommend practicing a bit with the TACC behaviors in safer environments before using frequently.

To state the obvious if you didn't look at my signature, I am on AP2.0 firmware version 17.17.4.

The issue is not whether TACC turns off or not when you touch the brakes. The issue is that when you take control of the wheel, you are notified that AP is off, but TACC does NOT turn off under that condition. So 1) brakes touched, AP + TACC disengage, 2) wheel turned, AP only is disengaged.

I purposely talked up thread about 'use error' vs. 'user error' because the former doesn't cast blame and encourages looking for the root cause. It's a design failure when the only way to prevent a use error is by 'we put it in the manual'. That's fine for kitchen appliances, but when it's a medical device (my field), a plane, or a moving vehicle, understanding what a user believes should happen is a very important part of the design (and indeed, with medical devices at least, it is required by law to understand what your defined user base believes will happen). Usually user decisions are being made in a compressed amount of time & anything the designed UI can do to encourage the user to make the right decision is a sign of good design.

Good design takes into account what the user believes will happen. In this case, you have two very different behaviors when you exercise the two different ways to disengage AP. The behaviors should be the same. Disengaging AP should either disengage TACC each time or should not. But disengaging only when brakes are touched but not when the wheel is turned is a UI problem. It's an introduced inconsistency.
 
The issue is not whether TACC turns off or not when you touch the brakes. The issue is that when you take control of the wheel, you are notified that AP is off, but TACC does NOT turn off under that condition. So 1) brakes touched, AP + TACC disengage, 2) wheel turned, AP only is disengaged.

I purposely talked up thread about 'use error' vs. 'user error' because the former doesn't cast blame and encourages looking for the root cause. It's a design failure when the only way to prevent a use error is by 'we put it in the manual'. That's fine for kitchen appliances, but when it's a medical device (my field), a plane, or a moving vehicle, understanding what a user believes should happen is a very important part of the design (and indeed, with medical devices at least, it is required by law to understand what your defined user base believes will happen). Usually user decisions are being made in a compressed amount of time & anything the designed UI can do to encourage the user to make the right decision is a sign of good design.

Good design takes into account what the user believes will happen. In this case, you have two very different behaviors when you exercise the two different ways to disengage AP. The behaviors should be the same. Disengaging AP should either disengage TACC each time or should not. But disengaging only when brakes are touched but not when the wheel is turned is a UI problem. It's an introduced inconsistency.
I have a different view and do not see the condition you represent as unsafe. I actually like the fact that I can disengage auto-steer without TACC disengaging. I saw it as a feature improvement. My Buick operated in a much more unsafe behavior with their version of TACC, yet it passed regulatory approvals. So, I would challenge Tesla's much safer TACC functionality would reach a level of regulatory adverse condition.

On a side note, I too work in the Life Science industry working directly with med device and pharmaceutical companies specifically documenting responses, labels, FAQs, protocols, device manuals, ect. So, I am familiar with that industries regulation expectations. I also have experience with technology hardware regulations. What I am not aware of is automobile regulations. So, I do not know what would be deemed unsafe as defined by automobile regulatory representatives.
 
I have a different view and do not see the condition you represent as unsafe. I actually like the fact that I can disengage auto-steer without TACC disengaging. I saw it as a feature improvement. My Buick operated in a much more unsafe behavior with their version of TACC, yet it passed regulatory approvals. So, I would challenge Tesla's much safer TACC functionality would reach a level of regulatory adverse condition.

On a side note, I too work in the Life Science industry working directly with med device and pharmaceutical companies specifically documenting responses, labels, FAQs, protocols, device manuals, ect. So, I am familiar with that industries regulation expectations. I also have experience with technology hardware regulations. What I am not aware of is automobile regulations. So, I do not know what would be deemed unsafe as defined by automobile regulatory representatives.
Leaving regulations out of it, I'd just like to see consistent behavior. It is not currently consistent, depending upon how you disengage AP. If you've ever led a UI team, consistency in message to the user is key.
 
I agree with @bonnie. A simple improvement would be that taking control of the steering wheel would disable both AP and TACC.

The second improvement I'd suggest is removal of cruise control activation by moving the lever up or down, which seems to have the potential to be confused with the blinker leading to . Activate cruise by a short pull and AP by a long pull of the lever and leave the up and down movements to speed changes while activated (and no effect while unactivated).

Third, adding a Settings option to disable cruise control stalk would seem like a good idea for those that want to be sure.

Finally, to avoid mode confusion, improvements could and should be made so that user is always better aware of TACC or AP activation. I would add separate green icons for them that appear when active and disappear entirely when they are not active. Or maybe they could even color the entire instrument cluster edge with a different color based on TACC/AP mdoe? Just coloring of circles blue that are always there does not seem so effective IMO....
 
  • Like
Reactions: Pwdr Extreme
Disengaging AP should either disengage TACC each time or should not. But disengaging only when brakes are touched but not when the wheel is turned is a UI problem. It's an introduced inconsistency.
I would find your way very confusing since I don't view TACC as part of AP. Or perhaps more to the point, I tend to simplify TACC as tracking and AP as steering.
 
  • Like
Reactions: rush6410