-\chapter{Experiment 1: Original Movement Behaviour}
-\section{Setup}
+\chapter{Experiment 1: Original Movement Behavior}
+\label{sec:exp1}
+
+The concepts described in the previous chapter are now used to set up a test
+series with the purpose to measure the error in the Roomba's movement and
+to improve its accuracy.
+In the first experiment, the Roomba's original movement behavior was
+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{Roomba Open Interface}.
+
+\section{Setup}
+\label{sec:exp1:setup}
\begin{figure}[htbp]
\centering
\includegraphics[width=0.45\textwidth]{./images/IMAGE_00079.jpg}
\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
-\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
+The test equipment consisted of a small x86 netbook\index{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 \ac{ROI}\index{Roomba
+Open Interface} port on the Roomba, and hosted as the environment for
+executing the Wiselib \index{Wiselib} code.
+
+In this experiment, the Roomba started and stopped with the full velocity the
+movement was executed with; so there was (ideally speaking) an infinite
+acceleration and deceleration at the start and the end of the movement. As
+mentioned before, due to limitations in the \ac{ROI}\index{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, keeps track of the turned angle
+and covered 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.
+type}, a laminated floor and a carpet floor, to see if the movement behavior
+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
+The actual traveled 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.
-
-After the initial setup, the application \prog{roomba\_tests} (see
+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\_test} (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
implementation-specific values.
For the straight drive tests, the arrays with predefined values were:\\
-\begin{tabular}[h!]{ll}
- Distances: & 20, 50, 100, 200, 500, 1000, 2000, and 4000~mm \\
- Velocities: & 20, 50, 70, 100, 150, 200, 300, and 400~mm/s \\
+\begin{tabular}{@{}ll@{}}
+Distances: & 20, 50, 100, 200, 500, 1000, 2000 and 4000~mm \\
+Velocities: & 20, 50, 70, 100, 150, 200, 300 and 400~mm/s
\end{tabular}
-For the turn tests, the arrays with predefined values were:\\
-\begin{tabular}[h!]{ll}
- Turn angles: & 5, 15, 30, 45, 90, 120, 180, 360, 530, and 720~degree \\
- Velocities: & 20, 50, 70, 100, 150, 200, 300, and 400~mm/s \\
+For the turn tests, the arrays with predefined values were: \\
+\begin{tabular}{@{}ll@{}}
+Turn angles: & \phantom{0}5, 15, 30, 45, 90, 120, 180, 360, 530 and 720~degree\\
+Velocities: & 20, 50, 70, 100, 150, 200, 300 and 400~mm/s
\end{tabular}
-According to the implementation of the Wiselib Roomba control,
-the velocities were given in mm/sec and referred to the distance the wheels
-travelled when the Roomba turned on the spot, which was a circle of 230~mm in
-diameter.
+According to the implementation of the Wiselib Roomba control, the velocities
+were given in mm/s and referred to the distance the wheels traveled when the
+Roomba turned on the spot, which was a circle of 230~mm in diameter.
\section{Results}
\label{exp1:results}
The following graphs show the difference from the measured value to the input
value for driving or turning with different velocities. Positive values mean
-that the Roomba had turned too much or travelled more than the target value,
-negative values mean that the Roomba had turned or travelled too less. The
+that the Roomba had turned too much or traveled more than the target value,
+negative values mean that the Roomba had turned or traveled less. The
plots show multiple test runs; given are the minimum, the maximum and the
arithmetic mean\index{arithmetic mean} of all results for a data point.
\todo{clearpage, cleardoublepage?}
-%\clearpage
\begin{figure}[p!]
\centering
\includegraphics[width=\textwidth]{images/iz250flur_drive_data.pdf}
- \caption{Original behaviour on laminated floor, straight drive tests
+ \caption{Original behavior on laminated floor, straight drive movements
\label{fig:orig:lam:drive}}
\end{figure}
\begin{figure}[p!]
\centering
\includegraphics[width=\textwidth]{images/iz250flur_turn_data.pdf}
- \caption{Original behaviour on laminated floor, turn tests
+ \caption{Original behavior on laminated floor, turn movements
\label{fig:orig:lam:turn}}
\end{figure}
\begin{figure}[p!]
\centering
\includegraphics[width=\textwidth]{images/seminarraum_drive_data.pdf}
- \caption{Original behaviour on carpet floor, straight drive tests
+ \caption{Original behavior on carpet floor, straight drive movements
\label{fig:orig:carpet:drive}}
\end{figure}
\begin{figure}[p!]
\centering
\includegraphics[width=\textwidth]{images/seminarraum_turn_data.pdf}
- \caption{Original behaviour on carpet floor, straight drive tests
+ \caption{Original behavior on carpet floor, turn movements
\label{fig:orig:carpet:turn}}
\end{figure}
-Figure~\ref{fig:orig:lam:drive} shows that the error becomes greater
-with increasing input distance when driving straight on the
-laminated floor, however, in Fig.~\ref{fig:orig:carpet:drive} we see the
-opposite effect on the carpet floor, the error decreases with greater input
-distance. This could happen due to imprecise measurement of distances in either
-the Roomba's sensors or the Wiselib implementation that controls the Roomba, or
-both, adding up over the time the movement continues. Also slippage of the
-wheels on the laminated floor could be possible, as well as slowdown through
-the carpet floor, explaining why the error increases on the laminated floor, but
-decreases into negative values on the carpet floor when the distance grows.
+Figure~\ref{fig:orig:lam:drive} shows that the error becomes greater with
+increasing input distance when driving straight on the laminated floor, however,
+in Figure~\ref{fig:orig:carpet:drive} we see the opposite effect on the carpet
+floor, the error decreases with greater input distance. This could happen due to
+imprecise measurement of distances in either the Roomba's sensors or the Wiselib
+implementation that controls the Roomba, or both, adding up over the time the
+movement continues. Also slippage of the wheels on the laminated floor could be
+possible, as well as slowdown through the carpet floor, explaining why the error
+increases on the laminated floor, but decreases into negative values on the
+carpet floor when the distance grows.
On the other hand, rising the velocity always seems to cause the
-error to increase.
+error to increase. This illustrates the effect of accumulating errors which
+represents the crucial drawback of dead reckoning\index{dead reckoning}.
The same effects also apply for turn tests. Additionally, there could be errors
-resulting from false assumptions about the Roomba's wheelbase\index{wheelbase}
-diameter, resulting in false calculations of the circle the Roomba's wheels
+resulting from false assumptions about the Roomba's wheel base\index{wheel
+base}, resulting in bogus calculations of the circle the Roomba's wheels
describe while turning, and therefore leading to false results.
-\todo{statistical values, stddev?}
+In the following, two approaches to correct errors and improve the accuracy of
+the movement are presented.
projects / bachelor-thesis / written-stuff.git / blobdiff