checkpoint

diff --git a/Ausarbeitung/experiment1.tex b/Ausarbeitung/experiment1.tex
index b467077..00e011a 100644 (file)
--- a/Ausarbeitung/experiment1.tex
+++ b/Ausarbeitung/experiment1.tex
@@ -54,7 +54,7 @@ pointer\index{laser pointer} attached to the Roomba pointed to the current
 orientation on the paper, as shown in Fig.~\ref{fig:laserpointer}. The accuracy
 for these tests was 1~degree.
 
 orientation on the paper, as shown in Fig.~\ref{fig:laserpointer}. The accuracy
 for these tests was 1~degree.
 

-After the initial setup, the application \cmd{roomba\_tests} (see
+After the initial setup, the application \prog{roomba\_tests} (see

 section~\ref{sec:impl:measuring}) was started on the netbook for half-automatic
 testing. It used a predefined array of nominal distances, angles and velocities
 and for each pair of distance (for straight drive tests) or angle (for turn
 section~\ref{sec:impl:measuring}) was started on the netbook for half-automatic
 testing. It used a predefined array of nominal distances, angles and velocities
 and for each pair of distance (for straight drive tests) or angle (for turn

diff --git a/Ausarbeitung/experiment2.tex b/Ausarbeitung/experiment2.tex
index ba75ff5..27d12a3 100644 (file)
--- a/Ausarbeitung/experiment2.tex
+++ b/Ausarbeitung/experiment2.tex
@@ -22,7 +22,7 @@ target distance or angle.
 
 \section{Setup}
 The hardware setup was exactly the same as in Experiment 1. However, in this
 
 \section{Setup}
 The hardware setup was exactly the same as in Experiment 1. However, in this

-experiment the application \cmd{mean\_correction\_test} was used to measure
+experiment the application \prog{mean\_correction\_test} was used to measure

 data. It did exactly the same as the application from Experiment 1, except that
 it adapted the target distance resp. target angle according to the algorithm
 described above.
 data. It did exactly the same as the application from Experiment 1, except that
 it adapted the target distance resp. target angle according to the algorithm
 described above.

diff --git a/Ausarbeitung/experiment3.tex b/Ausarbeitung/experiment3.tex
index b357daf..409d562 100644 (file)
--- a/Ausarbeitung/experiment3.tex
+++ b/Ausarbeitung/experiment3.tex
@@ -9,7 +9,7 @@ stop. no mean correction.
 approach: correct slippage on the floor
 
 setup same as in experiment 1 and 2, application on netbook was
 approach: correct slippage on the floor
 
 setup same as in experiment 1 and 2, application on netbook was

-"`soft\_start\_test"'.
+\prog{soft\_start\_test}.

 
 expectations \& were they fulfilled?
 
 
 expectations \& were they fulfilled?
 

diff --git a/Ausarbeitung/main.tex b/Ausarbeitung/main.tex
index 5f3600b..21dfd16 100644 (file)
--- a/Ausarbeitung/main.tex
+++ b/Ausarbeitung/main.tex
@@ -3,7 +3,7 @@
 \usepackage[T1]{fontenc}
 \usepackage{ae}
 \usepackage[ngerman,english]{babel}
 \usepackage[T1]{fontenc}
 \usepackage{ae}
 \usepackage[ngerman,english]{babel}

-\usepackage{hyperref,color,url,acronym,graphicx,makeidx,amsfonts}
+\usepackage{hyperref,color,url,acronym,graphicx,makeidx,amsfonts,amsmath}

 
 % FIXME hyperref setup
 
 
 % FIXME hyperref setup
 


@@ -11,8 +11,10 @@
 
 \newcommand{\todo}[1]{\textcolor{red}{\index{Todo}\LARGE TODO:~#1}}
 \newcommand{\definition}[1]{\textit{#1}\index{#1}} % FIXME: add to glossary?
 
 \newcommand{\todo}[1]{\textcolor{red}{\index{Todo}\LARGE TODO:~#1}}
 \newcommand{\definition}[1]{\textit{#1}\index{#1}} % FIXME: add to glossary?

-\newcommand{\cmd}[1]{\texttt{#1}\index{#1}} % FIXME: add to glossary?
+\newcommand{\cmd}[1]{\texttt{#1}\index{#1 (command)}} % FIXME: add to glossary?
+\newcommand{\prog}[1]{\texttt{#1}\index{#1 (program)}} % FIXME: add to glossary?

 \newcommand{\magicnumber}[1]{\texttt{#1}}
 \newcommand{\magicnumber}[1]{\texttt{#1}}

+\newcommand{\opcode}[1]{\ac{opcode} \magicnumber{#1}}

 
 % ignore output, but evaluate command with side-effects
 \newsavebox{\trashbox}
 
 % ignore output, but evaluate command with side-effects
 \newsavebox{\trashbox}


@@ -75,6 +77,7 @@ Braunschweig, den \today
 \begin{acronym}
  \acro{GNU}{GNU's Not Unix}
  \acro{GPS}{Global Positioning System}
 \begin{acronym}
  \acro{GNU}{GNU's Not Unix}
  \acro{GPS}{Global Positioning System}

+ \acro{LED}{Light-Emitting Diode}

  \acro{opcode}{operation code}
  \acro{ROI}{Roomba Open Interface}
  \acro{SVN}{Subversion}
  \acro{opcode}{operation code}
  \acro{ROI}{Roomba Open Interface}
  \acro{SVN}{Subversion}

diff --git a/Ausarbeitung/preliminaries.tex b/Ausarbeitung/preliminaries.tex
index a6124b4..4a684ad 100644 (file)
--- a/Ausarbeitung/preliminaries.tex
+++ b/Ausarbeitung/preliminaries.tex
@@ -18,6 +18,10 @@ these techniques are rather expensive to deploy, cannot (yet) be used in real
 time, or are even impreciser than relative approaches\cite{umbmark}, so dead
 reckoning can still be useful for the time being.
 
 time, or are even impreciser than relative approaches\cite{umbmark}, so dead
 reckoning can still be useful for the time being.
 

+In the following, the iRobot Roomba serves as an example of an autonomous,
+mobile agent, which can be used to implement dead reckoning for lack of either
+built-in absolute positioning and other relative approaches.
+

 \section{iRobot Roomba 500}
 Originally, the \definition{Roomba} is an autonomous vacuum cleaning robot,
 manufactured by the US-based company \definition{iRobot}. The 500 series
 \section{iRobot Roomba 500}
 Originally, the \definition{Roomba} is an autonomous vacuum cleaning robot,
 manufactured by the US-based company \definition{iRobot}. The 500 series


@@ -123,14 +127,46 @@ icants behaviour. However, the user is able to read the internal sensors. The
 
 In particular, every command is assigned an \ac{opcode} of one byte length,
 followed by a fixed amount of bytes as parameters which depend on the opcode.
 
 In particular, every command is assigned an \ac{opcode} of one byte length,
 followed by a fixed amount of bytes as parameters which depend on the opcode.

+For example, to start the communication with the Roomba, the \cmd{Start}
+command has to be sent, which has the \opcode{0x80} and takes no parameters. The
+\cmd{Safe} command to put the Roomba into safe mode has \opcode{0x83}, and like
+the \cmd{Full} command with \opcode{0x84}, it takes no parameters.
+
+For example, to start the communication with the Roomba and set it into Safe
+mode, one would send the following bytes over the serial interface:
+\begin{verbatim}
+0x80,             // Start command
+0x83              // Safe command
+\end{verbatim}
+The, additional commands can be sent over the \ac{ROI}, like actuator commands
+for controlling the Roomba's driving behaviour.
+
+\paragraph{Actuator commands}
+The \ac{ROI} specifies various actuator commands to control the Roomba's wheels,
+brushes and \ac{LED} displays, and let the Roomba play tunes. However, the
+central command needed for the experiments in thie thesis is the \cmd{Drive}
+command, \opcode{0x89}, which takes 4 additional bytes as parameter: the first
+two bytes specify the velocity that the Roomba's centerpoint should travel with
+while driving, and the third and fourth bytes specify the radius of the arc the
+Roomba's centerpoint should describe. The Roomba then calculates the required
+right and left wheel velocities internally without further interference of the
+user.
+
+The velocity is interpreted in mm/s, the value can range from -500~mm/s to
+500~mm/s, with negative values implying backwards movement. The radius is
+interpreted in mm, ranging from -2000~mm to 2000~mm. Negative values make the
+Roomba turn toward the right, whereas positive values make it turn toward the
+left. There are also four special values for the radius: \magicnumber{1} makes
+the Roomba turn on the spot in counter-clockwise direction, \magicnumber{-1}
+makes the Roomba turn on the spot in clockwise direction, and
+\magicnumber{0x7fff} and \magicnumber{0x8000} make him drive straight.
+

 For example, to drive straight with a velocity of 1000~mm, one would send the
 following bytes over the serial interface:
 \begin{verbatim}
 For example, to drive straight with a velocity of 1000~mm, one would send the
 following bytes over the serial interface:
 \begin{verbatim}

-0x80,             // start byte
-0x83,             // safe mode
-0x89,             // drive
-0x03, 0xe8        // drive: parameter velocity: 0x03e8 == 1000
-0x80, 0x00        // drive: parameter radius: special value "straight"
+0x89,             // Drive command
+0x03, 0xe8        // parameter velocity: 0x03e8 == 1000
+0x80, 0x00        // parameter radius: special value "straight"

 \end{verbatim}
 
 A little disadvantage of the \ac{ROI} \cmd{Drive} command is that the robot is
 \end{verbatim}
 
 A little disadvantage of the \ac{ROI} \cmd{Drive} command is that the robot is


@@ -138,17 +174,76 @@ modeled as a state machine. In the previous example, the Roomba would keep on
 driving until it runs out of energy, or a safety condition occurs which causes
 the Roomba to revert into Passive mode, or a new \cmd{Drive} command with the
 velocity parameter set to zero is sent. Thus, if the user wants to drive a
 driving until it runs out of energy, or a safety condition occurs which causes
 the Roomba to revert into Passive mode, or a new \cmd{Drive} command with the
 velocity parameter set to zero is sent. Thus, if the user wants to drive a

-specific distance, he has to calculate the time interval the robot needs to
-travel that distance, measure the time interval, and stop the robot after that
-time interval has passed.
+specific distance, he has to calculate the time the robot needs to travel that
+distance, measure the time, and stop the robot after that time interval has
+passed. When using incorrect clocks, or when using inaccurate timers, this can
+lead to errors in movement. Because of that, it is appropriate to monitor the
+Roomba's movement, for example with its internal sensors.
+
+\paragraph{Input commands}
+The Roomba~500 series features a total of 49 different sensor values. Among the
+sensors mentioned above, there are also some internal values concerning battery
+charge, capacity, and temperature, motor currents, and even some more (or less)
+useful variables like the characters read from the infrared remote control, the
+current \ac{ROI} mode or the currently playing song. Nevertheless, there is
+also the possibility to query the travelled distance, the turned angle and the
+internal encoder counts ("`ticks"') for the left and right wheel. Each sensor
+value is 1 or 2 bytes long and is assigned a specific \definition{packet ID}.
+Some packet IDs also describe groups of multiple sensor values sent together.
+
+Sensor values can be retrieved either by explicit polling or by enabling a
+stream of values that is sent every 15~ms. Explicit polling works through the
+\cmd{Sensors} command (\opcode{0x8e}), which takes the packet ID of a single
+sensor as parameter, or through the \cmd{Query List} (\opcode{0x95}) command,
+which takes multiple packet IDs headed by the total number of requested packets
+as parameter. Both of these functions send back the requested values directly.
+
+By using the \cmd{Stream} command (\opcode{0x94}), it is possible to receive
+the requested sensor values every 15~ms. This is very convenient for real-time
+behaviour, when the sensor values have to be evaluated very often. As the
+\cmd{Query List} command, the \cmd{Stream} command takes the total number of
+packet IDs followed by the requested packet IDs as parameter. It sends back the
+sensor values in packets using the following format:\\
+\verb|0x13|, $n, p_1, v(p_1), p_2, v(p_2), \ldots, p_n, v(p_n), c$\\
+where:
+\begin{description}
+  \item[$n$] is the number of bytes sent back, excluding $n$ and $c$,
+  \item[$p_i$] is a requested packet ID, $i = 1, \ldots, n$
+  \item[$v(p_i)$] is the value of the packet with the packet ID $p_i$
+  \item[$c$] is a checksum, with
+    $\sum_{i=1}^n\left(p_1 + v(p_1)\right) + c + n \equiv 0 \mod 256$
+\end{description}
+
+Example: The following byte sequence requests data from the left cliff
+signal (packet~ID \magicnumber{0x1d}) and virtual wall sensor (packet~ID
+\magicnumber{0x0d}):
+\begin{verbatim}
+0x94,         // Stream command
+0x02,         // parameter: 2 packets following
+0x1d, 0x0d    // parameter: request packets 0x1d and 0x0d
+\end{verbatim}
+
+The Roomba then returns the following bytes every 15~ms:
+\begin{verbatim}
+0x13,         // Header byte
+0x05,         // 5 bytes following, except checksum
+0x1d,         // Packet ID 0x1d following
+0x02, 0x19,   // Data for Packet ID 0x1d (2 byte)
+0x0d,         // Packet ID 0x1d following
+0x00,         // Data for Packet ID 0x0d (1 byte)
+0xb6          // checksum: 0x5 + 0x1d + 0x2 + 0x19 + 0xd + 0x0 + 0xb6 = 256
+\end{verbatim}

 
 In our setup, an iRobot Roomba~530 is used as an instance of an autonomous,
 mobile robot to conduct the experiments described afterwards. For that, the
 Roomba's movements are controlled over a netbook mounted on top of the Roomba
 
 In our setup, an iRobot Roomba~530 is used as an instance of an autonomous,
 mobile robot to conduct the experiments described afterwards. For that, the
 Roomba's movements are controlled over a netbook mounted on top of the Roomba

-(cf.~Figure~\ref{fig:roombasetup}), which is running Wiselib code.
+(cf.~Figure~\ref{fig:roombasetup}), which is running Wiselib code. The Wiselib
+code in turn uses the \ac{ROI} and especially the \cmd{Stream} and
+\cmd{Drive} command to control the Roomba.

 
 \section{Wiselib}
 
 \section{Wiselib}

-The \definition{Wiselib}\cite{wiselib} is a C++ algorithm library for sensor
+The \definition{Wiselib}\cite{wiselib} is a C++\index{C++} algorithm library for
+sensor

 networks, containing for example algorithms for routing, localization and time
 synchronization, and is strongly focused on portability and cross-platform
 development. In particular, it allows the user to develop applications that run
 networks, containing for example algorithms for routing, localization and time
 synchronization, and is strongly focused on portability and cross-platform
 development. In particular, it allows the user to develop applications that run


@@ -158,9 +253,42 @@ platforms are diverse sensor node platforms, like iSense, Contiki and TinyOS,
 but there are as well implementations for the diverse x86-compatible Personal
 Computer platforms, and the Shawn sensor network simulator.
 
 but there are as well implementations for the diverse x86-compatible Personal
 Computer platforms, and the Shawn sensor network simulator.
 

+\subsection{Architecture}
+\paragraph{Concepts and Models}
+Wiselib makes strong uses of \definition{concepts} and \definition{models} as
+central design objects. Concepts serve as an informal description of interfaces,
+only existent in documentation, defining expected parameters and types. Models
+however implement these interfaces in C++ code while fulfilling their
+specification. The Wiselib algorithms can in turn rely on the concepts as a
+generic specification, and take models as template parameters to use their
+functionality, so a function call will be immediately resolved to a specific
+model at compile time without the need for an additional function call as it is
+the case with virtual inheritance.
+
+This makes cross-platform development easily possible. For example, to implement
+a routing algorithm, one can rely on the concept of a Radio to send and receive
+data packets, without needing to implement code specific to the used radio
+hardware. The users of that routing algorithm can now choose which radio model
+they want to use, according to their needs and the underlying hardware, provided
+that their radio model also implements the same Radio concept that the routing
+algorithm uses.
+
+\begin{figure}
+  \centering
+  \includegraphics[width=.8\textwidth]{images/Wiselib-Arch.pdf}
+  \caption{Wiselib architecture\label{fig:wiselib-arch}}
+\end{figure}
+Besides algorithms, the Wiselib also consists of two other main parts: the
+internal interface and the external interface (see Figure
+\ref{fig:wiselib-arch}).
+
+\paragraph{}
+
+\subsection{Roomba}

 Moreover, the Wiselib includes code to control the iRobot
 Moreover, the Wiselib includes code to control the iRobot

-Roomba\index{Roomba~500} over a
+Roomba\index{Roomba} over a

 serial interface, and getting access to its internal sensor data, using the
 iRobot Roomba Open Interface mentioned earlier.
 
 \todo{cite Wisebed book chapter on Roomba code}
 serial interface, and getting access to its internal sensor data, using the
 iRobot Roomba Open Interface mentioned earlier.
 
 \todo{cite Wisebed book chapter on Roomba code}

+\todo{which roomba sensors were used?}
\ No newline at end of file