Skip to main content

Reflections on Tesla's Autopilot 2.0

Tesla announced an upgrade to their autopilot sensor suite on October 19th, to be installed on all cars produced as of that day. This new sensor suite is being called Autopilot 2.0, or AP 2.0 for short, on forums. AP 2.0 adds several additional cameras and improves the ultrasonic sensors. It's also a big improvement in the visual processing hardware required to process the sensor data. You can read about it on Tesla's Autopilot page. Tesla's claim is that this system will be able to achieve "Full Self-Driving capability". The description of the systems capabilities matches the highest SAE vehicle automation level of 5 where the human has only to set the destination and activate the system.



The increase in capabilities between AP 1.0 and AP 2.0 has caused a significant emotional response across the range of existing Tesla owners, especially as Elon has confirmed that there is no option for retrofitting.
People who took ownership of their car in the days before the announcement feel like they missed out on the newest tech and have expressed the desire to have known in advance or have been given special treatment to upgrade. Other owners wonder what their resale value will be on useful, but not nearly as capable AP 1.0 enabled cars. Some people that were on the fence about ordering were happy they waited. There is a general sense of excitement about the leap in capabilities with AP 2.0.

Here is a sampling of some of the threads posted on a popular online site, TeslaMotorsClub.com:

I've had a Model S since June, so about five months. It was one of the first cars to have the new style nose and the front center console that holds drinks and provides some storage space. Since June Tesla has introduced the larger 100kWh battery on performance models that improves the 0-60 time from 2.9s to 2.5s. Rear usb ports and cup holders have been added. Now they've introduced AP 2.0. I like to joke that these improvements have made my car obsolete two or three times in only a handful of months. Tesla makes continual improvements to their cars without any notion of model years and has done so since they started selling cars.


As a recent buyer of a Tesla with the now older AP 1.0 hardware, how do I feel about the introduction of AP 2.0?

Tesla's AP 1.0 has been available since 2014 and it's functionality is still unmatched. AP 2.0 looks like it will significantly improve upon those capabilities. Would I prefer they didn't move so quickly, so I could have the best technology for a longer period of time? Nope. AP 2.0 doesn't reduce the utility of Autopilot in my AP 1.0 car. I'll continue using it for about half of my 90 minute / 70 mile daily round trip commute.

I did consider trading my car in for a newer model with AP 2.0 hardware. First year depreciation on Tesla's has been estimated at approximately 25%. Depreciation plus taxes on a new car is a significant cost on a car that is priced near $100k USD. And you have to factor in the $5000 increase for the fully autonomous autopilot feature that is a new feature available with AP 2.0 hardware. It doesn't seem worth it at this point and it may take a year or more for the software to support fully autonomous driving.

I'm probably most concerned about the impact on the resale value of my car, but there are a lot of people that seem to lack interest in self driving features.

A secondary concern I have is about software support for the older generation hardware. Tesla released a significant upgrade in their software about a month ago, moving from v7.x to v8.0. v8.0 came with a bunch of Autopilot improvements and refreshed the center screen UI. It also brought a handful of bugs. For example, the media player had a bug where the last 20 to 40 seconds of Slacker radio songs was often skipped. After four or five weeks a v8.0 update corrected the skipping issue. It was surprising that the bug made it into the initial v8.0 release at all. Uncaught bugs like this may be generally reflective of Tesla's software quality control. I still run into v8.0 bugs nearly each day.

I do wish there was a cost effective way to retrofit. Given the wiring harness and frame changes for the new sensors it would be a labor intensive process without considering the engineering effort required to determine how to do so in a reliable, efficient, and cost effective manner. Those resources are better spent improving future cars.

Everyone will be able to watch to see how AP 2.0 functionality improves. AP 2.0 hardware and sensors are going to be non-functional while Tesla completes software development and testing. Tesla has said that by December 2016 AP 2.0 functionality will be back to the level of AP 1.0 functionality. Tesla has been known to be late at times, we'll see if they can wrap the software up by then. AP 2.0 hardware is considerably more advanced than AP 1.0 hardware so it wouldn't be surprising if cars with AP 2.0 hardware are significantly more capable than AP 1.0 by the end of 2017.

I'm looking forward to upgrading to AP 2.0 hardware, or maybe even AP 3.0 by then, when I eventually sell or trade my Model S in for a newer model. Until then I'll be watching from the sidelines to see if Tesla can achieve full autonomous driving in the near future.

Comments

Popular posts from this blog

Debugging an imprecise bus access fault on a Cortex-M3

This information may apply to other cortex series processors but is written from practical experience with the Cortex-M3. Imprecise bus access faults are ambiguous, as noted by the term "imprecise". Compared to precise bus errors, imprecise errors are much trickier to debug and especially so without a deep understanding of arm processors and assembly language. Imprecise and precise flags are found in the BusFault status register, a byte in the CFSR (Configurable Fault Status Register). BusFault status register bits The definition for imprecise and precise bits is: [2] IMPRECISERR Imprecise data bus error: 0 = no imprecise data bus error 1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current pr...

Travelling on Spirit airlines out of Boston Logan airport? Here are some tips.

I attended CES 2017 in Las Vegas. Booking the trip late I ended up on Spirit airlines. It was both non-stop, making it six hours to Las Vegas from Boston, and affordable, less than $300 for a one way trip compared to around $700 with JetBlue. Here are some tips that might help you when travelling on Spirit from Boston Logan airport. Eat Spirit is located in the B-terminal, gates B-37 and 38, with its own TSA security checkpoint. While it does have restrooms and places to sit the food selection is limited to a single food stand. I'd recommend eating at the Legal C Bar (number 77 in the image below) prior to going through the terminal security checkpoint. The food and service there were great. Drink The water and other drinks are cheaper if you buy them at the food cart rather than on the flight. Seats The seats on Spirit don't recline. They do this to reduce weight, seat cost, seat maintenance costs, and so seats don't impact the free space of other passengers,...

Yocto recipe SRC_URI for a BitBucket / GitHub ssh git repository

This is a particularly geeky post but because Google searches didn't turn up any information I thought it would be helpful to document the issue and solution for others. I was writing  Yocto recipes that pulled from BitBucket git repositories in ssh form and ran into several issues getting a SRC_URI that worked. GitHub uses the same syntax for their ssh repositories. A BitBucket / GitHub git url, in ssh form, looks like: < username >@bitbucket.org:< account name >/< repository name >.git a more concrete example for a git repository in one of my BitBucket accounts looks like: git@bitbucket.org:cmorgan/somerepository.git Yocto recipes can pull from git repositories by setting the SRC_URI variable appropriately. Unfortunately you can't just do: SRC_URI = "git@bitbucket.org:cmorgan/somerepository.git You'll get errors because the Yocto won't know what kind of url this is. You need to specify the protocol for Yocto to k...