AIRWiki - User contributions [en]

Brain-Computer Interface

2010-04-02T14:46:56Z

BernardoDalSeno: /* Publications */

[[Category:Research Topic]]
This research topic belongs to the research area [[belongsToArea::BioSignal Analysis]].

A Brain-Computer Interface (BCI) is an experimental communication system that allows an individual to control a device by using signals from the brain (e.g., electroencephalography -- EEG).

Click [http://airlab.elet.polimi.it/index.php/airlab/research_areas/affective_computing here] for a brief description of the Research Area, taken from the AirLab website.

==Ongoing Projects==

Projects on this topic:

{{#ask: [[Category:Project]][[prjResTopic::{{PAGENAME}}]][[PrjEnd::>{{CURRENTYEAR}}/{{CURRENTMONTH}}/{{CURRENTDAY}}]] |format=ul}}

== Project proposals ==

{{#ask: [[Category:ProjectProposal]]
[[PrjResTopic::{{PAGENAME}}]]|
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
?PrjLevel |
?PrjType |
format = template |
template = Template:ProjectProposalViz
}}

==Finished Projects==

{{#ask: [[Category:Project]][[prjResTopic::{{PAGENAME}}]] [[PrjEnd::<{{CURRENTYEAR}}/{{CURRENTMONTH}}/{{CURRENTDAY}}]]|format=ul}}

* [[A genetic algorithm for automatic feature extraction from EEG data]]
* [[Graphical user interface for an autonomous wheelchair]]
* [[Online automatic tuning of the number of repetitions in a P300-based BCI]]* [[Predictive BCI Speller based on Motor Imagery]] (Master thesis, Tiziano D'Albis)
* [[Feature Selection and Extraction for a BCI based on motor imagery]] (Master thesis, Francesco Amenta)
* [[Integrating Motor Imagery and Error Potentials in a Brain-Computer Interface]] (Master Thesis, Paolo Calloni)
* [[Ocular Artifacts Filter implementation for a BCI based on motor imagery]] (First Level thesis, Fabio Beltramini)
* [[Reproduction of an algorithm for the recognition of error potentials]]
* [[Online P300 and ErrP recognition with BCI2000]] (Master thesis, Andrea Sgarlata).
* Tesi di Carlo Gimondi e Luisella Messana
* Tesi di Gianmaria Visconti
* Tesi di Francesco Cartella

== Equipment ==

* [[Electroencephalographs]]

== How to ==

* [[How to mount electrodes]]
* [[How to setup BCI software]]

== Publications ==

You can find other publications in the BCI field by AIRLab members involved in this topic (see above) on their home pages.

=== Journals ===
B. Dal Seno, L. Mainardi, and M. Matteucci. [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5256301 The Utility metric: A novel method to assess the overall performance of discrete brain-computer interfaces]. ''IEEE Transactions on Neural Systems and Rehabilitation Engineering'', pages 20-28, February 2010.

B. Dal Seno, M. Matteucci, and L. Mainardi. [http://www.hindawi.com/journals/cin/2010/307254.html On-line detection of P300 and error potentials in a BCI speller]. ''Computational Intelligence and Neuroscience, Special Issue on Processing of Brain Signals by Using Hemodynamic and Neuroelectromagnetic Modalities'', Article ID 307254, 5 pages, 2010.

=== PhD Theses ===

B. Dal Seno. [[media:B_DalSeno_PhdThesis2009.pdf | Toward An Integrated P300- And ErrP-Based Brain-Computer Interface]]. Ph.D. dissertation, Politecnico di Milano, 2009.

== Media ==

* 22 Jan 2009: [http://tv.repubblica.it/copertina/muoversi-con-il-pensiero/28512?video Repubblica TV report on Lurch and BCI] (in Italian)
* Aug 2008: [http://www.youtube.com/watch?v=lRP-ae4iaZA RAI TGLeonardo report on Airlab research] (in Italian). The video is a fragment of a longer report on mind and intelligence.

File:B DalSeno PhdThesis2009.pdf

2010-04-02T14:42:43Z

BernardoDalSeno: PhD Thesis of Bernardo Dal Seno: "Toward An Integrated P300- And ErrP-Based Brain-Computer Interface"

PhD Thesis of Bernardo Dal Seno: "Toward An Integrated P300- And ErrP-Based Brain-Computer Interface"

First Level Theses

2009-10-29T22:30:56Z

BernardoDalSeno: /* Brain-Computer Interface */

Here you can find proposals for first level thesis (7.5 CFU for each student). See [[Project Proposals]] for other kinds of projects and theses.


==== BioSignal Analysis ====
===== Brain-Computer Interface =====

{{Project template
|title=Real-time removal of ocular artifact from EEG
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=In a [[Brain-Computer Interface|BCI]] based on electroencephalogram (EEG), one of the most important sources of noise is related to ocular movements. Algorithms have been devised to cancel the effect of such artifacts. The project consists in the in the implementation in real time of an existing algorithm (or one newly developed) in order to improve the performance of a BCI.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]
: R.J. Croff, R.J. Barry. ''Removal of ocular artifact from the EEG: a review'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=09877053&volume=30&issue=1&firstpage=5&form=html]
|number=1
|cfu=10-20
|image=B_bci.jpg}}

{{Project template
|title=Driving an autonomous wheelchair with a P300-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. The work will be validated with live experiments.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000], Matlab
:Linux
:EEG system
:Lurch wheelchair

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]
|start=Anytime
|number=1
|cfu=5-20
|image=LURCH_wheelchair.jpg}}

{{Project template
|title=Reproduction of an algorithm for the recognition of error potentials
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=Error potentials (ErrPs) are [http://en.wikipedia.org/wiki/Event-related_potential event-related potentials] present in the EEG (electroencephalogram) when a subject makes a mistake or when the machine a subject is interacting with works in an expected way. They could be used in the [[Brain-Computer Interface|BCI]] field to improve the performance of a BCI by automatically detecting classification errors.
The project aims at reproducing algorithms for ErrP detection from the literature.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000]
:EEG system

;Bibliography
:P.W. Ferrez, J. Millán. ''You Are Wrong! Automatic Detection of Interaction Errors from Brain Waves'' [ftp://ftp.idiap.ch/pub/reports/2005/ferrez_2005_ijcai.pdf]
:G. Schalk et al. ''EEG-based communication: presence of an error potential'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=13882457&volume=111&issue=12&firstpage=2138&form=html]
|start=This project has already been assigned
|number=1
|cfu=5-15
|image=Bci_arch.png}}




==== Computational Intelligence and Games ====

{{#ask: [[Category:ProjectProposal]]
[[PrjResTopic::Computational Intelligence and Games]]
[[PrjLevel::Bs]]
[[PrjType::Thesis]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}

==== Social Software and Semantic Web ====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Social Software and Semantic Web]]
[[PrjLevel::Bs]]
[[PrjType::Thesis]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}



==== Machine Learning ====
{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Machine Learning]]
[[PrjLevel::Bs]]
[[PrjType::Thesis]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}

==== Robotics ====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Robotics]]
[[PrjLevel::Bs]]
[[PrjType::Thesis]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}

{{Project template
|title=Simulation of 6-DOF Robot Manipulator
|tutor=Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this project is to develop a simulator for a 6-DOF robot manipulator, using the [http://www.ode.org/ ode] (open dynamics engine) library for simulating the rigid body dynamics. The project involves three different phases:
* Building the physical model of the manipulator
* Implementing the forward and inverse kinematic routines
* Implementing the trajectory planning routines
* Implementing the control modules
* Implementing an interface to control the robot movements

This project allows to put into practice what has been explained during the first part of the course of Robotics.

The project can be turned into a thesis, by using the simulated manipulator to perform some learning experiments.
|start=Anytime
|number=2-3
|cfu=10-15
|image=puma6dof1.jpg}}

{{Project template
|title=Calibration of IMU-camera system
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]], [[User:DavideMigliore|Davide Migliore]]
|description=This work is about the problem to calibrate a system composed by an XSense
Inertial Measurement Unit and a Fire-i Camera. The pro ject will be focus on
the problem to estimate both unknown rotation between the two devices and the
extrinsic/intrinsic parameters of the camera. This algorithm allows to use the
system for SLAM or robotics applications, like a wereable device for autonomous
navigation or augmented reality.

;Tools and instruments
:Matlab/C++

;Links
:Matlab Toolbox for mutual calibration [http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Toolbox.html]
:List of pubblications[http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Pubs.php]

|start=Anytime
|number=1
|cfu=5-20
|image=Imu_cam_big_sphere.gif}}

{{Project template
|title= Robot games
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to develop an interactive game with robots using commercial devices such as the WII Mote (see the [http://airwiki.elet.polimi.it/mediawiki/index.php/Robogames Robogames page])
Projects are available in different areas:
* Design and implementation of the game on one of the available robots and extension of the robot functionalities
* Design and implementation of the game and a new suitable robot
* Evaluation of the game with users (in collaboration with [http://www.elet.polimi.it/people/garzotto Franca Garzotto])

These projects allow to experiment with real mobile robots and real interaction devices.

Parts of these projects can be considered as course projects. These projects can also be extended to cover course projects.
|start=Anytime
|number=1-2
|cfu=7.5-12.5
|image=Robowii_robot.jpg}}

Driving an autonomous wheelchair with a P300-based BCI

2009-10-26T19:19:43Z

BernardoDalSeno:

{{ProjectProposal
|title=Driving an autonomous wheelchair with a P300-based BCI
|image=LURCH_wheelchair.jpg
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair (LURCH) with a BCI, through the development of key software modules. Depending on the effort the student is willing to put into it, the project can grow to a full experimental thesis.
|tutor=MatteoMatteucci;
|start=2008/11/01
|cfumin=5
|cfumax=20
|resarea=BioSignal Analysis
|restopic=Brain-Computer Interface
|level=Bs; Ms
|type=Course
}}
This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. Depending on the effort the student is willing to put into it, the project can grow to a full experimental thesis.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000]
:Linux

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]

Real-time removal of ocular artifact from EEG

2009-10-26T19:19:10Z

BernardoDalSeno:

{{ProjectProposal
|title=Real-time removal of ocular artifact from EEG
|image=B_bci.jpg
|description=In a Brain-Computer Interface (BCI) based on electroencephalogram (EEG), one of the most important sources of noise is related to ocular movements. Algorithms have been devised to cancel the effect of such artifacts. The project consists in the in the implementation in real time of an existing algorithm (or one newly developed) in order to improve the performance of a BCI.

* J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' (http://tinyurl.com/yhq27pq)
* R.J. Croff, R.J. Barry. ''Removal of ocular artifact from the EEG: a review'' (http://tinyurl.com/ykk6ks9)
|tutor=MatteoMatteucci;
|start=2009/10/01
|studmin=1
|studmax=2
|cfumin=2.5
|cfumax=5
|resarea=BioSignal Analysis
|restopic=Brain-Computer Interface
|level=Bs; Ms
|type=Course
|status=Active
}}
;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG-system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]
: R.J. Croff, R.J. Barry. ''Removal of ocular artifact from the EEG: a review'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=09877053&volume=30&issue=1&firstpage=5&form=html]
|number=1

Recognition of the user's focusing on the stimulation matrix

2009-10-26T19:18:37Z

BernardoDalSeno:

{{ProjectProposal
|title=Recognition of the user's focusing on the stimulation matrix
|image=B_p300_speller.jpg
|description=A P300-based Brain-Computer Interface (BCI) stimulates the user continuously, and the detection of a P300 designates the choice of the user. When the user is not paying attention to the interface, false positives are likely. The objective of this work is to avoid this problem; the analysis of the electroencephalogram (EEG) over the visual cortex (and possibly an analysis of P300s or of other biosignals) should tell when the user is looking at the interface
*E. Donchin, K.M. Spencer, R. Wijesinghe. ''The Mental Prosthesis: Assessing the Speed of a P300-Based Brain-Computer Interface'' (http://www.cs.cmu.edu/~tanja/BCI/P300Speed_2000.pdf)
|tutor=MatteoMatteucci
|start=2009/10/01
|studmin=1
|studmax=2
|cfumin=5
|cfumax=20
|resarea=BioSignal Analysis
|restopic=Brain-Computer Interface
|level=Bs; Ms
|type=Course; Thesis
|status=Active
}}
;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG system

;Bibliography
: E. Donchin, K.M. Spencer, R. Wijesinghe. ''The Mental Prosthesis: Assessing the Speed of a P300-Based Brain-Computer Interface'' [http://www.cs.cmu.edu/~tanja/BCI/P300Speed_2000.pdf]

Creation of new EEG training by introduction of noise

2009-10-26T19:17:30Z

BernardoDalSeno:

{{ProjectProposal
|title=Creation of new EEG training by introduction of noise
|image=Bci_arch.png
|description=A Brain-Computer Interface (BCI) must be trained on the individual user in order to be effective. This training phase require recording data in long sessions, which is time consuming and boring for the user. The aim of this project is to develop algorithm to create new training EEG (electroencephalography) data from existing ones, so as to speed up the training phase.

*J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' (http://tinyurl.com/yhq27pq)
|tutor=MatteoMatteucci;
|start=2009/10/01
|studmin=1
|studmax=2
|cfumin=5
|cfumax=20
|resarea=BioSignal Analysis
|restopic=Brain-Computer Interface
|level=Bs; Ms
|type=Course; Thesis
|status=Active
}}
;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000]
:Knowledge of C++ may be useful
:EEG system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]

User:BernardoDalSeno

2009-10-14T13:05:03Z

BernardoDalSeno:

{{Researcher
|firstname=Bernardo
|lastname=Dal Seno
|email=bernardo.dalseno@polimi.it
|advisor=MatteoMatteucci
}}

See [http://www.dei.polimi.it/personale/motorericerca/dettaglio.php?&id_persona=398&idlang=eng my page on the department site]

For '''urgent''' matters, my cell phone is +39 3407179411.

Brain-Computer Interface

2009-10-05T15:11:14Z

BernardoDalSeno:

A Brain-Computer Interface (BCI) is an experimental communication system that allows an individual to control a device by using signals from the brain (e.g., electroencephalography -- EEG).

You can find a longer description on the [http://airlab.elet.polimi.it/index.php/airlab/research_areas/biosignal_analysis?z=2299 AIRLab page].

The BCI project is in the [[BioSignal_Analysis]] area.

== Ongoing projects ==

* [[A genetic algorithm for automatic feature extraction from EEG data]]
* [[BCI based on Motor Imagery]]
** [[Predictive BCI Speller based on Motor Imagery]] (Master thesis, Tiziano D'Albis)
** [[Feature Selection and Extraction for a BCI based on motor imagery]] (Master thesis, Francesco Amenta)
* [[Graphical user interface for an autonomous wheelchair]]
* [[Online automatic tuning of the number of repetitions in a P300-based BCI]]

== New projects ==
There are various proposal for students interested in projects/thesis in the field of brain-computer interfaces:
*[[First Level Course Projects#Brain-Computer_Interface|First Level Course Projects]]
*[[First Level Theses#Brain-Computer_Interface|First Level Theses]]
*[[Master Level Course Projects#Brain-Computer_Interface|Master Level Course Projects]]
*[[Master Level Theses#Brain-Computer_Interface|Master Level Theses]]

== Finished projects ==

* [[Reproduction of an algorithm for the recognition of error potentials]]
* [[Online P300 and ErrP recognition with BCI2000]] (Master thesis, Andrea Sgarlata).
* Tesi di Carlo Gimondi e Luisella Messana
* Tesi di Gianmaria Visconti
* Tesi di Francesco Cartella

== Instruments ==

* [[Electroencephalographs]]

== How to ==

* [[How to mount electrodes]]
* [[How to setup BCI software]]

== Publications ==

You can find publications in the BCI field by Airlab members on their home pages:
* [http://home.dei.polimi.it/dalseno/publications.html Bernardo Dal Seno's publications]

== Media ==

* 22 Jan 2009: [http://tv.repubblica.it/copertina/muoversi-con-il-pensiero/28512?video Repubblica TV report on Lurch and BCI] (in Italian)
* Aug 2008: [http://www.youtube.com/watch?v=lRP-ae4iaZA RAI TGLeonardo report on Airlab research] (in Italian). The video is a fragment of a longer report on mind and intelligence.

Writing Good Code

2009-09-14T16:26:37Z

BernardoDalSeno: /* Matlab */

==Why this page==
When tutoring students for their theses or projects, I often find many problems with the code they write. I'm not referring to bugs; bugs happen, as flu happens, although there are some things you can do to make them more unlikely. The problem discussed here is ''Bad code''TM, i.e., code that nobody can read or understand, not even its author. So I've decided to write this page with some advice on how to write ''Good code''TM. Please note that everything you find in this page should not be considered as strict rules, as it expresses the point of view of its author(s); but a reasonable piece of advice needs a good reason to counter it, in order not to follow it; so at least think about it. Contributions are welcome.
::--Bernardo

==General==

The source of the program is not only a way to obtain a binary that your computer can run, it is a way to express ideas. They should be clear to the compiler, so it compiles and you have your nice executable, but they should be clear also to anyone that reads your code, including your fellow students, your supervisor, and, of course, '''you''' — even after a couple of months. Writing a program is the ultimate way to check your ideas and hypothesis. So, '''write for you and your fellows, not only for the computer!'''

===I Think Therefore I Program===

And the inverse is true: you cannot program without thinking. So, before rushing to the keyboard, take a piece of paper and try to lay down your ideas. A clear idea of the structure of data and the algorithm you want to apply is important to write a properly working program. Think about how you're going to use the data and shape the data structures accordingly; think about how to factorize your algorithm, what functions (methods) and what parameters you need.

===Names===

Names should be meaningful, clear, short (at least, not too long), and to the point. That applies to pretty everything: classes, variables, functions, modules, members. Remember: the compiler doesn't care about names, but humans do; your colleagues are humans, and probably they want to understand your code when they happen to read it. If the project you are working on or the language you are using come with a naming convention just follow it; separate words in names by using underscores '_' or mixedCaseLikeThis.

In general, you want to use nouns or adjectives as names for variable and attributes, while verbs are appropriate for functions and methods. Names with a wider scope (classes, public methods, global variables, global functions...) require more care: They cannot be too simple to avoid clashing with local names, and both the meaning and the context should be clear. 'tmp' can be a good name for a local variable with a life of a couple of lines of code, or 'k' is good for a loop counter, but they are really bad names for anything with a scope wider than a loop. For example, if you have to store the name of a temporary file where you save the result of the application of a fast Fourier transform, something like 'fft_file_name' is more appropriate; if you have a counter that keeps track of the number of time you called the 'evaluate_fitness()' method (e.g., for statistical purposes), you could chose something like 'fitness_call_count'. Completely uninformative and generic names like 'var', 'flag', 'foo', 'pippo', 'number'... are always bad.

===Comments===

A big problem is the use of comments. You can encounter projects with hundreds of lines of code and not a single line of comment, so that it is hard to guess even the general purpose of the program, or projects with ultra-verbose comments, like this:
k = k + 1; // increment k
Yeah, thanks, I thought it was extracting the square root of k.

Comments are important, and their correct use improves the quality of the code, even when there are no comments. Really! Often comments are written as a patch to badly-written code, but a tangled piece of code is not a way to clearly convey your ideas; and a comment added to a tangled piece of code doesn't make it much clearer. Besides, if you can't understand a piece of code, does some comment raise your confidence that the code is really working? Tangled code is more likely to be bugged, and more difficult to modify, so please write your algorithm in a way that it can be understood just be reading the instructions, not the comments. There are [http://www.ioccc.org/ good places] where to write obfuscated code, and a thesis is not one of them.

Just an example (taken from real code! names have been changed to protect the innocent):
#define NUM_IT 3
for (j = 0; j < NUM_IT; ++j) {
if (j == 0) { // First iteration
// Do something
...
} else if (j == 1) { // Second iteration
// Do something else
...
} else if (j == 2) { // Third iteration
// Do things
...
}
}
This is a rather confusing way to write a simple sequence:
// Do something
...
// Do something else
...
// Do things
...

So, what to comment? Good places for comments are:
* Class declarations
* Functions and methods declarations. Important aspects to document are:
** What the function is about (also, expected results and any side effect)
** What the parameters are (don't forget to specify the acceptable value ranges)
** Return values (if any)
** How errors are handled (e.g., any exception raised, or what happens if in case of an abnormal situation)
* Class attribute declarations
* Declarations of global or important variables
* The beginning of a file
In C and C++ you want to put comments in header (.h) files, as those are the files read by whoever will use the code you wrote. Comments inside .c or .cpp files should be about implementation details, i.e., matters useful only to anyone who wants to modify or understand your algorithms.

Also, whenever you take a tricky decision, please document it in the appropriate place!

===Debugging===

There is no program without a bug (or was it "There is no rose without a bug"?). Your programs are no exception, so you'll have to remove bugs. Many books could be written about debugging (and they are), but here just a few ideas are hinted.

When you experience a failure, don't rush hacking at the code until it disappears. We are in an engineering school, so use the engineering method: build a model. In other words, try to pinpoint the error that caused the failure, before trying to remove it. Do tests and explore the functioning of your program in order to find the problem; try to find a way to make the failure reproducible, so after you correct the error you can check that everything is working properly. Debuggers are useful to inspect the state of the program, but you can use also [http://en.wikipedia.org/wiki/Assertion_%28computing%29 assertions] and <code>printf</code>s (or the output function of your favorite language) when you can't or don't want to run a debugger.

Sometimes you have to write some debugging code to check conditions, to validate data structures, or print out the value of variables.
This code is not needed when you've finished debugging, but this no reason for removing it. If you spent time writing code, don't waste your effort; you or someone else may need it in the future to debug a similar problem. Leave it in place; surround it with conditionals: <code>#ifdef DEBUG</code> if you are using C, or <code>if (debug)</code> in Java or other languages that have no preprocessor (<code>debug</code> is a global variable in this case); in this way, it is easy to activate it. Unless the code is inside a deeply-nested loop, the performance hit of a run-time ''if'' is negligible; if (and only if) your debugging code is an a deeply-nested loop, wrap it in a comment.

If you write test cases (or better yet test scripts), don't throw them away. Rerun your tests periodically, so you can avoid regressions. There are even tools that help in this, like [http://junit.sourceforge.net/ JUnit] (for Java; there are ports [http://sourceforge.net/projects/cppunit for C++] and other languages).

===Optimization===

You want your code to be as fast as possible, right? Wrong! Really, do you care if your favorite word processor saves a microsecond every time you type a character, or would you trade that microsecond for a greater reliability, so that it doesn't crash losing half a chapter of your precious thesis?

Optimizing code require (your) time, and sometimes the code becomes less readable and maintainable. So, concentrate your efforts on the parts of the program that really require it; measure the speed of your program, and use a [http://en.wikipedia.org/wiki/Profiler_%28computer_science%29 profiler] to identify the bottlenecks. A simple rule of thumb can be given: anything that is not inside a doubly-nested loop is not worth optimizing. Always measure your progress, as bottlenecks may change.

And never forget that a better algorithm beats any tweaking of your code. For example, if you are looking for the maximum in an array, sorting the array and taking the first element is a bad solution (it has at least O(n log n) complexity); if you don't need the sorted array for other purposes, a linear sweep of the array is faster (it's O(n)) and requires less memory.

===Indentation and spaces===

In most languages, spaces and indentation are not part of the syntax, and they are mostly ignored by the compiler (Python is a significant exception), yet indentation and spaces are very useful to format your code and make it more readable. There are many way to use them, but the first rule is 'consistency'. Choose the style you like the most, and stick to it; particularly, choose if you want to use spaces or tabs for indentation, and be consistent, otherwise when someone else opens your project with a different editor with a different idea of tab length, your nice (you made it nice, didn't you?) indentation will be screwed up.

===Warnings===

When compiled, your program should not raise any warnings. '''Any''' warnings, which includes harmless warnings. Compilers generate warnings for a reason: you have written a code that does something suspicious and you should look into it. So, if someone else compiles your program, should they also check that all the warnings of your code are harmless? Or how can they be sure that you effectively checked all warnings and you're not just a sloppy coder? :-) And what happens if they (or you) change your code that raises a gazillion of warnings? How can anyone spot any new warning?
So, please make sure that your code raises no warnings, and whoever will use it in the future will thank you for that.

==C and C++ code==

The [http://www.google.com/search?q=%22Linux+kernel+coding+style%22 Linux kernel coding style] is an interesting reading, particularly chapters 3 (Placing Braces and Spaces), 4 (Naming), 6 (Functions), 8 (Commenting), 12 (Macros).

C (and C++) have a fair number of operators, with strictly defined precedences. Even if you know all the precedence rules by heart, don't assume others do; so, please use parentheses when writing complex expressions.

If you are writing any non-trivial project (anything that spans more than one file of source code can be considered non-trivial), you may want to use [http://www.stack.nl/~dimitri/doxygen/ Doxygen] for documentation. It's simple to use, and after you've learned how it works, it doesn't require additional work. On the contrary, it helps you in keeping your code well documented.

In C++, never use the C-style cast operator, particularly with pointers. Use <code>static_cast</code> or a constructor for classes, and <code>dynamic_cast</code> for pointers. C-style casts are ambiguous, as they can mean many different type of casts, some of which are dangerous. The only situation where a C-style cast may have a place is for conversion between built-in numeric types.

===Header files===

Apparently, header (include) files can be problematic, probably because of the Java background common to many people nowadays. If you have any doubt about them, Wikipedia does a good job in briefly explaining what [http://en.wikipedia.org/wiki/Header_file header files] are.

Major misconceptions regards what goes inside a header file. This a topic better described in a programming manual (and you've already read it, haven't you?), but a good rule of thumb is: only declarations and definitions that neither reserve memory nor produce code.

A header file should contain all (and only) the include directives necessary for its compilation, i.e., if the file makes use of any data type or symbol, it must include the header that defines such data type or symbol.

There can be problems with header files, due to multiple or recursive inclusions. To avoid them, you can wrap their content in a <code>#ifndef</code>...<code>#endif</code> construct (inside the header file!), like this:
#ifndef MY_PROJECT_MY_HEADER_H
#define MY_PROJECT_MY_HEADER_H
/* Real content of the file */
...
#endif
The name of the macro should be something that is unlikely to clash with other macros; e.g., prepend the name of your project.

==Matlab==

Matlab is a rather slow interpreted language, but it shines — as its name implies — at matrix manipulation. So try to avoid loops, and do operations in parallel on arrays. Many vectorized functions are built-in, so look in the help when you need simple operations like sums, means, maximum...

Matlab has a tool, <code>mlint</code>, that checks the code for easily detectable problems. It is active by default in the Matlab editor, and it highlight problems with jagged orange lines under the troubled code (and corresponding orange indicators on the right-hand bar). Don't ignore them, unless you are sure they are harmless; look up in the help or on the Web if don't understand a problem.

One of the problems spotted by <code>mlint</code> is the dynamic growth of arrays. Avoid that; it slows Matlab, as it turns O(n) algorithms into O(n²). For example,
a = [];
for k = 1:50000
a(k) = k;
end
takes more than 30 seconds on a machine, while
a = zeros(50000,1);
for k = 1:50000
a(k) = k;
end
takes only 0.1 seconds on the same machine. See
[http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f1-85766.html#f1-88760 the full explanation] on the Mathworks Web site.

Remember not to trust <code>mlint</code> too much; there is no perfect static analyzer (you remember [http://en.wikipedia.org/wiki/Rice%27s_theorem Rice's theorem], right?). If you have no warnings, it doesn't mean that your program is perfect.

===Comments===

Matlab has its own way to comment M-files, as comments are used to provide information for the <code>help</code> command, and also the command <code>lookfor</code> searches inside the first line of an M-file comment. See the section [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f7-41453.html#f7-38702 Providing Help for Your Program] inside the topic [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f7-41453.html Working with M-Files] and the topic [http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_env/bruby4n-1.html#brubzjb-1 Providing Your Own Help and Demos] in the online Matlab documentation.

Writing Good Code

2009-09-07T16:52:34Z

BernardoDalSeno: /* Header files */

Brain-Computer Interface

2009-08-20T20:16:28Z

BernardoDalSeno: /* Ongoing projects */

A Brain-Computer Interface (BCI) is an experimental communication system that allows an individual to control a device by using signals from the brain (e.g., electroencephalography -- EEG).

You can find a longer description on the [http://airlab.elet.polimi.it/index.php/airlab/research_areas/biosignal_analysis?z=2299 AIRLab page].

The BCI project is in the [[BioSignal_Analysis]] area.

== Ongoing projects ==

* [[A genetic algorithm for automatic feature extraction from EEG data]]
* [[BCI based on Motor Imagery]]
** [[Predictive BCI Speller based on Motor Imagery]] (Master thesis, Tiziano D'Albis)
** [[Feature Selection and Extraction for a BCI based on motor imagery]] (Master thesis, Francesco Amenta)
* [[Graphical user interface for an autonomous wheelchair]]
* [[Online automatic tuning of the number of repetitions in a P300-based BCI]]
* [[Reproduction of an algorithm for the recognition of error potentials]]

== New projects ==
There are various proposal for students interested in projects/thesis in the field of brain-computer interfaces:
*[[First Level Course Projects#Brain-Computer_Interface|First Level Course Projects]]
*[[First Level Theses#Brain-Computer_Interface|First Level Theses]]
*[[Master Level Course Projects#Brain-Computer_Interface|Master Level Course Projects]]
*[[Master Level Theses#Brain-Computer_Interface|Master Level Theses]]

== Finished projects ==

* [[Online P300 and ErrP recognition with BCI2000]] (Master thesis, Andrea Sgarlata).
* Tesi di Carlo Gimondi e Luisella Messana
* Tesi di Gianmaria Visconti
* Tesi di Francesco Cartella

== Instruments ==

* [[Electroencephalographs]]

== How to ==

* [[How to mount electrodes]]
* [[How to setup BCI software]]

== Publications ==

You can find publications in the BCI field by Airlab members on their home pages:
* [http://home.dei.polimi.it/dalseno/publications.html Bernardo Dal Seno's publications]

== Media ==

* 22 Jan 2009: [http://tv.repubblica.it/copertina/muoversi-con-il-pensiero/28512?video Repubblica TV report on Lurch and BCI] (in Italian)
* Aug 2008: [http://www.youtube.com/watch?v=lRP-ae4iaZA RAI TGLeonardo report on Airlab research] (in Italian). The video is a fragment of a longer report on mind and intelligence.

Brain-Computer Interface

2009-08-20T20:15:56Z

BernardoDalSeno: /* Ongoing projects */

A Brain-Computer Interface (BCI) is an experimental communication system that allows an individual to control a device by using signals from the brain (e.g., electroencephalography -- EEG).

You can find a longer description on the [http://airlab.elet.polimi.it/index.php/airlab/research_areas/biosignal_analysis?z=2299 AIRLab page].

The BCI project is in the [[BioSignal_Analysis]] area.

== Ongoing projects ==

* [[A genetic algorithm for automatic feature extraction from EEG data]]
* [[BCI based on Motor Imagery]]
** [[Predictive BCI Speller based on Motor Imagery]] (Master thesis, Tiziano D'Albis)
** [[Feature Selection and Extraction for a BCI based on motor imagery]] (Master thesis, Francesco Amenta)
* [[Graphical user interface for an autonomous wheelchair]] (Roberto Massimini)
* [[Online automatic tuning of the number of repetitions in a P300-based BCI]]
* [[Reproduction of an algorithm for the recognition of error potentials]]

== New projects ==
There are various proposal for students interested in projects/thesis in the field of brain-computer interfaces:
*[[First Level Course Projects#Brain-Computer_Interface|First Level Course Projects]]
*[[First Level Theses#Brain-Computer_Interface|First Level Theses]]
*[[Master Level Course Projects#Brain-Computer_Interface|Master Level Course Projects]]
*[[Master Level Theses#Brain-Computer_Interface|Master Level Theses]]

== Finished projects ==

* [[Online P300 and ErrP recognition with BCI2000]] (Master thesis, Andrea Sgarlata).
* Tesi di Carlo Gimondi e Luisella Messana
* Tesi di Gianmaria Visconti
* Tesi di Francesco Cartella

== Instruments ==

* [[Electroencephalographs]]

== How to ==

* [[How to mount electrodes]]
* [[How to setup BCI software]]

== Publications ==

You can find publications in the BCI field by Airlab members on their home pages:
* [http://home.dei.polimi.it/dalseno/publications.html Bernardo Dal Seno's publications]

== Media ==

* 22 Jan 2009: [http://tv.repubblica.it/copertina/muoversi-con-il-pensiero/28512?video Repubblica TV report on Lurch and BCI] (in Italian)
* Aug 2008: [http://www.youtube.com/watch?v=lRP-ae4iaZA RAI TGLeonardo report on Airlab research] (in Italian). The video is a fragment of a longer report on mind and intelligence.

Talk:Graphical user interface for an autonomous wheelchair

2009-08-18T23:22:12Z

BernardoDalSeno: /* Da fare */

==General==

The interface is used mainly to drive the [[LURCH - The autonomous wheelchair|Lurch wheelchair]]. It has different screens, corresponding to the different rooms or different environments where the wheelchair can move. The screens are organized hierarchically: a main screen permits to choose whether to drive the wheelchair or perform other tasks. The screens used for driving the wheelchair show a map of the environment, with different levels of details; e.g., a map might show just the rooms of a house, and then another map might show the living room with the furniture and ‘interesting’ positions (like near the table, in front of the TV, beside the window...).

The interface should be as [http://en.wikipedia.org/wiki/Accessibility accessible] as possible. It can be driven by a BCI, used with the touch screen or with the keyboard. The BCI is based on the P300 and ErrP potentials; so the interface should highlight the possible choices on at a time (in orthogonal groups if the choices are numerous), and show the choice detected by the BCI for ErrP-based confirmation.

Maybe the screen should be updated while the wheelchair navigates; e.g., when the wheelchair enter into the kitchen, the GUI shows the map of the kitchen.

===To Do===

==Map representation==
[[Image:Lurch_map_xml_structure_v2.png|600px|xml map structure]]

link to OpenOffice Draw source [[media:Lurch_map_xml_structure_v2.zip‎]]

link to a simple example [[media:Lurch_map_xml_example.xml.zip]] '''complete this example, it's very minimal'''

* If there is no map in a zone, the interface will show only the names of the the possible destinations (i.e., zones). If there is a map, zones are drawn as polygons ().
* If anything has no NAME, the ID is used instead.
* Costs for a portal are 1 by default; forbidden connections have infinite cost.
* Rooms that are portals have no destinations and no inner rooms.
* Colors currently are not saved by the cad and are not read by the bci gui.

==Communication Protocol Requirements==

* Cross-platform (at least Linux and Windows)
* Based on the IP protocol
* Asynchronous (as much as possible), so as not to block remote processes
* Preferably, the protocol should be in ASCII, with fixed-width fields (the number of fields is variable, by necessity).

===To Do===

* List of the pieces of information to be transferred between the application and the GUI

==Communication Protocol==
===UML Sequence Diagram===
====Diagram====

[[Image:ComunicationProtocol.jpg]]

====Comments about the diagram====
Structure of MessageA:
* Number of repetitions: number of flashings
* Number of stimulations: number of flashings in one repetition
* List of the stimulations: list of the possible stimulations with its type
* Number of types
* Stimulations sequence: it includes all the repetitions

Each stimulation must hav associated a type (e.g Icon, Row-Column)

Structure of SelectionA:
* For each number of stimulation types you have a equal number of ids (e.g for Icon it will be used 1 id, for Row-Column 2 ids)

Graphic example of id:

[[Image:IdExample.jpg]]

It will be also an end asynchronous message, that brings the BCI in pause, and it closes the graphic interface.

If the syncrony will be lost there's a Reset Message that restarts from the calibration. It will be activated when the number of the classifications is different from the number of the stimulations on the screen

== Implementation of GUI ==
=== Primo incontro (04/03/2009) ===

* Attualmente sulla carrozzella è installata una GUI molto semplice, che lavora all'interno del sistema BCI2000. L'idea è quella di creare una interfaccia asincrona che dovrà interagire con il sistema BCI2000 già realizzato mediante un socket TCP.

* Ci sono diverse possibilità per implementare la GUI:

0) Stimoliamo le singole location presenti all'interno della mappa: il problema è che può diventare pesante, e che può essere difficile dal punto di vista cognitivo per l'utente.

1) Per prima cosa stimoliamo i diversi locali, e poi stimoliamo le location appartenenti al singolo locale selezionato (in realtà dovremo continuare a stimolare anche gli altri locali, nel caso in cui l'utente volesse uscire dalla stanza!)
Le singole location possono essere stimolate in diversi modi: per gruppi, singolarmente, tramite una griglia.

2) Dividiamo la piantina in celle e poi le stimoliamo singolarmente. Questo approccio può essere problematico dal punto di vista della pianificazione del percorso: come fare se la location non è direttamente raggiungibile dall'interno della singola cella, per esempio a causa della presenza di un muro?

L'approccio 1) è decisamente il più naturale. Si può comunque pensare di sviluppare tutti i metodi e poi confrontarli.

* Le caratteristiche della GUI devono essere:
- menu gerarchico per la navigazione

- file di configurazione (direttamente lo stesso file del pianificatore) deve definire la piantina, le stanze, le location, (gruppi di location?).

* Il linguaggio in cui sviluppare la GUI può essere
- MAIA forte rischio di avere problemi di sincronizzazione!

- SDL su C++. Optiamo per questa scelta, che presenta meno rischi.

* '''FATTO''' (disponibile su airBAT)
- interfaccia grafica con due quadrati che si illuminano in modo sincronizzato tra loro.

- interfaccia grafica con una semplice mappa, i cui ambienti si illuminano in maniera randomica. Da notare che le librerie usate sono SDL.h e SDL_image.h (quest'ultima è stata introdotta al momento della creazione delle stanze da illuminare e non nella precedente versione con i quadrati che si illuminano in modo sincrono)

=== Secondo incontro (19/03/2009) ===

* I sorgenti realizzati sono stati provati sulla carrozzina e funzionano correttamente. Il monitor non deve essere settato ad un livello troppo luminoso, altrimenti i fotodiodi vanno in saturazione.

* Problema delle mappe: bisogna decidere come descrivere i vari ambienti della mappa. L'idea è quella di usare dei punti e delle rette. Inoltre il metodo che verrà deciso per la GUI dovrà essere lo stesso che utilizzerà anche il pianificatore. Eventualmente il metodo può essere generalizzabile per una qualsiasi mappa caricata.

* '''FATTO''' (disponibile su airBAT)
- estensione della precedente interfaccia grafica, realizzata utilizzando le librerie SDL_gfx. In questo modo è stato possibile "esternalizzare" il disegno delle primitive geometriche, rendendo più semplice l'individuazione dei poligoni di illuminazione delle varie stanze a partire dagli spigoli delle stanze stesse.

=== Terzo incontro (09/04/2009) ===

* Il presente incontro è stato interamente dedicato alla discussione e formalizzazione di uno schema comune di descrizione delle mappe. Il modello (la cui descrizione è visibile nella sezione 'Map representation') verrà utilizzato sia da coloro che realizzeranno l'interfaccia grafica, sia da coloro che dovranno migliorare il pianificatore attualmente funzionante sulla carrozzina.

* Si è deciso di utilizzare un modello basato sul linguaggio XML, grazie alle sue caratteristiche di flessibilità e semplicità.

* Per quello che riguarda la GUI, alcune parti (scelta della zona, del piano...) saranno realizzate mediante l'illuminazione di scritte, mentre altre parti (scegliere la singola stanza o la singola location all'interno della stanza) mediante l'illuminazione della mappa vera e propria.

* '''SVILUPPI FUTURI'''
- utilizzo di "portali" per il passaggio diretto tra luoghi diversi, anche a diversi livelli dell'albero XML. Al momento attuale, ci si potrà spostare di un solo livello per volta.

- studio dei diversi colori da utilizzare nell'interfaccia grafica

* '''FATTO''' (disponibile su AIRbat)
- realizzazione di un parser xml mediante l'utilizzo delle librerie libxml2

- realizzazione delle parti riguardanti le zone e i piani (illuminazione di scritte).

=== Quarto incontro (11/05/2009) ===

* Il presente incontro è stato dedicato alla discussione di alcuni problemi riscontrati nella fase di scrittura e ingegnerizzazione del codice.

* Warning: per essere certi di veder visualizzati tutti gli eventuali warning, in fase di compilazione bisogna digitare sia -Wall che -W

* Header: nei file .h bisogna solamente inserire la definizione della funzione e non la funzione di per sè: è un errore dal punto di vista logico, ma può creare anche problemi di funzionamento (doppie definizioni...).

* Modularizzazione: l'idea è quella di creare tante funzioni piccole che fanno poche cose molto precise, anche in un'ottica di eventuale riuso e manutenzione. Si può implementare una funzione che crea la struttura dati dal file XML e una che la usa. All'interno di quest'ultima, altre funzioni che passano da un menu all'altro, che disegnano la schermata per gli elenchi, che disegnano la schermata per le cartine, che illuminano gli elenchi, che illuminano le cartine...

* XML: creare una struttura dati esterna per evitare di dover usare direttamente il file XML che descrive gli ambienti da visualizzare. Questo per problematiche di efficienza, ma soprattutto per separare da un punto di vista logico la descrizione del problema e la struttura per la sua soluzione. L'idea è quella di creare un albero "gemello", eliminando tutti i nodi aggiuntivi (e inutili ai nostri fini) del file XML (commenti...)

* '''FATTO''' (disponibile su AIRbat - cartella versiontwo)
- Riscrittura del codice secondo la nuova struttura dati adottata

- Il codice è stato modularizzato

=== Quinto incontro (05/06/2009) ===

* Nella precedente versione della struttura dati era stato creato un albero per riprodurre fedelmente quella che era la struttura del file xml in un novo file in memoria. Questa soluzione è funzionalmente corretta, ma in realtà inutile: il nostro fine è quello di creare una applicazione che deve funzionare in un ambito ben specifico, e non è dunque necessario approntare un modello generale, che può essere utilizzato in diverse situazioni. Inoltre un albero è per definizione un qualcosa di dinamico, che può crescere nel tempo: nel nostro caso, invece, la struttura viene creata una volta sola (quando viene parsato l'albero xml) e poi non viene più modificata.

* La soluzione che è stata concordata è stata quella di "appiattire" la struttura ad albero (con l'eliminazione dei puntatori a nodo padre, figlio e fratello) e di inserire delle strutture vector (che fondamentalmente possono essere visti come degli "array dinamici") in cui vengono elencati tutti i vari figli di un particolare nodo.

* Verrà mantenuta la struttura gerarchica precedente, ma la classe Node diventerà una classe astratta, i cui metodi principali (draw, highlight e select) dovranno essere implementati nelle classi figlie.

* I nodi xml polyline, location e contour non erediteranno da Node, ma saranno delle semplici strutture (dato che non hanno bisogno dei tre metodi principali) che saranno incluse nelle varie room.

* Verrà creato un file header in cui inserire tutte le costanti che saranno utilizzate nell'applicazione: in questo modo è più facile trovarle e modificarle nel caso ce ne fosse bisogno.

=== Sesto incontro (24/07/2009) ===

* E' necessario ripensare in parte il meccanismo di fornitura degli attributi delle zone, stanze ecc: invece di usare dei semplici metodi getter (che di fatto violano il concetto di information hiding, in quanto forniscono delle informazioni all'interno di classi non di loro competenza) è meglio creare dei metodi appositi che incapsulano al loro interno il codice di modifica degli attributi. Effetto di tale modifica è anche quello di operare un'ulteriore modularizzazione del codice,

* Invece di usare dei setter per la creazione della struttura, è buona cosa sostituirli con dei costruttori pensati appositamente.

* '''FATTO''' (disponibile su AIRbat - cartella ptrFinalVersion)
- Riscrittura del codice secondo le indicazioni sopra riportate (quinto e sesto incontro).

=== Settimo incontro (30/07/2009) ===

* Si è deciso di eliminare la funzione navigateAndFill che fino ad ora si occupava di creare la struttura dati, optando per l'"inglobamento" di tale funzione all'interno dei vari costruttori che, ora, dovranno anche navigare l'albero xml in cui viene descritta la mappa.
* Bisogna aggiungere una funzione che, all'interno della select, mostri quella che è stata la scelta appena effettuata, al fine di avere un ulteriore feedback da parte dell'utente.
* Si è cominciato a discutere di quello che deve essere il nostro lavoro per la seconda parte del progetto, ovvero quella che riguarda la comunicazione tra lanostra nuova GUI e BCI2000/Galileo (che sono già installati sulla lurch).
Si è deciso di suddividere il lavoro in questo modo: agosto -> creazione del protocollo di comunicazione in locale nei nostri pc, utilizzando delle connessioni "fake"; settembre (primi 20 giorni) -> trasporto del tutto nel contesto reale; 22 settembre -> laurea

* '''FATTO''' (disponibile su AIRbat - cartella ptrFinalVersion)
- Nuovi costruttori

- Feedback della scelta

=== Ottavo incontro (07/08/2009) ===

* In questo incontro abbiamo deciso di concentrarci sullo sviluppo dell'interfaccia grafica, migliorando le funzionalità già presenti, piuttosto che incominciare a studiare la comunicazione tra GUI e BCI2000, che sarà oggetto della tesi/progetto di qualche altro studente.
* Le cose che dobbiamo dunque fare sono: miglioramento della struttura attuale (migliore modularizzazione e razionalizzazione del codice), creazione di un generatore di permutazioni per illuminare le zone/stanze/locazioni, creazione di una classe di comunicazione tra GUI e BCI2000. Il nostro compito, come detta sarà quello di configurare solo il lato dell'interfaccia grafica, creando altresì uno stub per simulare il funzionamento di BCI2000.

* '''FATTO''' (disponibile su AIRbat - cartella ptrFinalVersion)
- Verificata la compatibilità della classe di comunicazione di BCI2000 in Linux

- Creato un generatore di permutazioni (che utilizza l'algoritmo di [http://en.wikipedia.org/wiki/Steinhaus%E2%80%93Johnson%E2%80%93Trotter_algorithm Johnson Trotter]) per l'illuminazione della lista delle possibili opzioni. Il generatore soddisfa le richieste poste per le sequenze: nessun oggetto viene illuminato due volte consecutive e tutti gli oggetti vengono illuminati un numero uguale di volte.

- Sollevate delle eccezioni ogni qualvolta il file XML appena caricato presenta delle incoerenze

- Aggiunto un parametro che permette di limitare l'altezza dei box per le zone

- Aggiunto un parametro che permette di impostare la dimensione del carattere per la scrittura su finestra SDL

- Sistemati gli header dei file in modo che siano visualizzati anche i nomi dei parametri, e che i commenti siano significativi (input / output della funzione segnalati, utlità della funzione...)

- Eliminato l'attributo ''type'' da ''Node''

- Per quanto riguarda il rettangolo di sincronizzazione abbiamo deciso di mantenere modificabili solo le dimensioni (larghezza ed altezza)ed il posizionamento sull'asse verticale, poichè la posizione sull'asse delle x è calcolata a partire dalla larghezza della fienstra SDL e dalla larghezza della cornice (parametri ''areaX'' e ''externalEdge''): in questo modo il rettangolo è sempre mantenuto sul lato destro della finestra SDL, come nelle specifiche date inizialmente

=== Protocollo di comunicazione ===

In allegato il file che spiega la struttura e il funzionamento dei messaggi che devono essere scambiati per far sì che GUI e interfaccia grafica possano comunicare: [[Media:Communication_Protocol.pdf‎]]

=== Da fare ===

* Creare una classe di comunicazione nella GUI che contenga tutti i metodi per la comunicazione
* Creare una classe di comunicazione per BCI2000 che contenga tutti i metodi per la comunicazione
* inizialmente ci sarà da fare una parte di sincronizzazione: lo stub invierà il numero dei lampeggi (secondo i messaggi standard spiegati sopra) e il quadrato di sincronizzazione li farà. Se la taratura del sensore ottico è corretta, il numero di flash fatti dal quadrato di sincronizzazione sarà uguale al numero inviato dallo stub
* Fare uno stub "interattivo"
* Generare permutazioni casuali
* La gui termini su Ctrl-C
* Eliminare segmentation fault se manca file font o file xml
* Gestire l'errore di apertura del file xml delle zone
* Commentare i metodi in <tt>communication.h</tt>
* Gestire correttamente l'individuazione dei confini dei messaggi all'interno del flusso TCP
* Mettere indirizzo e porta tra i parametri
* Documentare i parametri nel file Xml
* Eliminare le dichiarazioni 'friend'?

Writing Good Code

2009-08-16T11:58:13Z

BernardoDalSeno: /* Comments */

==Why this page==
When tutoring students for their theses or projects, I often find many problems with the code they write. I'm not referring to bugs; bugs happen, as flu happens, although there are some things you can do to make them more unlikely. The problem discussed here is ''Bad code''TM, i.e., code that nobody can read or understand, not even its author. So I've decided to write this page with some advice on how to write ''Good code''TM. Please note that everything you find in this page should not be considered as strict rules, as it expresses the point of view of its author(s); but a reasonable piece of advice needs a good reason to counter it, in order not to follow it; so at least think about it. Contributions are welcome.
::--Bernardo

==General==

The source of the program is not only a way to obtain a binary that your computer can run, it is a way to express ideas. They should be clear to the compiler, so it compiles and you have your nice executable, but they should be clear also to anyone that reads your code, including your fellow students, your supervisor, and, of course, '''you''' — even after a couple of months. Writing a program is the ultimate way to check your ideas and hypothesis. So, '''write for you and your fellows, not only for the computer!'''

===I Think Therefore I Program===

And the inverse is true: you cannot program without thinking. So, before rushing to the keyboard, take a piece of paper and try to lay down your ideas. A clear idea of the structure of data and the algorithm you want to apply is important to write a properly working program. Think about how you're going to use the data and shape the data structures accordingly; think about how to factorize your algorithm, what functions (methods) and what parameters you need.

===Names===

Names should be meaningful, clear, short (at least, not too long), and to the point. That applies to pretty everything: classes, variables, functions, modules, members. Remember: the compiler doesn't care about names, but humans do; your colleagues are humans, and probably they want to understand your code when they happen to read it. If the project you are working on or the language you are using come with a naming convention just follow it; separate words in names by using underscores '_' or mixedCaseLikeThis.

In general, you want to use nouns or adjectives as names for variable and attributes, while verbs are appropriate for functions and methods. Names with a wider scope (classes, public methods, global variables, global functions...) require more care: They cannot be too simple to avoid clashing with local names, and both the meaning and the context should be clear. 'tmp' can be a good name for a local variable with a life of a couple of lines of code, or 'k' is good for a loop counter, but they are really bad names for anything with a scope wider than a loop. For example, if you have to store the name of a temporary file where you save the result of the application of a fast Fourier transform, something like 'fft_file_name' is more appropriate; if you have a counter that keeps track of the number of time you called the 'evaluate_fitness()' method (e.g., for statistical purposes), you could chose something like 'fitness_call_count'. Completely uninformative and generic names like 'var', 'flag', 'foo', 'pippo', 'number'... are always bad.

===Comments===

A big problem is the use of comments. You can encounter projects with hundreds of lines of code and not a single line of comment, so that it is hard to guess even the general purpose of the program, or projects with ultra-verbose comments, like this:
k = k + 1; // increment k
Yeah, thanks, I thought it was extracting the square root of k.

Comments are important, and their correct use improves the quality of the code, even when there are no comments. Really! Often comments are written as a patch to badly-written code, but a tangled piece of code is not a way to clearly convey your ideas; and a comment added to a tangled piece of code doesn't make it much clearer. Besides, if you can't understand a piece of code, does some comment raise your confidence that the code is really working? Tangled code is more likely to be bugged, and more difficult to modify, so please write your algorithm in a way that it can be understood just be reading the instructions, not the comments. There are [http://www.ioccc.org/ good places] where to write obfuscated code, and a thesis is not one of them.

Just an example (taken from real code! names have been changed to protect the innocent):
#define NUM_IT 3
for (j = 0; j < NUM_IT; ++j) {
if (j == 0) { // First iteration
// Do something
...
} else if (j == 1) { // Second iteration
// Do something else
...
} else if (j == 2) { // Third iteration
// Do things
...
}
}
This is a rather confusing way to write a simple sequence:
// Do something
...
// Do something else
...
// Do things
...

So, what to comment? Good places for comments are:
* Class declarations
* Functions and methods declarations. Important aspects to document are:
** What the function is about (also, expected results and any side effect)
** What the parameters are (don't forget to specify the acceptable value ranges)
** Return values (if any)
** How errors are handled (e.g., any exception raised, or what happens if in case of an abnormal situation)
* Class attribute declarations
* Declarations of global or important variables
* The beginning of a file
In C and C++ you want to put comments in header (.h) files, as those are the files read by whoever will use the code you wrote. Comments inside .c or .cpp files should be about implementation details, i.e., matters useful only to anyone who wants to modify or understand your algorithms.

Also, whenever you take a tricky decision, please document it in the appropriate place!

===Debugging===

There is no program without a bug (or was it "There is no rose without a bug"?). Your programs are no exception, so you'll have to remove bugs. Many books could be written about debugging (and they are), but here just a few ideas are hinted.

When you experience a failure, don't rush hacking at the code until it disappears. We are in an engineering school, so use the engineering method: build a model. In other words, try to pinpoint the error that caused the failure, before trying to remove it. Do tests and explore the functioning of your program in order to find the problem; try to find a way to make the failure reproducible, so after you correct the error you can check that everything is working properly. Debuggers are useful to inspect the state of the program, but you can use also [http://en.wikipedia.org/wiki/Assertion_%28computing%29 assertions] and <code>printf</code>s (or the output function of your favorite language) when you can't or don't want to run a debugger.

Sometimes you have to write some debugging code to check conditions, to validate data structures, or print out the value of variables.
This code is not needed when you've finished debugging, but this no reason for removing it. If you spent time writing code, don't waste your effort; you or someone else may need it in the future to debug a similar problem. Leave it in place; surround it with conditionals: <code>#ifdef DEBUG</code> if you are using C, or <code>if (debug)</code> in Java or other languages that have no preprocessor (<code>debug</code> is a global variable in this case); in this way, it is easy to activate it. Unless the code is inside a deeply-nested loop, the performance hit of a run-time ''if'' is negligible; if (and only if) your debugging code is an a deeply-nested loop, wrap it in a comment.

If you write test cases (or better yet test scripts), don't throw them away. Rerun your tests periodically, so you can avoid regressions. There are even tools that help in this, like [http://junit.sourceforge.net/ JUnit] (for Java; there are ports [http://sourceforge.net/projects/cppunit for C++] and other languages).

===Optimization===

You want your code to be as fast as possible, right? Wrong! Really, do you care if your favorite word processor saves a microsecond every time you type a character, or would you trade that microsecond for a greater reliability, so that it doesn't crash losing half a chapter of your precious thesis?

Optimizing code require (your) time, and sometimes the code becomes less readable and maintainable. So, concentrate your efforts on the parts of the program that really require it; measure the speed of your program, and use a [http://en.wikipedia.org/wiki/Profiler_%28computer_science%29 profiler] to identify the bottlenecks. A simple rule of thumb can be given: anything that is not inside a doubly-nested loop is not worth optimizing. Always measure your progress, as bottlenecks may change.

And never forget that a better algorithm beats any tweaking of your code. For example, if you are looking for the maximum in an array, sorting the array and taking the first element is a bad solution (it has at least O(n log n) complexity); if you don't need the sorted array for other purposes, a linear sweep of the array is faster (it's O(n)) and requires less memory.

===Indentation and spaces===

In most languages, spaces and indentation are not part of the syntax, and they are mostly ignored by the compiler (Python is a significant exception), yet indentation and spaces are very useful to format your code and make it more readable. There are many way to use them, but the first rule is 'consistency'. Choose the style you like the most, and stick to it; particularly, choose if you want to use spaces or tabs for indentation, and be consistent, otherwise when someone else opens your project with a different editor with a different idea of tab length, your nice (you made it nice, didn't you?) indentation will be screwed up.

===Warnings===

When compiled, your program should not raise any warnings. '''Any''' warnings, which includes harmless warnings. Compilers generate warnings for a reason: you have written a code that does something suspicious and you should look into it. So, if someone else compiles your program, should they also check that all the warnings of your code are harmless? Or how can they be sure that you effectively checked all warnings and you're not just a sloppy coder? :-) And what happens if they (or you) change your code that raises a gazillion of warnings? How can anyone spot any new warning?
So, please make sure that your code raises no warnings, and whoever will use it in the future will thank you for that.

==C and C++ code==

The [http://www.google.com/search?q=%22Linux+kernel+coding+style%22 Linux kernel coding style] is an interesting reading, particularly chapters 3 (Placing Braces and Spaces), 4 (Naming), 6 (Functions), 8 (Commenting), 12 (Macros).

C (and C++) have a fair number of operators, with strictly defined precedences. Even if you know all the precedence rules by heart, don't assume others do; so, please use parentheses when writing complex expressions.

If you are writing any non-trivial project (anything that spans more than one file of source code can be considered non-trivial), you may want to use [http://www.stack.nl/~dimitri/doxygen/ Doxygen] for documentation. It's simple to use, and after you've learned how it works, it doesn't require additional work. On the contrary, it helps you in keeping your code well documented.

In C++, never use the C-style cast operator, particularly with pointers. Use <code>static_cast</code> or a constructor for classes, and <code>dynamic_cast</code> for pointers. C-style casts are ambiguous, as they can mean many different type of casts, some of which are dangerous. The only situation where a C-style cast may have a place is for conversion between built-in numeric types.

===Header files===

Apparently, header (include) files can be problematic, probably because of the Java background common to many people nowadays. If you any doubt about them, Wikipedia does a good job in briefly explaining what [http://en.wikipedia.org/wiki/Header_file header files] are.

Major misconceptions regards what goes inside a header file. This a topic better described in a programming manual (and you've already read it, haven't you?), but a good rule of thumb is: only declarations and definitions that neither reserve memory nor produce code.

A header file should contain all (and only) the include directives necessary for its compilation, i.e., if the file makes use of any data type or symbol, it must include the header that defines such data type or symbol.

There can be problems with header files, due to multiple or recursive inclusions. To avoid them, you can wrap their content in a <code>#ifndef</code>...<code>#endif</code> construct (inside the header file!), like this:
#ifndef MY_PROJECT_MY_HEADER_H
#define MY_PROJECT_MY_HEADER_H
/* Real content of the file */
...
#endif
The name of the macro should be something that is unlikely to clash with other macros; e.g., prepend the name of your project.

==Matlab==

Matlab is a rather slow interpreted language, but it shines — as its name implies — at matrix manipulation. So try to avoid loops, and do operations in parallel on arrays. Many vectorized functions are built-in, so look in the help when you need simple operations like sums, means, maximum...

Matlab has a tool, <code>mlint</code>, that checks the code for easily detectable problems. It is active by default in the Matlab editor, and it highlight problems with jagged orange lines under the troubled code (and corresponding orange indicators on the right-hand bar). Don't ignore them, unless you are sure they are harmless; look up in the help or on the Web if don't understand a problem.

One of the problems spotted by <code>mlint</code> is the dynamic growth of arrays. Avoid that; it slows Matlab, as it turns O(n) algorithms into O(n²). For example,
a = [];
for k = 1:50000
a(k) = k;
end
takes more than 30 seconds on a machine, while
a = zeros(50000,1);
for k = 1:50000
a(k) = k;
end
takes only 0.1 seconds on the same machine. See
[http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f1-85766.html#f1-88760 the full explanation] on the Mathworks Web site.

Remember not to trust <code>mlint</code> too much; there is no perfect static analyzer (you remember [http://en.wikipedia.org/wiki/Rice%27s_theorem Rice's theorem], right?). If you have no warnings, it doesn't mean that your program is perfect.

Talk:Graphical user interface for an autonomous wheelchair

2009-08-05T12:28:09Z

BernardoDalSeno: Implementation of GUI: To do

==General==

The interface is used mainly to drive the [[LURCH - The autonomous wheelchair|Lurch wheelchair]]. It has different screens, corresponding to the different rooms or different environments where the wheelchair can move. The screens are organized hierarchically: a main screen permits to choose whether to drive the wheelchair or perform other tasks. The screens used for driving the wheelchair show a map of the environment, with different levels of details; e.g., a map might show just the rooms of a house, and then another map might show the living room with the furniture and ‘interesting’ positions (like near the table, in front of the TV, beside the window...).

The interface should be as [http://en.wikipedia.org/wiki/Accessibility accessible] as possible. It can be driven by a BCI, used with the touch screen or with the keyboard. The BCI is based on the P300 and ErrP potentials; so the interface should highlight the possible choices on at a time (in orthogonal groups if the choices are numerous), and show the choice detected by the BCI for ErrP-based confirmation.

Maybe the screen should be updated while the wheelchair navigates; e.g., when the wheelchair enter into the kitchen, the GUI shows the map of the kitchen.

===To Do===

==Map representation==
[[Image:Lurch_map_xml_structure_v2.png|600px|xml map structure]]

link to OpenOffice Draw source [[media:Lurch_map_xml_structure_v2.zip‎]]

link to a simple example [[media:Lurch_map_xml_example.xml.zip]] '''complete this example, it's very minimal'''

* If there is no map in a zone, the interface will show only the names of the the possible destinations (i.e., zones). If there is a map, zones are drawn as polygons ().
* If anything has no NAME, the ID is used instead.
* Costs for a portal are 1 by default; forbidden connections have infinite cost.
* Rooms that are portals have no destinations and no inner rooms.
* Colors currently are not saved by the cad and are not read by the bci gui.

==Communication Protocol Requirements==

* Cross-platform (at least Linux and Windows)
* Based on the IP protocol
* Asynchronous (as much as possible), so as not to block remote processes
* Preferably, the protocol should be in ASCII, with fixed-width fields (the number of fields is variable, by necessity).

===To Do===

* List of the pieces of information to be transferred between the application and the GUI

==Communication Protocol==
===UML Sequence Diagram===
====Diagram====

[[Image:ComunicationProtocol.jpg]]

====Comments about the diagram====
Structure of MessageA:
* Number of repetitions: number of flashings
* Number of stimulations: number of flashings in one repetition
* List of the stimulations: list of the possible stimulations with its type
* Number of types
* Stimulations sequence: it includes all the repetitions

Each stimulation must hav associated a type (e.g Icon, Row-Column)

Structure of SelectionA:
* For each number of stimulation types you have a equal number of ids (e.g for Icon it will be used 1 id, for Row-Column 2 ids)

Graphic example of id:

[[Image:IdExample.jpg]]

It will be also an end asynchronous message, that brings the BCI in pause, and it closes the graphic interface.

If the syncrony will be lost there's a Reset Message that restarts from the calibration. It will be activated when the number of the classifications is different from the number of the stimulations on the screen

== Implementation of GUI ==
=== Primo incontro (04/03/2009) ===

* Attualmente sulla carrozzella è installata una GUI molto semplice, che lavora all'interno del sistema BCI2000. L'idea è quella di creare una interfaccia asincrona che dovrà interagire con il sistema BCI2000 già realizzato mediante un socket TCP.

* Ci sono diverse possibilità per implementare la GUI:

0) Stimoliamo le singole location presenti all'interno della mappa: il problema è che può diventare pesante, e che può essere difficile dal punto di vista cognitivo per l'utente.

1) Per prima cosa stimoliamo i diversi locali, e poi stimoliamo le location appartenenti al singolo locale selezionato (in realtà dovremo continuare a stimolare anche gli altri locali, nel caso in cui l'utente volesse uscire dalla stanza!)
Le singole location possono essere stimolate in diversi modi: per gruppi, singolarmente, tramite una griglia.

2) Dividiamo la piantina in celle e poi le stimoliamo singolarmente. Questo approccio può essere problematico dal punto di vista della pianificazione del percorso: come fare se la location non è direttamente raggiungibile dall'interno della singola cella, per esempio a causa della presenza di un muro?

L'approccio 1) è decisamente il più naturale. Si può comunque pensare di sviluppare tutti i metodi e poi confrontarli.

* Le caratteristiche della GUI devono essere:
- menu gerarchico per la navigazione

- file di configurazione (direttamente lo stesso file del pianificatore) deve definire la piantina, le stanze, le location, (gruppi di location?).

* Il linguaggio in cui sviluppare la GUI può essere
- MAIA forte rischio di avere problemi di sincronizzazione!

- SDL su C++. Optiamo per questa scelta, che presenta meno rischi.

* '''FATTO''' (disponibile su airBAT)
- interfaccia grafica con due quadrati che si illuminano in modo sincronizzato tra loro.

- interfaccia grafica con una semplice mappa, i cui ambienti si illuminano in maniera randomica. Da notare che le librerie usate sono SDL.h e SDL_image.h (quest'ultima è stata introdotta al momento della creazione delle stanze da illuminare e non nella precedente versione con i quadrati che si illuminano in modo sincrono)

=== Secondo incontro (19/03/2009) ===

* I sorgenti realizzati sono stati provati sulla carrozzina e funzionano correttamente. Il monitor non deve essere settato ad un livello troppo luminoso, altrimenti i fotodiodi vanno in saturazione.

* Problema delle mappe: bisogna decidere come descrivere i vari ambienti della mappa. L'idea è quella di usare dei punti e delle rette. Inoltre il metodo che verrà deciso per la GUI dovrà essere lo stesso che utilizzerà anche il pianificatore. Eventualmente il metodo può essere generalizzabile per una qualsiasi mappa caricata.

* '''FATTO''' (disponibile su airBAT)
- estensione della precedente interfaccia grafica, realizzata utilizzando le librerie SDL_gfx. In questo modo è stato possibile "esternalizzare" il disegno delle primitive geometriche, rendendo più semplice l'individuazione dei poligoni di illuminazione delle varie stanze a partire dagli spigoli delle stanze stesse.

=== Terzo incontro (09/04/2009) ===

* Il presente incontro è stato interamente dedicato alla discussione e formalizzazione di uno schema comune di descrizione delle mappe. Il modello (la cui descrizione è visibile nella sezione 'Map representation') verrà utilizzato sia da coloro che realizzeranno l'interfaccia grafica, sia da coloro che dovranno migliorare il pianificatore attualmente funzionante sulla carrozzina.

* Si è deciso di utilizzare un modello basato sul linguaggio XML, grazie alle sue caratteristiche di flessibilità e semplicità.

* Per quello che riguarda la GUI, alcune parti (scelta della zona, del piano...) saranno realizzate mediante l'illuminazione di scritte, mentre altre parti (scegliere la singola stanza o la singola location all'interno della stanza) mediante l'illuminazione della mappa vera e propria.

* '''SVILUPPI FUTURI'''
- utilizzo di "portali" per il passaggio diretto tra luoghi diversi, anche a diversi livelli dell'albero XML. Al momento attuale, ci si potrà spostare di un solo livello per volta.

- studio dei diversi colori da utilizzare nell'interfaccia grafica

* '''FATTO''' (disponibile su AIRbat)
- realizzazione di un parser xml mediante l'utilizzo delle librerie libxml2

- realizzazione delle parti riguardanti le zone e i piani (illuminazione di scritte).

=== Quarto incontro (11/05/2009) ===

* Il presente incontro è stato dedicato alla discussione di alcuni problemi riscontrati nella fase di scrittura e ingegnerizzazione del codice.

* Warning: per essere certi di veder visualizzati tutti gli eventuali warning, in fase di compilazione bisogna digitare sia -Wall che -W

* Header: nei file .h bisogna solamente inserire la definizione della funzione e non la funzione di per sè: è un errore dal punto di vista logico, ma può creare anche problemi di funzionamento (doppie definizioni...).

* Modularizzazione: l'idea è quella di creare tante funzioni piccole che fanno poche cose molto precise, anche in un'ottica di eventuale riuso e manutenzione. Si può implementare una funzione che crea la struttura dati dal file XML e una che la usa. All'interno di quest'ultima, altre funzioni che passano da un menu all'altro, che disegnano la schermata per gli elenchi, che disegnano la schermata per le cartine, che illuminano gli elenchi, che illuminano le cartine...

* XML: creare una struttura dati esterna per evitare di dover usare direttamente il file XML che descrive gli ambienti da visualizzare. Questo per problematiche di efficienza, ma soprattutto per separare da un punto di vista logico la descrizione del problema e la struttura per la sua soluzione. L'idea è quella di creare un albero "gemello", eliminando tutti i nodi aggiuntivi (e inutili ai nostri fini) del file XML (commenti...)

* '''FATTO''' (disponibile su AIRbat - cartella versiontwo)
- Riscrittura del codice secondo la nuova struttura dati adottata

- Il codice è stato modularizzato

=== Quinto incontro (05/06/2009) ===

* Nella precedente versione della struttura dati era stato creato un albero per riprodurre fedelmente quella che era la struttura del file xml in un novo file in memoria. Questa soluzione è funzionalmente corretta, ma in realtà inutile: il nostro fine è quello di creare una applicazione che deve funzionare in un ambito ben specifico, e non è dunque necessario approntare un modello generale, che può essere utilizzato in diverse situazioni. Inoltre un albero è per definizione un qualcosa di dinamico, che può crescere nel tempo: nel nostro caso, invece, la struttura viene creata una volta sola (quando viene parsato l'albero xml) e poi non viene più modificata.

* La soluzione che è stata concordata è stata quella di "appiattire" la struttura ad albero (con l'eliminazione dei puntatori a nodo padre, figlio e fratello) e di inserire delle strutture vector (che fondamentalmente possono essere visti come degli "array dinamici") in cui vengono elencati tutti i vari figli di un particolare nodo.

* Verrà mantenuta la struttura gerarchica precedente, ma la classe Node diventerà una classe astratta, i cui metodi principali (draw, highlight e select) dovranno essere implementati nelle classi figlie.

* I nodi xml polyline, location e contour non erediteranno da Node, ma saranno delle semplici strutture (dato che non hanno bisogno dei tre metodi principali) che saranno incluse nelle varie room.

* Verrà creato un file header in cui inserire tutte le costanti che saranno utilizzate nell'applicazione: in questo modo è più facile trovarle e modificarle nel caso ce ne fosse bisogno.

=== Sesto incontro (24/07/2009) ===

* E' necessario ripensare in parte il meccanismo di fornitura degli attributi delle zone, stanze ecc: invece di usare dei semplici metodi getter (che di fatto violano il concetto di information hiding, in quanto forniscono delle informazioni all'interno di classi non di loro competenza) è meglio creare dei metodi appositi che incapsulano al loro interno il codice di modifica degli attributi. Effetto di tale modifica è anche quello di operare un'ulteriore modularizzazione del codice,

* Invece di usare dei setter per la creazione della struttura, è buona cosa sostituirli con dei costruttori pensati appositamente.

* '''FATTO''' (disponibile su AIRbat - cartella ptrFinalVersion)
- Riscrittura del codice secondo le indicazioni sopra riportate (quinto e sesto incontro).

=== Settimo incontro (30/07/2009) ===

* Si è deciso di eliminare la funzione navigateAndFill che fino ad ora si occupava di creare la struttura dati, optando per l'"inglobamento" di tale funzione all'interno dei vari costruttori che, ora, dovranno anche navigare l'albero xml in cui viene descritta la mappa.
* Bisogna aggiungere una funzione che, all'interno della select, mostri quella che è stata la scelta appena effettuata, al fine di avere un ulteriore feedback da parte dell'utente.
* Si è cominciato a discutere di quello che deve essere il nostro lavoro per la seconda parte del progetto, ovvero quella che riguarda la comunicazione tra lanostra nuova GUI e BCI2000/Galileo (che sono già installati sulla lurch).
Si è deciso di suddividere il lavoro in questo modo: agosto -> creazione del protocollo di comunicazione in locale nei nostri pc, utilizzando delle connessioni "fake"; settembre (primi 20 giorni) -> trasporto del tutto nel contesto reale; 22 settembre -> laurea

* '''FATTO''' (disponibile su AIRbat - cartella ptrFinalVersion)
- Nuovi costruttori
- Feedback della scelta

===DA FARE===
* installazione di BCI2000 sui nostri computer e inizio del lavoro di connessione, controllando innanzitutto se la classe di comunicazione socket di BCI2000 è esportabile sotto Linux, magari con l'apporto di piccole modifiche
* L'ordine di illuminazione delle scelte avvenga attraverso una serie di permutazioni della lista delle possibili opzioni; non dev'essere mai illuminato due volte consecutive la stessa scelta (si faccia attenzione all'ultimo e primo elemento di due permutazioni successive).
* Verificare la coerenza dell'albero delle scelte al caricamento dal file xml.
* Imporre un'altezza massima ai rettangoli di selezione delle zone
* Aggiungere dimensione del font tra i parametri
* Aggiungere posizone X del rettangolo di sincronizzazione tra i parametri
* Mettere i nomi dei parametri nei prototipi
* Nei commenti delle funzioni spiegare sempre:
** Cosa sono i parametri in ingresso
** Qual è il risultato restituito
** Cosa fa la funzione
** Quali sono gli effetti collaterali (es., variabili o attributi aggiornati)
** Condizioni di errore (eccezioni sollevate; comportamento nei casi anomali, es. file mancante)
* Eliminare l'attributo ''type'' dalla classe ''Node''

IIT-Lab

2009-08-03T16:17:06Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, [http://www.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=101039811798485926206.00045c07a77c0f575377f&ll=45.481957,9.238375&spn=0.005363,0.008433&z=17 Via Rimembranze di Lambrate, 14, Milan].

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Tuesday 4 August|| 16:00-19:30 || [[User:BernardoDalSeno]] || EEG
|-
| Wednesday 5 August|| 9:30-16:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

IIT-Lab

2009-08-03T16:16:32Z

BernardoDalSeno: /* Location */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, [http://www.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=101039811798485926206.00045c07a77c0f575377f&ll=45.481957,9.238375&spn=0.005363,0.008433&z=17 Via Rimembranze di Lambrate, 14, Milan].

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Wednesday 5 August|| 9:30-16:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

The AIRlab sites

2009-08-03T16:14:32Z

BernardoDalSeno:

The AIRLAb facilities are distributed on '''5 different sites'''. The following links lead to the pages of the [http://www.airlab.elet.polimi.it/ AIRLab site] containing detailed information about those sites.

* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_como AIRLab Como]
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_dei AIRLab DEI]
[http://www.google.com/maps/ms?ie=UTF8&hl=en&t=h&msa=0&msid=101039811798485926206.00045c07a77c0f575377f&ll=45.478896,9.232314&spn=0.005364,0.008433&z=17 Locate on Google Maps]
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_durando AIRLab Durando]
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]
[http://www.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=101039811798485926206.00045c07a77c0f575377f&ll=45.481957,9.238375&spn=0.005363,0.008433&z=17 Locate on Google Maps]
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_lambrate AIRLab Lambrate]
[http://www.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=101039811798485926206.00045c07a77c0f575377f&ll=45.481957,9.238375&spn=0.005363,0.008433&z=17 Locate on Google Maps]

Some experiments require external controlled conditions (no mobiles must ring, no people have to talk...) and particular instruments ([[Electroencephalographs]], [[Biofeedback and neurofeedback systems]]). If this is the case, you can book the IIT-Lab by going to [[IIT-Lab|its own page within the AIRWiki]]. Of course you have to be a [[Registered users|registered user]] to do that.

For a list of the material that you can find in the various AIRLab sites and use for your work, see [[What's in the AIRLab]].

IIT-Lab

2009-08-03T13:07:11Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Wednesday 5 August|| 9:30-16:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

IIT-Lab

2009-08-03T10:13:14Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Tuesday 4 August|| 9:30-16:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

IIT-Lab

2009-07-30T13:55:27Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Friday 30 July|| 9:30-13:30 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

Airpaper

2009-07-27T22:28:56Z

BernardoDalSeno:

Airpaper

2009-07-27T22:26:22Z

BernardoDalSeno: Deleted /* Crash Course */

Using Subversion

2009-07-27T22:25:52Z

BernardoDalSeno: /* Command Line Crash Course */

For general information about Subversion and how to use it, please see the [http://svnbook.red-bean.com/ Subversion manual]. If you are not familiar with version-control systems, the first chapter of the manual is a must-read. If you are familiar with [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], please read at least [http://svnbook.red-bean.com/nightly/en/svn.forcvs.html Appendix B] of the manual. From the command line, ''svn help'' gives you a complete overview of the commands and their use.

On the [http://www.bci2000.org/wiki/index.php BCI2000 Wiki], you can find good tutorials on [http://www.bci2000.org/wiki/index.php/Programming_Howto:SVN_Client_Setup using the Subversion client] and
[http://www.bci2000.org/wiki/index.php/Programming_Howto:Using_TortoiseSVN TortoiseSVN]. They have been written for BCI2000, but can be used also for other repositories if you change the URLs. Another graphical front-end for Subversion is [http://rapidsvn.tigris.org/ RapidSVN], which is cross-platform and works with Linux.

See also the [[Configuring Subversion]] page.

==Quick Introduction==
Please really do read the [http://svnbook.red-bean.com/ Subversion manual], and in particular the first chapter if you are new to version-control systems or the Appendix B if you are used to CVS. Here follows a short list of the tasks that you can accomplish using Subversion, so you have an idea of what you can (or should) do.
;Checkout
:'Checkout' refers to getting a copy of the repository on your local disk. The <tt>svn checkout</tt> command creates a mirror of the repository, with all files and directories and some metadata used by Subversion to keep things in sync. You can checkout just a part (a subdirectory) of a repository, if you like. Please notice that since version 1.5 of the Subversion client you can also exclude specific subdirectories from the checkout; for more details please refer to the [http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html Sparse directory feature on the manual].
;Creating new files from scratch
:Create the file as usual (e.g., File->New from your favorite editor) and add it to the repository when you have the first version ready. You can use the <tt>svn add</tt> command from the command line or the equivalent command from a graphical front-end.
;Creating new files from existing files
:Use the <tt>svn copy</tt> command (or the equivalent menu entry of a graphical front-end) to create a copy of the file and edit the new file. This is needed to preserve the modification history; do not make the copy with a file manager or operating system commands.
;Renaming or moving files/directories
:The <tt>svn move</tt> command is the correct way to rename a file/directory or to move it from a directory to another one. Do not use a file manager or other operating system commands, as this will lose the history of the file.
;Creating new directories
:Use the <tt>svn mkdir</tt> command. Alternatively, you can create a directory with you favorite file manager and then use the <tt>svn add</tt> command (in this case any file in the directory may be added to the repository).
;Commit changes
:This is '''important'''. Every change you make is local until you perform a commit; from the command line, use <tt>svn ci</tt>. This transfers the local changes to the repository on the server (it works in one direction only: It doesn't fetch modifications from the server).
;Update from the server
:In order to receive the modifications made by others on the repository you have to issue an <tt>svn update</tt> command. This modifies only your local copy, and doesn't modify in any way what's on the server.
:It's a good practice to make an update every time you begin to work on a file, so you get notified of any change that someone else has made.
;View history and changes
:You can examine the history of a file or directory with the <tt>svn log</tt> command. It shows who made any modification to the repository and when, and also which files were affected.
:You can examine the differences between your local version of a file or directory and any older version, or between two old versions. Please refer to the help on the <tt>svn diff</tt> command for the details.
;Retrieving or restoring old versions
:You can access an old version of a file with <tt>svn cat</tt> command.

===Command Line Crash Course===
This is a short list of commands you can use to start using a Subversion repository immediately:
$ svn co <nowiki>https://svn.ws.dei.polimi.it/REPOSITORY</nowiki>
or for a subdirectory just
$ svn co <nowiki>https://svn.ws.dei.polimi.it/REPOSITORY/PATH</nowiki>

To add a new file or directory (directories are imported recursively) to the repository just execute
$ svn add <filename/dirname>
This code does not actually update the Subversion repository. In order to do this you need to check-in the change with
$ svn ci <filename/dirname>
you can use this command to check-in any change to your local files, not just to import new ones.

If you just want to check if something has changed locally or remotely, you can use
$ svn stat
while to update your local version with the latest changes in the repository you just need to update with
$ svn update
This command might generate conflicts you need to settle... but this is another story and you should read it on [http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve the manual]

This may always come handy:
$ svn help

Using Subversion

2009-07-27T22:25:12Z

BernardoDalSeno:

For general information about Subversion and how to use it, please see the [http://svnbook.red-bean.com/ Subversion manual]. If you are not familiar with version-control systems, the first chapter of the manual is a must-read. If you are familiar with [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], please read at least [http://svnbook.red-bean.com/nightly/en/svn.forcvs.html Appendix B] of the manual. From the command line, ''svn help'' gives you a complete overview of the commands and their use.

On the [http://www.bci2000.org/wiki/index.php BCI2000 Wiki], you can find good tutorials on [http://www.bci2000.org/wiki/index.php/Programming_Howto:SVN_Client_Setup using the Subversion client] and
[http://www.bci2000.org/wiki/index.php/Programming_Howto:Using_TortoiseSVN TortoiseSVN]. They have been written for BCI2000, but can be used also for other repositories if you change the URLs. Another graphical front-end for Subversion is [http://rapidsvn.tigris.org/ RapidSVN], which is cross-platform and works with Linux.

See also the [[Configuring Subversion]] page.

==Quick Introduction==
Please really do read the [http://svnbook.red-bean.com/ Subversion manual], and in particular the first chapter if you are new to version-control systems or the Appendix B if you are used to CVS. Here follows a short list of the tasks that you can accomplish using Subversion, so you have an idea of what you can (or should) do.
;Checkout
:'Checkout' refers to getting a copy of the repository on your local disk. The <tt>svn checkout</tt> command creates a mirror of the repository, with all files and directories and some metadata used by Subversion to keep things in sync. You can checkout just a part (a subdirectory) of a repository, if you like. Please notice that since version 1.5 of the Subversion client you can also exclude specific subdirectories from the checkout; for more details please refer to the [http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html Sparse directory feature on the manual].
;Creating new files from scratch
:Create the file as usual (e.g., File->New from your favorite editor) and add it to the repository when you have the first version ready. You can use the <tt>svn add</tt> command from the command line or the equivalent command from a graphical front-end.
;Creating new files from existing files
:Use the <tt>svn copy</tt> command (or the equivalent menu entry of a graphical front-end) to create a copy of the file and edit the new file. This is needed to preserve the modification history; do not make the copy with a file manager or operating system commands.
;Renaming or moving files/directories
:The <tt>svn move</tt> command is the correct way to rename a file/directory or to move it from a directory to another one. Do not use a file manager or other operating system commands, as this will lose the history of the file.
;Creating new directories
:Use the <tt>svn mkdir</tt> command. Alternatively, you can create a directory with you favorite file manager and then use the <tt>svn add</tt> command (in this case any file in the directory may be added to the repository).
;Commit changes
:This is '''important'''. Every change you make is local until you perform a commit; from the command line, use <tt>svn ci</tt>. This transfers the local changes to the repository on the server (it works in one direction only: It doesn't fetch modifications from the server).
;Update from the server
:In order to receive the modifications made by others on the repository you have to issue an <tt>svn update</tt> command. This modifies only your local copy, and doesn't modify in any way what's on the server.
:It's a good practice to make an update every time you begin to work on a file, so you get notified of any change that someone else has made.
;View history and changes
:You can examine the history of a file or directory with the <tt>svn log</tt> command. It shows who made any modification to the repository and when, and also which files were affected.
:You can examine the differences between your local version of a file or directory and any older version, or between two old versions. Please refer to the help on the <tt>svn diff</tt> command for the details.
;Retrieving or restoring old versions
:You can access an old version of a file with <tt>svn cat</tt> command.

===Command Line Crash Course===
This is a short list of commands you can use to start using a Subversion repository immediately:
$ svn co <nowiki>https://svn.ws.dei.polimi.it/REPOSITORY</nowiki>
or for a subdirectory just
$ svn co <nowiki>https://svn.ws.dei.polimi.it/REPOSITORY/PATH</nowiki>

To add a new file or directory (directories are imported recursively) to the repository just execute
$ svn add <filename/dirname>
This code does not actually update the Subversion repository. In order to do this you need to check-in the change with
$ svn ci <filename/dirname>
you can use this command to check-in any change to your local files, not just to import new ones.

If you just want to check if something has changed locally or remotely, you can use
$ svn stat
while to update your local version with the latest changes in the repository you just need to update with
$ svn update
This command might generate conflicts you need to settle... but this is another story and you should read it [http://svnbook.red-bean.com/en/1.5/svn.tour.cycle.html#svn.tour.cycle.resolve the manual]

This may always come handy:
$ svn help

AirBAT Instructions

2009-07-27T16:10:52Z

BernardoDalSeno: /* Becoming a member */

[https://svn.ws.dei.polimi.it/airbat/ AirBAT] is a repository containing software developed in projects related to the [[BioSignal Analysis]] area.

== Becoming a member ==
AirBAT is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airbat/</nowiki>''.

Students who need to work with AirBAT should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should then ask their supervisor to confirm their account (supervisors, here are [[DEI Subversion Administration#Let users create their own accounts|the instructions for you]]).

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

DEI Subversion Administration

2009-07-27T16:10:46Z

BernardoDalSeno:

This page contains instruction for administrator of Subversion repository hosted on the departmental servers.

==Adding a new user==
To add a new user, do the following:
* Go to https://acme.elet.polimi.it/ and login with your Dei account
* If needed, [[#Creating a new account|Create a new account]]
* Edit the file ''trac.ws.dei.polimi.it:/var/www/trac/<REPOSITORY>/conf/authz''; the syntax is described on the [https://svn.ws.dei.polimi.it/authz.plp help page] on the Subversion server. Editing is done in three steps:
** Copy the file to your computer using scp: <pre>scp -p <YOUR_USERNAME>@trac.ws.dei.polimi.it:/var/www/trac/<REPOSITORY>/conf/authz /tmp/</pre>
** Edit the file ''/tmp/authz''
** Copy the file back to the server: <pre>scp -p /tmp/authz <YOUR_USERNAME>@trac.ws.dei.polimi.it:/var/www/trac/<REPOSITORY>/conf/</pre>

==Creating a new account==
The best way to create a new account is to ask the user to do it: [[#Let users create their own accounts|Let users create their own accounts]]

This operation can be performed by anyone who has a valid departmental account.
* Go to https://acme.elet.polimi.it/ and login with your Dei account
* Select 'Accounts' -> 'New account'
* Fill in the data (users can subsequently change their passwords)

==Let users create their own accounts==
This procedure let the users to select all the details of the account, so the supervisor has only to confirm the account.

Instructions for a new user:
* Go to https://acme.ws.dei.polimi.it/request_account.plp and fill the form. Select your supervisor (or colleague, or whatever) from Dei as the "Dei responsible".
* Ask your ''Dei responsible'' (e.g., by email) to extend the duration of the account.

Instructions for the Dei responsible to confirm a newly created account
* Login on https://acme.ws.dei.polimi.it/
* Select 'Accounts' -> 'Modify accounts'
* Select the new user from the list
* Click on the 'Extend' button near the expiration date

IIT-Lab

2009-07-25T16:57:17Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Monday 27 July|| 14:30-18:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

AirBAT Instructions

2009-07-24T17:01:01Z

BernardoDalSeno: /* Becoming a member */

[https://svn.ws.dei.polimi.it/airbat/ AirBAT] is a repository containing software developed in projects related to the [[BioSignal Analysis]] area.

== Becoming a member ==
AirBAT is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airbat/</nowiki>''.

Students who need to work with AirBAT should fill the form at https://acme.ws.dei.polimi.it/request_account.plp with their info and put their supervisor in the "DEI responsible" field. They should wait for the authorization from their supervisor.

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

Writing Good Code

2009-07-02T10:20:45Z

BernardoDalSeno: /* General */

==Why this page==
When tutoring students for their theses or projects, I often find many problems with the code they write. I'm not referring to bugs; bugs happen, as flu happens, although there are some things you can do to make them more unlikely. The problem discussed here is ''Bad code''TM, i.e., code that nobody can read or understand, not even its author. So I've decided to write this page with some advice on how to write ''Good code''TM. Please note that everything you find in this page should not be considered as strict rules, as it expresses the point of view of its author(s); but a reasonable piece of advice needs a good reason to counter it, in order not to follow it; so at least think about it. Contributions are welcome.
::--Bernardo

==General==

The source of the program is not only a way to obtain a binary that your computer can run, it is a way to express ideas. They should be clear to the compiler, so it compiles and you have your nice executable, but they should be clear also to anyone that reads your code, including your fellow students, your supervisor, and, of course, '''you''' — even after a couple of months. Writing a program is the ultimate way to check your ideas and hypothesis. So, '''write for you and your fellows, not only for the computer!'''

===I Think Therefore I Program===

And the inverse is true: you cannot program without thinking. So, before rushing to the keyboard, take a piece of paper and try to lay down your ideas. A clear idea of the structure of data and the algorithm you want to apply is important to write a properly working program. Think about how you're going to use the data and shape the data structures accordingly; think about how to factorize your algorithm, what functions (methods) and what parameters you need.

===Names===

Names should be meaningful, clear, short (at least, not too long), and to the point. That applies to pretty everything: classes, variables, functions, modules, members. Remember: the compiler doesn't care about names, but humans do; your colleagues are humans, and probably they want to understand your code when they happen to read it. If the project you are working on or the language you are using come with a naming convention just follow it; separate words in names by using underscores '_' or mixedCaseLikeThis.

In general, you want to use nouns or adjectives as names for variable and attributes, while verbs are appropriate for functions and methods. Names with a wider scope (classes, public methods, global variables, global functions...) require more care: They cannot be too simple to avoid clashing with local names, and both the meaning and the context should be clear. 'tmp' can be a good name for a local variable with a life of a couple of lines of code, or 'k' is good for a loop counter, but they are really bad names for anything with a scope wider than a loop. For example, if you have to store the name of a temporary file where you save the result of the application of a fast Fourier transform, something like 'fft_file_name' is more appropriate; if you have a counter that keeps track of the number of time you called the 'evaluate_fitness()' method (e.g., for statistical purposes), you could chose something like 'fitness_call_count'. Completely uninformative and generic names like 'var', 'flag', 'foo', 'pippo', 'number'... are always bad.

===Comments===

A big problem is the use of comments. You can encounter projects with hundreds of lines of code and not a single line of comment, so that it is hard to guess even the general purpose of the program, or projects with ultra-verbose comments, like this:
k = k + 1; // increment k
Yeah, thanks, I thought it was extracting the square root of k.

Comments are important, and their correct use improves the quality of the code, even when there are no comments. Really! Often comments are written as a patch to badly-written code, but a tangled piece of code is not a way to clearly convey your ideas; and a comment added to a tangled piece of code doesn't make it much clearer. Besides, if you can't understand a piece of code, does some comment raise your confidence that the code is really working? Tangled code is more likely to be bugged, and more difficult to modify, so please write your algorithm in a way that it can be understood just be reading the instructions, not the comments. There are [http://www.ioccc.org/ good places] where to write obfuscated code, and a thesis is not one of them.

Just an example (taken from real code! names have been changed to protect the innocent):
#define NUM_IT 3
for (j = 0; j < NUM_IT; ++j) {
if (j == 0) { // First iteration
// Do something
...
} else if (j == 1) { // Second iteration
// Do something else
...
} else if (j == 2) { // Third iteration
// Do things
...
}
}
This is a rather confusing way to write a simple sequence:
// Do something
...
// Do something else
...
// Do things
...

So, what to comment? Good places for comments are class declarations, functions or methods (you tell what the function is about, what the parameters are, and describe the expected results and side effects), class attribute declarations, global or important variables, the beginning of a file, and a few others. Also, when you take a tricky decision, please document it!

===Debugging===

There is no program without a bug (or was it "There is no rose without a bug"?). Your programs are no exception, so you'll have to remove bugs. Many books could be written about debugging (and they are), but here just a few ideas are hinted.

When you experience a failure, don't rush hacking at the code until it disappears. We are in an engineering school, so use the engineering method: build a model. In other words, try to pinpoint the error that caused the failure, before trying to remove it. Do tests and explore the functioning of your program in order to find the problem; try to find a way to make the failure reproducible, so after you correct the error you can check that everything is working properly. Debuggers are useful to inspect the state of the program, but you can use also [http://en.wikipedia.org/wiki/Assertion_%28computing%29 assertions] and <code>printf</code>s (or the output function of your favorite language) when you can't or don't want to run a debugger.

Sometimes you have to write some debugging code to check conditions, to validate data structures, or print out the value of variables.
This code is not needed when you've finished debugging, but this no reason for removing it. If you spent time writing code, don't waste your effort; you or someone else may need it in the future to debug a similar problem. Leave it in place; surround it with conditionals: <code>#ifdef DEBUG</code> if you are using C, or <code>if (debug)</code> in Java or other languages that have no preprocessor (<code>debug</code> is a global variable in this case); in this way, it is easy to activate it. Unless the code is inside a deeply-nested loop, the performance hit of a run-time ''if'' is negligible; if (and only if) your debugging code is an a deeply-nested loop, wrap it in a comment.

If you write test cases (or better yet test scripts), don't throw them away. Rerun your tests periodically, so you can avoid regressions. There are even tools that help in this, like [http://junit.sourceforge.net/ JUnit] (for Java; there are ports [http://sourceforge.net/projects/cppunit for C++] and other languages).

===Optimization===

You want your code to be as fast as possible, right? Wrong! Really, do you care if your favorite word processor saves a microsecond every time you type a character, or would you trade that microsecond for a greater reliability, so that it doesn't crash losing half a chapter of your precious thesis?

Optimizing code require (your) time, and sometimes the code becomes less readable and maintainable. So, concentrate your efforts on the parts of the program that really require it; measure the speed of your program, and use a [http://en.wikipedia.org/wiki/Profiler_%28computer_science%29 profiler] to identify the bottlenecks. A simple rule of thumb can be given: anything that is not inside a doubly-nested loop is not worth optimizing. Always measure your progress, as bottlenecks may change.

And never forget that a better algorithm beats any tweaking of your code. For example, if you are looking for the maximum in an array, sorting the array and taking the first element is a bad solution (it has at least O(n log n) complexity); if you don't need the sorted array for other purposes, a linear sweep of the array is faster (it's O(n)) and requires less memory.

===Indentation and spaces===

In most languages, spaces and indentation are not part of the syntax, and they are mostly ignored by the compiler (Python is a significant exception), yet indentation and spaces are very useful to format your code and make it more readable. There are many way to use them, but the first rule is 'consistency'. Choose the style you like the most, and stick to it; particularly, choose if you want to use spaces or tabs for indentation, and be consistent, otherwise when someone else opens your project with a different editor with a different idea of tab length, your nice (you made it nice, didn't you?) indentation will be screwed up.

===Warnings===

When compiled, your program should not raise any warnings. '''Any''' warnings, which includes harmless warnings. Compilers generate warnings for a reason: you have written a code that does something suspicious and you should look into it. So, if someone else compiles your program, should they also check that all the warnings of your code are harmless? Or how can they be sure that you effectively checked all warnings and you're not just a sloppy coder? :-) And what happens if they (or you) change your code that raises a gazillion of warnings? How can anyone spot any new warning?
So, please make sure that your code raises no warnings, and whoever will use it in the future will thank you for that.

==C and C++ code==

The [http://www.google.com/search?q=%22Linux+kernel+coding+style%22 Linux kernel coding style] is an interesting reading, particularly chapters 3 (Placing Braces and Spaces), 4 (Naming), 6 (Functions), 8 (Commenting), 12 (Macros).

C (and C++) have a fair number of operators, with strictly defined precedences. Even if you know all the precedence rules by heart, don't assume others do; so, please use parentheses when writing complex expressions.

If you are writing any non-trivial project (anything that spans more than one file of source code can be considered non-trivial), you may want to use [http://www.stack.nl/~dimitri/doxygen/ Doxygen] for documentation. It's simple to use, and after you've learned how it works, it doesn't require additional work. On the contrary, it helps you in keeping your code well documented.

In C++, never use the C-style cast operator, particularly with pointers. Use <code>static_cast</code> or a constructor for classes, and <code>dynamic_cast</code> for pointers. C-style casts are ambiguous, as they can mean many different type of casts, some of which are dangerous. The only situation where a C-style cast may have a place is for conversion between built-in numeric types.

===Header files===

Apparently, header (include) files can be problematic, probably because of the Java background common to many people nowadays. If you any doubt about them, Wikipedia does a good job in briefly explaining what [http://en.wikipedia.org/wiki/Header_file header files] are.

Major misconceptions regards what goes inside a header file. This a topic better described in a programming manual (and you've already read it, haven't you?), but a good rule of thumb is: only declarations and definitions that neither reserve memory nor produce code.

A header file should contain all (and only) the include directives necessary for its compilation, i.e., if the file makes use of any data type or symbol, it must include the header that defines such data type or symbol.

There can be problems with header files, due to multiple or recursive inclusions. To avoid them, you can wrap their content in a <code>#ifndef</code>...<code>#endif</code> construct (inside the header file!), like this:
#ifndef MY_PROJECT_MY_HEADER_H
#define MY_PROJECT_MY_HEADER_H
/* Real content of the file */
...
#endif
The name of the macro should be something that is unlikely to clash with other macros; e.g., prepend the name of your project.

==Matlab==

Matlab is a rather slow interpreted language, but it shines — as its name implies — at matrix manipulation. So try to avoid loops, and do operations in parallel on arrays. Many vectorized functions are built-in, so look in the help when you need simple operations like sums, means, maximum...

Matlab has a tool, <code>mlint</code>, that checks the code for easily detectable problems. It is active by default in the Matlab editor, and it highlight problems with jagged orange lines under the troubled code (and corresponding orange indicators on the right-hand bar). Don't ignore them, unless you are sure they are harmless; look up in the help or on the Web if don't understand a problem.

One of the problems spotted by <code>mlint</code> is the dynamic growth of arrays. Avoid that; it slows Matlab, as it turns O(n) algorithms into O(n²). For example,
a = [];
for k = 1:50000
a(k) = k;
end
takes more than 30 seconds on a machine, while
a = zeros(50000,1);
for k = 1:50000
a(k) = k;
end
takes only 0.1 seconds on the same machine. See
[http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f1-85766.html#f1-88760 the full explanation] on the Mathworks Web site.

Remember not to trust <code>mlint</code> too much; there is no perfect static analyzer (you remember [http://en.wikipedia.org/wiki/Rice%27s_theorem Rice's theorem], right?). If you have no warnings, it doesn't mean that your program is perfect.

Master Level Theses

2009-06-30T14:13:20Z

BernardoDalSeno: Brain-Computer Interface: removed p300 repetions project

Here you can find proposals for master thesis (20 CFU for each student). See [[Project Proposals]] for other kinds of projects and theses.

==== Evolutionary Optimization and Stochastic Optimization ====

{{Project template
|title=Combinatorial optimization based on stochastic relaxation
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc-AT-elet-DOT-polimi-DOT-it]), [[User:LuigiMalago|Luigi Malagò]] ([mailto:malago-AT-elet-DOT-polimi-DOT-it email])
|description=The project will focus on the study, implementation, comparison and analysis of different algorithms for the optimization of pseudo-Boolean functions, i.e., functions defined over binary variables with values in R. These functions have been studied a lot in the mathematical programming literature, and different algorithms have been proposed [1]. More recently, the same problems have been faced in evolutionary computations, with the use of genetic algorithms, and in particular estimation of distribution algorithms [2,3]. Estimation of distribution algorithms are a recent meta-heuristic, where classical crossover and mutation operators used in genetic algorithms are replaced with operators that comes from statistics, such as sampling and estimation.

The focus will be on the implementation of a new algorithm able to combine different approaches (estimation and sampling, from one side, and exploitation of prior knowledge about the structure of problem, on the other), together with the comparison of the results with existing techniques that historically appear in different (and often separated) communities. Good coding (C/C++) abilities are required. Since the approach will be based on statistical models, the student is supposed to be comfortable with notions that come from probability and statistics courses. The project could require some extra effort in order to build and consolidate some background in math, especially in Bayesian statistics and MCMC techniques, such as Gibbs and Metropolis samplers [4].

The project can be extended to master thesis, according to interesting and novel directions of research that will emerge in the first part of the work. Possible ideas may concern the proposal of new algorithms able to learn existing dependencies among the variables in the function to be optimized, and exploit them in order to increase the probability to converge to the global optimum.

Picture taken from http://www.ra.cs.uni-tuebingen.de/

;Bibliography
*[1] Boros, Endre and Boros, Endre and Hammer, Peter L. (2002) Pseudo-boolean optimization. Discrete Applied Mathematics .
*[2] Pelikan, Martin; Goldberg, David; Lobo, Fernando (1999), A Survey of Optimization by Building and Using Probabilistic Models, Illinois: Illinois Genetic Algorithms Laboratory (IlliGAL), University of Illinois at Urbana-Champaign.
*[3] Larrañga, Pedro; & Lozano, Jose A. (Eds.). Estimation of distribution algorithms: A new tool for evolutionary computation. Kluwer Academic Publishers, Boston, 2002.
*[4] Image Analysis, Random Fields Markov Chain Monte Carlo Methods

|start=Anytime
|number=1-2
|cfu=20-40
|image=stochastic.jpg}}



==== BioSignal Analysis ====

===== Analysis of the Olfactory Signal =====
{{Project template
|title=Computational Intelligence techniques to analyse the olfactory signal acquired by an electronic nose for cancer diagnosis
|tutor=[[User:AndreaBonarini|Andrea Bonarini]] ([mailto:bonarini@elet.polimi.it email]), [[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucci@elet.polimi.it email]), [[User:RossellaBlatt|Rossella Blatt]] ([mailto:blatt@elet.polimi.it email])
|description= The electronic nose is an instrument able to detect and recognize odors, that is the volatile substances in the atmosphere or emitted by the analyzed substance. This device can react to a gas substance by providing signals that can be analyzed to classify the input. It is composed of a sensor array (MOS sensors, in our case) and a pattern classification system based on machine learning techniques. Each sensor reacts in a different way to the analyzed substance, providing multidimensional data that can be considered as a unique olfactory blueprint of the analyzed substance. We have already tested the use of the electronic nose as diagnostic tool for lung cancer; boosted from the very satisfactory results that we have achieved by these analysis, we want to investigate the possibility of diagnosing other types of cancer and to improve the current computation intelligence techniques.
The project is done in collaboration with the Istituto dei Tumori, Milano.

;Tools and instruments: Matlab

;Bibliography : BLATT R., BONARINI A, CALABRÒ E, DELLA TORRE M, MATTEUCCI M, PASTORINO U. (2008). Pattern Classification Techniques for Early Lung Cancer Diagnosis using an Electronic Nose. In: Frontiers in Artificial Intelligence and Applications. European Conference on Artificial Intelligence - Prestigious Applications of Intetelligent Systems. Patras, Greece. 21-15 luglio 2008. (vol. 178, pp. 693-697). ISBN/ISSN: 978-1-58603-891-5. IOS Press. [[Image:PAIS.pdf|Paper-PAIS2008]]

|start=Anytime (a new acquisition phase will start in March)
|number=1-2
|cfu=20
|image=Acquisition.jpg}}

===== Sleep Staging =====

{{Project template
|title=Development of a computer-assisted CAP (Sleep cyclic alternating pattern) scoring method
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), Martin Mendez ([mailto:martin.mendez@polimi.it email]), Anna Maria Bianchi ([mailto:annamaria.bianchi@polimi.it email]), Mario Terzano (Ospedale di Parma)
|description=In 1985, Terzano describes for the first time the Cyclic Alternating Pattern [http://en.wikipedia.org/wiki/Cyclical_alternating_pattern] during sleep and, nowadays, CAP is widely accepted by the medical community as basic analysis of sleep. The CAP evaluation is of fundamental importance since it represents the mechanism developed by the brain evolution to monitor the inner and outer world and to assure the survival during sleep. However, visual detection of CAP in polisomnography (i.e., the standard procedure) is a slow and time-consuming process. This limiting factor generates the necessity of new computer-assisted scoring methods for fast CAP evaluation. This thesis deals with the development of a Decision Support System for CAP scoring based on features extraction at multi-system level (by statistical and signal analysis) and Pattern Recognition or Machine Learning approaches. This may allow the automatic detection of CAP sleep and could be integrated, through reinforcement learning techniques, with the corrections given by physicians.

;Tools and instruments
:Matlab, C/C++

;Bibliography
: Mario Terzano, Liborio Parrino. ''Atlas, rules, and recording techniques for the scoring of cyclic alternating pattern (CAP) in human sleep'', Sleep Medicine 2 (2001) 537–553. [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6W6N-44DY2B4-8&_user=2620285&_coverDate=11%2F30%2F2001&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000058180&_version=1&_urlVersion=0&_userid=2620285&md5=aa61a060d005f23f6afed5c1fc2f1126]
|start=Anytime
|number=1-2
|cfu=20
|image=CAP_Sleep_Staging.jpg}}

===== Brain-Computer Interface =====

{{Project template
|title=Recognition of the user's focusing on the stimulation matrix
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=A [http://en.wikipedia.org/wiki/P300_(Neuroscience) P300]-based [[Brain-Computer_Interface|BCI]] stimulates the user continuously, and the detection of a P300 designates the choice of the user. When the user is not paying attention to the interface, false positives are likely. The objective of this work is to avoid this problem; the analysis of the electroencephalogram (EEG) over the visual cortex (and possibly an analysis of P300s or of other biosignals) should tell when the user is looking at the interface.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG system

;Bibliography
: E. Donchin, K.M. Spencer, R. Wijesinghe. ''The Mental Prosthesis: Assessing the Speed of a P300-Based Brain-Computer Interface'' [http://www.cs.cmu.edu/~tanja/BCI/P300Speed_2000.pdf]
|start=Anytime
|number=1-2
|cfu=20
|image=B_p300_speller.jpg}}

{{Project template
|title=Creation of new EEG training by introduction of noise
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=A [[Brain-Computer Interface|BCI]] must be trained on the individual user in order to be effective. This training phase require recording data in long sessions, which is time consuming and boring for the user. The aim of this project is to develop algorithm to create new training EEG (electroencephalography) data from existing ones, so as to speed up the training phase.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000]
:Knowledge of C++ may be useful
:EEG system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]
|start=Anytime
|number=1
|cfu=20
|image=Bci_arch.png}}

{{Project template
|title=Real-time removal of ocular artifact from EEG
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=In a [[Brain-Computer Interface|BCI]] based on electroencephalogram (EEG), one of the most important sources of noise is related to ocular movements. Algorithms have been devised to cancel the effect of such artifacts. The project consists in the in the implementation in real time of an existing algorithm (or one newly developed) in order to improve the performance of a BCI.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG-system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]
: R.J. Croff, R.J. Barry. ''Removal of ocular artifact from the EEG: a review'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=09877053&volume=30&issue=1&firstpage=5&form=html]
|number=1
|cfu=10-20
|image=B_bci.jpg}}

{{Project template
|title=Aperiodic visual stimulation in a VEP-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=[http://en.wikipedia.org/wiki/Evoked_potential#Visual_evoked_potential Visual-evoked potentials] (VEPs) are a possible way to drive the a [[Brain-Computer Interface|BCI]]. This projects aims at maximizing the discrimination between different stimuli.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]

|number=1
|cfu=20
|image=Bci_arch.png}}

{{Project template
|title=Driving an autonomous wheelchair with a P300-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. The work will be validated with live experiments.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000], Matlab
:Linux
:EEG system
:Lurch wheelchair

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]
|start=November 2008
|number=1
|cfu=5-20
|image=LURCH_wheelchair.jpg}}





==== Machine Learning ====

{{Project template
|title=Statistical inference for phylogenetic trees
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc-AT-elet-DOT-polimi-DOT-it]), [[User:LuigiMalago|Luigi Malagò]] ([mailto:malago-AT-elet-DOT-polimi-DOT-it email])
|description=The project will focus on the study, implementation, comparison and analysis of different statistical inference techniques for phylogenetic trees. Phylogenetic trees [1, 2] are evolutionary trees used to represent the relationships between different species with a common ancestor. Typical inference task concern the construction of a tree starting from DNA sequences, involving both the choice of the topology of the tree (i.e., model selection) and the values of the parameters (i.e., model fitting). The focus will be a probabilistic description of the tree, given by the introduction of stochastic variables associated to both internal nodes and leaves of the tree.

The project will focus on the understanding of the problem and on the implementation of different algorithms, so (C/C++ or Matlab or R) coding will be required. Since the approach will be based on statistical models, the student is supposed to be comfortable with notions that come from probability and statistics courses.

The project is thought to be extended to master thesis, according to interesting and novel directions of research that will emerge in the first part of the work. Possible ideas may concern the proposal and implementation of new algorithms, based on recent approaches to phylogenetic inference available in the literature, as in [3] and [4]. In this case the thesis requires some extra effort in order to build and consolidate some background in math in oder to understand some recent literature, especially in (mathematical) statistics and, for example, in the emerging field of algebraic statistics [5].

Picture taken from http://www.tolweb.org/tree/

;Bibliography
*[1] Felsenstein 2003: Inferring Phylogenies
*[2] Semple and Steel 2003: Phylogenetics: The mathematics of phylogenetics
*[3] Louis J. Billera, Susan P. Holmes and and Karen Vogtmann Geometry of the space of phylogenetic trees. Advances in Applied Math 27, 733-767 (2001)
*[4] Evans, S.N. and Speed, T.P. (1993). Invariants of some probability models used in phylogenetic inference. Annals of Statistics 21, 355-377.
*[5] Lior Pachter, Bernd Sturmfels 2005, Algebraic Statistics for Computational Biology.

|start=Anytime
|number=1-2
|cfu=20-40
|image=toloverview.jpg}}

{{Project template
|title=Reinforcement Learning in Poker
|tutor=Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=In this years, Artificial Intelligence research has shifted its attention from fully observable environments such as Chess to more challenging partially observable ones such as Poker.

Up to this moment research in this kind of environments, which can be formalized as Partially Observable Stochastic Games, has been more from a game theoretic point of view, thus focusing on the pursue of optimality and equilibrium, with no attention to payoff maximization, which may be more interesting in many real-world contexts.

On the other hand Reinforcement Learning techniques demonstrated to be successful in solving both fully observable problems, single and multi-agent, and single-agent partially observable ones, while lacking application to the partially observable multi-agent framework.

This research aims at studying the solution of Partially Observable Stochastic Games, analyzing the possibility to combine the Opponent Modeling concept with the well proven Reinforcement Learning solution techniques to solve problems in this framework, adopting Poker as testbed.
|start=Anytime
|number=1-2
|cfu=20-40
|image=PokerPRLT.png}}

{{Project template
|title= EyeBot
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it), Alessandro Giusti (giusti-AT-elet-DOT-polimi-DOT-it), and Pierluigi Taddei (taddei-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. So far, the controller developed for TORCS used as input only information extracted directly from the state of the game. The goal of this project is to extend the existing controller API (see [http://cig.dei.polimi.it/ here]) to use the visual information (e.g. the screenshots of the game) as input to the controllers. A successfull project will include both the development of the API and some basic imaga preprocessing to extract information from the images.
|start=Anytime
|number=1 to 2
|cfu=20
|image=TORCS2.jpg}}

{{Project template
|title= SmarTrack
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=The generation of customized game content for each player is an attractive direction to improve the game experience in the next-generation computer games. In this scenario, Machine Learning could play an important role to provide automatically such customized game content.
The goal of this project is to apply machine learning techniques for the generation of customized tracks in
[http://torcs.sourceforge.net/ TORCS], a state-of-the-art open source racing simulator. The project include different activities: the automatic generation of tracks, the section of relevant features to characterize a track and the analysis of an interest measure.
|start=Anytime
|number=1 to 2
|cfu=20
|image=TORCS3.jpg}}

{{Project template
|title=Automatic generation of domain ontologies
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:AndreaBonarini|Andrea Bonarini]] ([mailto:bonarini%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description= This thesis to be developed together with [http://www.noustat.it/ Noustat S.r.l.], who are developing research activities directed toward the optimization of knowledge management services, in collaboration with another company operating in this field. This project is aimed at removing the ontology building bottleneck, long and expensive activity that usually requires the direct collaboration of a domain expert. The possibility of automatic building the ontology, starting from a set of textual documents related to a specific domain, is expected to improve the ability to provide the knowledge management service, both by reducing the time-to-application, and by increasing the number of domains that can be covered. For this project, unsupervised learning methods will be applied in sequence, exploiting the topological properties of the ultra-metric spaces that emerge from the taxonomic structure of the concepts present in the texts, and associative methods will extend the concept network to lateral, non-hierarchical relationships.

|start=before November 30th
|number=1-2
|cfu=20
|image=}}



==== Social Software and Semantic Web ====

===== Wiki Analysis =====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Social Software and Semantic Web]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}



==== Robotics ====
{{Project template
|title= Robot games
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to develop an interactive game with robots using commercial devices such as the WII Mote (see the [http://airwiki.elet.polimi.it/mediawiki/index.php/Robogames Robogames page])
Projects are available in different areas:
* Design and implementation of the game on one of the available robots and extension of the robot functionalities
* Design and implementation of the game and a new suitable robot
* Evaluation of the game with users (in collaboration with [http://www.elet.polimi.it/people/garzotto Franca Garzotto])

These projects allow to experiment with real mobile robots and real interaction devices.

Parts of these projects can be considered as course projects. These projects can also be extended to cover course projects.
|start=Anytime
|number=1-2
|cfu=7.5-20
|image=Robowii_robot.jpg}}

Master Level Course Projects

2009-06-30T14:11:37Z

BernardoDalSeno: Brain-Computer Interface: removed p300 repetions project

Here you can find a list of project proposals for the courses of "Laboratorio di Intelligenza Artificiale e Robotica" (5 CFU for each student) and "Soft Computing" (1 CFU for each student). See [[Project Proposals]] for other kinds of projects and theses.

==== Evolutionary Optimization and Stochastic Optimization ====

{{Project template
|title=Combinatorial optimization based on stochastic relaxation
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc-AT-elet-DOT-polimi-DOT-it]), [[User:LuigiMalago|Luigi Malagò]] ([mailto:malago-AT-elet-DOT-polimi-DOT-it email])
|description=The project will focus on the study, implementation, comparison and analysis of different algorithms for the optimization of pseudo-Boolean functions, i.e., functions defined over binary variables with values in R. These functions have been studied a lot in the mathematical programming literature, and different algorithms have been proposed [1]. More recently, the same problems have been faced in evolutionary computations, with the use of genetic algorithms, and in particular estimation of distribution algorithms [2,3]. Estimation of distribution algorithms are a recent meta-heuristic, where classical crossover and mutation operators used in genetic algorithms are replaced with operators that come from statistics, such as sampling and estimation.

The focus will be on the implementation of existing algorithms able to combine different approaches (estimation and sampling, from one side, and exploitation of prior knowledge about the structure of problem, on the other), together with the comparison of the results with existing techniques that historically appear in different (and often separated) communities. Good coding (C/C++) abilities are required. Since the approach will be based on statistical models, the student is supposed to be comfortable with notions that come from probability and statistics courses.

Picture taken from http://www.ra.cs.uni-tuebingen.de/

;Bibliography
*[1] Boros, Endre and Boros, Endre and Hammer, Peter L. (2002) Pseudo-boolean optimization. Discrete Applied Mathematics.
*[2] Pelikan, Martin; Goldberg, David; Lobo, Fernando (1999), A Survey of Optimization by Building and Using Probabilistic Models, Illinois: Illinois Genetic Algorithms Laboratory (IlliGAL), University of Illinois at Urbana-Champaign.
*[3] Larrañga, Pedro; & Lozano, Jose A. (Eds.). Estimation of distribution algorithms: A new tool for evolutionary computation. Kluwer Academic Publishers, Boston, 2002.
*[4] Image Analysis, Random Fields Markov Chain Monte Carlo Methods

|start=Anytime
|number=1-2
|cfu=20-40
|image=stochastic.jpg}}

==== Evolutionary Computation ====

{{Project template
|title=Combining Estimation of Distribution Algorithms and other Evolutionary techniques for combinatorial optimization
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc-AT-elet-DOT-polimi-DOT-it]), [[User:LuigiMalago|Luigi Malagò]] ([mailto:malago-AT-elet-DOT-polimi-DOT-it email])
|description=The project will focus on the study, implementation, comparison and analysis of different algorithms for combinatorial optimization using techniques and algorithms proposed in Evolutionary Computation. In particular we are interested in the study of Estimation of Distribution Algorithms [1,2,3,4], a recent meta-heuristic, often presented as an evolution of Genetic Algorithms, where classical crossover and mutation operators, used in genetic algorithms, are replaced with operators that come from statistics, such as sampling and estimation.

The focus will be on the implementation of new hybrid algorithms able to combine estimation of distribution algorithms with different approaches available in the evolutionary computation literature, such as genetic algorithms and evolutionary strategies, together with other local search techniques. Good coding (C/C++) abilities are required. Some background in combinatorial optimization form the "Fondamenti di Ricerca Operativa" is desirable. The project could require some effort in order to build and consolidate some background in MCMC techniques, such as Gibbs and Metropolis samplers [4]. The project could be extended to master thesis, according to interesting and novel directions of research that will emerge in the first part of the work.

Picture taken from http://www.genetic-programming.org

;Bibliography
*[1] Pelikan, Martin; Goldberg, David; Lobo, Fernando (1999), A Survey of Optimization by Building and Using Probabilistic Models, Illinois: Illinois Genetic Algorithms Laboratory (IlliGAL), University of Illinois at Urbana-Champaign.
*[2] Larrañga, Pedro; & Lozano, Jose A. (Eds.). Estimation of distribution algorithms: A new tool for evolutionary computation. Kluwer Academic Publishers, Boston, 2002.
*[3] Lozano, J. A.; Larrañga, P.; Inza, I.; & Bengoetxea, E. (Eds.). Towards a new evolutionary computation. Advances in estimation of distribution algorithms. Springer, 2006.
*[4] Pelikan, Martin; Sastry, Kumara; & Cantu-Paz, Erick (Eds.). Scalable optimization via probabilistic modeling: From algorithms to applications. Springer, 2006.

|start=Anytime
|number=1-2
|cfu=5-10
|image=genetic.jpg}}

===== Sleep Staging =====

{{Project template
|title=Development of a computer-assisted CAP (Sleep cyclic alternating pattern) scoring method
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), Martin Mendez ([mailto:martin.mendez@polimi.it email]), Anna Maria Bianchi ([mailto:annamaria.bianchi@polimi.it email]), Mario Terzano (Ospedale di Parma)
|description=In 1985, Terzano describes for the first time the Cyclic Alternating Pattern [http://en.wikipedia.org/wiki/Cyclical_alternating_pattern] during sleep and, nowadays, CAP is widely accepted by the medical community as basic analysis of sleep. The CAP evaluation is of fundamental importance since it represents the mechanism developed by the brain evolution to monitor the inner and outer world and to assure the survival during sleep. However, visual detection of CAP in polisomnography (i.e., the standard procedure) is a slow and time-consuming process. This limiting factor generates the necessity of new computer-assisted scoring methods for fast CAP evaluation. This thesis deals with the development of a Decision Support System for CAP scoring based on features extraction at multi-system level (by statistical and signal analysis) and Pattern Recognition or Machine Learning approaches. This may allow the automatic detection of CAP sleep and could be integrated, through reinforcement learning techniques, with the corrections given by physicians.

;Tools and instruments
:Matlab, C/C++

;Bibliography
: Mario Terzano, Liborio Parrino. ''Atlas, rules, and recording techniques for the scoring of cyclic alternating pattern (CAP) in human sleep'', Sleep Medicine 2 (2001) 537–553. [http://www.sciencedirect.com/science?_ob=ArticleURL&_udi=B6W6N-44DY2B4-8&_user=2620285&_coverDate=11%2F30%2F2001&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000058180&_version=1&_urlVersion=0&_userid=2620285&md5=aa61a060d005f23f6afed5c1fc2f1126]
|start=Anytime
|number=1-2
|cfu=5-20
|image=CAP_Sleep_Staging.jpg}}



==== BioSignal Analysis ====

{{Project template
|title=Human-computer interaction via voice recognition system
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=We want develop a system to allow a voice interaction between the user and the wheelchair.
This project consists in develop one of the solutions proposed in literature and extended the LURCH software to include this kind of interface.
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux

References:
* Phinx project [http://cmusphinx.org/]

|start= Anytime
|number=1-2
|cfu=2.5-10
|image=LURCH_wheelchair.jpg
}}

===== Brain-Computer Interface =====

{{Project template
|title=Driving an autonomous wheelchair with a P300-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. Depending on the effort the student is willing to put into it, the project can grow to a full experimental thesis.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000]
:Linux

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]
|start=November 2008
|number=1
|cfu=5-20
|image=LURCH_wheelchair.jpg}}

{{Project template
|title=Reproduction of an algorithm for the recognition of error potentials
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=Error potentials (ErrPs) are [http://en.wikipedia.org/wiki/Event-related_potential event-related potentials] present in the EEG (electroencephalogram) when a subject makes a mistake or when the machine a subject is interacting with works in an expected way. They could be used in the [[Brain-Computer Interface|BCI]] field to improve the performance of a BCI by automatically detecting classification errors.
The project aims at reproducing algorithms for ErrP detection from the literature.

;Tools and instruments
:Matlab

;Bibliography
:P.W. Ferrez, J. Millán. ''You Are Wrong! Automatic Detection of Interaction Errors from Brain Waves'' [ftp://ftp.idiap.ch/pub/reports/2005/ferrez_2005_ijcai.pdf]
:G. Schalk et al. ''EEG-based communication: presence of an error potential'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=13882457&volume=111&issue=12&firstpage=2138&form=html]
|start=This project has already been assigned
|number=1
|cfu=5-15
|image=Bci_arch.png}}

==== Computer Vision and Image Analysis ====

{{Project template
|title=Environment Monitoring
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The goal of this project is to develop a video surveillance system to track in 3D vehicles or people.
The idea is to use one or more calibrated camera to estimate the position and the trajectories of the moving objects in the scene.
The skills required for this project are:
* C/C++ and OpenCV library
* Linux o.s.
* Geometry/Image processing
* Probabilistic robotics/IMAD

The project can be turned into a thesis extending the algorithm for a generic outdoor environment.
|start=Anytime
|number=2-3
|cfu=10-15
|image=Danch4.png
}}

{{Project template
|title=Visual Merchandising
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The goal of this project is to develop algorithms to count the number of products on the shelves of a market.
The idea is to use a calibrated camera to recognize the shelves, estimate the scale and improve the image quality.
The skills required for this project are:
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux
* Geometry/Image processing

|start= As soon as possible
|number=2-3
|cfu=2.5-15
|image=VisualM.jpg
}}

{{Project template
|title=Analysis of patch recognition algorithms
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=Extract distinctive features from images is very important in computer vision application.
It can be used in algorithms for tasks like matching different views of an object or scene (e.g. for stereo vision) and object recognition.
The aim of this work is to integrate in an existent framework the existing solution proposed in literature.

Skills
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux
* Geometry/Image processing

References:
*Oxford website [http://www.robots.ox.ac.uk/~vgg/research/affine/index.html]
*Hess website [http://web.engr.oregonstate.edu/~hess/index.html]
*Feature FAST [http://mi.eng.cam.ac.uk/~er258/work/fast.html]

|start= Anytime
|number=2-3
|cfu=2.5-15
|image=Object.jpg
}}

{{Project template
|title=Catadioptric MonoSLAM
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The goal of this work is to investigate a SLAM solutions based on catadioptric camera, integrating the solution presented in literature into an existing frameword.
Improvements could be the basis for a tesi.

Skills
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux
* Geometry/Image processing

References:
*Visual SLAM by Single Catadioptric Stereo [http://cv2.kaist.ac.kr/VisualSLAMBySingleCameraCatadioptricStereo.pdf]
*Catadioptric reconstruction [http://citeseer.ist.psu.edu/cache/papers/cs/23657/http:zSzzSzwww.cis.upenn.eduzSz~cgeyerzSzsfm_tr.pdf/geyer01structure.pdf]

|start= Anytime
|number=2-3
|cfu=2.5-15
|image=Photo.jpg
}}

{{Project template
|title=Trinocular Vision System (SUGR)
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=A Trinocular Vision System is a device composed by three cameras that allows to measure 3D data (in this case segments) directly from images.
The aim of this tesina/project is to implement a trinocular algorithm based on SUGR, a library for Uncertain Projective Geometry.

Skills
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux
* Geometry/Image processing

|start= As soon as possible
|number=2-3
|cfu=2.5-15
|image=Trinoex.jpg
}}

{{Project template
|title=GIFT and features extraction and description
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The idea is to improve and optimize the solution proposed by Campari et al. in their paper, who propose to estimate invariant descriptor using geodesic features descriptor based on color information.

Skills
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux
* Geometry/Image processing

|start= Anytime
|number=1-3
|cfu=10-20
|image=Palla_GIFT.jpg
}}

{{Project template
|title=Multimedia Indexing Framework
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The goal of this project is to develop a framework for multimedia indexing.
The idea is create an images database indexer that allows to make query using images or strings.

Skills
* C/C++ and OpenCV library
* Matlab (optionally)
* Linux

References:
*CBIR system definition [http://en.wikipedia.org/wiki/CBIR]
*Image database [http://www.cs.washington.edu/research/imagedatabase/]

|start= Anytime
|number=1-3
|cfu=2.5-15
|image=CIR.gif
}}


==== Machine Learning ====

{{Project template
|title=Statistical inference for phylogenetic trees
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc-AT-elet-DOT-polimi-DOT-it]), [[User:LuigiMalago|Luigi Malagò]] ([mailto:malago-AT-elet-DOT-polimi-DOT-it email])
|description=The project will focus on the study, implementation, comparison and analysis of different statistical inference techniques for phylogenetic trees. Phylogenetic trees [1, 2, 3] are evolutionary trees used to represent the relationships between different species with a common ancestor. Typical inference task concern the construction of a tree starting from DNA sequences, involving both the choice of the topology of the tree (i.e., model selection) and the values of the parameters (i.e., model fitting). The focus will be a probabilistic description of the tree, given by the introduction of stochastic variables associated to both internal nodes and leaves of the tree.

The project will focus on the understanding of the problem and on the implementation of different algorithms, so (C/C++ or Matlab or R) coding will be required. Since the approach will be based on statistical models, the student is supposed to be comfortable with notions that come from probability and statistics courses.

Picture taken from http://www.tolweb.org/tree/

;Bibliography
*[1] Felsenstein 2003: Inferring Phylogenies
*[2] Semple and Steel 2003: Phylogenetics: The mathematics of phylogenetics
*[3] Louis J. Billera, Susan P. Holmes and and Karen Vogtmann Geometry of the space of phylogenetic trees. Advances in Applied Math 27, 733-767 (2001)

|start=Anytime
|number=1-2
|cfu=20-40
|image=toloverview.jpg}}

{{Project template
|title=Reinforcement Learning Competition
|tutor=Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=This project has the goal of participating to (and possibly winning ;)) the 2009 Reinforcement Learning competition. To have an idea of what participate to such a competition means you can have a look at the website of the [http://rl-competition.org/content/view/51/79/ 2008 RL competition].
The problems that will be proposed are still unknown. As soon as the domains will be published, the work will start by analyzing their main characteristics and, then we will identify which RL algorithms are most suited for solving such problems. After an implementation phase, the project will required a long experimental period to tune the parameters of the learning algorithms in order to improve the performance as much as possible.
|start=January, 2009
|number=2-4
|cfu=10-20
|image=keepaway.gif}}

{{Project template
|title= Learning API for TORCS
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. The goal of this project is to extend the existing C++ API (available [http://cig.dei.polimi.it/ here]) to simplify the development of controller using a learning framework.
Such an extension can be partially developed by porting an existing Java API for TORCS that already provides a lot of functionalities for machine learning approaches.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS.jpg}}

{{Project template
|title= EyeBot
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it), Alessandro Giusti (giusti-AT-elet-DOT-polimi-DOT-it), and Pierluigi Taddei (taddei-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. So far, the controller developed for TORCS used as input only information extracted directly from the state of the game. The goal of this project is to extend the existing controller API (see [http://cig.dei.polimi.it/ here]) to use the visual information (e.g. the screenshots of the game) as input to the controllers. A successfull project will include both the development of the API and some basic imaga preprocessing to extract information from the images.
|start=Anytime
|number=1 to 2
|cfu=5 to 20
|image=TORCS2.jpg}}

{{Project template
|title= SmarTrack
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=The generation of customized game content for each player is an attractive direction to improve the game experience in the next-generation computer games. In this scenario, Machine Learning could play an important role to provide automatically such customized game content.
The goal of this project is to apply machine learning techniques for the generation of customized tracks in
[http://torcs.sourceforge.net/ TORCS], a state-of-the-art open source racing simulator. The project include different activities: the automatic generation of tracks, the section of relevant features to characterize a track and the analysis of an interest measure.
|start=Anytime
|number=1 to 2
|cfu=5 to 20
|image=TORCS3.jpg}}

{{Project template
|title= TORCS competition
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques.
The goal of this project is to apply any machine learning technique to develop a successfull controller following the competition rules (available [http://cig.dei.polimi.it/?page_id=67 here])
|start=Anytime
|number=1
|cfu=5
|image=TORCS.jpg}}

==== Social Software and Semantic Web ====

===== Wiki Analysis =====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Social Software and Semantic Web]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}



==== Robotics ====

{{Project template
|title= Robot games
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to develop an interactive game with robots using commercial devices such as the WII Mote (see the [http://airwiki.elet.polimi.it/mediawiki/index.php/Robogames Robogames page])
Projects are available in different areas:
* Design and implementation of the game on one of the available robots
* Design of the game and a new suitable robot
* Implementation/setting of a suitable robot
* Evaluation of the game with users (in collaboration with [http://www.elet.polimi.it/people/garzotto Franca Garzotto])

These projects allow to experiment with real mobile robots and real interaction devices.

The project can be turned into a thesis by producing a new game and robot.
|start=Anytime
|number=1-2
|cfu=5-12.5
|image=Robowii_robot.jpg}}

{{Project template
|title= Robocup: soccer robots
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it), Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to finalize the team of robots that will participate to the robocup world championship in Graz next summer (see the [http://www.robocup.org Robocup page] and the [http://robocup.elet.polimi.it MRT Team page])
Projects are available in different areas:
* Implementation of mechanical and electronical parts of the robots for the management of the ball and kicking
* Design of robot behaviors (fuzzy systems)
* Coordination of robots
* New sensors

These projects allow to experiment with real mobile robots. Participation to the championships is a unique experience (2000 people, with 800 robots playing all sort of games...)

The project can be turned into a thesis by facing different problems in depth.
|start=Anytime
|number=1-2
|cfu=5-12.5
|image=RIeRO.jpg}}

{{Project template
|title=Calibration of IMU-camera system
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This work is about the problem to calibrate a system composed by an XSense
Inertial Measurement Unit and a Fire-i Camera. The pro ject will be focus on
the problem to estimate both unknown rotation between the two devices and the
extrinsic/intrinsic parameters of the camera. This algorithm allows to use the
system for SLAM or robotics applications, like a wereable device for autonomous
navigation or augmented reality.

;Tools and instruments
:Matlab/C++

;Links
:Matlab Toolbox for mutual calibration [http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Toolbox.html]
:List of pubblications[http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Pubs.php]

|start=Anytime
|number=1
|cfu=5-20
|image=Imu_cam_big_sphere.gif}}

{{Project template
|title=MonoSLAM system implementation
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:DavideMigliore|Davide Migliore]] ([mailto:migliore%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=The aim of this proposal is to investigate the different monocamera SLAM solution proposed in literature.
After a deepen bibliography research, the work will be focused on developing one of these algorithms into an existing framework and, only for tesi option, investigate possible improvements.

The algorithms interested are based on [http://www-personal.acfr.usyd.edu.au/tbailey/software/slam_simulations.htm]:
*Extended Kalman Filter [http://www.doc.ic.ac.uk/~ajd/publications.html]
*Unscented Kalman Filter [http://www.cs.unc.edu/~welch/kalman/media/pdf/Julier1997_SPIE_KF.pdf]
*FastSLAM [http://robots.stanford.edu/papers.html]
*GraphSLAM [http://mi.eng.cam.ac.uk/~ee231/]

;Tools and instruments
:Matlab/C++

|start=Anytime
|number=1-2
|cfu=5-20
|image=KC_jc_third.jpg}}

First Level Theses

2009-06-30T14:10:39Z

BernardoDalSeno: Brain-Computer Interface: removed p300 repetions project

Here you can find proposals for first level thesis (7.5 CFU for each student). See [[Project Proposals]] for other kinds of projects and theses.


==== BioSignal Analysis ====
===== Brain-Computer Interface =====

{{Project template
|title=Real-time removal of ocular artifact from EEG
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=In a [[Brain-Computer Interface|BCI]] based on electroencephalogram (EEG), one of the most important sources of noise is related to ocular movements. Algorithms have been devised to cancel the effect of such artifacts. The project consists in the in the implementation in real time of an existing algorithm (or one newly developed) in order to improve the performance of a BCI.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000], C++
:EEG system

;Bibliography
: J.R. Wolpaw et al. ''Brain-computer interfaces for communication and control'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&journal=13882457&issue=v113i0006&article=767_bifcac&form=pdf&file=file.pdf]
: R.J. Croff, R.J. Barry. ''Removal of ocular artifact from the EEG: a review'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=09877053&volume=30&issue=1&firstpage=5&form=html]
|number=1
|cfu=10-20
|image=B_bci.jpg}}

{{Project template
|title=Driving an autonomous wheelchair with a P300-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. The work will be validated with live experiments.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000], Matlab
:Linux
:EEG system
:Lurch wheelchair

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]
|start=Anytime
|number=1
|cfu=5-20
|image=LURCH_wheelchair.jpg}}

{{Project template
|title=Reproduction of an algorithm for the recognition of error potentials
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=Error potentials (ErrPs) are [http://en.wikipedia.org/wiki/Event-related_potential event-related potentials] present in the EEG (electroencephalogram) when a subject makes a mistake or when the machine a subject is interacting with works in an expected way. They could be used in the [[Brain-Computer Interface|BCI]] field to improve the performance of a BCI by automatically detecting classification errors.
The project aims at reproducing algorithms for ErrP detection from the literature.

;Tools and instruments
:Matlab, [http://www.bci2000.org/ BCI2000]
:EEG system

;Bibliography
:P.W. Ferrez, J. Millán. ''You Are Wrong! Automatic Detection of Interaction Errors from Brain Waves'' [ftp://ftp.idiap.ch/pub/reports/2005/ferrez_2005_ijcai.pdf]
:G. Schalk et al. ''EEG-based communication: presence of an error potential'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=13882457&volume=111&issue=12&firstpage=2138&form=html]
|start=This project has already been assigned
|number=1
|cfu=5-15
|image=Bci_arch.png}}




==== Machine Learning ====
{{Project template
|title= Learning API for TORCS
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. The goal of this project is to extend the existing C++ API (available [http://cig.dei.polimi.it/ here]) to simplify the development of controller using a learning framework.
Such an extension can be partially developed by porting an existing Java API for TORCS that already provides a lot of functionalities for machine learning approaches.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS.jpg}}

{{Project template
|title= EyeBot
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it), Alessandro Giusti (giusti-AT-elet-DOT-polimi-DOT-it), and Pierluigi Taddei (taddei-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. So far, the controller developed for TORCS used as input only information extracted directly from the state of the game. The goal of this project is to extend the existing controller API (see [http://cig.dei.polimi.it/ here]) to use the visual information (e.g. the screenshots of the game) as input to the controllers. A successfull project will include both the development of the API and some basic imaga preprocessing to extract information from the images.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS2.jpg}}

{{Project template
|title= SmarTrack
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=The generation of customized game content for each player is an attractive direction to improve the game experience in the next-generation computer games. In this scenario, Machine Learning could play an important role to provide automatically such customized game content.
The goal of this project is to apply machine learning techniques for the generation of customized tracks in
[http://torcs.sourceforge.net/ TORCS], a state-of-the-art open source racing simulator. The project include different activities: the automatic generation of tracks, the section of relevant features to characterize a track and the analysis of an interest measure.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS3.jpg}}

{{Project template
|title= TORCS competition
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques.
The goal of this project is to apply any machine learning technique to develop a successfull controller following the competition rules (available [http://cig.dei.polimi.it/?page_id=67 here])
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS.jpg}}

==== Social Software and Semantic Web ====

===== Wiki Analysis =====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Social Software and Semantic Web]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}


==== Robotics ====
{{Project template
|title=Simulation of 6-DOF Robot Manipulator
|tutor=Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this project is to develop a simulator for a 6-DOF robot manipulator, using the [http://www.ode.org/ ode] (open dynamics engine) library for simulating the rigid body dynamics. The project involves three different phases:
* Building the physical model of the manipulator
* Implementing the forward and inverse kinematic routines
* Implementing the trajectory planning routines
* Implementing the control modules
* Implementing an interface to control the robot movements

This project allows to put into practice what has been explained during the first part of the course of Robotics.

The project can be turned into a thesis, by using the simulated manipulator to perform some learning experiments.
|start=Anytime
|number=2-3
|cfu=10-15
|image=puma6dof1.jpg}}

{{Project template
|title=Calibration of IMU-camera system
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]], [[User:DavideMigliore|Davide Migliore]]
|description=This work is about the problem to calibrate a system composed by an XSense
Inertial Measurement Unit and a Fire-i Camera. The pro ject will be focus on
the problem to estimate both unknown rotation between the two devices and the
extrinsic/intrinsic parameters of the camera. This algorithm allows to use the
system for SLAM or robotics applications, like a wereable device for autonomous
navigation or augmented reality.

;Tools and instruments
:Matlab/C++

;Links
:Matlab Toolbox for mutual calibration [http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Toolbox.html]
:List of pubblications[http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Pubs.php]

|start=Anytime
|number=1
|cfu=5-20
|image=Imu_cam_big_sphere.gif}}

{{Project template
|title= Robot games
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to develop an interactive game with robots using commercial devices such as the WII Mote (see the [http://airwiki.elet.polimi.it/mediawiki/index.php/Robogames Robogames page])
Projects are available in different areas:
* Design and implementation of the game on one of the available robots and extension of the robot functionalities
* Design and implementation of the game and a new suitable robot
* Evaluation of the game with users (in collaboration with [http://www.elet.polimi.it/people/garzotto Franca Garzotto])

These projects allow to experiment with real mobile robots and real interaction devices.

Parts of these projects can be considered as course projects. These projects can also be extended to cover course projects.
|start=Anytime
|number=1-2
|cfu=7.5-12.5
|image=Robowii_robot.jpg}}

First Level Course Projects

2009-06-30T14:09:53Z

BernardoDalSeno: Brain-Computer Interface: removed p300 repetions project

Here you can find a list of project proposals for the courses of "Progetto di Ingegneria Informatica" and "Progetto di Robotica" (5 CFU for each student). See [[Project Proposals]] for other kinds of projects and theses.



==== BioSignal Analysis ====

===== Brain-Computer Interface =====
{{Project template
|title=Driving an autonomous wheelchair with a P300-based BCI
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=This project pulls together different Airlab projects with the aim to drive an autonomous wheelchair ([[LURCH - The autonomous wheelchair|LURCH]]) with a [[Brain-Computer Interface|BCI]], through the development of key software modules. Depending on the effort the student is willing to put into it, the project can grow to a full experimental thesis.

;Tools and instruments
:C++, C, [http://www.bci2000.org/ BCI2000]
:Linux

;Bibliography
: R. Blatt et al. ''Brain Control of a Smart Wheelchair'' [http://www.booksonline.iospress.com/Content/View.aspx?piid=9401]
|start=November 2008
|number=1
|cfu=5-20
|image=LURCH_wheelchair.jpg}}

{{Project template
|title=Reproduction of an algorithm for the recognition of error potentials
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]] ([mailto:matteucc%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email]), [[User:BernardoDalSeno|Bernardo Dal Seno]] ([mailto:dalseno%40%65%6c%65%74%2e%70%6f%6c%69%6d%69%2e%69%74 email])
|description=Error potentials (ErrPs) are [http://en.wikipedia.org/wiki/Event-related_potential event-related potentials] present in the EEG (electroencephalogram) when a subject makes a mistake or when the machine a subject is interacting with works in an expected way. They could be used in the [[Brain-Computer Interface|BCI]] field to improve the performance of a BCI by automatically detecting classification errors.
The project aims at reproducing algorithms for ErrP detection from the literature.

;Tools and instruments
:Matlab

;Bibliography
:P.W. Ferrez, J. Millán. ''You Are Wrong! Automatic Detection of Interaction Errors from Brain Waves'' [ftp://ftp.idiap.ch/pub/reports/2005/ferrez_2005_ijcai.pdf]
:G. Schalk et al. ''EEG-based communication: presence of an error potential'' [http://scienceserver.cilea.it/cgi-bin/sciserv.pl?collection=journals&issn=13882457&volume=111&issue=12&firstpage=2138&form=html]
|start=Anytime
|number=1
|cfu=5-15
|image=Bci_arch.png}}



==== Computer Vision and Image Analysis ====

{{Project template
|title=Video surveillance system for indoor Environment
|tutor=Matteo Matteucci (matteucci-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this project is to develop a video surveillance system based on background subtraction algorithm. The idea is to use a single static camera to track moving objects in a known environment.
The skills required for this project are:
* C/C++ and OpenCV library
* Linux o.s.

The project can be turned into a thesis extending the algorithm for camera network.
|start=Anytime
|number=2-3
|cfu=2.5-15
|image=Danch4.png
}}



==== Machine Learning ====
{{Project template
|title= Learning API for TORCS
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. The goal of this project is to extend the existing C++ API (available [http://cig.dei.polimi.it/ here]) to simplify the development of controller using a learning framework.
Such an extension can be partially developed by porting an existing Java API for TORCS that already provides a lot of functionalities for machine learning approaches.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS.jpg}}

{{Project template
|title= EyeBot
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it), Alessandro Giusti (giusti-AT-elet-DOT-polimi-DOT-it), and Pierluigi Taddei (taddei-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques. So far, the controller developed for TORCS used as input only information extracted directly from the state of the game. The goal of this project is to extend the existing controller API (see [http://cig.dei.polimi.it/ here]) to use the visual information (e.g. the screenshots of the game) as input to the controllers. A successfull project will include both the development of the API and some basic imaga preprocessing to extract information from the images.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS2.jpg}}

{{Project template
|title= SmarTrack
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=The generation of customized game content for each player is an attractive direction to improve the game experience in the next-generation computer games. In this scenario, Machine Learning could play an important role to provide automatically such customized game content.
The goal of this project is to apply machine learning techniques for the generation of customized tracks in
[http://torcs.sourceforge.net/ TORCS], a state-of-the-art open source racing simulator. The project include different activities: the automatic generation of tracks, the section of relevant features to characterize a track and the analysis of an interest measure.
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS3.jpg}}

{{Project template
|title= TORCS competition
|tutor= Daniele Loiacono (loiacono-AT-elet-DOT-polimi-DOT-it)
|description=[http://torcs.sourceforge.net/ TORCS] is a state-of-the-art open source racing simulator that represents an ideal bechmark for machine learning techniques. We already organized two successfull competitions based on TORCS where competitors have been asked to develop a controller using their preferred machine learning techniques.
The goal of this project is to apply any machine learning technique to develop a successfull controller following the competition rules (available [http://cig.dei.polimi.it/?page_id=67 here])
|start=Anytime
|number=1 to 2
|cfu=5 to 12.5
|image=TORCS.jpg}}

==== Social Software and Semantic Web ====

===== Wiki Analysis =====

{{#ask: [[Category:ProjectProposal]]
[[PrjResArea::Social Software and Semantic Web]] |
?PrjTitle |
?PrjImage |
?PrjDescription |
?PrjTutor |
?PrjStarts |
?PrjStudMin |
?PrjStudMax |
?PrjCFUMin |
?PrjCFUMax |
?PrjResArea |
?PrjResTopic |
format = template |
template = Template:ProjectProposalViz
}}



==== Robotics ====
{{Project template
|title=Simulation of 6-DOF Robot Manipulator
|tutor=Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this project is to develop a simulator for a 6-DOF robot manipulator, using the [http://www.ode.org/ ode] (open dynamics engine) library for simulating the rigid body dynamics. The project involves three different phases:
* Building the physical model of the manipulator
* Implementing the forward and inverse kinematic routines
* Implementing the trajectory planning routines
* Implementing the control modules
* Implementing an interface to control the robot movements

This project allows to put into practice what has been explained during the first part of the course of Robotics.

The project can be turned into a thesis, by using the simulated manipulator to perform some learning experiments.
|start=Anytime
|number=2-3
|cfu=10-15
|image=puma6dof1.jpg}}

{{Project template
|title=Calibration of IMU-camera system
|tutor=[[User:MatteoMatteucci|Matteo Matteucci]], [[User:DavideMigliore|Davide Migliore]]
|description=This work is about the problem to calibrate a system composed by an XSense
Inertial Measurement Unit and a Fire-i Camera. The pro ject will be focus on
the problem to estimate both unknown rotation between the two devices and the
extrinsic/intrinsic parameters of the camera. This algorithm allows to use the
system for SLAM or robotics applications, like a wereable device for autonomous
navigation or augmented reality.

;Tools and instruments
:Matlab/C++

;Links
:Matlab Toolbox for mutual calibration [http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Toolbox.html]
:List of pubblications[http://www.deec.uc.pt/~jlobo/InerVis_WebIndex/InerVis_Pubs.php]

|start=Anytime
|number=1
|cfu=5-20
|image=Imu_cam_big_sphere.gif}}

{{Project template
|title= Robot games
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to develop an interactive game with robots using commercial devices such as the WII Mote (see the [http://airwiki.elet.polimi.it/mediawiki/index.php/Robogames Robogames page])
Projects are available in different areas:
* Design and implementation of the game on one of the available robots
* Design of the game and a new suitable robot
* Implementation/setting of a suitable robot
* Evaluation of the game with users (in collaboration with [http://www.elet.polimi.it/people/garzotto Franca Garzotto])

These projects allow to experiment with real mobile robots and real interaction devices.

The project can be turned into a thesis by producing a new game and robot.
|start=Anytime
|number=1-2
|cfu=5-12.5
|image=Meccano-spyke-medium.jpg|{width} 50}}

{{Project template
|title= Robocup: soccer robots
|tutor= Andrea Bonarini (bonarini-AT-elet-DOT-polimi-DOT-it), Marcello Restelli (restelli-AT-elet-DOT-polimi-DOT-it)
|description=The goal of this activity is to finalize the team of robots that will participate to the robocup world championship in Graz next summer (see the [http://www.robocup.org Robocup page] and the [http://robocup.elet.polimi.it MRT Team page])
Projects are available in different areas:
* Implementation of mechanical and electronical parts of the robots for the management of the ball and kicking
* Design of robot behaviors (fuzzy systems)
* Coordination of robots
* New sensors

These projects allow to experiment with real mobile robots. Participation to the championships is a unique experience (2000 people, with 800 robots playing all sort of games...)

The project can be turned into a thesis by facing different problems in depth.
|start=Anytime
|number=1-2
|cfu=5-12.5
|image=RIeRO.jpg}}

Brain-Computer Interface

2009-06-30T12:18:48Z

BernardoDalSeno: Ongoing projects: added tuning of P300 repetitions

A Brain-Computer Interface (BCI) is an experimental communication system that allows an individual to control a device by using signals from the brain (e.g., electroencephalography -- EEG).

You can find a longer description on the [http://airlab.elet.polimi.it/index.php/airlab/research_areas/biosignal_analysis?z=2299 AIRLab page].

The BCI project is in the [[BioSignal_Analysis]] area.

== Ongoing projects ==

* [[A genetic algorithm for automatic feature extraction from EEG data]]
* [[BCI based on Motor Imagery]]
** [[Predictive BCI Speller based on Motor Imagery]] (Master thesis, Tiziano D'Albis)
** [[Feature Selection and Extraction for a BCI based on motor imagery]] (Master thesis, Francesco Amenta)
* [[Graphical user interface for an autonomous wheelchair]] (Roberto Massimini)
* [[Online automatic tuning of the number of repetitions in a P300-based BCI]]

== New projects ==
There are various proposal for students interested in projects/thesis in the field of brain-computer interfaces:
*[[First Level Course Projects#Brain-Computer_Interface|First Level Course Projects]]
*[[First Level Theses#Brain-Computer_Interface|First Level Theses]]
*[[Master Level Course Projects#Brain-Computer_Interface|Master Level Course Projects]]
*[[Master Level Theses#Brain-Computer_Interface|Master Level Theses]]

== Finished projects ==

* [[Online P300 and ErrP recognition with BCI2000]] (Master thesis, Andrea Sgarlata).
* Tesi di Carlo Gimondi e Luisella Messana
* Tesi di Gianmaria Visconti
* Tesi di Francesco Cartella

== Instruments ==

* [[Electroencephalographs]]

== How to ==

* [[How to mount electrodes]]
* [[How to setup BCI software]]

== Publications ==

You can find publications in the BCI field by Airlab members on their home pages:
* [http://home.dei.polimi.it/dalseno/publications.html Bernardo Dal Seno's publications]

== Media ==

* 22 Jan 2009: [http://tv.repubblica.it/copertina/muoversi-con-il-pensiero/28512?video Repubblica TV report on Lurch and BCI] (in Italian)
* Aug 2008: [http://www.youtube.com/watch?v=lRP-ae4iaZA RAI TGLeonardo report on Airlab research] (in Italian). The video is a fragment of a longer report on mind and intelligence.

IIT-Lab

2009-06-25T11:03:12Z

BernardoDalSeno: /* Booking */

== What is the IIT-Lab ==

AIRLab-IITLab is dedicated to activities founded by the Italian Institute of Technology.
The lab hosts activities related to Brain-Computer Interfaces (BCI) and Affective Computing.

=== Location ===
It is located in the Rimembranze di Lambrate building of the Department of Electronics and Information, Via Rimembranze di Lambrate, 14, Milan.

'''The Lab has moved. It is now located at the first floor just over the Airlab, always in the Rimembranze di Lambrate building.'''

=== Access Rules ===
The access to AIRLab-IITLab is reserved to registered users. If you are student and want to register, you have to fill the AIRLab registration form (to be signed by your tutor) and the security form. The key of the lab is provided to registered users by the doorkeeper at the main entrance of the Lambrate building.

=== Booking ===

Please book the instrument you want to use by adding an entry to the table; the booking of an instrument implies the booking of the room. If you want to use a different instrument at the same time of an existing booking, please contact the other person involved and check that you can share the room; alternatively, you can ask the doorkeeper for an empty room in the building.


{| border="1"
! Day !! Time !! Person !! Instrument
|-
| Thursady 25 June|| 12:00-24:00 || [[User:BernardoDalSeno]] || EEG
|-
| Friday 26 June|| 0:00-20:00 || [[User:BernardoDalSeno]] || EEG
|-
|}

== Links ==

* [[Brain-Computer Interface]] page on this Wiki
* [[Affective Computing]] page on this Wiki
* [http://www.airlab.elet.polimi.it/index.php/airlab/visitor_info/airlab_iitlab AIRLab - IITLab]

Airpaper

2009-06-24T22:08:08Z

BernardoDalSeno: /* Crash Course */

[https://svn.ws.dei.polimi.it/airpaper/ Airpaper] (authentication needed) is the repository of papers written at Airlab.

It is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page, but you don't need the key and Ssh part as Airpaper uses Http authentication. ''<nowiki>https://svn.ws.dei.polimi.it/airpaper/</nowiki>'' is the repository Url when you checkout your working copy.

You have to be added as a user to the project by one of the administrators, even if you already are a user of Dei's Savane. Administrators/authors currently are: [[User:RossellaBlatt|Rossella Blatt]], [[User:BernardoDalSeno|Bernardo Dal Seno]], [[User:GiulioFontana|Giulio Fontana]], [[User:MatteoMatteucci|Matteo Matteucci]], [[User:SimoneTognetti|Simone Tognetti]]. (New administrators, please add your names here)

== Structure ==

This is a partial structure of the repository:
* '''bci''': BCI-related stuff
* '''benchmarking''': papers related to benchmarking in robotics
* '''common''': common stuff
** '''bib''': bibliography (Bibtex files, databases and styles)
** '''images''': obvious
* '''slam''': simultaneous localization ans mapping
* '''wheelchair''': Lurch-related stuff

All files related to a paper should be contained in one directory; please use a name that is clear and begins with a year, e.g., ''2009_Science'', ''2010_Nature_Higgs''.

== Crash Course ==

For general information about Subversion and how to use it, please see the [http://svnbook.red-bean.com/ Subversion manual]. If you are not familiar with version-control systems, the first chapter of the manual is a must-read. If you are familiar with [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS], please read at least [http://svnbook.red-bean.com/nightly/en/svn.forcvs.html Appendix B] of the manual. This section and the page [[Using Subversion]] on this wiki are a quick introduction in case you are in a hurry, but they are no substitute for a manual, so if you are new to Subversion or version-control system, please take time to read the mentioned manuals before you upset anyone by inadvertently deleting their work.

Being a subversion repository you need a subversion client to use it (rather obvious). The simplest one is a terminal client, and the following are first command you can use to start using airpaper immediately:

<code>
$ svn co <nowiki>https://svn.ws.dei.polimi.it/airpaper</nowiki>
</code>

or for a subdirectory just

<code>
$ svn co <nowiki>https://svn.ws.dei.polimi.it/airpaper/bci</nowiki>
</code>

to add a new file or directory (directories are imported recursively) to the repository just execute

<code>
$ svn add <filename/dirname>
</code>

this code does not actually update the svn repository to do this you need to check-in the change with

<code>
$ svn ci <filename/dirname>
</code>

and you can use this command to check-in any change to your local file not just to import new ones.

If you just want to check if something is changed locally or remotely, you can use

<code>
$ svn stat
</code>

while to update your local version with the last changes in the repository you just need to update with

<code>
$ svn update
</code>

this command might generate conflicts you need to settle ... but this is another story and you should read it by you own from

<code>
$ svn help
</code>

And remember, read the [http://svnbook.red-bean.com/ Subversion manual]!

== Rules ==

TODO

== For administrators ==

Instruction for managing users are on the page [[DEI Subversion Administration]]

Airpaper

2009-06-24T21:59:24Z

BernardoDalSeno: /* Crash Course */

[https://svn.ws.dei.polimi.it/airpaper/ Airpaper] (authentication needed) is the repository of papers written at Airlab.

It is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page, but you don't need the key and Ssh part as Airpaper uses Http authentication. ''<nowiki>https://svn.ws.dei.polimi.it/airpaper/</nowiki>'' is the repository Url when you checkout your working copy.

You have to be added as a user to the project by one of the administrators, even if you already are a user of Dei's Savane. Administrators/authors currently are: [[User:RossellaBlatt|Rossella Blatt]], [[User:BernardoDalSeno|Bernardo Dal Seno]], [[User:GiulioFontana|Giulio Fontana]], [[User:MatteoMatteucci|Matteo Matteucci]], [[User:SimoneTognetti|Simone Tognetti]]. (New administrators, please add your names here)

== Structure ==

This is a partial structure of the repository:
* '''bci''': BCI-related stuff
* '''benchmarking''': papers related to benchmarking in robotics
* '''common''': common stuff
** '''bib''': bibliography (Bibtex files, databases and styles)
** '''images''': obvious
* '''slam''': simultaneous localization ans mapping
* '''wheelchair''': Lurch-related stuff

All files related to a paper should be contained in one directory; please use a name that is clear and begins with a year, e.g., ''2009_Science'', ''2010_Nature_Higgs''.

== Crash Course ==

For a more detailed discussion see [[Using Subversion]].

Being a subversion repository you need a subversion client to use it (rather obvious). The simplest one is a terminal client, and the following are first command you can use to start using airpaper immediately:

<code>
$ svn co <nowiki>https://svn.ws.dei.polimi.it/airpaper</nowiki>
</code>

or for a subdirectory just

<code>
$ svn co <nowiki>https://svn.ws.dei.polimi.it/airpaper/bci</nowiki>
</code>

to add a new file or directory (directories are imported recursively) to the repository just execute

<code>
$ svn add <filename/dirname>
</code>

this code does not actually update the svn repository to do this you need to check-in the change with

<code>
$ svn ci <filename/dirname>
</code>

and you can use this command to check-in any change to your local file not just to import new ones.

If you just want to check if something is changed locally or remotely, you can use

<code>
$ svn stat
</code>

while to update your local version with the last changes in the repository you just need to update with

<code>
$ svn update
</code>

this command might generate conflicts you need to settle ... but this is another story and you should read it by you own from

<code>
$ svn help
</code>

== Rules ==

TODO

== For administrators ==

Instruction for managing users are on the page [[DEI Subversion Administration]]

DEI Subversion Administration

2009-06-24T21:53:40Z

BernardoDalSeno: /* Adding a new user */

Writing Good Code

2009-06-16T15:55:16Z

BernardoDalSeno: /* C and C++ code */

==Why this page==
When tutoring students for their theses or projects, I often find many problems with the code they write. I'm not referring to bugs; bugs happen, as flu happens, although there are some things you can do to make them more unlikely. The problem discussed here is ''Bad code''TM, i.e., code that nobody can read or understand, not even its author. So I've decided to write this page with some advice on how to write ''Good code''TM. Please note that everything you find in this page should not be considered as strict rules, as it expresses the point of view of its author(s); but a reasonable piece of advice needs a good reason to counter it, in order not to follow it; so at least think about it. Contributions are welcome.
::--Bernardo

==General==

The source of the program is not only a way to obtain a binary that your computer can run, it is a way to express ideas. They should be clear to the compiler, so it compiles and you have your nice executable, but they should be clear also to anyone that reads your code, including your fellow students, your supervisor, and, of course, you — even after a couple of months. '''Write for your fellows, not only for the computer!'''

===I Think Therefore I Program===

And the inverse is true: you cannot program without thinking. So, before rushing to the keyboard, take a piece of paper and try to lay down your ideas. A clear idea of the structure of data and the algorithm you want to apply is important to write a properly working program. Think about how you're going to use the data and shape the data structures accordingly; think about how to factorize your algorithm, what functions (methods) and what parameters you need.

===Names===

Names should be meaningful, clear, short (at least, not too long), and to the point. That applies to pretty everything: classes, variables, functions, modules, members. Remember: the compiler doesn't care about names, but humans do; your colleagues are humans, and probably they want to understand your code when they happen to read it. If the project you are working on or the language you are using come with a naming convention just follow it; separate words in names by using underscores '_' or mixedCaseLikeThis.

In general, you want to use nouns or adjectives as names for variable and attributes, while verbs are appropriate for functions and methods. Names with a wider scope (classes, public methods, global variables, global functions...) require more care: They cannot be too simple to avoid clashing with local names, and both the meaning and the context should be clear. 'tmp' can be a good name for a local variable with a life of a couple of lines of code, or 'k' is good for a loop counter, but they are really bad names for anything with a scope wider than a loop. For example, if you have to store the name of a temporary file where you save the result of the application of a fast Fourier transform, something like 'fft_file_name' is more appropriate; if you have a counter that keeps track of the number of time you called the 'evaluate_fitness()' method (e.g., for statistical purposes), you could chose something like 'fitness_call_count'. Completely uninformative and generic names like 'var', 'flag', 'foo', 'pippo', 'number'... are always bad.

===Comments===

A big problem is the use of comments. You can encounter projects with hundreds of lines of code and not a single line of comment, so that it is hard to guess even the general purpose of the program, or projects with ultra-verbose comments, like this:
k = k + 1; // increment k
Yeah, thanks, I thought it was extracting the square root of k.

Comments are important, and their correct use improves the quality of the code, even when there are no comments. Really! Often comments are written as a patch to badly-written code, but a tangled piece of code is not a way to clearly convey your ideas; and a comment added to a tangled piece of code doesn't make it much clearer. Besides, if you can't understand a piece of code, does some comment raise your confidence that the code is really working? Tangled code is more likely to be bugged, and more difficult to modify, so please write your algorithm in a way that it can be understood just be reading the instructions, not the comments. There are [http://www.ioccc.org/ good places] where to write obfuscated code, and a thesis is not one of them.

Just an example (taken from real code! names have been changed to protect the innocent):
#define NUM_IT 3
for (j = 0; j < NUM_IT; ++j) {
if (j == 0) { // First iteration
// Do something
...
} else if (j == 1) { // Second iteration
// Do something else
...
} else if (j == 2) { // Third iteration
// Do things
...
}
}
This is a rather confusing way to write a simple sequence:
// Do something
...
// Do something else
...
// Do things
...

So, what to comment? Good places for comments are class declarations, functions or methods (you tell what the function is about, what the parameters are, and describe the expected results and side effects), class attribute declarations, global or important variables, the beginning of a file, and a few others. Also, when you take a tricky decision, please document it!

===Debugging===

There is no program without a bug (or was it "There is no rose without a bug"?). Your programs are no exception, so you'll have to remove bugs. Many books could be written about debugging (and they are), but here just a few ideas are hinted.

When you experience a failure, don't rush hacking at the code until it disappears. We are in an engineering school, so use the engineering method: build a model. In other words, try to pinpoint the error that caused the failure, before trying to remove it. Do tests and explore the functioning of your program in order to find the problem; try to find a way to make the failure reproducible, so after you correct the error you can check that everything is working properly. Debuggers are useful to inspect the state of the program, but you can use also [http://en.wikipedia.org/wiki/Assertion_%28computing%29 assertions] and <code>printf</code>s (or the output function of your favorite language) when you can't or don't want to run a debugger.

Sometimes you have to write some debugging code to check conditions, to validate data structures, or print out the value of variables.
This code is not needed when you've finished debugging, but this no reason for removing it. If you spent time writing code, don't waste your effort; you or someone else may need it in the future to debug a similar problem. Leave it in place; surround it with conditionals: <code>#ifdef DEBUG</code> if you are using C, or <code>if (debug)</code> in Java or other languages that have no preprocessor (<code>debug</code> is a global variable in this case); in this way, it is easy to activate it. Unless the code is inside a deeply-nested loop, the performance hit of a run-time ''if'' is negligible; if (and only if) your debugging code is an a deeply-nested loop, wrap it in a comment.

If you write test cases (or better yet test scripts), don't throw them away. Rerun your tests periodically, so you can avoid regressions. There are even tools that help in this, like [http://junit.sourceforge.net/ JUnit] (for Java; there are ports [http://sourceforge.net/projects/cppunit for C++] and other languages).

===Optimization===

You want your code to be as fast as possible, right? Wrong! Really, do you care if your favorite word processor saves a microsecond every time you type a character, or would you trade that microsecond for a greater reliability, so that it doesn't crash losing half a chapter of your precious thesis?

Optimizing code require (your) time, and sometimes the code becomes less readable and maintainable. So, concentrate your efforts on the parts of the program that really require it; measure the speed of your program, and use a [http://en.wikipedia.org/wiki/Profiler_%28computer_science%29 profiler] to identify the bottlenecks. A simple rule of thumb can be given: anything that is not inside a doubly-nested loop is not worth optimizing. Always measure your progress, as bottlenecks may change.

And never forget that a better algorithm beats any tweaking of your code. For example, if you are looking for the maximum in an array, sorting the array and taking the first element is a bad solution (it has at least O(n log n) complexity); if you don't need the sorted array for other purposes, a linear sweep of the array is faster (it's O(n)) and requires less memory.

===Indentation and spaces===

In most languages, spaces and indentation are not part of the syntax, and they are mostly ignored by the compiler (Python is a significant exception), yet indentation and spaces are very useful to format your code and make it more readable. There are many way to use them, but the first rule is 'consistency'. Choose the style you like the most, and stick to it; particularly, choose if you want to use spaces or tabs for indentation, and be consistent, otherwise when someone else opens your project with a different editor with a different idea of tab length, your nice (you made it nice, didn't you?) indentation will be screwed up.

===Warnings===

When compiled, your program should not raise any warnings. '''Any''' warnings, which includes harmless warnings. Compilers generate warnings for a reason: you have written a code that does something suspicious and you should look into it. So, if someone else compiles your program, should they also check that all the warnings of your code are harmless? Or how can they be sure that you effectively checked all warnings and you're not just a sloppy coder? :-) And what happens if they (or you) change your code that raises a gazillion of warnings? How can anyone spot any new warning?
So, please make sure that your code raises no warnings, and whoever will use it in the future will thank you for that.

==C and C++ code==

The [http://www.google.com/search?q=%22Linux+kernel+coding+style%22 Linux kernel coding style] is an interesting reading, particularly chapters 3 (Placing Braces and Spaces), 4 (Naming), 6 (Functions), 8 (Commenting), 12 (Macros).

C (and C++) have a fair number of operators, with strictly defined precedences. Even if you know all the precedence rules by heart, don't assume others do; so, please use parentheses when writing complex expressions.

If you are writing any non-trivial project (anything that spans more than one file of source code can be considered non-trivial), you may want to use [http://www.stack.nl/~dimitri/doxygen/ Doxygen] for documentation. It's simple to use, and after you've learned how it works, it doesn't require additional work. On the contrary, it helps you in keeping your code well documented.

In C++, never use the C-style cast operator, particularly with pointers. Use <code>static_cast</code> or a constructor for classes, and <code>dynamic_cast</code> for pointers. C-style casts are ambiguous, as they can mean many different type of casts, some of which are dangerous. The only situation where a C-style cast may have a place is for conversion between built-in numeric types.

===Header files===

Apparently, header (include) files can be problematic, probably because of the Java background common to many people nowadays. If you any doubt about them, Wikipedia does a good job in briefly explaining what [http://en.wikipedia.org/wiki/Header_file header files] are.

Major misconceptions regards what goes inside a header file. This a topic better described in a programming manual (and you've already read it, haven't you?), but a good rule of thumb is: only declarations and definitions that neither reserve memory nor produce code.

A header file should contain all (and only) the include directives necessary for its compilation, i.e., if the file makes use of any data type or symbol, it must include the header that defines such data type or symbol.

There can be problems with header files, due to multiple or recursive inclusions. To avoid them, you can wrap their content in a <code>#ifndef</code>...<code>#endif</code> construct (inside the header file!), like this:
#ifndef MY_PROJECT_MY_HEADER_H
#define MY_PROJECT_MY_HEADER_H
/* Real content of the file */
...
#endif
The name of the macro should be something that is unlikely to clash with other macros; e.g., prepend the name of your project.

==Matlab==

Matlab is a rather slow interpreted language, but it shines — as its name implies — at matrix manipulation. So try to avoid loops, and do operations in parallel on arrays. Many vectorized functions are built-in, so look in the help when you need simple operations like sums, means, maximum...

Matlab has a tool, <code>mlint</code>, that checks the code for easily detectable problems. It is active by default in the Matlab editor, and it highlight problems with jagged orange lines under the troubled code (and corresponding orange indicators on the right-hand bar). Don't ignore them, unless you are sure they are harmless; look up in the help or on the Web if don't understand a problem.

One of the problems spotted by <code>mlint</code> is the dynamic growth of arrays. Avoid that; it slows Matlab, as it turns O(n) algorithms into O(n²). For example,
a = [];
for k = 1:50000
a(k) = k;
end
takes more than 30 seconds on a machine, while
a = zeros(50000,1);
for k = 1:50000
a(k) = k;
end
takes only 0.1 seconds on the same machine. See
[http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f1-85766.html#f1-88760 the full explanation] on the Mathworks Web site.

Remember not to trust <code>mlint</code> too much; there is no perfect static analyzer (you remember [http://en.wikipedia.org/wiki/Rice%27s_theorem Rice's theorem], right?). If you have no warnings, it doesn't mean that your program is perfect.

Writing Good Code

2009-06-16T15:55:01Z

BernardoDalSeno: /* C and C++ code */

==Why this page==
When tutoring students for their theses or projects, I often find many problems with the code they write. I'm not referring to bugs; bugs happen, as flu happens, although there are some things you can do to make them more unlikely. The problem discussed here is ''Bad code''TM, i.e., code that nobody can read or understand, not even its author. So I've decided to write this page with some advice on how to write ''Good code''TM. Please note that everything you find in this page should not be considered as strict rules, as it expresses the point of view of its author(s); but a reasonable piece of advice needs a good reason to counter it, in order not to follow it; so at least think about it. Contributions are welcome.
::--Bernardo

==General==

The source of the program is not only a way to obtain a binary that your computer can run, it is a way to express ideas. They should be clear to the compiler, so it compiles and you have your nice executable, but they should be clear also to anyone that reads your code, including your fellow students, your supervisor, and, of course, you — even after a couple of months. '''Write for your fellows, not only for the computer!'''

===I Think Therefore I Program===

And the inverse is true: you cannot program without thinking. So, before rushing to the keyboard, take a piece of paper and try to lay down your ideas. A clear idea of the structure of data and the algorithm you want to apply is important to write a properly working program. Think about how you're going to use the data and shape the data structures accordingly; think about how to factorize your algorithm, what functions (methods) and what parameters you need.

===Names===

Names should be meaningful, clear, short (at least, not too long), and to the point. That applies to pretty everything: classes, variables, functions, modules, members. Remember: the compiler doesn't care about names, but humans do; your colleagues are humans, and probably they want to understand your code when they happen to read it. If the project you are working on or the language you are using come with a naming convention just follow it; separate words in names by using underscores '_' or mixedCaseLikeThis.

In general, you want to use nouns or adjectives as names for variable and attributes, while verbs are appropriate for functions and methods. Names with a wider scope (classes, public methods, global variables, global functions...) require more care: They cannot be too simple to avoid clashing with local names, and both the meaning and the context should be clear. 'tmp' can be a good name for a local variable with a life of a couple of lines of code, or 'k' is good for a loop counter, but they are really bad names for anything with a scope wider than a loop. For example, if you have to store the name of a temporary file where you save the result of the application of a fast Fourier transform, something like 'fft_file_name' is more appropriate; if you have a counter that keeps track of the number of time you called the 'evaluate_fitness()' method (e.g., for statistical purposes), you could chose something like 'fitness_call_count'. Completely uninformative and generic names like 'var', 'flag', 'foo', 'pippo', 'number'... are always bad.

===Comments===

A big problem is the use of comments. You can encounter projects with hundreds of lines of code and not a single line of comment, so that it is hard to guess even the general purpose of the program, or projects with ultra-verbose comments, like this:
k = k + 1; // increment k
Yeah, thanks, I thought it was extracting the square root of k.

Comments are important, and their correct use improves the quality of the code, even when there are no comments. Really! Often comments are written as a patch to badly-written code, but a tangled piece of code is not a way to clearly convey your ideas; and a comment added to a tangled piece of code doesn't make it much clearer. Besides, if you can't understand a piece of code, does some comment raise your confidence that the code is really working? Tangled code is more likely to be bugged, and more difficult to modify, so please write your algorithm in a way that it can be understood just be reading the instructions, not the comments. There are [http://www.ioccc.org/ good places] where to write obfuscated code, and a thesis is not one of them.

Just an example (taken from real code! names have been changed to protect the innocent):
#define NUM_IT 3
for (j = 0; j < NUM_IT; ++j) {
if (j == 0) { // First iteration
// Do something
...
} else if (j == 1) { // Second iteration
// Do something else
...
} else if (j == 2) { // Third iteration
// Do things
...
}
}
This is a rather confusing way to write a simple sequence:
// Do something
...
// Do something else
...
// Do things
...

So, what to comment? Good places for comments are class declarations, functions or methods (you tell what the function is about, what the parameters are, and describe the expected results and side effects), class attribute declarations, global or important variables, the beginning of a file, and a few others. Also, when you take a tricky decision, please document it!

===Debugging===

There is no program without a bug (or was it "There is no rose without a bug"?). Your programs are no exception, so you'll have to remove bugs. Many books could be written about debugging (and they are), but here just a few ideas are hinted.

When you experience a failure, don't rush hacking at the code until it disappears. We are in an engineering school, so use the engineering method: build a model. In other words, try to pinpoint the error that caused the failure, before trying to remove it. Do tests and explore the functioning of your program in order to find the problem; try to find a way to make the failure reproducible, so after you correct the error you can check that everything is working properly. Debuggers are useful to inspect the state of the program, but you can use also [http://en.wikipedia.org/wiki/Assertion_%28computing%29 assertions] and <code>printf</code>s (or the output function of your favorite language) when you can't or don't want to run a debugger.

Sometimes you have to write some debugging code to check conditions, to validate data structures, or print out the value of variables.
This code is not needed when you've finished debugging, but this no reason for removing it. If you spent time writing code, don't waste your effort; you or someone else may need it in the future to debug a similar problem. Leave it in place; surround it with conditionals: <code>#ifdef DEBUG</code> if you are using C, or <code>if (debug)</code> in Java or other languages that have no preprocessor (<code>debug</code> is a global variable in this case); in this way, it is easy to activate it. Unless the code is inside a deeply-nested loop, the performance hit of a run-time ''if'' is negligible; if (and only if) your debugging code is an a deeply-nested loop, wrap it in a comment.

If you write test cases (or better yet test scripts), don't throw them away. Rerun your tests periodically, so you can avoid regressions. There are even tools that help in this, like [http://junit.sourceforge.net/ JUnit] (for Java; there are ports [http://sourceforge.net/projects/cppunit for C++] and other languages).

===Optimization===

You want your code to be as fast as possible, right? Wrong! Really, do you care if your favorite word processor saves a microsecond every time you type a character, or would you trade that microsecond for a greater reliability, so that it doesn't crash losing half a chapter of your precious thesis?

Optimizing code require (your) time, and sometimes the code becomes less readable and maintainable. So, concentrate your efforts on the parts of the program that really require it; measure the speed of your program, and use a [http://en.wikipedia.org/wiki/Profiler_%28computer_science%29 profiler] to identify the bottlenecks. A simple rule of thumb can be given: anything that is not inside a doubly-nested loop is not worth optimizing. Always measure your progress, as bottlenecks may change.

And never forget that a better algorithm beats any tweaking of your code. For example, if you are looking for the maximum in an array, sorting the array and taking the first element is a bad solution (it has at least O(n log n) complexity); if you don't need the sorted array for other purposes, a linear sweep of the array is faster (it's O(n)) and requires less memory.

===Indentation and spaces===

In most languages, spaces and indentation are not part of the syntax, and they are mostly ignored by the compiler (Python is a significant exception), yet indentation and spaces are very useful to format your code and make it more readable. There are many way to use them, but the first rule is 'consistency'. Choose the style you like the most, and stick to it; particularly, choose if you want to use spaces or tabs for indentation, and be consistent, otherwise when someone else opens your project with a different editor with a different idea of tab length, your nice (you made it nice, didn't you?) indentation will be screwed up.

===Warnings===

When compiled, your program should not raise any warnings. '''Any''' warnings, which includes harmless warnings. Compilers generate warnings for a reason: you have written a code that does something suspicious and you should look into it. So, if someone else compiles your program, should they also check that all the warnings of your code are harmless? Or how can they be sure that you effectively checked all warnings and you're not just a sloppy coder? :-) And what happens if they (or you) change your code that raises a gazillion of warnings? How can anyone spot any new warning?
So, please make sure that your code raises no warnings, and whoever will use it in the future will thank you for that.

==C and C++ code==

The [http://www.google.com/search?q=%22Linux+kernel+coding+style%22 Linux kernel coding style] is an interesting reading, particularly chapters 3 (Placing Braces and Spaces), 4 (Naming), 6 (Functions), 8 (Commenting), 12 (Macros).

C (and C++) have a fair number of operators, with strictly defined precedences. Even if you know all the precedence rules by heart, don't assume others do; so, please use parentheses when writing complex expressions.

If you are writing any non-trivial project (anything that spans more than one file of source code can be considered non-trivial), you may want to use [http://www.stack.nl/~dimitri/doxygen/ Doxygen] for documentation. It's simple to use, and after you've learned how it works, it doesn't require additional work. On the contrary, it helps you in keeping your code well documented.

In C++, never use the C-style cast operator, particularly with pointers. Use <code>static_cast</code> or a constructor for classes, and <code>dynamic_cast</code> for pointers. C-style casts are ambiguous, as they can mean many different type of casts, some of which are dangerous. The only situation where a C-style cast may have a place is for conversion between built-in numeric types.

===Header files===
Apparently, header (include) files can be problematic, probably because of the Java background common to many people nowadays. If you any doubt about them, Wikipedia does a good job in briefly explaining what [http://en.wikipedia.org/wiki/Header_file header files] are.

Major misconceptions regards what goes inside a header file. This a topic better described in a programming manual (and you've already read it, haven't you?), but a good rule of thumb is: only declarations and definitions that neither reserve memory nor produce code.

A header file should contain all (and only) the include directives necessary for its compilation, i.e., if the file makes use of any data type or symbol, it must include the header that defines such data type or symbol.

There can be problems with header files, due to multiple or recursive inclusions. To avoid them, you can wrap their content in a <code>#ifndef</code>...<code>#endif</code> construct (inside the header file!), like this:
#ifndef MY_PROJECT_MY_HEADER_H
#define MY_PROJECT_MY_HEADER_H
/* Real content of the file */
...
#endif
The name of the macro should be something that is unlikely to clash with other macros; e.g., prepend the name of your project.

==Matlab==

Matlab is a rather slow interpreted language, but it shines — as its name implies — at matrix manipulation. So try to avoid loops, and do operations in parallel on arrays. Many vectorized functions are built-in, so look in the help when you need simple operations like sums, means, maximum...

Matlab has a tool, <code>mlint</code>, that checks the code for easily detectable problems. It is active by default in the Matlab editor, and it highlight problems with jagged orange lines under the troubled code (and corresponding orange indicators on the right-hand bar). Don't ignore them, unless you are sure they are harmless; look up in the help or on the Web if don't understand a problem.

One of the problems spotted by <code>mlint</code> is the dynamic growth of arrays. Avoid that; it slows Matlab, as it turns O(n) algorithms into O(n²). For example,
a = [];
for k = 1:50000
a(k) = k;
end
takes more than 30 seconds on a machine, while
a = zeros(50000,1);
for k = 1:50000
a(k) = k;
end
takes only 0.1 seconds on the same machine. See
[http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f1-85766.html#f1-88760 the full explanation] on the Mathworks Web site.

Remember not to trust <code>mlint</code> too much; there is no perfect static analyzer (you remember [http://en.wikipedia.org/wiki/Rice%27s_theorem Rice's theorem], right?). If you have no warnings, it doesn't mean that your program is perfect.

AirBAT Instructions

2009-06-03T14:08:37Z

BernardoDalSeno:

[https://svn.ws.dei.polimi.it/airbat/ AirBAT] is a repository containing software developed in projects related to the [[BioSignal Analysis]] area.

== Becoming a member ==
AirBAT is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.ws.dei.polimi.it/airbat/</nowiki>''.

Students who need to work with AirBAT should ask their supervisor to create an account for them on https://acme.ws.dei.polimi.it/, and then ask one of the administrators of AirBAT for permissions.

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

Airpaper

2009-06-03T14:06:17Z

BernardoDalSeno:

Configuring Subversion

2009-06-03T14:04:59Z

BernardoDalSeno: /* TortoiseSVN under Windows */

This page describe how to setup Subversion on your machine to work with various projects of the AirLAB. For more information about how to use Subversion please see [[Using Subversion]] and the specific project page.

On the [http://www.bci2000.org/wiki/index.php BCI2000 Wiki], you can find good tutorials on [http://www.bci2000.org/wiki/index.php/Programming_Howto:SVN_Client_Setup using the Subversion client] and
[http://www.bci2000.org/wiki/index.php/Programming_Howto:Using_TortoiseSVN TortoiseSVN]. They have been written for BCI2000, but can be used also for other projects if you change the URLs.

== TortoiseSVN under Windows ==

Since the migration to the new server, using [http://tortoisesvn.tigris.org/ TortoiseSVN] under Windows should be easier, as there is no more need for a certificate. Please refer to the documentation of the program.

Configuring Subversion

2009-05-27T10:57:56Z

BernardoDalSeno: /* TortoiseSVN under Windows */

This page describe how to setup Subversion on your machine to work with various projects of the AirLAB. For more information about how to use Subversion please see [[Using Subversion]] and the specific project page.

On the [http://www.bci2000.org/wiki/index.php BCI2000 Wiki], you can find good tutorials on [http://www.bci2000.org/wiki/index.php/Programming_Howto:SVN_Client_Setup using the Subversion client] and
[http://www.bci2000.org/wiki/index.php/Programming_Howto:Using_TortoiseSVN TortoiseSVN]. They have been written for BCI2000, but can be used also for other projects if you change the URLs.

== TortoiseSVN under Windows ==

Since the migration to the new serve, using [http://tortoisesvn.tigris.org/ TortoiseSVN] under Windows should be easier, as there is no more need for a certificate. Please refer to the documentation of the program.

AirBAT Instructions

2009-05-27T10:56:05Z

BernardoDalSeno: /* Becoming a member */

[https://savane.elet.polimi.it/projects/airbat/ AirBAT] is a repository containing software developed in projects related to the [[BioSignal Analysis]] area.

== Becoming a member ==
AirBAT is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page. The repository URL is ''<nowiki>https://svn.elet.polimi.it/airbat/</nowiki>''.

Students who need to work with AirBAT should ask their supervisor to create an account for them on https://acme.ws.dei.polimi.it/, and then ask one of the administrators of AirBAT for permissions.

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].

Airpaper

2009-05-27T10:48:28Z

BernardoDalSeno:

[https://svn.elet.polimi.it/airpaper/ Airpaper] (authentication needed) is the repository of papers written at Airlab.

It is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page, but you don't need the key and Ssh part as Airpaper uses Http authentication. ''<nowiki>https://svn.elet.polimi.it/airpaper/</nowiki>'' is the repository Url when you checkout your working copy.

You have to be added as a user to the project by one of the administrators, even if you already are a user of Dei's Savane. Administrators currently are: [[User:RossellaBlatt|Rossella Blatt]], [[User:BernardoDalSeno|Bernardo Dal Seno]], [[User:GiulioFontana|Giulio Fontana]], [[User:MatteoMatteucci|Matteo Matteucci]], [[User:SimoneTognetti|Simone Tognetti]]. (New administrators, please add your names here)

== Structure ==

This is a partial structure of the repository:
* '''bci''': BCI-related stuff
* '''common''': common stuff
** '''bib''': bibliography (Bibtex files, databases and styles)
** '''images''': obvious
* '''wheelchair''': Lurch-related stuff
All files related to a paper should be contained in one directory; please use a name that is clear and begins with a year, e.g., ''2009_Science'', ''2010_Nature_Higgs''.

== Rules ==

TODO

== For administrators ==

Instruction for managing users are on the page [[DEI Subversion Administration]]

DEI Subversion Administration

2009-05-27T10:45:41Z

BernardoDalSeno: /* Adding a new user */

AirBAT Instructions

2009-05-27T10:41:17Z

BernardoDalSeno:

[https://savane.elet.polimi.it/projects/airbat/ AirBAT] is a repository containing software developed in projects related to the [[BioSignal Analysis]] area.

== Becoming a member ==
AirBAT is based on [http://subversion.tigris.org/ Subversion]; you can find some help in configuring Subversion in the [[Configuring Subversion]] page.

Students who need to work with AirBAT should ask their supervisor to create an account for them on https://acme.ws.dei.polimi.it/, and then ask one of the administrators of AirBAT for permissions.

== Structure ==

This is a very brief overview of the directory hierarchy of the repository. The root contains these directories:
* '''AffectiveComputing''': software for analysis of biological signals for [[BioSignal Analysis]]
* '''Robot''': software used for the control of the robots built to generate different level of stress in users
* '''bci''': software for analysis of EEG used for [[Brain-Computer Interface | Brain-Computer Interfaces]]. There are a common directory and a directory for each person.
** '''common''': contains files and programs that could be useful to others, e.g., Matlab functions to load data. The subdirectory '''java''' contains (as you guessed) Java software, while the subdirectory '''matlab''' contains Matlab scripts and functions.
** There are also directories for each person (or group) working on BCI, named after the persons. The stuff in these directories is "private", i.e., only the owner should modify things there and they may contain work in progress, programs still badly documented or incomplete... These directories are not secret and not intended to be so. Moreover, they are also writable by other users, as the repository doesn't enforce any such policy; but it is slightly rude to modify files on which others are working.
* '''lurch''': software used for the [[LURCH - The autonomous wheelchair | Lurch]] project.

== Rules ==

The project depends on the collaborative effort of people; these rules are not strict laws enforced by the AirBAT police, but guidelines to make an effective use of the tools. In summary, you can break them, but you have to have a good reason to do that :-). If you think that some policy could be made better, please tell your advisor or co-advisor.

'''Please note that this section has been written by Bernardo Dal Seno, but no one has said that any rule is bad yet'''

Subversion should be used only for source files; so, no executables, object files (.o, .obj), archives (e.g., .jar, .zip) and other binary files. The reason for the repository is to keep track of versions and share your work with other people; computer-generated files are no good for this.

Makefiles or project files are definitely source files, as they contain directions for the compiler. So please add them to the repository. If you are in doubt about which files are used, try to copy the files on another machine and see which files are needed in order to correctly edit and compile the project. See [[#Project Files|the Project Files section below]] for some known files.

If your project needs some external file or library, don't add it to the repository, but say so in a README and put a link to where to find the library. The repository remains cleaner, it is clearer what is your contribution, and it is easier to upgrade to a new version of the external library.

If you want to share binaries, e.g., the executable of the latest version of your project, the best place is probably your project page on this Wiki.

Versioned and unversioned files can live side-by-side in the local copy on your PC. That means, for example, that you can compile source files in your local copy, just avoid adding whole directories if they contain binary files; Subversion commands are recursive by default, so add individual files instead.
Using the local copy as your working space and checking in frequently (e.g., every day) is the most effective way to exploit the power of version control systems. Don't be afraid to mistakes; everything in the repository history can be retrieved, so irreparable losses are not possible. Whatever you don't check in, though, can be lost. Check in frequently! (or should I tell you how some people have lost 1-month worth of work?)

For the '''bci''' hierarchy, where a '''common''' directory exists, some additional care is needed before committing: you don't want to commit a broken function that you have not yet debugged, as your fellows working on a different project could be hurt (or ''you'' may be hurt, if they revert your changes). You have two options: either you postpone committing until you have finished debugging (but you lose the advantages of the version control system), or you use [http://en.wikipedia.org/wiki/Branching_%28software%29 branching]. For branching, do a copy with the Subversion copy command (''svn cp'' from the command line) from the '''common''' directory to your own, and use the copy until you are finished changing. After the debugging is complete, you do a final commit, and then you can import your changes with the ''merge'' command; don't just overwrite the old copy in '''common''', unless you are sure nobody changed it after the branching.

====Project Files====
Here the project files used by some IDEs are reported. Please help to make the list longer and more accurate. (The parts in ''italic'' are supposed to be substituted by actual names.)
;Eclipse (Java projects)
:''project_dir'' / .classpath
:''project_dir'' / .project
;Borland C++
:''project_dir'' / ''project_name''.bdsproj

== Administration ==
Instructions for administration tasks can be found here: [[DEI Subversion Administration]].