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

Adequate Self Driving

This site may earn commission on affiliate links.
Robust Tesla self driving is years away, if ever. What could Tesla do in the meantime to make us happier? Currently, individual cars learn nothing from our interventions. Suppose there were a way to tell our car something we know but it doesn’t.

  • I’m thinking of local-to-car map overrides that the user creates based on his personal experience.
    • Fix issues where the maps are wrong or suboptimal.
      • Outdated speed limits
      • Mapped speed limit for a residential area is correct, but really should be lower.
      • Road construction.
      • If the updates allow day of week and time of day qualifiers, they could be used to describe school zones.
      • Change the start of a lower speed limit section of a road earlier, so the car has slowed to the right speed at the real start of the section.
      • Corners that the car takes too fast.
    • If there are intersections or highway entry/exit ramps that the car doesn’t handle well, the override could flag them as blocked/unusable and the router would pick a different route.
    • As a variation, you could mark just certain lanes as blocked—e.g., for a left turn that is unsafe, but it’s okay for the car to use the intersection to go straight.
  • Next, Tesla could provide what amount to location-specific post-perception overrides.
    • Deal with specific flashing yellow lights that cause unnecessary slowing.
    • That speed limit sign is for trucks only, dummy.
    • Ignore speed limit changes for the next 100 meters, because you often get it wrong. (E.g., when one road crosses another or when lanes are shifted due to construction.)
    • Mark unseen speed bumps (and potholes?)
  • Possible implementation
    • A directory on the flash drive that contains individual files, each with one or more overrides. On startup, the computer loads the information from the files into memory. (There needs to be some way to deal with conflicts. Most specific wins?)
      • For now, this requires the user to have a flash drive installed.
    • To reduce load on the CPU, overrides that apply just to routing are separated out and examined only when creating routes. The remaining entries can be split into those that apply somewhere near where we are now and those that can be ignored at the moment.
    • As the car drives, it continuously checks for an override that should be honored now or shortly in the future.
    • Tesla needs to define only the API (valid syntax and recognized options) for the override files. Third-parties can create the GUI apps for users, reducing the burden on Tesla developers.
    • Users within a community could share overrides they have found useful, simply by sharing the individual files with the selected settings. (E.g., school zones)
    • I’m thinking a small team at Tesla could prototype this much in a couple months.
  • Down the road
    • Tesla could expose certain tuning parameters via the API, without needing to create a GUI method for users to set them. Somewhat like extending the Service menu, but with additional qualifiers (location, time-of-day).
      • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.
      • Drivers could tweak assertiveness settings based on where they are. E.g., If they know they need to be pushy on a particular entry ramp during rush-hours.
    • Tesla could provide a built-in app that could be given a URL to an override file. The app would fetch the file and add it to the overrides directory. The app could also allow examining or deleting existing override files. There might be some use cases for overrides that are cryptographically signed, but I haven’t thought of any.
    • It would be nice for the API to be general enough that other ADAS vendors might adopt it. Schools could then provide a single override specification for their zones that all AVs could use, for example. Transportation departments could share construction zone info. But, please don’t delay implementation while waiting for a committee to set the specs.
Comments?

46071715365_d36a6e2bf4_b.jpg

"Full Self Driving Tesla" by rulenumberone2 is licensed under CC BY 2.0.
Admin note: Image added for Blog feed
 
  • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.

Lol.

Or just use my file. I would mark every stop light as a useful intervention/override scenario.

The braking behavior is truly mysterious. Some day they will fix it.

Note that even using regen only would not fix the current behavior. This is a key observation.
 
Robust Tesla self driving is years away, if ever. What could Tesla do in the meantime to make us happier? Currently, individual cars learn nothing from our interventions. Suppose there were a way to tell our car something we know but it doesn’t.

  • I’m thinking of local-to-car map overrides that the user creates based on his personal experience.
    • Fix issues where the maps are wrong or suboptimal.
      • Outdated speed limits
      • Mapped speed limit for a residential area is correct, but really should be lower.
      • Road construction.
      • If the updates allow day of week and time of day qualifiers, they could be used to describe school zones.
      • Change the start of a lower speed limit section of a road earlier, so the car has slowed to the right speed at the real start of the section.
      • Corners that the car takes too fast.
    • If there are intersections or highway entry/exit ramps that the car doesn’t handle well, the override could flag them as blocked/unusable and the router would pick a different route.
    • As a variation, you could mark just certain lanes as blocked—e.g., for a left turn that is unsafe, but it’s okay for the car to use the intersection to go straight.
  • Next, Tesla could provide what amount to location-specific post-perception overrides.
    • Deal with specific flashing yellow lights that cause unnecessary slowing.
    • That speed limit sign is for trucks only, dummy.
    • Ignore speed limit changes for the next 100 meters, because you often get it wrong. (E.g., when one road crosses another or when lanes are shifted due to construction.)
    • Mark unseen speed bumps (and potholes?)
  • Possible implementation
    • A directory on the flash drive that contains individual files, each with one or more overrides. On startup, the computer loads the information from the files into memory. (There needs to be some way to deal with conflicts. Most specific wins?)
      • For now, this requires the user to have a flash drive installed.
    • To reduce load on the CPU, overrides that apply just to routing are separated out and examined only when creating routes. The remaining entries can be split into those that apply somewhere near where we are now and those that can be ignored at the moment.
    • As the car drives, it continuously checks for an override that should be honored now or shortly in the future.
    • Tesla needs to define only the API (valid syntax and recognized options) for the override files. Third-parties can create the GUI apps for users, reducing the burden on Tesla developers.
    • Users within a community could share overrides they have found useful, simply by sharing the individual files with the selected settings. (E.g., school zones)
    • I’m thinking a small team at Tesla could prototype this much in a couple months.
  • Down the road
    • Tesla could expose certain tuning parameters via the API, without needing to create a GUI method for users to set them. Somewhat like extending the Service menu, but with additional qualifiers (location, time-of-day).
      • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.
      • Drivers could tweak assertiveness settings based on where they are. E.g., If they know they need to be pushy on a particular entry ramp during rush-hours.
    • Tesla could provide a built-in app that could be given a URL to an override file. The app would fetch the file and add it to the overrides directory. The app could also allow examining or deleting existing override files. There might be some use cases for overrides that are cryptographically signed, but I haven’t thought of any.
    • It would be nice for the API to be general enough that other ADAS vendors might adopt it. Schools could then provide a single override specification for their zones that all AVs could use, for example. Transportation departments could share construction zone info. But, please don’t delay implementation while waiting for a committee to set the specs.
Comments?

I think that is way too complicated. You are basically suggesting Tesla put a lot of work into implementing a workaround system instead of just making FSD more reliable.

My suggestions would be this:

1) Use cars to crowdsource HD maps (like Mobileye has already done). Tesla has got the fleet size to do it. Basically, have every car build a HD map of the roads it drives on, store that map in the car, and also upload a copy to the cloud. Cars could also download map updates periodically. This would help cars avoid a lot of the map based mistakes we see now.

2) Build a more robust driving policy (like what Mobileye has done with RSS) that would dictate things like lane changes, yielding, follow distance, smooth acceleration curve at stop lights and stop signs etc... This would give the car a more natural and safer driving behavior. And hopefully, it would make the driving more comfortable too.
 
I think that is way too complicated. You are basically suggesting Tesla put a lot of work into implementing a workaround system instead of just making FSD more reliable.

I don’t think it is a lot of work, and would make me happier while waiting on a possible robust FSD.
My suggestions would be this:

1) Use cars to crowdsource HD maps (like Mobileye has already done). Tesla has got the fleet size to do it. Basically, have every car build a HD map of the roads it drives on, store that map in the car, and also upload a copy to the cloud. Cars could also download map updates periodically. This would help cars avoid a lot of the map based mistakes we see now.

True, for popular locations. Not much use for less traveled rural areas. Also, makes the car more dependent on good networking. Do HD maps handle the weird school zone times? Desired slower speeds in residential areas?
2) Build a more robust driving policy (like what Mobileye has done with RSS) that would dictate things like lane changes, yielding, follow distance, smooth acceleration curve at stop lights and stop signs etc... This would give the car a more natural and safer driving behavior. And hopefully, it would make the driving more comfortable too.
Yup. Tesla should do this. But, I want something now (or at least this year).
 
True, for popular locations. Not much use for less traveled rural areas.

My approach would work for any road that any Tesla car has traveled at least once. So, as long as one Tesla has driven on the road in the past, the entire fleet would have a map of it. This is the advantage of crowdsourcing. Over time, as more and more Tesla cars drive around, eventually every road would get mapped. And if there is a road where you happen to be the first ever Tesla to drive on it, then your car would build a map, the first time you drive that road, and store that map in your car for future drives, and share the map with the fleet so that they can benefit from it if they happen to drive on that road later.

Also, makes the car more dependent on good networking.

The maps would be stored offline when driving. So you would not need a network while driving. You would only need a network to download a map update like you do with OTA updates.

Do HD maps handle the weird school zone times? Desired slower speeds in residential areas?

Yes, that would be part of the HD map.
 
My approach would work for any road that any Tesla car has traveled at least once. So, as long as one Tesla has driven on the road in the past, the entire fleet would have a map of it. This is the advantage of crowdsourcing. Over time, as more and more Tesla cars drive around, eventually every road would get mapped. And if there is a road where you happen to be the first ever Tesla to drive on it, then your car would build a map, the first time you drive that road, and store that map in your car for future drives, and share the map with the fleet so that they can benefit from it if they happen to drive on that road later.



The maps would be stored offline when driving. So you would not need a network while driving. You would only need a network to download a map update like you do with OTA updates.



Yes, that would be part of the HD map.
I wonder how we'd go about calculating the storage requirements for HD maps of the entire US.
 
I wonder how we'd go about calculating the storage requirements for HD maps of the entire US.

I know we've debated whether they are really "HD" but Mobileye is able to do their maps with only 10 kb/km. You could do maps that are less than HD to reduce size. Also, the map for the entire US would only be stored in the cloud, NOT on individual cars. Cars would only need to store local maps for their drives. That would drastically help save storage space. So, I think it would be doable.
 
Robust Tesla self driving is years away, if ever. What could Tesla do in the meantime to make us happier? Currently, individual cars learn nothing from our interventions. Suppose there were a way to tell our car something we know but it doesn’t.

  • I’m thinking of local-to-car map overrides that the user creates based on his personal experience.
    • Fix issues where the maps are wrong or suboptimal.
      • Outdated speed limits
      • Mapped speed limit for a residential area is correct, but really should be lower.
      • Road construction.
      • If the updates allow day of week and time of day qualifiers, they could be used to describe school zones.
      • Change the start of a lower speed limit section of a road earlier, so the car has slowed to the right speed at the real start of the section.
      • Corners that the car takes too fast.
    • If there are intersections or highway entry/exit ramps that the car doesn’t handle well, the override could flag them as blocked/unusable and the router would pick a different route.
    • As a variation, you could mark just certain lanes as blocked—e.g., for a left turn that is unsafe, but it’s okay for the car to use the intersection to go straight.
  • Next, Tesla could provide what amount to location-specific post-perception overrides.
    • Deal with specific flashing yellow lights that cause unnecessary slowing.
    • That speed limit sign is for trucks only, dummy.
    • Ignore speed limit changes for the next 100 meters, because you often get it wrong. (E.g., when one road crosses another or when lanes are shifted due to construction.)
    • Mark unseen speed bumps (and potholes?)
  • Possible implementation
    • A directory on the flash drive that contains individual files, each with one or more overrides. On startup, the computer loads the information from the files into memory. (There needs to be some way to deal with conflicts. Most specific wins?)
      • For now, this requires the user to have a flash drive installed.
    • To reduce load on the CPU, overrides that apply just to routing are separated out and examined only when creating routes. The remaining entries can be split into those that apply somewhere near where we are now and those that can be ignored at the moment.
    • As the car drives, it continuously checks for an override that should be honored now or shortly in the future.
    • Tesla needs to define only the API (valid syntax and recognized options) for the override files. Third-parties can create the GUI apps for users, reducing the burden on Tesla developers.
    • Users within a community could share overrides they have found useful, simply by sharing the individual files with the selected settings. (E.g., school zones)
    • I’m thinking a small team at Tesla could prototype this much in a couple months.
  • Down the road
    • Tesla could expose certain tuning parameters via the API, without needing to create a GUI method for users to set them. Somewhat like extending the Service menu, but with additional qualifiers (location, time-of-day).
      • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.
      • Drivers could tweak assertiveness settings based on where they are. E.g., If they know they need to be pushy on a particular entry ramp during rush-hours.
    • Tesla could provide a built-in app that could be given a URL to an override file. The app would fetch the file and add it to the overrides directory. The app could also allow examining or deleting existing override files. There might be some use cases for overrides that are cryptographically signed, but I haven’t thought of any.
    • It would be nice for the API to be general enough that other ADAS vendors might adopt it. Schools could then provide a single override specification for their zones that all AVs could use, for example. Transportation departments could share construction zone info. But, please don’t delay implementation while waiting for a committee to set the specs.
Comments?
I specifically asked during a TMC webcast why can't the neural network learn how to drive from us? They said it was a good idea but Elon wants to use his magical Dojo computer. IE. Not gonna happen
 
  • Like
Reactions: DWtsn
I specifically asked during a TMC webcast why can't the neural network learn how to drive from us? They said it was a good idea but Elon wants to use his magical Dojo computer. IE. Not gonna happen
I thought about this awhile back, and I can totally understand Tesla's approach. What if the person is a bad driver? What if they drive high/buzzed? The NN shouldn't be trained on bad behavior. We want it safer than a human, not the exact same as the guy who can't drive to begin with.
 
  • Like
Reactions: LadyOnikara
My suggestions would be this:

1) Use cars to crowdsource HD maps (like Mobileye has already done). Tesla has got the fleet size to do it. Basically, have every car build a HD map of the roads it drives on, store that map in the car, and also upload a copy to the cloud. Cars could also download map updates periodically. This would help cars avoid a lot of the map based mistakes we see now.

2) Build a more robust driving policy (like what Mobileye has done with RSS) that would dictate things like lane changes, yielding, follow distance, smooth acceleration curve at stop lights and stop signs etc... This would give the car a more natural and safer driving behavior. And hopefully, it would make the driving more comfortable too.

There's actually no evidence Mobileye's approach has better performance than 25.1 though, especially the RSS part.

I get what you're saying, but it's very obvious (to me) Tesla has thought about these things as well, because the ideas presented here are low-hanging fruit.
 
I thought about this awhile back, and I can totally understand Tesla's approach. What if the person is a bad driver? What if they drive high/buzzed? The NN shouldn't be trained on bad behavior. We want it safer than a human, not the exact same as the guy who can't drive to begin with.
Actually I was hoping for Autopilot to drive better than I drive.
 
  • Like
Reactions: Mullermn
So if I was a bad driver then FSD might seem good? Not sure they will ever get mapping right in rural areas. Probably only have the speed right half the time around here. While most roads have no speed limit sign (even most bad drivers can figure out the speed limit), I even have a case here where I am leaving a small town with 25 mph posted speed, which the car follows. On leaving the town there is a 55 mph sign. The car starts to accelerate, and in less than 5 seconds it slows to 35 mph. I have gone around and around with Tesla “service” on this and all they have done is try and blame state authorities for bad map data that it defaults to, even in the presence of an actual sign. I have investigated their ”state authority” for map data and found that there is and never has been any such authority here, and Tesla has never even asked for this data. FSD beta is a huge fail and will be a huge surprise if ever even “adequate”. Instead of constantly doubling down on a terrible strategy (city self driving), they really just need to get highway driving right (like hands free right), to actually give us something sort of useful, instead of a continual stress test for the suckers who paid real money for this.
 
  • Like
Reactions: DWtsn
I suspect AI may not have anything to do with driving safely and reasonably. 85 years ago we could tell the horse, "lets go home". And lean back and have a nap, because the horse was able to navigate a route home, then safely follow that route. If we met someone, the horse knew to move over to the edge of the road / path and share it. No phantom braking, no wild jumping off in some weird direction because the shadow from a bird flying over. Horses are not that bright, tame and social perhaps, but not good at chess or go. Still, crashes were pretty much unheard of. In fact even now, horse races have far fewer crashes than NASCAR??? Perhaps someone needs to take a tip from the navy and check out using a pigeon to watch the touch screen and peck appropriately to control the driving? I would certainly trust a pigeon much more than 2022.44.30.5 or even some of the previous better versions.
 
Last edited:
  • Like
Reactions: OxBrew and DWtsn
Robust Tesla self driving is years away, if ever. What could Tesla do in the meantime to make us happier? Currently, individual cars learn nothing from our interventions. Suppose there were a way to tell our car something we know but it doesn’t.

  • I’m thinking of local-to-car map overrides that the user creates based on his personal experience.
    • Fix issues where the maps are wrong or suboptimal.
      • Outdated speed limits
      • Mapped speed limit for a residential area is correct, but really should be lower.
      • Road construction.
      • If the updates allow day of week and time of day qualifiers, they could be used to describe school zones.
      • Change the start of a lower speed limit section of a road earlier, so the car has slowed to the right speed at the real start of the section.
      • Corners that the car takes too fast.
    • If there are intersections or highway entry/exit ramps that the car doesn’t handle well, the override could flag them as blocked/unusable and the router would pick a different route.
    • As a variation, you could mark just certain lanes as blocked—e.g., for a left turn that is unsafe, but it’s okay for the car to use the intersection to go straight.
  • Next, Tesla could provide what amount to location-specific post-perception overrides.
    • Deal with specific flashing yellow lights that cause unnecessary slowing.
    • That speed limit sign is for trucks only, dummy.
    • Ignore speed limit changes for the next 100 meters, because you often get it wrong. (E.g., when one road crosses another or when lanes are shifted due to construction.)
    • Mark unseen speed bumps (and potholes?)
  • Possible implementation
    • A directory on the flash drive that contains individual files, each with one or more overrides. On startup, the computer loads the information from the files into memory. (There needs to be some way to deal with conflicts. Most specific wins?)
      • For now, this requires the user to have a flash drive installed.
    • To reduce load on the CPU, overrides that apply just to routing are separated out and examined only when creating routes. The remaining entries can be split into those that apply somewhere near where we are now and those that can be ignored at the moment.
    • As the car drives, it continuously checks for an override that should be honored now or shortly in the future.
    • Tesla needs to define only the API (valid syntax and recognized options) for the override files. Third-parties can create the GUI apps for users, reducing the burden on Tesla developers.
    • Users within a community could share overrides they have found useful, simply by sharing the individual files with the selected settings. (E.g., school zones)
    • I’m thinking a small team at Tesla could prototype this much in a couple months.
  • Down the road
    • Tesla could expose certain tuning parameters via the API, without needing to create a GUI method for users to set them. Somewhat like extending the Service menu, but with additional qualifiers (location, time-of-day).
      • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.
      • Drivers could tweak assertiveness settings based on where they are. E.g., If they know they need to be pushy on a particular entry ramp during rush-hours.
    • Tesla could provide a built-in app that could be given a URL to an override file. The app would fetch the file and add it to the overrides directory. The app could also allow examining or deleting existing override files. There might be some use cases for overrides that are cryptographically signed, but I haven’t thought of any.
    • It would be nice for the API to be general enough that other ADAS vendors might adopt it. Schools could then provide a single override specification for their zones that all AVs could use, for example. Transportation departments could share construction zone info. But, please don’t delay implementation while waiting for a committee to set the specs.
Comments?
That’s a lot of work put into typing something up that isn’t necessary. FSD Beta is fantastic.
 
I thought about this awhile back, and I can totally understand Tesla's approach. What if the person is a bad driver? What if they drive high/buzzed? The NN shouldn't be trained on bad behavior. We want it safer than a human, not the exact same as the guy who can't drive to begin with.
Good point but I would think if a human had to take over from a bad FSD decision then the reverse should be true. FSD would prevent bad drivers and incorporate good habits. If you read the spec on the Hyundai Ioniq 6 it says the car learns the driving habits of the driver. So you can have both
 
Robust Tesla self driving is years away, if ever. What could Tesla do in the meantime to make us happier? Currently, individual cars learn nothing from our interventions. Suppose there were a way to tell our car something we know but it doesn’t.

  • I’m thinking of local-to-car map overrides that the user creates based on his personal experience.
    • Fix issues where the maps are wrong or suboptimal.
      • Outdated speed limits
      • Mapped speed limit for a residential area is correct, but really should be lower.
      • Road construction.
      • If the updates allow day of week and time of day qualifiers, they could be used to describe school zones.
      • Change the start of a lower speed limit section of a road earlier, so the car has slowed to the right speed at the real start of the section.
      • Corners that the car takes too fast.
    • If there are intersections or highway entry/exit ramps that the car doesn’t handle well, the override could flag them as blocked/unusable and the router would pick a different route.
    • As a variation, you could mark just certain lanes as blocked—e.g., for a left turn that is unsafe, but it’s okay for the car to use the intersection to go straight.
  • Next, Tesla could provide what amount to location-specific post-perception overrides.
    • Deal with specific flashing yellow lights that cause unnecessary slowing.
    • That speed limit sign is for trucks only, dummy.
    • Ignore speed limit changes for the next 100 meters, because you often get it wrong. (E.g., when one road crosses another or when lanes are shifted due to construction.)
    • Mark unseen speed bumps (and potholes?)
  • Possible implementation
    • A directory on the flash drive that contains individual files, each with one or more overrides. On startup, the computer loads the information from the files into memory. (There needs to be some way to deal with conflicts. Most specific wins?)
      • For now, this requires the user to have a flash drive installed.
    • To reduce load on the CPU, overrides that apply just to routing are separated out and examined only when creating routes. The remaining entries can be split into those that apply somewhere near where we are now and those that can be ignored at the moment.
    • As the car drives, it continuously checks for an override that should be honored now or shortly in the future.
    • Tesla needs to define only the API (valid syntax and recognized options) for the override files. Third-parties can create the GUI apps for users, reducing the burden on Tesla developers.
    • Users within a community could share overrides they have found useful, simply by sharing the individual files with the selected settings. (E.g., school zones)
    • I’m thinking a small team at Tesla could prototype this much in a couple months.
  • Down the road
    • Tesla could expose certain tuning parameters via the API, without needing to create a GUI method for users to set them. Somewhat like extending the Service menu, but with additional qualifiers (location, time-of-day).
      • If there is a normal-braking-force parameter, AlanSubie4Life could set it so the car slows down using only regen when possible.
      • Drivers could tweak assertiveness settings based on where they are. E.g., If they know they need to be pushy on a particular entry ramp during rush-hours.
    • Tesla could provide a built-in app that could be given a URL to an override file. The app would fetch the file and add it to the overrides directory. The app could also allow examining or deleting existing override files. There might be some use cases for overrides that are cryptographically signed, but I haven’t thought of any.
    • It would be nice for the API to be general enough that other ADAS vendors might adopt it. Schools could then provide a single override specification for their zones that all AVs could use, for example. Transportation departments could share construction zone info. But, please don’t delay implementation while waiting for a committee to set the specs.
Comments?
Good intentions but you're dreaming. How long have you been following Tesla? Tesla is actually very predicatable and what you're suggesting isn't in their DNA.
 
"Not a lot of work" = You wouldn't be doing it.
Your comment kicked me into doing some more reading and I had a minor epiphany! There is no need for Tesla to invent a new format for the override files. The XML used by the OpenStreetMap project is perfect for this. Which means Tesla could use the libraries that already exist for reading OSM XML files. And no new third-party GUI apps would be needed—the ones available for the OpenStreetMap project should be fine. After all, you’re basically editing map data.

So, the items I listed in the first section (routing changes) could be made available simply by logically appending the override info to the existing map data at startup. I assume Tesla uses a custom format for the map data it sends to the car, so this appending might not be trivial, but is probably straight forward. No other code changes are necessary, especially to the driving logic.
  • I don’t know if Tesla currently pays attention to time-of-day annotations for OSM “ways”. If not, school zones cannot be fully implemented this way, but you could instead make the safer speed limit apply all the time.
I understand that the non-NN part of Tesla’s code is mostly C++. I’m not proficient in C++, but I have done some coding with it. So, I think my estimate that a small team could prototype this in a few weeks is in the ballpark. If Tesla’s code for loading the map data were open source, I’d be tempted to see what I could do myself.

The suggested post-perception overrides are likely trickier to implement and would require careful code review and testing, since they have a more direct effect on how the car drives.