multitouch/docs/report.tex

\documentclass[twoside,openright]{uva-bachelor-thesis}

\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
\usepackage{hyperref,graphicx,float}

% Link colors
\hypersetup{colorlinks=true,linkcolor=black,urlcolor=blue,citecolor=DarkGreen}

% Title Page
\title{Universal multi-touch event mechanism}
\author{Taddeüs Kroes}
\supervisors{Dr. Robert G. Belleman (UvA)}
\signedby{Dr. Robert G. Belleman (UvA)}

\begin{document}

% Title page
\maketitle
\begin{abstract}
    % TODO
\end{abstract}

% Set paragraph indentation
\parindent 0pt
\parskip 1.5ex plus 0.5ex minus 0.2ex

% Table of contant on separate page
\tableofcontents

\chapter{Introduction}

% Ruwe probleemstelling
Multi-touch interaction is becoming increasingly common, mostly due to the wide
use of touch screens in phones and tablets. When programming applications using
this method of interaction, the programmer needs an abstraction of the raw data
provided by the touch driver of the device. This abstraction exists in several
multi-touch application frameworks like Nokia's
Qt\footnote{\url{http://qt.nokia.com/}}. However, applications that do not use
these frameworks have no access to their multi-touch events.

% Aanleiding
This problem was observed during an attempt to create a multi-touch
``interactor'' class for the Visualization Toolkit (VTK \cite{VTK}). Because
VTK provides the application framework here, it is undesirable to use an entire
framework like Qt simultaneously only for its multi-touch support.

% Ruw doel
The goal of this project is to define a universal multi-touch event triggering
mechanism. To test the definition, a reference implementation is written in
Python.

% Setting
To test multi-touch interaction properly, a multi-touch device is required.
The University of Amsterdam (UvA) has provided access to a multi-touch table
from PQlabs. The table uses the TUIO protocol \cite{TUIO} to communicate touch
events.

% Afbakening
% TODO: moet dit omlaag naar 'Definition of the problem'?
The scope of this thesis includes the design of an multi-touch triggering
mechanism, a reference implementation of this design, and its integration into
a VTK interactor. To be successful, the design should allow for extensions to
be added to any implementation. The reference implementation is a Proof of
Concept that translates TUIO events to some simple touch gestures that are used
by a VTK interactor.

    \section{Structure of this document}

    % TODO

\chapter{Definition of the problem}

% Hoofdvraag
The goal of this thesis is to create a multi-touch event triggering mechanism
for use in a VTK interactor. The design of the mechanism must be universal.

% Deelvragen
To design such a mechanism properly, the following questions are relevant:
\begin{itemize}
    \item What is the input of the mechanism? Different touch drivers have
        different API's. To be able to support different drivers (which is
        highly desirable), there should probably be a translation from the
        driver API to a fixed input format.
    \item How can extendability be accomplished? The set of supported events
        should not be limited to a single implementation, but an application
        should be able to define its own custom events.
    \item Can events be shared with multiple processes at the same time? For
        example, a network implementation could run as a service instead of
        within a single application, triggering events in any application that
        needs them.
    \item Is performance an issue? For example, an event loop with rotation
        detection could swallow up more processing resources than desired.
\end{itemize}

\chapter{Preliminary inquiries}

    \section{The TUIO protocol}

    The TUIO protocol \cite{TUIO} defines a way to geometrically describe
    tangible objects, such as fingers or fiducials on a multi-touch table.  The
    table used for this thesis uses the protocol in its driver. Object
    information is sent to the TUIO UDP port (3333 by default).

    For efficiency reasons, the TUIO protocol is encoded using the Open Sound
    Control (OSC)\footnote{\url{http://opensoundcontrol.org/specification}}
    format.  An OSC server/client implementation is available for Python:
    pyOSC\footnote{\url{https://trac.v2.nl/wiki/pyOSC}}.

    A Python implementation of the TUIO protocol also exists:
    pyTUIO\footnote{\url{http://code.google.com/p/pytuio/}}. However, the
    execution of an example script yields an error regarding Python's built-in
    \texttt{socket} library. Therefore, the reference implementation uses the
    pyOSC package to receive TUIO messages.

    The two most important message types of the protocol are ALIVE and SET
    messages. An ALIVE message contains the list of session id's that are
    currently ``active'', which in the case of multi-touch a table means that
    they are touching the screen. A SET message provides geometric information
    of a session id, such as position, velocity and acceleration.

    Each session id represents an object. The only type of objects on the
    multi-touch table are what the TUIO protocol calls ``2DCur'', which is a
    (x, y) position on the screen.

    ALIVE messages can be used to determine when an object touches and releases
    the screen. For example, if a session id was in the previous message but
    not in the current, The object it represents has been lifted from the
    screen.

    SET provide information about movement. In the case of simple (x, y)
    positions, only the movement vector of the position itself can be
    calculated. For more complex objects such as fiducials, arguments like
    rotational position is also included.

    TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the
    left top corner of the screen and $(1.0, 1.0)$ the right bottom corner.  To
    focus events within a window, a translation to window coordinates is
    required in the client application, as stated by the online specification
    \cite{TUIO_specification}:
    \begin{quote}
        In order to compute the X and Y coordinates for the 2D profiles a TUIO
        tracker implementation needs to divide these values by the actual
        sensor dimension, while a TUIO client implementation consequently can
        scale these values back to the actual screen dimension.
    \end{quote}

% TODO

\chapter{Experiments}

% testimplementatie met taps, rotatie en pinch. Hieruit bleek:
% - dat er verschillende manieren zijn om bijv. "rotatie" te
%   detecteren, (en dat daartussen onderscheid moet kunnen worden
%   gemaakt)
% - dat detectie van verschillende soorten gestures moet kunnen
%   worden gescheiden, anders wordt het een chaos.
% - Er zijn een aantal keuzes gemaakt bij het ontwerpen van de gestures,
%   bijv dat rotatie ALLE vingers gebruikt voor het centroid. Het is
%   wellicht in een ander programma nodig om maar 1 hand te gebruiken, en
%   dus punten dicht bij elkaar te kiezen (oplossing: windows).

% Tekenprogramma dat huidige points + centroid tekent en waarmee
% transformatie kan worden getest Link naar appendix "supported events"

% Proof of Concept: VTK interactor

% -------
% Results
% -------

\chapter{Server structure}

% TODO: link naar appendix met schema

    \section{Input server}

    % TODO
    % vertaling driver naar point down, move, up
    % TUIO in reference implementation

    \section{Gesture server}

        \subsection{Windows}

        % TODO
        % toewijzen even aan deel v/h scherm:
        % TUIO coördinaten zijn over het hele scherm en van 0.0 tot 1.0, dus moeten
        % worden vertaald naar pixelcoördinaten binnen een ``window''

        \subsection{Trackers}

        % TODO
        % event binding/triggering
        % extendability

\chapter{Reference implementation}

% TODO
% draw.py
% VTK interactor

\chapter{Conclusions}

% TODO
% Windows zijn een manier om globale events toe te wijzen aan vensters
% Trackers zijn een effectieve manier om gebaren te detecteren
% Trackers zijn uitbreidbaar door object-orientatie

\chapter{Suggestions for future work}

% TODO: Network protocol (ZeroMQ)

\bibliography{report}{}
\bibliographystyle{plain}

\appendix

\chapter{Schema of mechanism structure}
\label{app:schema}

% TODO: "dia"

\chapter{Supported events in reference implementation}
\label{app:supported-events}

% TODO

\end{document}