Skip to end of metadata
Go to start of metadata

Instructions for interested students

Firstly, welcome to the world of Open Source Automotive! We look forward to welcoming you into our community and a long term fruitful collaboration with participants of Google Summer of Code. This page lists a bunch of ideas that GDP community thought would be a good fit for GSoC but this list is by no means exhaustive, you're more than welcome to suggest a new project.

Now for practical information. First thing you need to do is get in touch with potential mentors and let me them know about your interest. Second, you need to familiarize yourself with GDP and it's community:

  • Please familiarize yourself with GDP overall architecture/components and build GDP Master following instructions. here: . Qemu x86_64 would be the easiest option but if you could get yourself a Raspberry Pi (version 2 or 3) as well, that would be awesome. NOTE: Qemu x86_64 and Raspberry Pi are target systems and not build/development. i-e You're expected to build and develop on a modern (enough) laptop or desktop machine and then run the built GDP image/system on the targets.
  • Since DBus is involved in many of the projects, you're adviced to learn about it and play with it a bit in C++.
  • Sign up for our mailing list:
  • Hang out on our IRC channel as much as possible: #automotive on . Please note that this channels is shared with Automated Grade Linux project.

The IRC and mailing list are also good places for seeking help if/when you get into trouble with anything.

Templates suitable for proposals

While we have a list of suggestions below, we don't want to limit anyone should they have a great idea. We're posting links here to templates suitable for GSoC that a student might use if they have an idea they'd like to submit.

Proposed projects for 2018

GENIVI has been provided a GSoC slot again this year! You can follow our progress in the GENIVI blog here:

Voice command of IVI system

IVI control through speech commands is becoming very common in modern automobiles. It would be really awesome if we can add a working reference implementation and high-level APIs in GDP. The AI part will have to be plugin-based for enabling OEMs to be able to use their own TTS systems. GENIVI member Mycroft's software might be a very good start:

Requirements: Some experience of programming in C/C++ on Linux is required. Experience of Yocto or machine learning would be a huge plus.

Mentors: Jeremiah Foster, Gunnar Andersson

Dynamic, vector graphics for map tiles

Loading map tiles over a slow network connection is a non-starter for automotive, especially when cars need highly detailed maps. Can vector graphics replace tiles for mapping? There already is a project attempting this called Cartagen; "Instead of sending pre-rendered tiles for every zoom level, Cartagen draws maps dynamically on the client side. This means maps can move, adapt, and redraw, and can include as many layers of data as needed. Vector mapping is done in native HTML 5, which runs on the iPhone and the Android platforms, and uses less bandwidth overall." Developing a proof of concept for a GENIVI based system using Cartagen or just using vector graphics for maps ought to be challenging and quite useful to the community.

Potential Mentors: Philippe Colliot

New spin on phone call app

- Implement an innovative automotive phone application app using open-source Bluetooth.
- This serves as an opportunity to test/evaluate and prove the FOSS licensed BlueZ Bluetooth stack using a fully open-source application.  Many current implementations of a full embedded phone application using BlueZ are hidden in proprietary code bases.
- Study and improve BlueZ interoperability with multiple mobile phones.
- Optional: Operate phone calls/conferences also with FOSS licensed VOIP / WebRTC.

Requirements: C/C++ and Qt/QML required, experience of D-Bus a big plus.
Potential MentorsGunnar Andersson

Alternative HMI implementation

Our Human Machine Interface (HMI, the main UI) has been going through some iterations and is expected to continue to evolve. This project is about an experiment in implementing an alternative look and feel. By the end of the project, we'll compare it with our existing HMI (at that time) and if it's better, we'll replace the existing HMI for the new one. We can already compare the design early in the project (or maybe even before the project starts) to ensure that student's work is merged/used at the end of the project.

Requirements: C/C++ and experience of UI development on Linux required, experience of Qt/QML and D-Bus  a big plus.
Potential MentorsJeremiah Foster, Bassem Mohsen

Debian / Ubuntu packaging for GENIVI subsystems

Many companies use Ubuntu as a software development tool in automotive, even if the target system is not Ubuntu. Since DLT is often a prerequisite for other GENIVI components, having it already on your development system means easier to build GENIVI software and easier to compose virtual machines and docker instances. The work is fairly straight forward and there is even a bug in Debian for this:;msg=5 Adding additional subsystems, namely lifecycle management and persistence would expand the foundation of a GENIVI-like system.

Requirements: Some experience of Debian packaging is useful, but can be learned. Some experience of building software. Understanding of the role of a open source maintainer.

Potential MentorsJeremiah Foster, Oscar Andreasson

QEMU test suite 

Test suite for GDP and / or yocto based baseline. (More detail coming.)

Potential MentorsJeremiah FosterStephen Lawrence

WAMP connector

(More detail coming.)

The content below was for GSoC 2017

Incorporate Zebra into GDP for HTML5-based UIs

Zebra is a very attractive HTML5-based UI framework:

This will be an experiment in allowing creation of UIs for GDP, based on HTML5 rather than Qt. If the actual performance (e.g on Raspberry Pi) is good, we can even consider making it the default UI framework on GDP.

Yocto Grok

The Yocto (OpenEmbedded) build system is heavily used in various embedded system but it frequently builds hundreds of packages and is by many considered quite complex. Although Yocto has many features, the ability to "grok" (tech-speak for "understand") the final system could be improved:
- From license perspective (FOSSology integration?)
- From system content perspective (What components are there, what constitutes libraries and executables, and are there parts that are being built and included, unnecessarily?)
- Some existing reports, such as a complete dependency graph generation using graphviz/dot generally end up way too large and unreadable.
- Goal:  Extend Yocto reporting with summaries, statistics and graphs and user-friendly tools:  "Where is this file coming from, and why?"

Requirements: Python and basic knowledge of compilers (e.g gcc) on Linux. Experience of data-processing, statistics, graphing libraries and Yocto/OpenEmbedded a big plus.

Integrate latest open source tech in Navit

GDP makes use of Navit for navigation as part of it's Location Based Services. Navit, while still very much alive project, hasn't caught on with some of the latest tech in the open source world, like Geoclue2 and geocode-glib. Also it uses some old and unmaintained tech, like gypsy. The main task here would be to integrate these new techs to Navit and dropping use of old tech. Currently Geoclue2 doesn't support standalone GSP devices (only modem-based) so a secondary task would be to add that support (it's not at all as hard as it sounds).

: C/C++ on Linux required, experience of D-Bus and geospacial techs a big plus.

  • No labels


  1. Debian / Ubuntu packaging for Diagnostic Log and Trace

    I'm sorry to say but this feels like a really small piece of work for a GSoC. I think it could be expanded on though... Creating a repository and/or getting everything pulled into mainline fedora/debian/ubuntu and making DLT etc available for all of them would be a bigger task imho. It's a cross-domain task with a lot of administration work and socializing mainly though which I think could be interesting, you'd get to understand the bureaucracy of several large scale projects if nothing else. 

    1. > I'm sorry to say but this feels like a really small piece of work for a GSoC. I think it could be expanded on though

      I agree.  Instead the topic should be to create packaging for a number of components, and to set up the structure to make that more repeatable, perhaps even somewhat automated.

      > you'd get to understand the bureaucracy of several large scale projects if nothing else

      Yes.  And/or the student can investigate alternatives.  It's not always required to store packages in some official place for a distros if it turns out to be difficult (which I'm not agreeing it is, but under the assumption that you are right).  Most distros support adding third-party package repositories I mean.