Login

Introducing MeeGo IVI: Ignition Switch

MeeGo isn’t just for netbooks and smartphones. The In-Vehicle Infotainment (IVI) branch might someday power the computer system on your automobile.

This article was written by Nathan Willis, a freelance journalist who writes about Linux and open source technologies. It was originally published by - and comes courtesy of - http://www.smart-developer.com/.

The MeeGo project [1] launched in February of 2010, when it was widely described as the “merger” of two existing consumer-oriented Linux distributions: Intel’s Moblin, which targeted low-resource netbooks, and Nokia’s Maemo, which was designed for smartphones. Nokia’s recent decision to back-burner its own MeeGo smartphone strategy has left many to speculate on the future of the MeeGo project; however, MeeGo’s modular design means it isn’t limited to just smartphones and netbooks.

MeeGo is a highly compliance driven Linux project designed to produce a base platform for all sorts of embedded Linux products while remaining as close as possible to compatibility with “standard” desktop Linux distributions. Central to MeeGo’s design is its separation of the core OS from the “user experience” (UX) component; the handset and netbook UXs are just two possibilities.

Handsets, tablets, netbooks, set-top devices – any device “running MeeGo” will be API- and ABI-compatible with any other MeeGo device of the same generation. The goal is to give device OEMs a stable platform to build on and, just as importantly, to open the door for Linux applications to run on a wide assortment of unconventional computing devices. Why should users have a different set of apps to run on their Internet-connected TV and smartphone? And if you are an app developer, why should you have to develop for two different middleware stacks when they’re both Linux under the hood?

For the first six months of MeeGo’s existence, the developers had little to show for this vision of a universal platform because the only two companies doing visible UX work were Intel and Nokia, developing their respective netbook and handset UXs. The grander vision started to come into focus in late 2010, when the next MeeGo target platform started to emerge: in-vehicle infotainment (IVI).

If the word “infotainment” makes you shudder, don’t worry: I’m just talking about car computers. But the term reveals one of the major challenges of IVI as a computing UX: People anticipate a variety of unrelated, sometimes conflicting services in one operating system. Most people are familiar with the “big two” applications in front-seat, driver-facing IVI dash units – audio players and navigation – but MeeGo IVI has a broader scope, including rear-seat entertainment and integration with other vehicle services, like engine sensors, backup cameras, and roadside assistance services. Carmakers are already integrating these services (and more) into their vehicles. MeeGo’s creators hope to speed up product development and lower costs by using one Linux-based platform to run all of the components that support IVI.

IVI (Figure 1) is a very different beast from MeeGo’s netbook and smartphone UXs. The IVI UX was built from scratch, rather than transitioning from an existing project like Maemo or Moblin. But IVI also does not have a single hardware vendor setting its roadmap and driving its development, and that creates a big opportunity for the open source community.

{mospagebreak title=The MeeGo IVI Architecture}

MeeGo IVI sells itself to embedded vendors using the two principles of ABI/API stability and “upstream first” compatibility with the desktop Linux stack. The MeeGo Core architecture [2] (Figure 2) consists primarily of frameworks Linux developers will already be familiar with: the Linux kernel, PackageKit, RPM, D-Bus, BlueZ, Telepathy, PulseAudio, Gstreamer, Tracker, GeoClue, ConnMan, Qt, Xorg, and so on. MeeGo tries to maintain a minimal set of changes to the upstream components, focusing on delivering a stable baseline platform with each release and running a compliance program for vendors [3].

This model has worked well for the first two releases, 1.0 in May of 2010 and 1.1 in October. Understandably, both of those releases focused heavily on the existing Netbook and Handset UXs. Each release included an ISO image installable on compliant hardware devices and an example interface complete with a set of functional applications. The netbook UX functions much like any other portable Linux distribution, and the handset UX features some smartphone-only apps like a touch-friendly contacts manager and phone dialer, both integrated with the oFono open source telephony library.

IVI test images were released at the same time, though, for a limited set of compatible systems based on Intel Atom chips. The IVI release sported two custom apps, a dash-friendly “home screen” app designed to serve as a launcher and information screen, and a task manager specially designed to meet driver safety requirements. IVI also packaged a suite of open source automotive applications, including the Navit mapping and navigation tool.

Under the hood, the IVI release features far more customization than just a handful of apps, and still more changes are to come in future releases. 1.1 not only included touch screen support but also introduced support for dial-based scroll wheel controllers, such as those found in head units and on steering wheels. IVI also included the first text-to-speech (TTS) support in MeeGo with the Festival speech synthesis engine, along with speech recognition based on PocketSphinx.

Together, these three components for the key to building street-safe applications for vehicle deployment, but they are just the beginning. At the 2010 MeeGo Conference in November, IVI Working Group chair Rudolf Streif outlined additional points where IVI requires changes to the MeeGo hardware and software stack. These objectives include extending several existing components in ways that the other UXs do not need, such as adding support for multi-screen management to the video stack (think front-seat navigation screens plus rear-seat entertainment screens) and corresponding multi-zone audio work (Figure 3). See the box titled “IVI To-Do” for more on proposed new features and capabilities.

{mospagebreak title=Getting Started with MeeGo IVI}

So, if you’re an application developer interested in writing for MeeGo IVI today, how to you get started? Although the MeeGo doesn’t yet have an IVI-specific SDK, you can use the existing MeeGo SDK and build system to roll out your first IVI project.

The current release of the MeeGo SDK is version 1.1 [5]. The MeeGo project publishes the SDK through Apt and Yum repositories, and it has officially validated MeeGo on the latest 32-bit versions of Fedora and Ubuntu. Other distributions might run it just fine; the wiki maintains a compatibility list [6]. To install the SDK, you can simply add the MeeGo repository to your package and management system, import the repository’s GPG key, and select the meego-sdk package. meego-sdk is a meta-package that includes the QtCreator IDE, ARM and x86 toolchains, the MADDE (Maemo Application Development and Debugging Environment) cross-compiler, the QEMU emulator, and a set of QEMU images for the various MeeGo UXs.

Next, you can install a build target. Currently, the best option is to use the handset UX target, because it bears the most similarity to IVI – namely the reliance on touch-screen as opposed to hardware keyboard input. You make the target using MADDE. Run sudo mad-admin create -f meego-handset-ia32-1.1 to fetch the Handset-specific sysroot and create the target. You can check that the target installation was successful by building the QTHello demo program:

The next step is to install a MeeGo run time for QEMU if you intend to test on your development system. (If you intend to test on actual hardware, this step isn’t necessary, of course.) Here again, MADDE simplifies the process. Run mad-admin list runtimes to get a list of the available run times. The command sudo mad-admin create -f -e meego-handset-ia32-qemu-1.120101031.2201-sda-runtime (substituting the most recent version of the run time) fetches and installs it. Then, you can launch it in QEMU with sudo mad remote -r meego-handset-ia32-qemu-1.1.20101031.2201-sda-runtime poweron.

Finally, you need to configure QtCreator to use the MeeGo toolchain. Open Tools|Options|Qt4|Qt Versions and click on the Plus button to add a new Qt version. You will need to specify the full path to MADDE’s version of qmake; in this example, the path is /usr/lib/madde/linux-i686/targets/meego-handset-ia32-1.1/bin/qmake.

Creating a New Project

You can start a new MeeGo app project in QtCreator with the project wizard (Figure 4). From the File menu, select New File or Project, and QtCreator presents you with a series of templates from which to choose. Most mobile apps fall under the Mobile Qt Application and MeeGo Touch Framework Application templates. If you are unsure, choose Mobile Qt Application; the Touch framework is primarily for cutting-edge development on touch interfaces that have not yet made it into the official MeeGo APIs. You can then select one or more build targets for your application – the list inside Qt Creator is pre-populated with the MADDE targets you installed earlier. Last but not least, you can customize the skeleton files generated for your new project and add them to a version control system before you begin.

The MeeGo 1.1 API [7] is based on Qt and Qt Mobility, plus OpenGL ES versions 1.1 and 2.0. Additionally, the MeeGo Platform API is available but not recommended for general development; it consists of the in-progress Touch Framework and lower-level libraries like Gstreamer, PulseAudio, and Qt Web run time. If you are comfortable with these warnings, the developer documentation is available on the MeeGo wiki [8].

Qt provides two service frameworks for general GUI applications: QtGui and QTDeclarative (also known as Qt Quick). QtGui you are probably already familiar with, as it contains common C++ classes for applications, widgets, file access, events, and visual styles. Qt Quick uses the JavaScript-based QML markup language instead, which makes customizing the interface simpler and does not require coding in C++.

Qt also provides the D-Bus and network communications interfaces, WebKit browser engine, SQL database support, and high-level OpenGL and SVG support. MeeGo’s API lacks support for the full QT 4.7 standard, particularly when it comes to the Phonon library, QtOpenVG, QtDesigner, Qt3Support, and several of the testing tools.

MeeGo 1.1 does support the full Qt Mobility API, however, including PIM support, Messaging, Multimedia, the hardware Sensors API for detecting screen orientation, the Location API for GPS and other positioning information, and the Publish-and-Subscribe framework for notifications.

To familiarize yourself with the cross-compilation toolchain, you can build a simple “hello world” app using Qt Mobility to grab some system information. Place the code in Listing 1 in your new project’s main.cpp.file.

This code grabs the current language setting from QsystemInfo and displays it on screen. To build it as an application, you must also add (not overwrite…) two lines to the .pro project file:

CONFIG +- mobility
MOBILITY +- systeminfo

The first line tells qmake to process the Qt Mobility config script; the second tells the build script to link to the SystemInfo library. To compile the app into an RPM package, select Build Project from the Build menu.

If you are testing in QEMU, however, you need to configure access to the QEMU virtual device before you can run the app in the emulator. Go to Tools|Options|Projects|MeeGo Device Configurations in QtCreator. Click Add to create a new device. Choose the Meego emulator device type, select password authentication, and use root and meego as the username/password combination (Figure 5). Also make sure that the emulated device uses 127.0.0.1 as its hostname, and TCP port 6666 for SSH. The emulator redirects this connection to port 22 on the emulated device, so you can ssh into the device with ssh root@127.0.0.1 -p 6666. Click Apply to save your settings.

You can now run the app by switching to QtCreator’s Projects tab and selecting the MeeGo target. Under Run, you can choose the QEMU virtual device you just set up, then click on the Run toolbar button to run your app in the emulator.

For now, you will have to make do with the MeeGo Handset UX target, which is less than ideal for IVI, but it is a start. The MeeGo developer documentation is thorough particularly when you can supplement it with Qt and Qt Mobility docs from Nokia. Fortunately, MeeGo mandates that all UXs branded with a particular version number are API and ABI compatible, so the 1.1 SDK will at least build supported apps when you use the Handset target. You just don’t get the IVI home screen and taskbar in the emulator. Thanks to the compliance guarantee, though, you can package your app in QtCreator and install it manually on an Atom-based netbook running the MeeGo IVI 1.1 release – that give you as close to a real-world in-vehicle test platform as you can currently get.

{mospagebreak title=The Path Ahead}

MeeGo IVI is still in its infancy, but that means now is the perfect time to get involved. As it stands, carmakers that include a IVI system generally do so only in their higher end models; until now, they had to roll their own solutions. If you want to get more involved, you can join the MeeGo IVI mailing list and discussion forum [9]. Also, visit MP3Car.com [4], the largest DIY site for car computer enthusiasts. A MeeGo IVI section exists on the MP3Car discussion boards, and many of the developers who have spent the past few years adapting open source code for their DIY systems are starting to explore porting their code to MeeGo’s IVI UX.

Because the MeeGo project is tasked with delivering the platform and an example user interface (meaning individual carmakers will almost certainly add their own custom designs to the products they deploy), this community work is likely to be the best showcase for open source IVI. Considering the average product cycle, it will certainly beat carmakers’ custom builds to the market. Finally, follow the progress of the roadmap by watching the IVI feature request trackers in Bugzilla [10].

See the box titled “The Roadmap” for more on the MeeGo IVI work in progress. Apart from official SDK components like an IVI target and QEMU runtime image, the next major milestones in the project will be the 1.2 release and the San Francisco MeeGo Conference in May of 2011. The past few months have seen a growing list of carmakers and tier-one automotive suppliers come on board, so the months ahead are guaranteed to be a wild ride.

IVI To-do

on the list of changes for IVI are new components, such as the speech recognition and speech synthesis, acoustic echo cancellation, noise suppression for hands-free phone usage, and integration with new types of hardware, such as back-up cameras and door sensors. IVI systems also must contend with extremely fast boot requirements and initializing devices within milliseconds of ignition, not to mention rapid shut-down sequences – and the “loaf of bread” scenario. Suppose you start your car in the grocery store parking lot, then remember that you forgot to grab a loaf of bread, so you shut down the car and go back inside. The computer has to boot up and begin initializing with the ignition switch and then start the shutdown cycle when you change your mind. But, you can’t simply speed up boot time by pushing more system maintenance to the shutdown cycle: Getting the bread takes less than a minute, at which point the computer must be fully shut down and ready to boot again, or else the system is in an undefined state.

Additionally, vehicle manufacturers are interested in using MeeGo IVI to support vehicle telematics, which means an entire layer of engine sensors and instruments will need a new set of APIs, plus logging, diagnostic, and emergency assistance applications.

Adding still more complexity to the design is the fact that vehicle makers already use industry-specific communications buses to relay this sort of information and to connect rear-seat entertainment unites to driver head units and media storage. Several such buses are currently in deployment, like FlexRay, Media Oriented Systems Transport (MOST), and Controller Area Network (CAN) – and with few exceptions, the standards involved are not open or royalty-free. Fortunately, the industry partners participating in the MeeGo IVI project can exert some friendly pressure on the standard owners, most of whom simply aren’t familiar with the open source way of working – but the challenge of coding and testing the new components, remains.

The Roadmap

As daunting as the IVI challenge might seem, the developers are making progress. The IVI Working Group is tasked with interfacing with the carmakers, automotive suppliers, industry groups, and the open source developer community. One of the goals is to organize the list of requirements into a prioritized, manageable roadmap. The Working Group operates in the open on the IVI mailing list, even posting its meeting minutes publicly on the project wiki, so application developers can easily follow the plan.

Exactly how much of this work will make it into the next release of MeeGo remains unknown; version 1.2 is scheduled for a late April release. Fortunately, more developers are joining in the effort. Automotive product developers Pelagicore and GENIVI have both announced their involvement with the project.

Pelagicore has already started contributing to Qt for IVI, an extension to the Qt application framework. Currently, the project adds Terminal Mode to support to MeeGo, which links the automotive head unit (video screen, audio layer, and input devices) to a tethered device such as a Bluetooth phone, with VNC or other remote desktop protocol. The user can then access the phone’s address book, the mapping system, or other apps through the car’s front end, presumably reducing any driver distraction that would arise from fumbling for the phone.

This functionality is split into two parts: libqterminalmode provides the remote connection functionality, while qterminalmodeclient provides the forward-facing interface. Additional APIs that are under development but not yet released in Qt For IVI include integrating radio tuners and video cameras. Both of these features are hardware supported in upstream Qt but are so far not supported in MeeGo itself.

The other major to-do item for MeeGo IVI is building up a development kit. At the MeeGo conference, project manager Joel Clark solicited feedback from application developers for an IVI-specific software development kit (SDK); at the moment, the project recommends that independent IVI developers get started with the existing MeeGo SDK – the same core APIs are available on all UXs, and you can add additional components like Qt For IVI to test systems manually.

Although an SDK should be possible by the 1.2 release, the picture is a bit murkier on the hardware development kit front. The ISO releases work on common Atom-based netbooks, but getting independent developers working on actual in-vehicle systems will require expanding the supported hardware considerably. Most do-it-yourself car computer enthusiasts run mini-IT systems, often with cheaper, non-Atom CPUs and onboard graphics, and for now all MeeGo builds require support for the SSE3 instruction set and Intel graphics chips.

Because AMD recently joined the MeeGo project, wider CPU and GPU support is on the way. Another possibility is the ARM architecture; the IVI Working Group is looking into development kits based on BeagleBoard or PandaBoard single-board computes running on Texas Instruments OMAP processors.