The definitive guide for automotive GPS navigation application

Old fashioned car maps (or scrolling down the window to ask locals) are relics of the past, since anyone can have a navigation application on their smartphone. But when it comes to your car and its nice (and large screened) infotainment system, there is an option here: have an embedded application, or use the one from your phone connected to your infotainment?

The connected option has some really convincing appeals, especially to teams designing infotainment systems (from the scratch): all you need to provide is one of many connectivity solutions (car link, mirror link, Bosch MySpin, etc), and from this point on, it is up to an end user to choose the navigation they like the best, as long as it supports at least one of these protocols. The development and/or integration of the navigation software in the first phase of the infotainment system, and then updates of both maps and the application itself are elegantly circumvented.

But on the other hand, you as infotainment developer have lost any control over how will this look and feel inside your infotainment system. This may be purely aesthetical argument (and sometimes more than enough). But if the other vehicle subsystems require some of the ADAS data, then navigation application is a natural ADAS data provider, and in this case you will prefer it embedded. The vehicle developers might want to use vehicle sensors’ data for dead reckoning for example, and that will require embedded solution as well.

Mireo can help you with both scenarios: we already have implemented numerous connectivity protocols so our navigation running on users’ smartphone will be displayed on infotainments (large) screen, maps and app itself will be updated the same way any smartphone app will be.

If you prefer truly embedded application, we have it ready for you. Application and map updates? We have the infrastructure to support updates in any form that will suit you.

Mireo has all the infrastructure ready for the off board applications to use if that is the preferred approach, but we also offer the best quality on board navigation application.

Calculating your route to preferred destination can be performed locally on your infotainment system (onboard), or it can be performed as a service on some remote server (off-board).

An on board solution is rather straight forward: you have all the data you need present locally on your infotainment system, and you can readily draw map, perform searches for addresses (or Points Of Interest) and most importantly, calculate best routes from some departure location to some destination. But some of these functionalities can be quite challenging regarding the resources of your infotainment system, for example calculating routes. Routes for distant locations, spread over several countries, can be quite CPU consuming. Also, if you need large coverage, even global perhaps, you will need large storage space, and periodically update quite large amounts of map data.

Choosing the off board solution means you do not need to have any data locally stored, and you do not need to perform heavy calculations on your (local) hardware, but you do need (a good) internet connection so application can ask for these calculations to be performed someplace else. You can even download pre-rendered map images, in vector or bitmap form and draw it in your off board application. But once you are abroad, the roaming costs of the internet can present quite a problem.

Mireo has all the infrastructure ready for the off board applications to use (for example in MapBox Directions API format) if that is the preferred approach, but we also offer the best quality on board navigation application, and the support for all the needed logistics, like updates of maps and application itself.

Utilizing navigation SDK for your infotainment system, opposed to using complete navigation solution, seems like a natural choice at first glance: you get the functionality you need (map drawing, searching places, route calculations) in the engine along with the interface, and then you build your own UI around it, that will fit your infotainment like a glove fits a hand. And if this is your choice, Mireo can provide it.

The other option, to obtain full blown navigation application, is definitely a faster method, since developing new application will inevitably take time. And whether you like or not, if you are doing this for the first time, you will have to learn some things by correcting design errors that are consequence of the lack of the experience in the field. We have been doing this for 20 years, so we do have some insights here.

When we designed our latest navigation application, we made special care that its integration with infotainment systems, from the look and feel of it to the implementation of infotainment’s interfaces, can be done in minimum time.

But already developed application will hardly look like part of your infotainment when you take it off the shelf. It there a way to remedy this situation? Yes there is: when we designed our latest navigation application, we made special care that its integration with infotainment systems, from the look and feel of it to the implementation of infotainment’s interfaces, can be done in minimum time.

We have fitted some hands over the years so we can deliver functioning prototype that will look like you want it to look in 2 weeks, and we strongly suggest this approach, over the SDK approach.

The large main screen of your infotainment system is the most natural position for a navigation application, but having it shown on some other places in the vehicle can be really helpful. Of course, this does not mean there should be several screen showing exactly the same thing.

One could for example implement display of the next maneuver (an arrow) on the dashboard, right next to the display of speed. Or one could project the very same information, along with the distance to the maneuver, right on the windscreen, so the driver can see it without the need to remove her/his focus from the road even for a fraction of a second. Perhaps the navigation can be displayed inside a widget on the main screen of the infotainment, rather than being displayed in full screen?

On the other hand, the driver is not always the only person present in the vehicle, so why not display navigation to passengers in the back row for example, so they could, for instance, search some restaurants without disturbing the driver?

The first step to all of this is to have the navigation application that supports displaying multiple screens (at once, of course), and Mireo navigation software does exactly that. Mireo navigation can support any number of screens, having any conceivable dimensions, and all of them being separately configured for the features to be displayed: some of them will for example display map and others might not, some might draw additional data on map while others will not, etc etc. No limits.

West Europe (or any other region of the world) is covered by your navigation application, and you want to global with it. So it is a straight forward thing, you just add missing maps.

Or is it really?

First of all, there is not one single company in this world that can provide you map data for the whole world in a standardized form. This means that you can perhaps purchase the data for the whole world from a single company but data for some of the countries will in fact be redistributed data from local companies. This is not a problem in commercial aspect, but technically this means that data will be delivered in completely different format. This means you need a new module to parse the raw data, and convert it to some “common ground” format.

We already have achieved global coverage, and we can deliver it immediately.

Besides, for some countries it is illegal to compile map data to application-specific format outside the borders of that country. Also, for some countries the compiled data has to be “scrambled” and you must use government approved libraries to descramble the data so it can be normally used.

In Mireo, we have already done all of the above. We always first import provider’s raw data to our database, and then we use these raw but unified database data to compile data to the final navigation application suitable format. And we already have cooperated with many local data providers and are able to immediately deliver solution globally. And yes, we have already produced compiled map data for countries where you have to produce them and have them censored and approved locally.

We already have achieved global coverage, and we can deliver it immediately.

The map data are the necessary ingredient for navigation to perform its tasks, and that data needs to be updated regularly to reflect the reality of the state of road network. But for the aesthetically more pleasing display of map on hand and, and the usability of the whole application as well, lot of other data are also part of the “map data”, so map data is a naturally layered concept, lending itself to organizing different layers of data into different files.

The base layer, containing road network, administrative hierarchy (and polygons to draw) and basic POI data is packed into what we call base map files. We make those files either per country (in Europe) or per smaller region of large countries (like West USA for example) and these are updated with new data quarterly.

All other layers are optional, and are typically updated quite less often than the base map data. These layers are:

• 2D building footprints
• 3D building models
• 3D terrain
• external POI databases
• landmarks
• speed cameras (if legally allowed in country)
• truck attributes on road network
• TMC tables (live traffic)
• speed profiles on road network
• some other country specific data such as point postal codes for example

As new data is produced, it can be updated totally independently of all other data: you will typically update base map data and not update 2D building footprints. But you can also update base map of the country where you live, while not updating base map data for all other countries you have installed.

As for the updates, USB is one option. But you can also do it over the air, because the sizes of our map files are significantly smaller than those competition has: Italy is 385 MB base map, or 437 MB all of it.

Calculating the best path from one location to the other, i.e. route calculation, is THE reason for having navigation application: everything else servers either as help to prepare this calculation, or to present its results in the best possible way to the end user. So to be able to calculate the route, one obviously needs the road network data and the algorithm that will find the best path over this network, from some departure location to some destination. The best can mean the fastest, or it can mean the shortest, or it can be some other measure (such as least fuel consumption).

This calculation needs to be done as fast as possible, or at least in a reasonable amount of time, but the sheer volume of data that needs to be traversed requires something to be done about it. The legacy routing algorithms (still widely used) “solved” this problem by layering the data: one would actually organize data in layers, for example freeways being the “highest” layer and resident roads being the “lowest” layer of the road network data. Of course, one needs (a final) set of connection points that do connect these layers.

The algorithm Mireo uses for route calculation is modern algorithm that does not need connection points in the way legacy algorithms do, and the result of is always the best route.

This approach has a huge problem in the fact that the outcome of the algorithm hugely depends on how you have selected this connection points. You change them a little, and your route times and paths will modify, so this selections becomes paramount to having useful routing results. And if new road segments are added to the network, you may need to have completely new set of connection points.

The algorithm Mireo uses for route calculation is modern algorithm that does not need connection points in the way legacy algorithms do, and the result of is always the best route, and cannot change because of different selection of connection points.

Searching for places, i.e. their locations, is a paramount functionality of any navigation application. One could search for the exact address, the nearest gas station along the route, the location of the nearest garage to the current location. In some countries, there are some special schemes to geocode locations (Makani for example), so you might want to find specific location via those.

Mireo solution for the search is one line, where end user enters text: as they do it, we do the search and present the most relevant results first.

As the user is typing text into the input, our search engine parses it and does the contextualization of it. We do our best to guess if the specific word is meant to be city name, or street name, or PL or something else, and we do the search with this incomplete data and present results. Each time new letter is entered, we do this again.

Therefore, the results presented are not just the exact matches, but we return the prefix matches, and fuzzy matches as well (so a small typo can be tolerated). The ultimate goal is that the end user finds the specific location with as little key strokes as possible.

We said that we sort the results by relevance, so the most relevant result is displayed first and so forth. So, if you search for Eiffel Tower, you will have the Eiffel Tower as your first result, and some POI that has “Eiffel” or “Tower” in their name will come after that. But if you search for something generic as parking for example, the first result will be the parking nearest to your current location. If you have searched for a street name and have not specified town name, the street with that particular name in the town closest to your current location will appear before the street of the same name in some other town, or some other country

Localization of the navigation application is a bit specific and has some pitfalls your typical localized application would not have.

The overall layout of the navigation application does depend on whether it is used in a left side driving countries (so the steering wheel is on the right side of the car) or in a right side driving country, so the elements of the UI that should naturally be closer to the wheel (and driver behind it) are put to the right position. The other factor that will influence the overall UI design is whether the selected UI language is RTL (right-to-left) or not.

When choosing the font for the UI, one must make sure that the font file contains all the characters of all requested scripts, for example Cyrillic, Arabic and Japanese characters. And you cannot get by with just subset used in UI because the same font is used for the map drawing (street names, city names, POIs), so sooner or later you will need them all.

For the advice prompts, like “in 50 meters turn left”, you will need at least recorded voice phrases to generate them. The better solution is the TTS engine (if it exists for particular language) so your advice can become “in 50 meters turn left to Mountain Street”.

You can also utilize the Voice Recognition engine, so instead of typing text you want to search in map, you can just speak it out loud, and let VR engine turn it into text. In some countries it is forbidden to type while driving, and this becomes nice “hands free” solution to the problem.

Having live traffic information in navigation application is a great asset in providing the best possible route to your destination, because unexpected things do happen and need to be quickly presented to your navigation so it can utilize it to automatically avoid incidents, accidents, closed roads, etc.

But delivering traffic data to navigation application (or web service used to calculate routes) is not a trivial task.

We provide global coverage, we provide global live traffic coverage, but just like with map sources, live traffic sources come from different providers, thus necessarily in different format. And that format is text (XML) meaning the quantity of data is huge, and needs to be parsed into the suitable information. And then, navigation never needs all of the data at once, each navigation application instance needs a small subset of that data, depending on where is the user located.

So we need to collect data, in textual form, from several different sources, and then figure out how to eliminate most of it. That would be far too much to do in the navigation application itself, so we in Mireo have introduced one appropriate level of indirection here: there is ONE web service (one URL) for the whole world that holds the traffic data, collected from different sources, and converted to optimal binary format of data, organized in rectangle tree. This service is invoked with rectangle as parameter, and service extremely quickly gather exactly the data contained within that rectangle, and returns it to the caller.

On the server side, the data is collected from each source as soon as there is an update for it, and it is parsed and the current live traffic state is rebuilt when needed, and each instance of the navigation application queries for the live data when it is appropriate: either vehicle has moved sufficiently, or sufficient amount of time (3 minutes) has expired.

Integration of the infotainment system and the navigation application is a deeper problem than adjusting the look & feel of the navigation app with the rest of the system.

Spoken navigation advices are important, driver has to hear them clearly, otherwise what would be the point of having them in the first place. Thus interaction of the navigation’s sound module with the rest of the system does require some attention. Silencing everything else to the mute level does appear quite unnatural, so silencing background (like radio) but not muting it completely, while the advice is being spoken, is the best approach.

Flexibile integration with: sound system, display configuration, input devices and IVI device architecture.

Some devices will have some hardware keys that need to be integrated into the navigation application, for example dedicated zoom in/out hardware keys, or keys that tilt the angle of the camera when displaying map. Some devices will automatically launch navigation application, and they will do it in the background mode. Some other might also require that the exit from within the application (via close button or similar method) is disabled, i.e. that the life cycle of the navigation process is handled completely from the HMI. Some devices will drive the navigation software on more than one display. The last but not the least, some devices will require the navigation application to present the ADAS data to the rest of the system. That will most likely be done utilizing the ADASIS standard protocol.

Sometimes, we tweak the application behavior to meet something very specific for the device: for example, if OpenGL driver does not have proper hardware implementation for some specific function, we can tweak application not to use that particular function to speed things up.

Each of the fore-mentioned integrations will be very device specific and will require some special attention to tightly integrate with specific device.

Electric vehicles are more popular every day, many countries are making announcements about ruling out internal combustion vehicles by some year. And you want to have a navigation application inside EV just like you want it in all other vehicles. But the question is, can you just take existing navigation application, and use it in EV?

The short answer is that you do not want to do such thing, because there are specific things about EV-s, at least in the present time, which simply must be addressed by navigation application if it is to be useful for the EV user.

The first huge problem is caused by the rather rare network or charging stations, which is additionally amplified by the fact that the range of EV is smaller compared to regular vehicles’ ranges, and the charging time of EV is much longer than fueling time. This means that when calculating routes, you simply must consider possibility of recharging along the route, in order to make it there at all. This is the problem you do not have with regular vehicles because gas stations are simply … everywhere.

The second specific is directly connected to the first one: you need to be able to tell very precisely, in any time at all, how far you can get with your current state of the battery. This means you need to know a lot more about the roads you might be driving (elevation changes along the way), would be nice to know weather conditions that might be ahead on your route. The car manufacturer can provide reasonable data for such calculations in generic way, but we in Mireo collect the actual data for specific car, to make that model tailored to specific driver. Every meter can be crucial here.

SD-CARD, ADASIS, D-BUS, Wayland, Android Auto, Linux, Dead Reckoning, TTS, ASR, ALSA, ...

Nearing the deadline of integration of the navigation application with the infotainment system, the tension goes up, sometimes even a bit of panic appears, and over the time we have isolated a bit of a pattern of the causes for it.

The integration of the sound functionality of navigation application with the rest of the systems somehow emerges near the end of the project, almost always. The sound itself is obviously not the most important aspect of the project, not the most demanding in technological or any other aspect, and most likely because of that, it starts to be seriously considered a bit too late in the development cycle, and a bit of unnecessary urgency descends upon the project.

The startup of the navigation application is always considered with due high priority: everyone wants it to be done as soon as possible after the device is booted, everyone wants it to be ready for use as soon as possible. But very rarely anybody points out on the problem of proper shutdown, and quite often there is no shutdown of the application, but the whole device is simply off the power (as ignition key is out). Navigation application does need some time for a graceful shutdown (so it can be gracefully started next time).

And it is surprising that storage often presents problem. One aspect of the problem is that quite often it is overlooked that because of the map updates, one actually needs capacity that is twice the size of maps in use (and map sizes never shrink, but do steadily grow over time).

The other often overlooked aspect of storage problem is its performance, i.e. read times (write as well, but read is more critical): one does like that to be as fast as possible, and the common storage solution, which is SD card, is very poor solution with respect to the read performance. Navigation has to open and read relatively small chunks of data from map files quite often, and the overall experience of using it can be quite degraded with slow SD cards.