Progetti d'esame

Ci sono due modi per scegliere il progetto d'esame:

  1. Gli studenti propongono un progetto e lo sottopongono all'approvazine del docente prima di iniziare;
  2. Gli studenti selezionano uno dei progetti proposti dal docente in questa pagina.

In entrambi i casi gli studenti svolgeranno poi una prova orale durante la quale presenteranno il progetto realizzato.

Progetti proposti dagli studenti

I progetti proposti dagli studenti devono avere queste caratteristiche.

  • Il sistema deve essere innovativo:
    • devono risolvere un problema nuovo oppure
    • adottare una soluzione nuova ad un problema noto oppure
    • (meno rilevante) applicare una soluzione esistente ad un settore nuovo oppure
    • (TOP) implementare una soluzione proposta in letteratura scientifica producendo nuovi risultati scientifici (es: da confrontare con quelli esistenti in letteratura)
  • Devono essere proposti sistemi che includono una componente tipicamente per dispositivi mobili:
    • Es: il porting da web a mobile senza aggiunta di funzionalità tipiche del mobile non va bene
  • La soluzione proposta deve essere sofisticata: devo includere almeno una delle tecniche avanzate che presenteremo durante il corso oppure altre tecniche, magari non introdotte nel corso, ma valutate come sofisticate dal docente.

 Per richiedere l'approvazione al docente, si devono comunicare i seguenti dati (sarà fornito un template di documento da compilare):

  • Nome del progetto e nomi dei proponenti
  • Quale problema vuole affrontare il sistema che si intende realizzare (1 paragrafo)
  • Descrizione di massima della soluzione proposta (1 paragrafo)
  • Elenco delle funzionalità principali (ciascuna con una brevissima descrizione, es: 1 riga).
  • Elenco delle funzionalità avanzate (es: trattate nel corso) che saranno implementate
  • (se pertinente) quale server esistente sarà usato / necessità di sviluppare il server
  • (se pertinente) riferimenti all’articolo scientifico oggetto dello studio

 

Progetti proposti dal docente

Ogni progetto proposto dal docente ha un "project coordinator" che si occupa di fornire le specifiche del progetto stesso. Gli studenti che scelgono di svolgere un progetto proposto dal docente dovranno mettersi in contatto con il project coordinator per comprendere i dettagli del lavoro da svolgere e per contattarlo, durante la fase di sviluppo, per eventuali chiarimenti e per mostrare, se ritenuto necessario dagli studenti, lo svolgimento del lavoro. In generale gli studenti non dovrebbero contattate il project coordinator più di due/tre volte durante lo svolgimento del progetto, salvo casi particolare (es: se sussistono dubbi sul lavoro da svolgere). Nel caso in cui il project coordinator non parli italiano, gli studenti dovranno comunicare in inglese e dovranno fornire l'app e la documentazione in inglese. Al termine del lavoro svolto, prima della discussione con il docente, gli studenti dovranno mandare il progetto e la relativa documentazione al project coordinator, che fornirà un giudizio informale al docente. La valutazione ai fini dell'esame rimane in ogni caso a carico del docente.


Project name: SKIstream
Project coordinator: James Coughlan - Smith-Kettlewell Eye Research Institute
Number of students: 1 for the base project, 2 for the advanced version

Context and problem: in order to support the research activities at the Smith-Kettlewell Eye Research Institute, there is the need for an iOS application that collects sensor data and streams it in real time to a desktop app written in Python. The entire system is designed to be used by a researcher (not the general public), so the focus is on personalization and performance, rather than on UX.

General description: the iOS app should collect sensor data, including those coming from inertial sensors, camera and AR libraries. This information should be encoded in a format (defined and documented by the student) and then sent over the network to a Python library that should expose this data to a Python app. As a proof of concept, a Python app should be developed that just logs the data and optionally stores them on the hard drive.

Main functions. On the iOS app: acquire the data, allow the user to finely tune which data should be acquired, at which frequency and, where applicable, at which granularity (e.g., frame definition…). All possible sources should be considered, in terms of physical and virtual sensors, as well as data from ARKit (this will be clarified). The Python library should receive the data and make it available to an app that uses the library. One possible solution is to use an observer pattern (but the student can propose a different approach).

Advanced functions. The system implements a producer-consumer pattern with (possibly unreliable) network connection between the producer and the consumer. In the basic version, a naive approach can be used to manage synchronization e.g., in case network connection is too slow, the produces buffers the data to be sent, hence resulting in the consumer receiving them with some delay. In the advanced version of the project, different approaches should be possible, including, for example, that some types of data (e.g., video frames) can be marked as "droppable", meaning that the system automatically drops old data that has not been sent yet.


 

Project name: 3D graph viewer
Project coordinator: James Coughlan - Smith-Kettlewell Eye Research Institute
Number of students: 1
Context and problem: Researchers at the Smith-Kettlewell Eye Research Institute are investigating new approaches to 3D data visualization using augmented reality.

General description: an iOS application takes in input a CSV file that contains a set of points in 3D and then plots them as a 3D scatterplot in AR. Example 1 (consider only the scattered diagram). Example 2

Main functions: load a file hardcoded in the project or from a shared folder (like dropbox), allow the user to specify some visualization options and plot the file content in AR. The CSV file may contain optional RGB color and symbol size parameters, to specify the size and color of each data point if needed.


Nome del progetto: Annotazione temi musicali
Coordinatore: Luca Ludovico - Laboratorio Informatica Musicale
Numero di studenti: 1 or 2 (almeno uno con competenze musicali)
Obiettivo del progetto: realizzare un prototipo mobile per l’annotazione rapida di temi musicali. Il prototipo può essere realizzato mettendo a disposizione dell’utente controlli per annotare i parametri musicali principali (altezza e durata delle note, inserimento delle pause, eventuale griglia armonica), oppure interpretando input vocali nella forma di semplici melodie. L’applicazione deve includere i controlli per la riproduzione del tema inserito.


Nome del progetto: AR musicale

Coordinatore: Luca Ludovico - Laboratorio Informatica Musicale
Numero di studenti: 1 or 2 (anche senza competenze musicali)
Obiettivo del progetto: realizzare un prototipo mobile per un gioco musicale in realtà aumentata. L’applicazione deve permettere all’utente di identificare delle zone sensibili nell’ambiente fisico e riconoscere quando l’utente stesso vi entra. A tali zone vengono associati dei suoni da riprodurre.