Carpc project - software

I recently uploaded a new video to show my custom-made carpc based on a Raspberry Pi. In the video, I had to leave a lot of information out for the sake of runtime, so, I decided to write a little series of posts to explore thoughts and ideas about this project.

This episode is about the software.

Disclaimer (sort of):
Be aware that this post is not self-contained. If you haven't seen the video, you probably won't get much out of this reading. Also, this is not a tutorial on how to build a carpc like the one I made. For that, I'd need much more time and space. I just want to document the thought process behind a few hardware and software choices, share some techno-ramblings, and provide you with some links to get you started using the components I used.

Have you ever modified your car with custom electronics? Are you planning to hack a Raspberry Pi into a device that was not intended to be modified? Have you ever started a simple project (such as adding music to your car), and somehow turned it into a huge, titanic undertaking?

The software

 

Besides a myriad of scripts to control all hardware peripherals, the two most important pieces of software I had to choose are the navigation software, and the media player. This is the bit of the project where I produced the biggest amount of stupid ideas.

Stupid idea #1: "Hm, I should program a navigation software myself, and a media centre, using PyGame! I'll have easy access to GUI widgets, to the touchscreen, and I can blend the two functions in a single software package to obtain the perfect level of integration.". I believe there's no need to tell what's wrong with that. If the need is there, consider that a simple version of this idea requires easily 1 man-year of effort for a basic alpha release. With my limited spare time, I'll replace my car halfway through the project.
Stupid idea #2: "You know what, PyGame is the problem. It's too complex. I should just replace it with a dedicated toolkit for touchscreen devices, like Kivy." No, still unfeasible. Sorry.
Stupid idea #3: "How about a CLI application instead?". Really? On a touchscreen? Text mode? For GPS navigation? TEXT?!?
Stupid idea #4: "F*** it, I'll just install Centrafuse." Yes, and be locked to a proprietary platform running on Windows. I'm not sure if I can even run it on a Pi.
Stupid idea #5: "...vlc?". Nope. Can't customize it.

Well, it sounds like I argue with myself. Which I do. Sometimes. In the end I decided to use only software available in the official Raspbian repositories. My only criteria of choice (besides providing the functions I need), was the ability to customize the user interface, to a certain degree.

For GPS navigation I selected Navit (not that I had any real choice, as very few programs exist to do GPS navigation in Raspbian). Navit was really easy to configure after installing and running the gpsd module that hooks on the GPS receiver.

The Navit GUI.

As all respectable GPS packages, Navit needs maps, and for this project, I downloaded a full-featured map of continental Europe from OpenStreetMap. I love these maps: they are very detailed, and free! What else to ask for? Totally recommended.

One big point in favour of Navit is the possibility of customizing the interface with skins (or layouts, as they are called by the Navit community). Layouts are simple XML files describing the structure and functions of the on-screen components, and a library of graphics items and widgets. For this project I downloaded the 10.2" glossy netbook layout from https://wiki.navit-project.org/index.php/OSD_Layouts and edited both the XML and the graphics to suit my needs. I wanted to have as much information as possible on the screen during navigation, including the estimated time of arrival, the distance to my destination, the next turn, and the name of the road I'm supposed to turn to.

Voice direction was a little more problematic, not because it is difficult to obtain, but because it is difficult to understand. Navit supports the festival voice synthesis engine, so it is quite easy to add a voice to your GPS. The problem is that all compatible voices I could find are VERY difficult to understand. It's basically like trying to get directions from a drunk speak & spell toy with a digital potato in its mouth. Let's face it, Linux still lacks a proper free voice synthesis engine.

The Kodi GUI.

So, in the end I decided to work with the least crappy voice I could find, and be happy with it. Unfortunately, the voice I chose is quite heavy on the Pi, and takes around five seconds to start talking from the moment Navit produces a turn event... We'll see if that is quick enough for proper live direction. Worst case, I'll have a voice telling me where I SHOULD HAVE turned a moment ago...

Next up, the media center. Once I abandoned the crazy idea of making my own media center, the choice fell naturally on Kodi, formerly known as XBMC. Kodi is easy to use, way more featured than I need, and easy to customize. Kodi skins can be found all over the web, and for my project, I decided to start from the Carbon CarPC skin by idorel77. You can find the skin on GitHub (https://github.com/idorel77/skin.CarPc-Carbon). A helpful thread on Kodi's wiki: https://forum.kodi.tv/showthread.php?tid=320735 .

Once again, the appearance and behaviour of the skin can be customized by editing XML files, graphic resources, and shell scripts. I started from the existing Carbon CarPc GUI, and customized it to my needs, adding the car manufacturer logo, changing icons and colours to my taste, and modifying the behaviour of buttons and labels on the home screen. If you wish to make your own skin, know that Kodi has a large and active community ready to help. I did not find the customization process particularly pleasant or well documented, but with a bit of persistence I could achieve what I wanted. In particular I wanted to customize one button on the home screen to force the FM transmitter to hop to a different free channel. I achieved that by linking the mentioned script to the button, and programmatically change the label of the button to reflect the status of the script execution. When I touch the button, the script is invoked and the button label is changed to "Working...", to let me know the FM transmitter is scanning all FM frequencies in search of a free channel. At the end of the process, the frequency of the selected channel is used as the new permanent label of the button.
This serves the dual purpose of telling me when the script completed its execution, and what channel to tune my car radio to.

The last challenge was how to easily switch between Navit and Kodi at runtime. Well, the easy solution would be to start both programs at boot time, and link a button to the ALT+TAB key combination, to easily switch between the two program windows. Unfortunately, that seems to be either impossible, or too complex to achieve. The problem is that Kodi is designed to be launched in full screen mode and in the foreground. It does not really allow any other full screen application to jump in front of it, and it cannot easily be minimized or maximized. Now, I might be wrong, as I'm not a Kodi expert, but I did not find an easy solution to this problem. Most of the chatter online averts the problem of opening a third party application in front of Kody entirely by suggesting to write a Kodi addon for that application (see stupid idea #1).

So, my final solution was a bit of a hack, but it seems to work. Most of the times. At boot time Navit is started in full screen mode. After a few seconds, Kodi is launched. One of the buttons on the Kodi home screen is labelled "Navigation". All it does is closing Kodi, revealing the Navit window below. If I want to return to Kodi from Navit, I can touch a custom button on the Navit interface that launches Kodi, which again goes in the foreground.

The side consequence of this trick is that I won't be able to listen to music while Navit is in use, but that's life.

I can still blast music from my smartphone via Bluetooth if I want to...

Have fun,
Kradion