From 31c576ac200aa443984d141a393893acff4787e5 Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Wed, 27 Jul 2011 09:51:31 +0200 Subject: [PATCH 1/1] checkpoint --- Ausarbeitung/experiment1.tex | 2 +- Ausarbeitung/experiment2.tex | 2 +- Ausarbeitung/experiment3.tex | 2 +- Ausarbeitung/main.tex | 7 +- Ausarbeitung/preliminaries.tex | 150 ++++++++++++++++++++++++++++++--- 5 files changed, 147 insertions(+), 16 deletions(-) diff --git a/Ausarbeitung/experiment1.tex b/Ausarbeitung/experiment1.tex index b467077..00e011a 100644 --- 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. -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 diff --git a/Ausarbeitung/experiment2.tex b/Ausarbeitung/experiment2.tex index ba75ff5..27d12a3 100644 --- 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 -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. diff --git a/Ausarbeitung/experiment3.tex b/Ausarbeitung/experiment3.tex index b357daf..409d562 100644 --- 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 -"`soft\_start\_test"'. +\prog{soft\_start\_test}. expectations \& were they fulfilled? diff --git a/Ausarbeitung/main.tex b/Ausarbeitung/main.tex index 5f3600b..21dfd16 100644 --- a/Ausarbeitung/main.tex +++ b/Ausarbeitung/main.tex @@ -3,7 +3,7 @@ \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 @@ -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{\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{\opcode}[1]{\ac{opcode} \magicnumber{#1}} % 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} + \acro{LED}{Light-Emitting Diode} \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 --- 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. +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 @@ -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. +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} -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 @@ -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 -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 -(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} -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 @@ -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. +\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 -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} +\todo{which roomba sensors were used?} \ No newline at end of file -- 2.20.1