Programming for Software Improvements

[wk057]

Well, bear in mind that, as much as Tesla software could use improvement, it is still head and shoulders above any other car.

I'm not sure I completely agree. The Tesla software is nice looking and works well, but it is missing many features a lot of other cars already have and have had for years.

I'm coming from a Chevy Volt, and I would trade the Tesla "Media app" for the Volt's media stuff in a heartbeat. Playlists, shuffle, on-board music storage, video capability, etc. As much as I like Tesla, saying it is better than any car is nonsense.

- - - Updated - - -

I'm a software dev myself, and what I miss in this thread is the 20/80 rule... it takes 20% of the time to build 80% of the functionality, and it takes 80% of the time to build the final 20% (plus test/debug). And often the final 20% grows out of hand fast with scope creep and such, making it a never ending story.

The TS/OP sounds like a real dev too, as in way too optimistic in his estimates. Code up a shuffle function in a couple of hours? Sure if everything is aligned and all the pre work is already done, if you know the whole application (as in you wrote the rest also), all playlists etc. are available to you in a neat way, you might be able to get it done, but the devil is in the details. They probably would have done it already if it was that easy.
Probably the original developers already moved on to something else, the API between user interface, media player, and media holdings devices might not be straight forward, or even a third party media player might have been used with just a UI slapped on by Tesla, we don't know... So all in all it might take a new hire weeks to get it done.

What also might be the case (pure speculation) is that they might have a new revamped media component in development and don't want to waste resources on adding features on something that will be replaced soon anyway (again, this is pure speculation from my part).

I'm an actual software dev, yes. And you are correct as far as details getting out of hand. However, I don't see that here. It's not that the details are getting out of hand... they aren't getting done period.

While I'm certainly optimistic in my estimates on how hard it would be to add shuffle, I'm not overly so. I could likely replace the media app completely with something more function in a day or two, so, adding shuffle to an existing framework including time taken to dissect the existing code is pretty much a no brainer.

 

[bob_p]

One simple thing that Tesla could do would be to allocate one or two developers to focus only on the missing features.

While some of the missing features might be difficult to do - there are others that surely should be relatively easy.

Having done software startups and first releases of complex systems, I understand the challenges in balancing initial functionality with aggressive schedules and resource constraints. However, it's difficult to justify the slow progress Tesla has made in their software since the first production cars were released over two years ago.

Some of the missing features not only make the software inconvenient to use - but introduce unnecessary distractions for the driver, which is a potential safety issue. For example, because the software lacks playlists, I have one huge favorites list for the songs on my USB memory stick. Navigation of the favorites list is extremely difficult. If I want to scroll from the current USB song to a favorite on slacker or tunein, it requires tedious and distracting scrolling of the display by carefully dragging the list up for multiple screens, trying to avoid inadvertently selecting one of the songs that I'm trying to skip over to get to the desired position in the list to select.

There are several ways this could be improved. Favorites for individual media sources could be a multi-level list - so it would be easy to move between USB, XM, Slacker, ... Playlists could make it easier by having multiple and shorter lists. And/or scrolling could be accelerated by using something like the scrolling used for contact lists - using a scroll bar with the starting character in the song names.

Surely adding something like this shouldn't be too difficult.

Or, the ability to change the order of items in the browser or navigation favorites list. Both of those are longer than a single page - and having to do the scrolling - is time consuming and distracting.

Tesla is not blocking access to the user interface while driving - something other manufacturers do to minimize driver distractions (and potential liability). Tesla allows full access to the user interface - which is great, as long as that interface is easy to use and not too distracting - which they achieved, in most cases - and need to continue working to address those areas requiring unnecessary screen interactions (while driving).

If Tesla is reading the forums... Can someone from Tesla provide some positive confirmation that Tesla is listening and does plan to address the software deficiencies???

 

[wonko]

I have developed software for movie special effects for ten years. I have quite some experience with well written and chaotic software, bright developers and slow developers. I know very much about the pressure of release dates (when a 300 Mio. dollar production comes to a grinding halt because one software module for post production has a bug that just can not be found).

I also offered to Tesla to code for them free of charge, and I never received a reply. I even filled out job application, just to get into contact, and never received a reply.

But I am not at all surprised. I assume that the jump from 5.x to 6.0 included a major rewrite of the internal structures, maybe even a complete rewrite. Looking at the software, its design and its behavior in simple function, I believe that it was not managed perfectly in the first years, and structural mistakes had to be fixed.

There are other hurdles - besides the already mentioned developer tools and environments - that makes external developments difficult: every feature needs to go through a legal process, checked for patent violations, and verified with possible license holder. Even silly simple thing like shuffle may be protected (well, ok, not shuffle - that has been around for more than 21 years - but other stuff). Lastly, a possible impact on the car and driver has to be checked. Tiny changes may allow a loophole to allow video, which intern may cause distraction, and the obvious law suit.

 

[MartinAustin]

Tesla will only add improvements to minor functionality, which shuffle mode definitely falls into, if there becomes a serious over-availability of engineering resources. That could occur without hiring new staff - like, if they ran out of new major features to work on. IMO the functionality involved in recognising the road you're driving on, random variations in road conditions/weather, missing or revised road markings, road works, negotiating through a crash site that is a few minutes old, heeding the directions of a police officer that is waving traffic around, and so on... are more important than adding shuffle (or the ability to play audio CDs from a player you connect to the USB socket - which I would like!)

The lofty goals Tesla has - pushing the frontiers forwards and all that - are simply too important for them to think about revising their in-car entertainment functionality.

At some future time they'll roll out a revised in-car entertainment system, possibly with release of Model X.

(can't say ICE on this forum when talking about the stereo, but... In car entertainment - Wikipedia, the free encyclopedia)

every feature needs to go through a legal process, checked for patent violations, and verified with possible license holder. Even silly simple thing like shuffle may be protected (well, ok, not shuffle - that has been around for more than 21 years - but other stuff). Lastly, a possible impact on the car and driver has to be checked. Tiny changes may allow a loophole to allow video, which intern may cause distraction, and the obvious law suit.

Let me add... working in all versions of the car - pre Parking Sensors, original/revised signal stalk positions, pre Lane Daparture/Speed Assist, pre Autopilot Sensors & Electromagnetic Brakes, RHD & LHD, all languages including the new ones that get added for new markets, update all the online manuals (in all languages), work correctly on new revisions of computer hardware (display/chip/transducer suppliers changed, or faster RAM, Tegra 4 etc. when it gets selected), and then if there have been any internal problems on the software team that we've never found out about - weak production management, staff get replaced, mistakes get made, Design got new ideas and wants to replace existing work, etc. etc. - there is plenty of opportunity for delays to occur that will slow down what otherwise would seem to be a simple process. The process gets slower and slower as Tesla preside over a larger and larger number of different SKU combinations.

 

[Cosmacelf]

I assume that the jump from 5.x to 6.0 included a major rewrite of the internal structures, maybe even a complete rewrite. Looking at the software, its design and its behavior in simple function, I believe that it was not managed perfectly in the first years, and structural mistakes had to be fixed.

I agree, at some point Tesla will have to literally throw out their code and start from scratch, if they haven't already done that.

Having said that, some of their engineering priorities seem insane. Their Nav system still routinely dumps me in the middle of a street nowhere near the intended location, yet they spent oodles of time revamping the look and feel of the user interface.

 

[bob_p]

What might be interesting would be for someone to do a thorough feature-by-feature review of the Model S on board software and compare it to a range of new vehicles - from luxury cars at the same price point to entry level cars at considerably lower price points.

While Tesla gets high scores from consumer reports on the overall vehicle, I suspect that, overall, Tesla's software would rank very, very low for any vehicles that has "infotainment" systems. Tesla would get high scores from the large display, the touchscreen interface (and the nicely designed buttons/tabs), and providing full functionality while the car is in motion. But when it comes to comparing each of the "apps", media playback and navigation would probably rank near the bottom of what's on the market from other manufacturers...

 

[rdrcrmatt]

some of us car mechanic and software / systems people should get together with a model s or two, remove the touch screen and take an image of the OS and let the real development start.

 

[wonko]

some of us car mechanic and software / systems people should get together with a model s or two, remove the touch screen and take an image of the OS and let the real development start.

Haha, yeah, I thought about that. I doubt very much that the firmware is easily accessible though. At least the core is likely stored on the MCU. It's not like this is a RaspberryPi with an OpenSource OS on an SD card ;-)

There's only hardware mod that would be fun though: loop an FPGA into the display cable. That way, one could not only overlay parking lines on the rear camera view, but also partially superimpose the graphics from a smartphone. Within that screen, anything can be programmed.

My problem though, I do not know how to take apart the center console and get to the main and display board without destroying the trim (doh! there I am, programming the most complex stuff, but too afraid to break a few clips in my car's dashboard ;-)

A collection of photos on how to disassemble stuff would be nice... .

 

[wk057]

I'd considering trying to figure out exactly how to tap the display output. Looking at the teardown pics of the center stack, though, it'd probably be a bitch to do it. Plus no info on what lines were what to do the man-in-the-middle on the video.

If you did this with the video feed, and the touch controller, you could essentially do whatever you wanted if you're clever. It is my most likely "hack" vector if I ever did decide to do something.

For example, a 1-bit 1920x1080 array (259200 bytes) could be used to map the entire touchscreen between two devices (the car and the second display overlay input) so that areas could be redirected to the secondary processor/CPU that was added instead of the car. Combine that with the ability of the new CPU to make inputs to the car, and you could move icons and controls, add controls, etc with clever overlaying on to the original video and touch mapping.

 

[3s-a-charm]

I would like to have the ability to send addresses from Google maps on my desktop to the car. BMW and several other cars can do this and it is a very useful feature. I know there is Calendar integration but for me specifically the send to car feature is ideal (especially for large clusters of addresses).

Send to Car Settings