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. i-e 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: https://at.projects.genivi.org/wiki/display/GDP/GDP+Master . 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: https://lists.genivi.org/mailman/listinfo/genivi-projects
- Hang out on our IRC channel as much as possible: #automotive on irc.freenode.net . Please note that this channels is shared with Automated Grade Linux project.
The (especially) IRC and mailing-list are also good place for seeking help if/when you get into trouble with anything.
IVI controls through Speech commands
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 (potentially proprietary) backends.
Requirements: Some experience of programming in C/C++ on Linux is required. Experience of Yocto or AI/neural networks would be a huge plus.
Incorporate Zebra into GDP for HTML5-based UIs
Zebra is a very attractive HTML5-based UI framework: http://www.zebkit.com/
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.
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 Mentors: Gunnar Andersson (old account), Zeeshan Ali
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.
Potential Mentors: Gunnar Andersson (old account)
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 Mentors: Zeeshan Ali, Bassem Mohsen
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).
Requirements: C/C++ on Linux required, experience of D-Bus and geospacial techs a big plus.
Potential Mentors: Zeeshan Ali, Philippe Colliot