Commit 467f6b1f authored by Taddeüs Kroes's avatar Taddeüs Kroes

Final changes, report is handed-in.

parent a6abbafa
...@@ -311,8 +311,8 @@ ...@@ -311,8 +311,8 @@
\architecture{ \architecture{
\tikzstyle{area} = [block, fill=gray!15]; \tikzstyle{area} = [block, fill=gray!15];
\tikzstyle{tracker} = [block, draw=gray!50, text width=7em]; \tikzstyle{tracker} = [block, draw=gray!50, text width=7em];
\tikzstyle{left} = [xshift=-5em]; \tikzstyle{leftchild} = [xshift=-5em];
\tikzstyle{right} = [xshift=5em]; \tikzstyle{rightchild} = [xshift=5em];
\node[block, below of=driver] (eventdriver) {Event driver} \node[block, below of=driver] (eventdriver) {Event driver}
edge[linefrom] node[right, near end] {device-specific messages} (driver); edge[linefrom] node[right, near end] {device-specific messages} (driver);
...@@ -320,7 +320,7 @@ ...@@ -320,7 +320,7 @@
\node[area, below of=eventdriver] (rootarea) {Screen area} \node[area, below of=eventdriver] (rootarea) {Screen area}
edge[linefrom] (eventdriver); edge[linefrom] (eventdriver);
\node[area, below of=rootarea, left] (appwindow) {Application window area} \node[area, below of=rootarea, leftchild] (appwindow) {Application window area}
edge[lineto, <->] (rootarea); edge[lineto, <->] (rootarea);
\node[tracker, left of=appwindow, xshift=-4em, yshift=3em] {Transformation tracker} \node[tracker, left of=appwindow, xshift=-4em, yshift=3em] {Transformation tracker}
edge[linefrom, bend right=10] (appwindow) edge[linefrom, bend right=10] (appwindow)
...@@ -329,13 +329,13 @@ ...@@ -329,13 +329,13 @@
edge[lineto, dotted, bend right=10] (appwindow) edge[lineto, dotted, bend right=10] (appwindow)
edge[linefrom, bend left=10] (appwindow); edge[linefrom, bend left=10] (appwindow);
\node[area, below of=rootarea, right] (overlay) {Overlay area} \node[area, below of=rootarea, rightchild] (overlay) {Overlay area}
edge[lineto, <->] (rootarea); edge[lineto, <->] (rootarea);
\node[tracker, right of=overlay, xshift=4em] (tracker) {Hand tracker} \node[tracker, right of=overlay, xshift=4em] (tracker) {Hand tracker}
edge[lineto, dotted, bend left=10] (overlay) edge[lineto, dotted, bend left=10] (overlay)
edge[linefrom, bend right=10] (overlay); edge[linefrom, bend right=10] (overlay);
\node[area, below of=appwindow, left] (rectangle) {Rectangle area} \node[area, below of=appwindow, leftchild] (rectangle) {Rectangle area}
edge[lineto, <->] (appwindow); edge[lineto, <->] (appwindow);
\node[tracker, left of=rectangle, xshift=-4em, yshift=2em] (recttracker) {Transformation tracker} \node[tracker, left of=rectangle, xshift=-4em, yshift=2em] (recttracker) {Transformation tracker}
edge[lineto, dotted, bend left=10] (rectangle) edge[lineto, dotted, bend left=10] (rectangle)
...@@ -344,7 +344,7 @@ ...@@ -344,7 +344,7 @@
edge[lineto, dotted, bend right=10] (rectangle) edge[lineto, dotted, bend right=10] (rectangle)
edge[linefrom, bend left=10] (rectangle); edge[linefrom, bend left=10] (rectangle);
\node[area, below of=appwindow, right] (triangle) {Triangle area} \node[area, below of=appwindow, rightchild] (triangle) {Triangle area}
edge[lineto, <->] (appwindow); edge[lineto, <->] (appwindow);
\node[tracker, right of=triangle, xshift=4em, yshift=2em] {Transformation tracker} \node[tracker, right of=triangle, xshift=4em, yshift=2em] {Transformation tracker}
edge[lineto, dotted, bend right=10] (triangle) edge[lineto, dotted, bend right=10] (triangle)
......
...@@ -519,6 +519,12 @@ events. ...@@ -519,6 +519,12 @@ events.
The following component implementations are included in the implementation: The following component implementations are included in the implementation:
\textbf{Event drivers}
\begin{itemize}
\item TUIO driver, using only the support for simple touch points with an
$(x, y)$ position.
\end{itemize}
\textbf{Event areas} \textbf{Event areas}
\begin{itemize} \begin{itemize}
\item Circular area \item Circular area
...@@ -534,11 +540,8 @@ The following component implementations are included in the implementation: ...@@ -534,11 +540,8 @@ The following component implementations are included in the implementation:
\item Transformation tracker, supports $rotate,~pinch,~drag,~flick$ gestures. \item Transformation tracker, supports $rotate,~pinch,~drag,~flick$ gestures.
\end{itemize} \end{itemize}
\textbf{Event drivers} The implementation of the TUIO event driver is described in section
\begin{itemize} \ref{sec:tuio}.
\item TUIO driver, using only the support for simple touch points with an
$(x, y)$ position.
\end{itemize}
The reference implementation also contains some geometric functions that are The reference implementation also contains some geometric functions that are
used by several event area implementations. The event area implementations are used by several event area implementations. The event area implementations are
...@@ -548,9 +551,58 @@ All gesture trackers have been implemented using an imperative programming ...@@ -548,9 +551,58 @@ All gesture trackers have been implemented using an imperative programming
style. Section \ref{sec:tracker-registration} shows how gesture trackers can be style. Section \ref{sec:tracker-registration} shows how gesture trackers can be
added to the architecture. Sections \ref{sec:basictracker} to added to the architecture. Sections \ref{sec:basictracker} to
\ref{sec:transformationtracker} describe the gesture tracker implementations in \ref{sec:transformationtracker} describe the gesture tracker implementations in
detail. The implementation of the TUIO event driver is described in section detail.
\ref{sec:tuio}.
\section{The TUIO event driver}
\label{sec:tuio}
The TUIO protocol \cite{TUIO} defines a way to geometrically describe tangible
objects, such as fingers or objects on a multi-touch table. 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 \cite[OSC]{OSC} format.
An OSC server/client implementation is available for Python: pyOSC
\cite{pyOSC}.
A Python implementation of the TUIO protocol also exists: pyTUIO \cite{pyTUIO}.
However, a bug causes the execution of an example script to yield an error in
Python's built-in \texttt{socket} library. Therefore, the TUIO event driver
receives TUIO messages at a lower level, using 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 touch surface. A SET message provides geometric information of
a session, such as position, velocity and acceleration. Each session represents
an object touching the touch surface. 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 touch surface.
ALIVE messages can be used to determine when an object touches and releases the
screen. E.g. 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 messages
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 and
acceleration are also included. ALIVE and SET messages are combined to create
\emph{point\_down}, \emph{point\_move} and \emph{point\_up} events by the TUIO
event driver.
TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the left
top corner of the touch surface and $(1.0, 1.0)$ the right bottom corner. The
TUIO event driver scales these to pixel coordinates so that event area
implementations can use pixel coordinates to determine whether an event is
located within them. This transformation is also mentioned by the online
TUIO 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}
\newpage
\section{Gesture tracker registration} \section{Gesture tracker registration}
\label{sec:tracker-registration} \label{sec:tracker-registration}
...@@ -657,55 +709,6 @@ The angle used for the \emph{rotate} gesture is only divided by the number of ...@@ -657,55 +709,6 @@ The angle used for the \emph{rotate} gesture is only divided by the number of
touch points to obtain an average rotation of all touch points: touch points to obtain an average rotation of all touch points:
$$rotate.angle = \frac{\alpha}{N}$$ $$rotate.angle = \frac{\alpha}{N}$$
\section{The TUIO event driver}
\label{sec:tuio}
The TUIO protocol \cite{TUIO} defines a way to geometrically describe tangible
objects, such as fingers or objects on a multi-touch table. 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 \cite[OSC]{OSC} format.
An OSC server/client implementation is available for Python: pyOSC
\cite{pyOSC}.
A Python implementation of the TUIO protocol also exists: pyTUIO \cite{pyTUIO}.
However, a bug causes the execution of an example script to yield an error in
Python's built-in \texttt{socket} library. Therefore, the TUIO event driver
receives TUIO messages at a lower level, using 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 touch surface. A SET message provides geometric information of
a session, such as position, velocity and acceleration. Each session represents
an object touching the touch surface. 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 touch surface.
ALIVE messages can be used to determine when an object touches and releases the
screen. E.g. 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 messages
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 and
acceleration are also included. ALIVE and SET messages are combined to create
\emph{point\_down}, \emph{point\_move} and \emph{point\_up} events by the TUIO
event driver.
TUIO coordinates range from $0.0$ to $1.0$, with $(0.0, 0.0)$ being the left
top corner of the touch surface and $(1.0, 1.0)$ the right bottom corner. The
TUIO event driver scales these to pixel coordinates so that event area
implementations can use pixel coordinates to determine whether an event is
located within them. This transformation is also mentioned by the online
TUIO 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}
\chapter{Test applications} \chapter{Test applications}
\label{chapter:test-applications} \label{chapter:test-applications}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment