| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249 |
- \documentclass[a4paper]{article}
- \usepackage[english]{babel}
- \usepackage[utf8]{inputenc}
- \usepackage{amsmath,hyperref,graphicx,booktabs,float}
- % Link colors
- \hypersetup{colorlinks=true,linkcolor=black,urlcolor=blue}
- \title{Bachelor thesis\\Universal multi-touch event mechanism}
- \author{\begin{tabular}{ll}
- Name: & Taddeüs Kroes\\
- Student number: & 6054129\\
- E-mail address: & \texttt{taddeus.kroes@student.uva.nl}\\
- Address: & Wethouder van Wijckstraat 40, 1107 BR Amsterdam\\
- Phone number: & 06-23437025\\
- Supervisor: & Dr. R.G. Belleman (UvA)\\
- \end{tabular}}
- \begin{document}
- % Title page
- \maketitle
- \abstract{
- % TODO
- }
- % Set paragraph indentation
- \parindent 0pt
- \parskip 1.5ex plus 0.5ex minus 0.2ex
- % Table of contant on separate page
- \pagebreak
- \tableofcontents
- \pagebreak
- \section{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\footnote{\url{http://www.vtk.org/}}). 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 tests 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\footnote{\url{http://www.tuio.org/}} 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.
- \subsection{Structure of this document}
- % TODO
- \section{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}
- \section{Related work}
- % TODO
- \section{Methods}
- % TODO
- \subsection{Preliminary inquiries}
- \subsubsection{The TUIO protocol}
- The TUIO protocol\footnote{\url{http://tuio.org/?specification}}
- 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
- specification:
- \begin{citation}
- 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{citation}
- \subsection{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
- % -------
- \section{Server structure}
- % TODO: link naar appendix met schema
- \subsection{Input server}
- % TODO
- % vertaling driver naar point down, move, up
- % TUIO in reference implementation
- \subsection{Gesture server}
- \subsubsection{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''
- \subsubsection{Trackers}
- % TODO
- % event binding/triggering
- % extendability
- \section{Reference implementation}
- % TODO
- % draw.py
- % VTK interactor
- \section{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
- \section{Suggestions for future work}
- % TODO: Network protocol (ZeroMQ)
- \section{References}
- % TODO: BibTex
- \cite{TUIOspecification}
- \bibliography{report}{}
- \bibliographystyle{plain}
- \appendix
- \section{Schema of mechanism structure}
- \label{app:schema}
- % TODO: "dia"
- \section{Supported events in reference implementation}
- \label{app:supported-events}
- % TODO
- \end{document}
|