GSoC 2011
On this page... (hide)
1. About GSoC
Google's summer of code is now in its 7th year, funding student positions over the summer, working with various open source development projects producing code that benefits everyone. GSoC will put up $5000 US to cover the wage of a student during the period between the end of May and the end of August. Students who are interested in participating should scan through the GSoC FAQ for information about the program and how to apply, and scan through the "Project Ideas" listed below for potential projects they might participate in. Or, propose a project of your own and attach it to your application.
Since the deadline is quickly approaching, we are asking students interested in working with Komodo to submit a 2-4 page proposal to the GSoC site at http://www.google-melange.com/gsoc/org/google/gsoc2011/komodo using the template below:
- Summary
- Proposed Design
- Proposed Implementation
- Proposed Timeline (with milestones/deliverables)
- Full contact details (including skype, irc or other IM handle)
Please include a link to your resume on your proposal. Once you have made the submission, please let us know by sending an e-mail to info[at]komodoopenlab[dot]com or through our contact form here: http://komodoopenlab.com/contact/
If time allows, we will be providing feedback in the form of comments on your proposal page, so check back every few hours to see if we have managed to review it.
1.1 Important Dates
- Mentoring Organisation Applications February 28 to March 11
- Student Application Period March 28 to April 8
- Accepted Students Announced April 25
2. About Komodo OpenLab
Komodo OpenLab is a research and development lab specializing in the creation, adaptation and support of open and inclusive technologies that facilitate the daily lives of people with disabilities, while also benefiting everybody else.
Starting in 2011, Komodo will be working with the Inclusive Design Institute (IDI) in the ongoing development of two projects: Tekla (started with GSoC 2010) & tagin!. The goal of the IDI is to ensure that information and communication technologies are designed to be accessible and usable by the full range of human diversity from the very beginning. This is fully in line with the goals of Komodo OpenLab so we are very excited about the chance to work with the IDI!
3. Project Ideas
3.1 Tekla Project Ideas
(1 position available) Mentor: Jorge Silva
Tekla is a collection of mobile open source and open hardware applications that may be used to enable access to, and extend the functionality of, mobile devices for people with motor impairments.
Our initial goal is to enable access to mobile devices through the same interfaces that powered-wheelchair users employ to move around, thus allowing them to easily select between controlling their wheelchair or controlling their mobile device.
Students submitting ideas for the Tekla project should sign up to the development mailing list at: https://launchpad.net/~meadl-devel
Tekla Android App screenshot
Tekla plug-in framework for 3rd-party apps
Difficulty: moderate
The Tekla Android App is great for basic access to Android devices, but we would like to be able to share the love to 3rd-party applications so open and closed-source developers alike can make their apps fully accessible to people with mobility impairments. The Tekla Android App is currently made up of the Switch Event Provider (SEP) and the Tekla Input Method (IME). The SEP is a service responsible for (i) managing the Bluetooth connection with the Tekla Shield, and (ii) broadcasting switch events to the Android operating system. The IME, in turn, listens to the events broadcasted by the SEP and turns them into emulated keyboard inputs. However, this broadcast-based notification of switch events does not yet allow for 3rd-party applications such as games, to temporarily process switch input directly (i.e., by-passing the IME). We need to design and code a policy to allow 3rd-party applications to request and receive direct processing of switch events from any other application or from the IME. This will likely involve transforming the SEP into a manager able to selectively deliver switch events to specific applications.
Successful candidate students will have experience in Android development as well as a strong grasp of key Android concepts such as services, broadcasts/intents and service binding.
Schematic diagram of Tekla user case
Accessible, cross-platform slide presenter app
Difficulty: moderate
We would like to take advantage of the touch-free access to Android provided by the Tekla App and Tekla Shield in order to create an accessible, cross-platform slide-presenter app that allows anyone, but particularly Tekla users, to control slide presentations on Windows, Mac OS and/or Linux. This will most likely involve the adaptation of an already active open-source project like Gmote in order to ensure usability and accessibility for Tekla users.
Successful candidate students will have experience in Android and/or Java development as well as working knowledge of cross-platform desktop application development tools.
BlackBerry application support for Tekla Shield
Difficulty: moderate
Blackberry devices provide serial port profile (SPP) support for external bluetooth devices and it turns out SPP is the protocol the Tekla Shield uses to enable people with mobility impairments to access Bluetooth-enabled devices using their personally adapted assistive technologies. Therefore, it is possible to port some of the functionality provided by the Tekla Android App to Blackberry.
Specifically, this project will involve implementing a Switch Event Provider (SEP) service on Blackberry that applications can use to receive Tekla Shield commands, and thus become accessible to people with mobility impairments. The SEP service will (i) have the ability to establish an SPP connection to a nearby Tekla Shield, (ii) perform basic input processing tasks on the phone (e.g., wake and unlock phone), and (iii) broadcast switch events to interested applications on the operating system.
Successful candidate students will have experience in BlackBerry development, basic knowledge of serial port communication, and familiarity with porting applications from Android to Blackberry.
Screenshot of tagin! Android
demo app
3.2 tagin! Project Ideas
(2 positions available) Mentor: Jorge Silva
tagin! is an open source, location tagging engine that may be used to create indoor, location-based services (LBS) and applications. Developers can use tagin! to manage points of interest (POI) and digital signs making them available to their applications on WiFi-capable devices.
Students submitting ideas for the tagin! project should sign up to the development mailing list at: https://launchpad.net/~tagin-devel
Indoor Geocaching Game
Difficulty: hard (but fun)
Our tagin! indoor positioning engine works very well with up to room-level accuracies. However, we have a small problem: knowing where you are is not all that exciting for most people after the first 5 minutes. However, this information is still very useful for people with visual impairments, so we need to come up with a clever way to encourage everyone to use the tagin! engine to describe indoor locations so blind folks can reap the benefits. One idea we would like to explore is to create a simple mobile app that implements an indoor version of geocaching. The game would be designed to reward gamers who hide lots of caches in a building as well as gamers who accurately describe the location of any cache they find (hidden goal: ensure the location database is up to date).
Since this is a bit of a complex project, we are dividing it in two stages summarized below:
Hidding the cache
Hidding the cache will involve two steps:
- Recording the cache's location, and
- Fingerprinting the cache
Geocaching introductory video
The first thing a player hiding a cache should do, is to record the location where the cache will be hidden. This location will be based on the XMPP user location standard up to room-level accuracy. A wizard will guide the player to add buildings, floors, areas and rooms. We want to be able to do this offline as much as possible, so local data storage and cloud syncing will be required.
The next thing the player will have to do is 'fingerprint' the cache, which involves matching the previously recorded location information with the pattern of WiFi signals visible at the place where the cache is hidden. We already have the fingerprinting algorithms available on Android, so all we need for this part is the local storage and cloud syncing code.
Finding the cache
Finding the cache will involve three steps:
- Searching for previously hidden caches nearby,
- Track a cache, and
- Confirm the location of the cache
A player interested in finding a cache should be able to retrieve a list of previously hidden caches by proximity (proximity as defined through GPS or by manually entering a location). Once a particular cache is selected, the application will allow the user to track it, this may include a 'radar' or 'hot & cold' view that lets the user know how close or how far he/she is from the hidden cache. Once the cache is found, the user will confirm the find to the game server, and at that point, the app will submit a fresh fingerprint that may be used to update the positioning engine database (trick borrowed from 'reinforced learning' in artificial intelligence).
Please Note:
We don't expect to complete this project over the summer, but we should be able to get something functional off the ground. If you wish, you can focus on either the server or the client Android app.
Successful candidate students focusing on the server will have experience in the implementation of RESTful frameworks such as bottle or flask, data exchange protocols such as JSON and database engines such as PosgreSQL.
Successful candidate students focusing on the client Android app will have experience in Android development, as well as familiarity with data exchange protocols such as JSON and database engines such as SQLite.
In both cases, experience with the usual (outdoor) geocaching will be considered an asset.
4. Frequently Asked Questions
4.1 Can I propose a project that is not in your ideas page?
Answer: Definitely!, we are quite sure we couldn't possibly think of all of the best ideas on our own, but be aware that the project ideas described in this page reflect (more or less) our priorities, so your idea would have to be somewhat related or would really have to impress us in order to get picked. In any case, if you send a draft early, we can help you shape it into something that would be useful for the projects (if not already).
4.2 Do I need to have an Android / BlackBerry / iPhone / iPad?
Answer: Not necessarily, but it would make things a lot easier if you did have access to the device you are interested in working on. The main issue to consider is that since both the Tekla and tagin! projects rely heavily on hardware peripherals such as Bluetooth and WiFi, it may not be possible to fully test your code with the emulators provided on the SDKs. However, if like Linus Torvalds you believe you can write perfect code on your first try, then we definitely want you on the team even if you don't have the device, so do apply!
4.3 I am applying to Tekla, do I need access to a Tekla Shield?
Answer: No, Tekla provides a very simple API that can be easily emulated. In fact, we do have a bare-bones python script that can turn you bluetooth-enabled PC or laptop into a fully featured Tekla Shield emulator, so go ahead and submit your proposal, don't let the lack of access to the Tekla Shield stop you!
4.4 Would you accept a hardware development project?
Answer: Not really. Unfortunately, the Google Summer of Code program does not support projects with a heavy hardware development component. You can definitely work on hardware development as part of your project, but the hardware component cannot be the main focus of your proposal, nor should it be required for your final product to work.