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

Nav System after v5.0: wishes, wants, Google maps and more...

This site may earn commission on affiliate links.
It's all relative I guess. I'm the 21st century equivalent of the guy with the VCR flashing 1200. I think the Nav system is pretty great.

I second that. I have had no issues with the Nav system itself. Plus, I think the ability to shoot an address directly from Google Maps to the Nav display is pretty slick. My other cars have had Google Maps POIs, but these have been extremely poorly implemented.
 
It's all relative I guess. I'm the 21st century equivalent of the guy with the VCR flashing 1200. I think the Nav system is pretty great.

I'm glad you are happy with it. Really. But, I'd give it a grade of C+ at best with maybe a B for being "pretty". To get an A, they need to take real time traffic conditions into account and provide real time incident reports. Then, based on those, give real time arrival estimates and alternate routing to avoid problems. I've already gotten stuck in several traffic jams because even simple updating of traffic on the maps seems to be a challenge. Done, right, you don't need to do anything different from what you are doing now, so no programming that metaphorical VCR needed. All this is available with Google Maps/Nav.

As for street names not rotating in a nose-up orientation of the maps (separate from the nav system) - just rotating the map tiles is a cheesy, tired hack. Frankly, I'd rather see them use the effort to get to google maps in vector form. This is like 2 generations old on GMaps. Right now, my phone with Google Maps/Nav is a better solution than frankenNav.

Some of this is due to the platform Tesla chose. If they had google maps/nav on android, they would be able to stay reasonably current with out lots of rewriting.
 
The display and Nav right next to speed odometer with turns is the best of any Nav system I've ever seen. It certainly is missing many features. Garmin and Tomtom didn't have all of the desired features from the start but expect Tesla will implement good traffic and other features in time. Software is much better now than a year ago but Nav still missing some basic features. Love it over all though.
 
Android is the last thing I want to see on my car's dashboard, thank you. If the software vulnerabilities weren't enough, there is that whole "ugly" thing... Tesla's UI is much nicer than anything Android. Keep that crap off my car! lol
What makes you think android in a car is more vulnerable than the Tesla OS? And, do you think rotated tile maps are pretty?

As a developer, you can make it look anyway you want. But to be clear, without going to android for at least the map/nav system, we'll be stuck behind the curve on anything google. Tesla will have to do a lot of engineering to use the latest stuff (like vector maps). And right now, google maps/nav is as good as you can get and because of crowd sourced traffic info, one could argue it's better than anything else.
 
What makes you think android in a car is more vulnerable than the Tesla OS? And, do you think rotated tile maps are pretty?

As a developer, you can make it look anyway you want. But to be clear, without going to android for at least the map/nav system, we'll be stuck behind the curve on anything google. Tesla will have to do a lot of engineering to use the latest stuff (like vector maps). And right now, google maps/nav is as good as you can get and because of crowd sourced traffic info, one could argue it's better than anything else.

Well, I'm having trouble getting excited about the rotated maps thing, maybe personally because I like North is up better. I also don't think Tesla or any software team should base an entire platform OS decision on the possible features of one app. They have a small team, likely well versed in C/C++ that they want able to pitch in anywhere. Plus, there's no guarantee that even with Android they would have had access to all things Google maps: If they have to negotiate for access to vector maps now, how is that any less difficult than negotiating for either a complete google maps implementation for Android or vector maps on Android?

I should add that I don't think the current nav implementation is perfect or couldn't be improved a lot. What works well about it comes mostly from the screen size, which they got "for free". Rendering, and POI improvements are definitely necessary, but I see no reason those aren't doable within the current framework.
 
Last edited:
Well, I'm having trouble getting excited about the rotated maps thing, maybe personally because I like North is up better. I also don't think Tesla or any software team should base an entire platform OS decision on the possible features of one app. They have a small team, likely well versed in C/C++ that they want able to pitch in anywhere. Plus, there's no guarantee that even with Android they would have had access to all things Google maps: If they have to negotiate for access to vector maps now, how is that any less difficult than negotiating for either a complete google maps implementation for Android or vector maps on Android?

Since android was designed by Google, all android devices have access to Googles vector maps. (surprisingly enough, Google gave themselves access)
 
Since android was designed by Google, all android devices have access to Googles vector maps. (surprisingly enough, Google gave themselves access)

Ok, but that doesn't change my main point: basing an entire architecture decision around access to vector maps would be a moronic software development decision. Maybe there are other good reasons they should have gone Android (I don't think so), but that alone shouldn't do it.
 
Ok, but that doesn't change my main point: basing an entire architecture decision around access to vector maps would be a moronic software development decision. Maybe there are other good reasons they should have gone Android (I don't think so), but that alone shouldn't do it.

Agreed, it would be interesting to talk to someone on the dev team to see if they considered a (obviously highly modified) android system before they chose to implement a linux based system. I wonder what the pros and cons were? Were there other options considered?
 
Agreed, it would be interesting to talk to someone on the dev team to see if they considered a (obviously highly modified) android system before they chose to implement a linux based system. I wonder what the pros and cons were? Were there other options considered?

I would be willing to bet Android was in the mix, definitely. The decision would have been made 2-3 years ago. A different landscape then, too.
 
A potential downside of android is that people can get their hands on the code easily, there are a lot of people trying to find vulnerabilities in it. This isn't a bad thing, as it makes android more secure, but at the same time if someone finds a vulnerability in android (I realize most errors are found in implementation on specific phones) then it could easily be applied to a Model S.

Currently getting access to even test for vulnerabilities requires buying a car, then figuring out how to login to the car, and read the firmware. I know Security through obscurity isn't anything to count on. But I'd rather Tesla develop their own system than use Android.
 
A potential downside of android is that people can get their hands on the code easily, there are a lot of people trying to find vulnerabilities in it. This isn't a bad thing, as it makes android more secure, but at the same time if someone finds a vulnerability in android (I realize most errors are found in implementation on specific phones) then it could easily be applied to a Model S.

Currently getting access to even test for vulnerabilities requires buying a car, then figuring out how to login to the car, and read the firmware. I know Security through obscurity isn't anything to count on. But I'd rather Tesla develop their own system than use Android.

I don't know how much more secure a modified Linux system is to a modified Andriod system (that already utilizes a linux kernal).
 
I don't know how much more secure a modified Linux system is to a modified Andriod system (that already utilizes a linux kernal).

A ton of enterprise appliances (phone systems, storage systems, IPS, etc) are based on modified linux, the code base is very mature and vulnerabilities are few and far between. Android is a newer code base, vulnerabilities are found constantly. I hear of a new phone being rooted every few days.
 
Last edited:
Ok, but that doesn't change my main point: basing an entire architecture decision around access to vector maps would be a moronic software development decision. Maybe there are other good reasons they should have gone Android (I don't think so), but that alone shouldn't do it.

Well, lets take this one step further. What exactly would you base the platform decision on? I think your position sounds logical until you think through the cost of reinventing the infrastructure for a critical application. You would skip a platform that allows you to use significantly fewer resources just because you "wouldn't base the decision on vector maps"? Though, you need to replace "vector maps" with "best of class mapping and navigation". So, no, I totally disagree with your "moronic" point. Having run a fair number of software projects in my career, I've found that picking a platform that forces you to do re-engineering on critical applications that you wouldn't have had to otherwise is a nightmare as you are always trying to catch up. So far, this is exactly the situation that T Maps/Nav is in right now.
 
Well, lets take this one step further. What exactly would you base the platform decision on? I think your position sounds logical until you think through the cost of reinventing the infrastructure for a critical application. You would skip a platform that allows you to use significantly fewer resources just because you "wouldn't base the decision on vector maps"? Though, you need to replace "vector maps" with "best of class mapping and navigation". So, no, I totally disagree with your "moronic" point. Having run a fair number of software projects in my career, I've found that picking a platform that forces you to do re-engineering on critical applications that you wouldn't have had to otherwise is a nightmare as you are always trying to catch up. So far, this is exactly the situation that T Maps/Nav is in right now.

There is no way on God's green earth that there should be any OS/platform re-architecting necessary to support vector maps. The only thing holding them back as far as we know is Google granting access. This isn't an architectural issue, it's one where folks speculate that Tesla would get better maps by using Android not because of a code issue but because of a Google policy issue. My point, more precisely stated, is that choosing an architecture based on policy (one subject to change, at that!) of a third-party is pretty dangerous.
 
Lot's of FUD here about Android and Open Source software.

I work with Android every day and know it pretty inside and out. In addition to my own assessment of Android's security features, one of my professors in college (a security expert) was very closely connected to the Android team and he and his grad students have spent a number of years combing the source code for security vulnerabilities. If he is happy with it (and he is) then so am I. It is plenty secure, plenty fast, and plenty feature rich for use in Model S. Also, they could have completely changed the UI if they wanted (many phone manufacturers do this today). I do not know why they decided not to use it, I'm sure there must have been a good reason, but it was not for security or performance or style.

As a shareholder it concerns me that in addition to all the other complexity they have to deal with, they are trying to build a mini software company inside Tesla as well to develop a proprietary OS and app ecosystem. I think the complexity of this task probably escapes a lot of people here that have never looked at the Linux and/or Android source code. Android is the culmination of likely millions of person hours by some of the best software engineers on the planet. It is a fantastic OS that is extremely flexible and FREE. Tesla cannot possibly hope to duplicate this effort with much success.

From a purely technical perspective It doesn't make much sense to me. The consequences of this decision can be seen in buggy cameras, far inferior mapping and navigation, a one year delay in turning the WiFi on, the missing 4G we were promised, deficiencies in bluetooth, poor voice command recognition. These are all things that they would have gotten essentially for free had they built on top of Android.

Again, I'm sure there was a good reason they went their own way, but an explanation escapes me.
 
Lot's of FUD here about Android and Open Source software.

I work with Android every day and know it pretty inside and out. In addition to my own assessment of Android's security features, one of my professors in college (a security expert) was very closely connected to the Android team and he and his grad students have spent a number of years combing the source code for security vulnerabilities. If he is happy with it (and he is) then so am I. It is plenty secure, plenty fast, and plenty feature rich for use in Model S. Also, they could have completely changed the UI if they wanted (many phone manufacturers do this today). I do not know why they decided not to use it, I'm sure there must have been a good reason, but it was not for security or performance or style.

I am an Android developer as well, believe it or not.

As a shareholder it concerns me that in addition to all the other complexity they have to deal with, they are trying to build a mini software company inside Tesla as well to develop a proprietary OS and app ecosystem. I think the complexity of this task probably escapes a lot of people here that have never looked at the Linux and/or Android source code. Android is the culmination of likely millions of person hours by some of the best software engineers on the planet. It is a fantastic OS that is extremely flexible and FREE. Tesla cannot possibly hope to duplicate this effort with much success.

Well, let's be clear about what we are talking about. The cars control system computers do need a lot of fault-tolerance and custom work to accomplish that. So we are talking about the main-screen computer and the dash. I think it's a stretch to say they are developing a propietary OS here. They have taken Linux and used the Qt framework on top of that. They've probably done their own work to roll a Linux distribution to their liking and write drivers (which they'd have to do in any case). That's a far far cry from developing a custom OS.


From a purely technical perspective It doesn't make much sense to me. The consequences of this decision can be seen in buggy cameras, far inferior mapping and navigation, a one year delay in turning the WiFi on, the missing 4G we were promised, deficiencies in bluetooth, poor voice command recognition. These are all things that they would have gotten essentially for free had they built on top of Android.

Maybe they didn't want to tie their fate so closely to a third party? And I dispute the notion that they'd get any of the things (with the exception of maps) for "free" with Android: all of those other things are hardware features that phone and device manufacturers have to do themselves (which is why Android devices are often so slow to get OS updates). The drivers and low-level code for Wifi, bluetooth, 4G, cameras, etc. would need to be written/integrated and/or sourced (and not by google) by Tesla regardless. And isn't the voice recognition already google based?

Look, I've worked on projects based both on Linux + Qt, Android and and a bunch of real-time OS's. Pick your poison, there's advantages and disadvantages to all of them but there ain't no free lunch. Just a whole lot of tradeoffs. Android is not a magic bullet you drop into a project and away you go.