report.tex 8.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249
  1. \documentclass[a4paper]{article}
  2. \usepackage[english]{babel}
  3. \usepackage[utf8]{inputenc}
  4. \usepackage{amsmath,hyperref,graphicx,booktabs,float}
  5. % Link colors
  6. \hypersetup{colorlinks=true,linkcolor=black,urlcolor=blue}
  7. \title{Bachelor thesis\\Universal multi-touch event mechanism}
  8. \author{\begin{tabular}{ll}
  9. Name: & Taddeüs Kroes\\
  10. Student number: & 6054129\\
  11. E-mail address: & \texttt{taddeus.kroes@student.uva.nl}\\
  12. Address: & Wethouder van Wijckstraat 40, 1107 BR Amsterdam\\
  13. Phone number: & 06-23437025\\
  14. Supervisor: & Dr. R.G. Belleman (UvA)\\
  15. \end{tabular}}
  16. \begin{document}
  17. % Title page
  18. \maketitle
  19. \abstract{
  20. % TODO
  21. }
  22. % Set paragraph indentation
  23. \parindent 0pt
  24. \parskip 1.5ex plus 0.5ex minus 0.2ex
  25. % Table of contant on separate page
  26. \pagebreak
  27. \tableofcontents
  28. \pagebreak
  29. \section{Introduction}
  30. % Ruwe probleemstelling
  31. Multi-touch interaction is becoming increasingly common, mostly due to the wide
  32. use of touch screens in phones and tablets. When programming applications using
  33. this method of interaction, the programmer needs an abstraction of the raw data
  34. provided by the touch driver of the device. This abstraction exists in several
  35. multi-touch application frameworks like Nokia's
  36. Qt\footnote{\url{http://qt.nokia.com/}}. However, applications that do not use
  37. these frameworks have no access to their multi-touch events.
  38. % Aanleiding
  39. This problem was observed during an attempt to create a multi-touch
  40. ``interactor'' class for the Visualization Toolkit
  41. (VTK\footnote{\url{http://www.vtk.org/}}). Because VTK provides the application
  42. framework here, it is undesirable to use an entire framework like Qt
  43. simultaneously only for its multi-touch support.
  44. % Ruw doel
  45. The goal of this project is to define a universal multi-touch event triggering
  46. mechanism. To test the definition, a reference implementation is written in
  47. Python.
  48. % Setting
  49. To tests multi-touch interaction properly, a multi-touch device is required.
  50. The University of Amsterdam (UvA) has provided access to a multi-touch table
  51. from PQlabs. The table uses the TUIO
  52. protocol\footnote{\url{http://www.tuio.org/}} to communicate touch events.
  53. % Afbakening
  54. % TODO: moet dit omlaag naar 'Definition of the problem'?
  55. The scope of this thesis includes the design of an multi-touch triggering
  56. mechanism, a reference implementation of this design, and its integration into
  57. a VTK interactor. To be successful, the design should allow for extensions to
  58. be added to any implementation. The reference implementation is a Proof of
  59. Concept that translates TUIO events to some simple touch gestures that are used
  60. by a VTK interactor.
  61. \subsection{Structure of this document}
  62. % TODO
  63. \section{Definition of the problem}
  64. % Hoofdvraag
  65. The goal of this thesis is to create a multi-touch event triggering mechanism
  66. for use in a VTK interactor. The design of the mechanism must be universal.
  67. % Deelvragen
  68. To design such a mechanism properly, the following questions are relevant:
  69. \begin{itemize}
  70. \item What is the input of the mechanism? Different touch drivers have
  71. different API's. To be able to support different drivers (which is
  72. highly desirable), there should probably be a translation from the
  73. driver API to a fixed input format.
  74. \item How can extendability be accomplished? The set of supported events
  75. should not be limited to a single implementation, but an application
  76. should be able to define its own custom events.
  77. \item Can events be shared with multiple processes at the same time? For
  78. example, a network implementation could run as a service instead of
  79. within a single application, triggering events in any application that
  80. needs them.
  81. \item Is performance an issue? For example, an event loop with rotation
  82. detection could swallow up more processing resources than desired.
  83. \end{itemize}
  84. \section{Related work}
  85. % TODO
  86. \section{Methods}
  87. % TODO
  88. \subsection{Preliminary inquiries}
  89. \subsubsection{The TUIO protocol}
  90. The TUIO protocol\footnote{\url{http://tuio.org/?specification}}
  91. defines a way to geometrically describe tangible objects, such as
  92. fingers or fiducials on a multi-touch table. The table used for this
  93. thesis uses the protocol in its driver. Object information is sent to
  94. the TUIO UDP port (3333 by default).
  95. For efficiency reasons, the TUIO protocol is encoded using the Open
  96. Sound Control
  97. (OSC)\footnote{\url{http://opensoundcontrol.org/specification}} format.
  98. An OSC server/client implementation is available for Python:
  99. pyOSC\footnote{\url{https://trac.v2.nl/wiki/pyOSC}}.
  100. A Python implementation of the TUIO protocol also exists:
  101. pyTUIO\footnote{\url{http://code.google.com/p/pytuio/}}. However, the
  102. execution of an example script yields an error regarding Python's
  103. built-in \texttt{socket} library. Therefore, the reference
  104. implementation uses the pyOSC package to receive TUIO messages.
  105. The two most important message types of the protocol are ALIVE and SET
  106. messages. An ALIVE message contains the list of session id's that are
  107. currently ``active'', which in the case of multi-touch a table means
  108. that they are touching the screen. A SET message provides geometric
  109. information of a session id, such as position, velocity and acceleration.
  110. Each session id represents an object. The only type of objects on the
  111. multi-touch table are what the TUIO protocol calls ``2DCur'', which is
  112. a (x, y) position on the screen.
  113. ALIVE messages can be used to determine when an object touches and
  114. releases the screen. For example, if a session id was in the previous
  115. message but not in the current, The object it represents has been
  116. lifted from the screen.
  117. SET provide information about movement. In the case of simple (x, y)
  118. positions, only the movement vector of the position itself can be
  119. calculated. For more complex objects such as fiducials, arguments like
  120. rotational position is also included.
  121. TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the
  122. left top corner of the screen and $(1.0, 1.0)$ the right bottom corner.
  123. To focus events within a window, a translation to window coordinates is
  124. required in the client application, as stated by the
  125. specification:
  126. \begin{citation}
  127. In order to compute the X and Y coordinates for the 2D profiles a
  128. TUIO tracker implementation needs to divide these values by the
  129. actual sensor dimension, while a TUIO client implementation
  130. consequently can scale these values back to the actual screen
  131. dimension.
  132. \end{citation}
  133. \subsection{Experiments}
  134. % testimplementatie met taps, rotatie en pinch. Hieruit bleek:
  135. % - dat er verschillende manieren zijn om bijv. "rotatie" te
  136. % detecteren, (en dat daartussen onderscheid moet kunnen worden
  137. % gemaakt)
  138. % - dat detectie van verschillende soorten gestures moet kunnen
  139. % worden gescheiden, anders wordt het een chaos.
  140. % - Er zijn een aantal keuzes gemaakt bij het ontwerpen van de gestures,
  141. % bijv dat rotatie ALLE vingers gebruikt voor het centroid. Het is
  142. % wellicht in een ander programma nodig om maar 1 hand te gebruiken, en
  143. % dus punten dicht bij elkaar te kiezen (oplossing: windows).
  144. % Tekenprogramma dat huidige points + centroid tekent en waarmee
  145. % transformatie kan worden getest Link naar appendix "supported events"
  146. % Proof of Concept: VTK interactor
  147. % -------
  148. % Results
  149. % -------
  150. \section{Server structure}
  151. % TODO: link naar appendix met schema
  152. \subsection{Input server}
  153. % TODO
  154. % vertaling driver naar point down, move, up
  155. % TUIO in reference implementation
  156. \subsection{Gesture server}
  157. \subsubsection{Windows}
  158. % TODO
  159. % toewijzen even aan deel v/h scherm:
  160. % TUIO coördinaten zijn over het hele scherm en van 0.0 tot 1.0, dus moeten
  161. % worden vertaald naar pixelcoördinaten binnen een ``window''
  162. \subsubsection{Trackers}
  163. % TODO
  164. % event binding/triggering
  165. % extendability
  166. \section{Reference implementation}
  167. % TODO
  168. % draw.py
  169. % VTK interactor
  170. \section{Conclusions}
  171. % TODO
  172. % Windows zijn een manier om globale events toe te wijzen aan vensters
  173. % Trackers zijn een effectieve manier om gebaren te detecteren
  174. % Trackers zijn uitbreidbaar door object-orientatie
  175. \section{Suggestions for future work}
  176. % TODO: Network protocol (ZeroMQ)
  177. \section{References}
  178. % TODO: BibTex
  179. \cite{TUIOspecification}
  180. \bibliography{report}{}
  181. \bibliographystyle{plain}
  182. \appendix
  183. \section{Schema of mechanism structure}
  184. \label{app:schema}
  185. % TODO: "dia"
  186. \section{Supported events in reference implementation}
  187. \label{app:supported-events}
  188. % TODO
  189. \end{document}