From e29146877ebf1c77b2b31ad1fa804547286b2a21 Mon Sep 17 00:00:00 2001 From: Roland Hieber Date: Thu, 28 Jul 2011 05:02:04 +0200 Subject: [PATCH] checkpoint --- Ausarbeitung/experiment1.tex | 73 ++++++++++++++++++--------------- Ausarbeitung/experiment2.tex | 14 +++---- Ausarbeitung/implementation.tex | 10 +++-- Ausarbeitung/main.tex | 34 ++++++++------- Ausarbeitung/preliminaries.tex | 3 ++ Ausarbeitung/roomba.tex | 49 +++++++++++++++++++--- Ausarbeitung/wiselib.tex | 41 +++++++++--------- 7 files changed, 138 insertions(+), 86 deletions(-) diff --git a/Ausarbeitung/experiment1.tex b/Ausarbeitung/experiment1.tex index 05f7345..fd46738 100644 --- a/Ausarbeitung/experiment1.tex +++ b/Ausarbeitung/experiment1.tex @@ -1,6 +1,14 @@ \chapter{Experiment 1: Original Movement Behaviour} -\section{Setup} +In the first experiment, the Roomba's original movement behaviour is +measured to get an overview of the errors that occur while moving, and to +establish a pool of data for correction approaches to work on later. +There was no error correction involved (apart from any possible error +correction the Roomba itself implements in its underlying logic, and which is +not known to anyone except iRobot). To achieve this, the Wiselib Roomba Control +is used to access the Roomba over the \ac{ROI}\index{\acs{ROI}}. + +\section{Setup} \begin{figure}[htbp] \centering \includegraphics[width=0.45\textwidth]{./images/IMAGE_00079.jpg} @@ -12,47 +20,44 @@ \caption{Measuring turn angles with laser pointer\label{fig:laserpointer}} \end{figure} -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 +The test equipment consisted of a small x86 \index{netbook} netbook which was +mounted on an iRobot Roomba~530\index{Roomba} robot, as seen in +Figure~\ref{fig:roombasetup}. The netbook controlled the Roomba over a \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 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. -There was no error correction involved, and the Roomba started right off with -the full velocity the movement was executed with; so there was no control to -adhere a constant acceleration when starting or stopping the movement. Due to -limitations in the iRobot Roomba Open Interface\index{iRobot Roomba Open -Interface} it is only -possible to explicitly start and stop the Roomba's movements at different times, -so the Wiselib's implementation of the Roomba control code first starts the -Roomba's movement, calculates the time needed until the movement should be -finished, and then stops the Roomba. - -The tests were done in two atomic drive modes: letting the Roomba drive a +port on the Roomba, and hosted as the environment for executing the Wiselib +\index{Wiselib} code. + +In this experiment, the Roomba started right off with the full velocity the +movement was executed with; so there was no control to adhere a constant +acceleration when starting or stopping the movement. As mentioned before, due to +limitations in the \acs{ROI}\index{\acs{ROI}} it is only possible to explicitly +start and stop the Roomba's movements at different times, so the Wiselib's +implementation of the Roomba control code first starts the Roomba's movement, +keeps track of the turned angle and dcovered distance, and then stops +the Roomba if these values exceed the target values. + +The tests were done in two atomic drive modes: letting the Roomba walk a specific straight distance with a specific velocity in its viewing direction and letting it turn on the spot with a specific velocity about a specific angle. Each of the two modes was carried out on two different floor types\index{floor type}, a laminated floor and a carpet floor, to see if the movement behaviour -significantly depended on the floor type. +significantly depended on the floor type. The side brush was removed, since the +Roomba tends to turn slightly towards the left when driving straight on a +carpet floor. Without the side brush, this was not the case. The actual travelled distance of the straight drive tests were determined using a measuring tape with an accuracy of 1~mm. Only the distance in the Roomba's -original viewing direction was considered, as the offset perpendicular to the -viewing direction and a possible shift in orientation were too small to be -measured precisely. - -The actual turn angles of the turn tests were determined using a DIN~A0 sheet -of paper with a printed polar coordinate system in which a circular hole was cut -in the center to let the Roomba's wheels touch the floor. The sheet was fixed -on the floor, and the Roomba was aligned in the center of the paper. A laser -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. +original viewing direction was considered, as it turned out that the offset +perpendicular to the viewing direction and a possible shift in orientation were +too small to be measured precisely. + +The actual turn angles of the turn tests were determined using a +\acs{ISO}/\acs{DIN}~A0 sheet of paper with a printed polar coordinate system in +which a circular hole was cut in the center to let the Roomba's wheels touch the +floor. The sheet was fixed on the floor, and the Roomba was aligned in the +center of the paper. A laser 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 \prog{roomba\_tests} (see section~\ref{sec:impl:measuring}) was started on the netbook for half-automatic diff --git a/Ausarbeitung/experiment2.tex b/Ausarbeitung/experiment2.tex index 27d12a3..ad83cc8 100644 --- a/Ausarbeitung/experiment2.tex +++ b/Ausarbeitung/experiment2.tex @@ -13,19 +13,17 @@ the target distance resp. the target angle was adjusted, while the velocity remained unadjusted. Fitting the function\index{fit function} was done with \acs{GNU} R\index{GNU R} -through a wrapper script which is explained in section~\ref{sec:impl:eval}. In -this experiment, a linear fit of the form $o = a*v+b*i+c$ was used, with $o$ -being the measured value, $v$ the input velocity, $i$ the target distance or -angle, and $a,b,c \in \mathbb{R}$. The fitted values \todo{how? least -square?} for $a, b, c$ were then used in the algorithm to calculate the adapted -target distance or angle. +through the wrapper script \prog{graph.sh} which is explained in +section~\ref{sec:impl:eval}. In this experiment, a 2-dimensional linear fit for +the measured value was determined by the method of least squares, with target +value (angle or distance) and velocity as input parameters. The fit function was +then used in the algorithm to calculate the adapted target distance or angle. \section{Setup} The hardware setup was exactly the same as in Experiment 1. However, in this 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. +it adapted the target value according to the method described above. \section{Results} \begin{figure}[p!] diff --git a/Ausarbeitung/implementation.tex b/Ausarbeitung/implementation.tex index 66c7a3d..64e3a44 100644 --- a/Ausarbeitung/implementation.tex +++ b/Ausarbeitung/implementation.tex @@ -1,9 +1,13 @@ -\chapter{Description of Implementation} +\chapter{Implementation} + +\todo{?} +This chapter describes the implementation that was used for the aforementioned +experiments. It consists of the measuring program itself, as well as several +scripts to help with analysis of the measured data. + \section{Measuring} \label{sec:impl:measuring} -\todo{} - C++ code in wiselib/trunk/pc\_apps/roomba\_tests three single applications with same base: roomba\_test (main.cc), diff --git a/Ausarbeitung/main.tex b/Ausarbeitung/main.tex index f9223f2..d4a87f8 100644 --- a/Ausarbeitung/main.tex +++ b/Ausarbeitung/main.tex @@ -4,7 +4,7 @@ \usepackage{ae} \usepackage[ngerman,english]{babel} \usepackage{hyperref,color,url,acronym,graphicx,makeidx,amsfonts,amsmath} - +\usepackage{sidecap} \usepackage{todonotes} % FIXME hyperref setup @@ -77,19 +77,25 @@ Braunschweig, den \today % \listoftables % \cleardoublepage \chapter*{Table of Acronyms} -\begin{acronym} - \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} +\begin{acronym}[opcode] + \acro{8N1}{8 data bits, no parity, 1 start/stop bit} + \acro{DC}{Direct Current} + \acro{DIN}{Deutsches Institut für Normung (German Institute for + Standardization)} + \acro{GNU}{GNU's Not Unix} + \acro{GPS}{Global Positioning System} + \acro{ISO}{International Standardization Organization} + \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{TTL}{Transistor-Transistor Logic} + \acro{USB}{Universal Serial Bus} \end{acronym} \pagenumbering{arabic} diff --git a/Ausarbeitung/preliminaries.tex b/Ausarbeitung/preliminaries.tex index 9b2868a..2f4754b 100644 --- a/Ausarbeitung/preliminaries.tex +++ b/Ausarbeitung/preliminaries.tex @@ -24,3 +24,6 @@ built-in absolute positioning and other relative approaches. \input{roomba} \input{wiselib} + +Now that the prerequisites have been explained, it is time to assemble them all +together and \todo{and what} \ No newline at end of file diff --git a/Ausarbeitung/roomba.tex b/Ausarbeitung/roomba.tex index 819d034..f7dd0b7 100644 --- a/Ausarbeitung/roomba.tex +++ b/Ausarbeitung/roomba.tex @@ -5,9 +5,28 @@ currently represents the third generation of iRobot's cleaning robots, and the first generation of robots controllable over an external interface. \subsection{Hardware design} +\begin{SCfigure} + \centering + \includegraphics[width=.5\textwidth]{images/Roomba-Diagram.pdf} + \caption[Diagram of the Roomba 500 series]{Diagram of the Roomba 500 series, + view from below\label{fig:roomba-diagram} \\ + 1:~front~caster, 2:~battery, 3:~side~brush, 4:~main~wheels, 5:~main~brush, + 6:~vacuum~bin, 7:~front~bumper, 8:~cliff~sensors} +\end{SCfigure} + 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?} +of about 8~cm, so it can crawl easily under furniture for cleaning. +Figure~\ref{fig:roomba-diagram} shows a diagram of the Roomba seen from below. + +The top side features several buttons which vary between the different models, +most notably the ``Clean'' and ``Spot'' buttons for manual control of the +cleaning routine, and the ``Dock'' button to send the Roomba to its home base. +The cover on the top side can be removed, and covers the connector for +the \ac{ROI} which is discussed in Section~\ref{sec:roi}. + +On the side, a socket for a coaxial \acs{DC} power connector can be found, which +is used for external charging. + \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 @@ -81,11 +100,12 @@ 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} +\label{sec:roi} 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, in mode 8N1 -(8 data bits, no parity, 1 stop bit). Over this serial port, the Roomba speaks a -specified protocol, called the \ignoreoutput{\ac{ROI}}\definition{\acl{ROI}} +serial port, which provides a two-way communication at 5~V~\acs{TTL} levels over +a 7-pin mini-\acs{DIN} connector, with a speed of either 19,200 or 115,200 Baud, +in mode \acused{8N1} \ac{8N1} (\acl{8N1}). Over this serial port, the Roomba +speaks a specified protocol, called the \acused{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. @@ -213,6 +233,23 @@ The Roomba then would return a packet with the following format every 0xb6 // checksum: 0x5 + 0x1d + 0x2 + 0x19 + 0xd + 0x0 + 0xb6 = 0x100 \end{verbatim} +\paragraph{Latency} +On the connection, there is a certain latency between the time the command is +sent to the Roomba and the time the Roomba receives this command and carries out +the motion. At 19,200 baud, mode \ac{8N1}, the transfer of a 5-byte \cmd{Drive} +command needs $(5 \times 9) \div 19200 = 2.3$~ms. The time the Roomba +logic needs to process the command is not mentioned in the \ac{ROI} +Specification, and there was no way to measure it sufficiently. It is however +short enough that a human would describe it as ``instant''. + +The same latency of course also exists in the opposite directions when the +Roomba is sending sensor data to the user. However, the sensor data are sent by +the Roomba every 15~ms (which is the internal speed at which the data is +updated from the sensors) and according to the wheel's maximum velocity of +500~mm/s (which means that a sensor data packet is received every $0.03$~mm when +driving at this speed), this is acceptible for real-time evaluation of the data. + + 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 diff --git a/Ausarbeitung/wiselib.tex b/Ausarbeitung/wiselib.tex index 0c0b4b7..42bc223 100644 --- a/Ausarbeitung/wiselib.tex +++ b/Ausarbeitung/wiselib.tex @@ -60,7 +60,7 @@ 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 +\acused{pSTL}\definition{\acl{pSTL}} (\acs{pSTL}) which implements a subset of the \ac{STL} without the use of dynamic memory allocation. \paragraph{Stackability} @@ -149,26 +149,27 @@ values exceed the target values, the robot is stopped. \paragraph{Underlying Roomba Implementation} The actual communication with the Roomba is done in the \definition{RoombaModel} -class. It implements the aforementioned TurnWalkMotion and Odometer concepts -and therewith allows the interaction with a ControlledMotion instance. In -particular, it manages the serial communication with the Roomba and translates -the function calls \code{turn()}, \code{move()} and \code{stop()} of the -TurnWalkMotion concept to the according parameters for the \ac{ROI} \cmd{Drive} -command, reads a subset of the Roomba's sensors and presents the sensor data to -the user, and, while implementing the Odometer concept, calculates the covered -distance and angle from the Roomba's right and left wheel rotations. +class. It implements the aforementioned TurnWalkMotion \index{TurnWalkMotion +(concept)} and Odometer \index{Odometer (concept)} concepts and therewith allows +the interaction with a ControlledMotion instance. In particular, it manages the +serial communication with the Roomba and translates the function calls +\code{turn()}, \code{move()} and \code{stop()} of the TurnWalkMotion concept to +the according parameters for the \ac{ROI} \cmd{Drive} command, reads a subset of +the Roomba's sensors and presents the sensor data to the user, and, while +implementing the Odometer concept, calculates the covered distance and angle +from the Roomba's right and left wheel rotations. The sensor data is read from the Roomba using the \cmd{Stream} command on the \ac{ROI}, which results in a sensor data packet (see Section \ref{sec:roi-stream-packet}) every 15~ms, and $66.67$ packets per second. At a -speed of 19,200 baud in mode 8N1 (8 data bits, no parity, 1 start/stop bit), the -maximum size of a data packet is $19,200 \div (66.67 \times 9) = 32$ byte, -so at the moment only the sensor packets \emph{encoder counts left/right} -(IDs~\magicnumber{0x2b}, \magicnumber{0x2c}, 2+2 bytes), \emph{battery -voltage/current/charge/capacity} (IDs~\magicnumber{0x16}, \magicnumber{0x17}, -\magicnumber{0x19}, \magicnumber{0x1a}, 2+2+2+2 bytes) are streamed, which add -up to 18 data bytes + 3 header/checksum bytes. There has currently been no -success yet in communicating at the higher speed of 115,200 baud. +speed of 19,200 baud in mode \ac{8N1}, the maximum size of a data packet is +$19,200 \div (66.67 \times 9) = 32$ byte, so at the moment only the sensor +packets \emph{encoder counts left/right} (IDs~\magicnumber{0x2b}, +\magicnumber{0x2c}, 2+2 bytes), \emph{battery voltage/current/charge/capacity} +(IDs~\magicnumber{0x16}, \magicnumber{0x17}, \magicnumber{0x19}, +\magicnumber{0x1a}, 2+2+2+2 bytes) are streamed, which add up to 18 data bytes + +3 header/checksum bytes. There has currently been no success yet in +communicating at the higher speed of 115,200 baud. Also there has been research to use the distance and angle values that the Roomba itself provides (sensor packet~IDs \magicnumber{0x13} and @@ -188,9 +189,7 @@ After a few test runs, the number of encoder counts per~mm for straight walks turned out as $2.27$, and for turning on the spot, $2.27 \times 115 = 261.05$ encoder counts per radian, which is the number of encoder counts per~mm multiplicated with half the Roomba's wheelbase. So when new sensor data is read -each 15~ms, the RoombaModel implementation calculates the covered distance and -the turned angle from these values. - +each 15~ms, the RoombaModel implementation calculates the Odometer +\index{Odometer (concept)} distance and angle from these values. \todo{cite Wisebed book chapter on Roomba code} -\todo{which roomba sensors were used?} \ No newline at end of file -- 2.20.1