From: Roland Hieber Date: Wed, 27 Jul 2011 09:53:54 +0000 (+0200) Subject: checkpoint X-Git-Url: https://git.rohieb.name/bachelor-thesis/written-stuff.git/commitdiff_plain/01f65c23d6e26f56832c9c562f39765105b7794c checkpoint --- diff --git a/Ausarbeitung/experiment1.tex b/Ausarbeitung/experiment1.tex index 00e011a..05f7345 100644 --- a/Ausarbeitung/experiment1.tex +++ b/Ausarbeitung/experiment1.tex @@ -16,10 +16,10 @@ The test equipment consisted of a small x86 \index{netbook} which was mounted on an iRobot Roomba~500\index{Roomba} robot. The netbook controlled the Roomba over a -\acs{USB}-to-serial converter plugged into the Open Interface \index{iRobot -Roomba Open Interface} port on the +\acs{USB}-to-serial converter plugged into the Open Interface \index{\acs{ROI}} +port on the Roomba, and hosted as the environment for executing the Wiselib \index{Wiselib} -code (see Fig.~\ref{fig:roombasetup}). +code (see Figure~\ref{fig:roombasetup}). In the first experiment, the original movement behaviour of the Roomba was measured to establish a pool of data for correction approaches to work on. diff --git a/Ausarbeitung/main.tex b/Ausarbeitung/main.tex index 21dfd16..f9223f2 100644 --- a/Ausarbeitung/main.tex +++ b/Ausarbeitung/main.tex @@ -5,14 +5,17 @@ \usepackage[ngerman,english]{babel} \usepackage{hyperref,color,url,acronym,graphicx,makeidx,amsfonts,amsmath} +\usepackage{todonotes} + % FIXME hyperref setup \makeindex -\newcommand{\todo}[1]{\textcolor{red}{\index{Todo}\LARGE TODO:~#1}} +%\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 (command)}} % FIXME: add to glossary? \newcommand{\prog}[1]{\texttt{#1}\index{#1 (program)}} % FIXME: add to glossary? +\newcommand{\code}[1]{\texttt{#1}} \newcommand{\magicnumber}[1]{\texttt{#1}} \newcommand{\opcode}[1]{\ac{opcode} \magicnumber{#1}} @@ -78,8 +81,13 @@ Braunschweig, den \today \acro{GNU}{GNU's Not Unix} \acro{GPS}{Global Positioning System} \acro{LED}{Light-Emitting Diode} + \acro{NiMH}{Nickel-Metal Hydride} \acro{opcode}{operation code} + \acro{OS}{operating system} + \acro{pSTL}{pico Standard Template Library} + \acro{RAM}{Random Access Memory} \acro{ROI}{Roomba Open Interface} + \acro{STL}{Standard Template Library} \acro{SVN}{Subversion} \acro{USB}{Universal Serial Bus} \end{acronym} diff --git a/Ausarbeitung/preliminaries.tex b/Ausarbeitung/preliminaries.tex index 4a684ad..9b2868a 100644 --- a/Ausarbeitung/preliminaries.tex +++ b/Ausarbeitung/preliminaries.tex @@ -22,273 +22,5 @@ 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 -currently represents the third generation of iRobot's cleaning robots, and the -first generation of robots controllable over an external interface. - -\subsection{Hardware design} -\todo{diagram?} -\paragraph{Wheels} -The Roomba lives in a cylindrical case with diameter of about 34~cm and height -of about 7~cm. It has two main wheels which are positioned slightly behind the -centerline, so the Roomba leans forward due to gravity, and a small caster on -the front to prevent it from sliding on the floor. The main wheels can be -controlled over two independent motors, each one allowing to turn the connected -wheel with a minimum of 10~mm/s and a maximum of 500~mm/s in each direction. -One of the main wheel motors consumes about 300~mA in their slowest rotation -speed, and about 1000~mA when driving with normal speed. Each wheel is also -equipped with a drop sensor that tells if the respective wheel has dropped into -a hole or similar, and does not reach the ground anymore. These sensors are -realized with a spring pushing the wheel towards the ground, with the spring -force adjusted to the Roomba's weight, and a micro switch which triggers if the -wheel drops below a specified level. Furthermore, both wheels feature rotating, -toothed discs, which in conjunction with an LED and a photo-electric resistor -act as an optical interrupter. This system can be used to measure the wheel's -current speed by counting the optical interruptions the wheel causes while -moving. - -\paragraph{Brushes} -In addition to the wheel motors, the Roomba has a motor which operates the -vacuum brush, and a small motor on the front connected to a side brush, to allow -cleaning of room corners. - -\paragraph{Bumper shield} -Since the main movement direction in normal operation is forward, the front of -the Roomba consists of a crecent-shaped bumper shield which contains several -sensors. This bumper\index{Roomba!bumper} is spring-loaded and on the one -hand absorbs shock to reduce damage, on the other hand, it allows the Roomba to -detect obstacles in front of it, both via infrared sensors as well as by -mechanical means. There are two sensors for mechanical bump detection, located -30° to the left and to the right of the bumper's center, each implemented as -photo-electrical interruptors. Additionally, six infrared sensors are unevenly -distributed over the bumper, facing away from it in a star-like manner. Each one -of them allows the Roomba to recognize objects in a maxmimum distance of 10~cm. -Finally, the bumper shield contains four infrared sensors facing downwards, -acting as cliff sensors \index{Roomba!cliff sensor} to recognize steps or -similar chasms which could be dangerous for the Roomba to drive towards. - -The back part of the Roomba contains the main vacuum brush\index{Roomba!vacuum -brush}, and the reservoir for holding dirt. Both of them can be removed, though -the removal of the main brush reduces the Roomba's weight and slightly -unbalances the Roomba so the springs used for the wheel drop sensors are not in -balance anymore and push the Roomba upwards, so it tilts more to the front when -accelerating forwards. There is also a sensor on the underside -\index{Roomba!dirt sensor} for detecting particularly dirty regions of the -floor, which is implemented as a capacitive touch sensor. - -\paragraph{Battery} -The battery\index{Roomba!battery} is placed in the front part behind the bumper, -it is a rechargeable NiMH battery and holds a capacity of 3300~mAh which lasts -for about 90 to 120 minutes under normal operation. The Roomba can also find its -home base and charge itself when it has finished cleaning or runs out of energy -by using a special infrared sensor mounted on top of the Roomba. This sensor can -see in all directions and is able to detect the home base by looking for a -special infrared signal the home base\index{Roomba!home base} emits. The same -principle is used for so-called "`virtual walls"'\index{virtual wall} which can -be placed by the user in regions the Roomba should not move into. - -\subsection{Behaviour} -\paragraph{Intended Behaviour} -The Roomba normally follows its own, non-customizable algorithm to detect dirt -and clean rooms. It is kind of a random walk\index{random walk}, controlled by -the internal logic, which tries to keep the Roomba away from dangers like -stairs and walls (by evaluating the cliff and bump sensors), and direct it to -the more dusty regions of the room (by using the dirt sensor). The random walk -concept allows a more or less complete coverage of the room, given the time for -cleaning is large enough, while at the same only needing very little information -about the environment. Of course, that concept is not very efficient when it -comes to cleaning rooms, but cleaning time is not neccessarily the constraining -factor, and the robot still saves the human some time. - -\paragraph{Roomba Open Interface} -However, robots of the Roomba 500 series are also easily controllable over a -serial port, which provides a two-way communication at 5~V TTL levels over a -Mini-DIN connector, with a speed of either 19,200 or 115,200 Baud. Over this -serial port, the Roomba speaks a specified protocol, called the -\ignoreoutput{\ac{ROI}}\definition{\acl{ROI}} (\acs{ROI})~\cite{irobot-oi}, -which allows the user to interact with the robot's internal logic, reading its -sensor values, and control its movements and cleaning behaviour. - -After starting the communication with the Roomba by sending the \cmd{Start} -command, the robot is in a state called \definition{Passive mode}. In this mode, -the user cannot control the robot by himself, but the internal logic defines -icants behaviour. However, the user is able to read the internal sensors. The -\ac{ROI} then allows the user to set the Roomba into two different modes: -\begin{itemize} - \item In \definition{Safe mode}, the Roomba monitors the wheel drop, cliff - and internal charger sensors, and reverts into Passive mode if safety - conditions occur, so the Roomba is not harmed. - \item In \definition{Full mode}, the user has full control over the Roomba, - and has to take care not to harm the Roomba by evaluating the wheel drop, - cliff and internal charger sensors by himself. -\end{itemize} - -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} -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 -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 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. 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++\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 -on different hardware platforms without the need to change the code, and it -strongly uses C++ templates to achieve that feature. Amongst the supported -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} 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 +\input{roomba} +\input{wiselib} diff --git a/Ausarbeitung/roomba.tex b/Ausarbeitung/roomba.tex new file mode 100644 index 0000000..be12c0e --- /dev/null +++ b/Ausarbeitung/roomba.tex @@ -0,0 +1,219 @@ +\section{iRobot Roomba} +Originally, the \definition{Roomba} is an autonomous vacuum cleaning robot, +manufactured by the US-based company \definition{iRobot}. The 500 series +currently represents the third generation of iRobot's cleaning robots, and the +first generation of robots controllable over an external interface. + +\subsection{Hardware design} +The Roomba lives in a cylindrical case with diameter of about 34~cm and height +of about 7~cm, so it can crawl easily under furniture for cleaning. +\todo{diagram?} +\paragraph{Wheels} +The Roomba has two rubberized main wheels which are positioned slightly behind +the centerline, so the Roomba leans forward due to gravity, and a small caster +on the front to prevent it from sliding on the floor. The main wheels can be +controlled over two independent motors, each one allowing to turn the connected +wheel with a minimum of 10~mm/s and a maximum of 500~mm/s in each direction. One +of the main wheel motors consumes about 300~mA in their slowest rotation speed, +and about 1000~mA when driving with normal speed. Each wheel is also equipped +with a drop sensor that tells if the respective wheel has dropped into a hole or +similar, and does not reach the ground anymore. These sensors are realized with +a spring pushing the wheel towards the ground, with the spring force adjusted to +the Roomba's weight, and a micro switch which triggers if the wheel drops below +a specified level. Furthermore, both wheels feature rotating, toothed discs, +which in conjunction with an LED and a photo-electric resistor act as an optical +interrupter. This system can be used to measure the wheel's current speed by +counting the optical interruptions the wheel causes while moving. + +\paragraph{Brushes} +In addition to the wheel motors, the Roomba has a motor which operates the +vacuum brush, and a small motor on the front connected to a side brush, to allow +cleaning of room corners. + +\paragraph{Bumper shield} +Since the main movement direction in normal operation is forward, the front of +the Roomba consists of a crecent-shaped bumper shield which contains several +sensors. This bumper\index{Roomba!bumper} is spring-loaded and on the one +hand absorbs shock to reduce damage, on the other hand, it allows the Roomba to +detect obstacles in front of it, both via infrared sensors as well as by +mechanical means. There are two sensors for mechanical bump detection, located +30° to the left and to the right of the bumper's center, each implemented as +photo-electrical interruptors. Additionally, six infrared sensors are unevenly +distributed over the bumper, facing away from it in a star-like manner. Each one +of them allows the Roomba to recognize objects in a maxmimum distance of 10~cm. +Finally, the bumper shield contains four infrared sensors facing downwards, +acting as cliff sensors \index{Roomba!cliff sensor} to recognize steps or +similar chasms which could be dangerous for the Roomba to drive towards. + +The back part of the Roomba contains the main vacuum brush\index{Roomba!vacuum +brush}, and the reservoir for holding dirt. Both of them can be removed, though +the removal of the main brush reduces the Roomba's weight and slightly +unbalances the Roomba so the springs used for the wheel drop sensors are not in +balance anymore and push the Roomba upwards, so it tilts more to the front when +accelerating forwards. There is also a sensor on the underside +\index{Roomba!dirt sensor} for detecting particularly dirty regions of the +floor, which is implemented as a capacitive touch sensor. + +\paragraph{Battery} +The battery\index{Roomba!battery} is placed in the front part behind the bumper, +it is a rechargeable \ac{NiMH} battery and holds a capacity of 3300~mAh which +lasts for about 90 to 120 minutes under normal operation. The Roomba can also +find its home base and charge itself when it has finished cleaning or runs out +of energy by using a special infrared sensor mounted on top of the Roomba. This +sensor can see in all directions and is able to detect the home base by looking +for a special infrared signal the home base\index{Roomba!home base} emits. The +same principle is used for so-called ``virtual walls''\index{virtual wall} which +can be placed by the user in regions the Roomba should not move into. + +\subsection{Behaviour} +\paragraph{Original Behaviour} +The Roomba normally follows its own, non-customizable algorithm to detect dirt +and clean rooms. It is kind of a random walk\index{random walk}, controlled by +the internal logic, which tries to keep the Roomba away from dangers like +stairs and walls (by evaluating the cliff and bump sensors), and direct it to +the more dusty regions of the room (by using the dirt sensor). The random walk +concept allows a more or less complete coverage of the room, given the time for +cleaning is large enough, while at the same only needing very little information +about the environment. Of course, that concept is not very efficient when it +comes to cleaning rooms, but cleaning time is not neccessarily the constraining +factor, and the robot still saves the human some time. + +\paragraph{Roomba Open Interface} +However, robots of the Roomba 500 series are also easily controllable over a +serial port, which provides a two-way communication at 5~V TTL levels over a +Mini-DIN connector, with a speed of either 19,200 or 115,200 Baud. Over this +serial port, the Roomba speaks a specified protocol, called the +\ignoreoutput{\ac{ROI}}\definition{\acl{ROI}} (\acs{ROI})~\cite{irobot-oi}, +which allows the user to interact with the robot's internal logic, reading its +sensor values, and control its movements and cleaning behaviour. + +After starting the communication with the Roomba by sending the \cmd{Start} +command, the robot is in a state called \definition{Passive mode}. In this mode, +the user cannot control the robot by himself, but the internal logic defines +icants behaviour. However, the user is able to read the internal sensors. The +\ac{ROI} then allows the user to set the Roomba into two different modes: +\begin{itemize} + \item In \definition{Safe mode}, the Roomba monitors the wheel drop, cliff + and internal charger sensors, and reverts into Passive mode if safety + conditions occur, so the Roomba is not harmed. + \item In \definition{Full mode}, the user has full control over the Roomba, + and has to take care not to harm the Roomba by evaluating the wheel drop, + cliff and internal charger sensors by himself. +\end{itemize} + +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} +Then, 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 this 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 it 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} +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 +modeled without a time awareness. 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 the robot needs to travel that +distance, measure the time, and stop the robot after that time interval has +passed. When using inaccurate timers or the system controlling the Roomba is +overloaded, 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. Anyway, 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. The Wiselib +code in turn uses the \ac{ROI} and especially the \cmd{Stream} and +\cmd{Drive} command to control the Roomba. diff --git a/Ausarbeitung/wiselib.tex b/Ausarbeitung/wiselib.tex new file mode 100644 index 0000000..1126ef6 --- /dev/null +++ b/Ausarbeitung/wiselib.tex @@ -0,0 +1,131 @@ +\section{Wiselib} +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 +on different hardware platforms without the need to change the code, and it +strongly uses C++ templates to achieve that feature. Amongst the supported +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. Furthermore, this also allows usage on +platforms which do not have support for C++, as the bytecode generated by the +compiler does not include C++ specific extensions (no virtual function tables, +and templates are resolved at compile time) and can be linked against any +Standard C Library. + +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, and basic concepts and models, the Wiselib also consists of +two other main parts: the internal interface and the external interface (see +Figure \ref{fig:wiselib-arch}). + +\paragraph{External Interface} +The \definition{External Interface} provides access to the underlying \ac{OS}, +like iSense, Contiki, Shawn\ldots and defines concepts like a Radio or a Timer. +Thus, the concepts are as generic as possible to match all supported operating +systems and provide a light-weight abstraction to the underlying \ac{OS}. These +concepts sometimes extend the generic concepts, for example there is a TxRadio +which has the ability to set the transmission power on the radio. The models +(for example an iSenseRadioModel or a ShawnTimerModel) implement these concepts +on the specific operating system, and can be passed around as template +parameters. + +\paragraph{Internal Interface} +The \definition{Internal Interface} defines concepts and models for data +structures that can be used in algorithms. This allows to specialize for +restricted platforms; for instance a wireless sensor node without dynamic memory +management can use a static implementation of lists and other containers, +whereas a full-grown desktop can use the dynamic implementation provided by the +C++ \ac{STL}. For this purpose, the Wiselib also contains the +\ignoreoutput{\ac{pSTL}}\definition{\acl{pSTL}} (\acs{pSTL}) which implements a +subset of the \ac{STL} without the use of dynamic memory allocation. + +\paragraph{Stackability} +Another central design principle used in the Wiselib is +\definition{stackability}, which describes the possibility to stack +implementations of the same concept, thereby building a layered structure. For +example, one could stack a cryptography algorithm on top of a radio model, which +both implement the Radio concept. In this case, the cryptography layer doesn't +have to know anything at all about the underlying implementation, as long as it +can use the Radio concept of the underlying layer. And it can even provide the +same interface to a possibly higher layer in order to provide transparent packet +de- and encryption over the radio. + +\subsection{Roomba Control} +Even more interesting is the fact that the Wiselib includes code to control an +iRobot Roomba\index{Roomba} over a serial interface, and getting access to its +internal sensor data, using the \acl{ROI}\index{\acl{ROI}} mentioned earlier. +For this purpose, it defines two concepts for Robot Motion: + +\paragraph{TurnWalkMotion concept}\index{TurnWalkMotion (concept)} +Concept of a simple robot that can turn and walk straight, without time +awareness +\begin{description} + \item Types: + \begin{description} + \item[\code{velocity\_t}] Type for velocity measurement + \item[\code{angular\_velocity\_t}] Type for angular velocity measurement + \end{description} + \item \todo{clearpage?} Methods: + \begin{description} + \item[\code{int turn(angular\_velocity\_t)}] turn the robot with a + constant angular velocity + \item[\code{int move (velocity\_t)}] move the robot straight with a + constant velocity + \item[\code{int stop()}] stop the robot + \item[\code{int wait\_for\_stop()}] hold the execution until the robot has + stopped + \end{description} +\end{description} + +\paragraph{Odometer concept}\index{Odometer (concept)} +Concept of a class tracking motions over time. Whenever the object turns, or +moves, internal counters will adjust their guessing of the objects traveled +distance and current orientation. +\begin{description} + \item Types: + \begin{description} + \item[\code{angle\_t}] Type for angle measurement + \item[\code{distance\_t}] Type for distance measurement + \end{description} + \item Methods: + \begin{description} + \item[\code{angle\_t angle()}] return the current angle + \item[\code{int reset\_angle()}] reset the angle of the object + \item[\code{distance\_t distance()}] return the current distance + \item[\code{int reset\_distance()}] reset the distance of the object + \item[\code{int register\_state\_callback (T *obj)}] register a callback + that gets called when the state changes + \item[\code{int unregister\_state\_callback (int)}] unregister a + previously registered callback + \item[\code{int state()}] return the current state + \end{description} +\end{description} + +\paragraph{Implementation} + +\todo{cite Wisebed book chapter on Roomba code} +\todo{which roomba sensors were used?} \ No newline at end of file