\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.
+on the front to prevent it from sliding on the floor. The space between the
+cmainenter of the main wheels (the \definition{wheel base}) is 230~mm. 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
\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.
+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}}
+(\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,
\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
+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:
+The Roomba then would return a packet with the following format every
+15~ms:\label{sec:roi-stream-packet}
\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
+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 = 0x100
\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.
+code in turn uses the \ac{ROI} and especially the \cmd{Stream} and \cmd{Drive}
+command to control the Roomba.
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
+This concept represents a simple robot that can turn on the spot and walk
+straight, without automatic stopping.
\begin{description}
\item Types:
\begin{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.
+This concept represents an Odometer which tracks motions over time.
+Whenever the object turns or moves, internal counters will adjust their
+guessing of the object's traveled distance and current orientation.
\begin{description}
\item Types:
\begin{description}
\end{description}
\end{description}
-\paragraph{Implementation}
+\paragraph{ControlledMotion class}\index{ControlledMotion (class)}
+On top of the TurnWalkMotion and Odometer concepts builds the
+\definition{ControlledMotion} model. It takes implementations of each of these
+concepts as template parameters and extends the simple turn-and-walk paradigm by
+a temporal dimension, which let the robot stop after a specific time interval.
+In particular, it provides the following methods:
+\begin{description}
+ \item[\code{int move\_distance(distance\_t, velocity\_t)}] move the robot
+ straight by a given distance with a given velocity
+ \item[\code{int turn\_about(angle\_t, angular\_velocity\_t)}] turn the robot
+ about a given angle with a given angular distance
+ \item[\code{int turn\_to(angle\_t, angular\_velocity\_t)}] turn the robot
+ to a given orientation with a given angular distance
+\end{description}
+
+The class first registers a callback function at the given Odometer instance,
+and then uses its distance and angle values to control the robot over the
+TurnWalkMotion instance. Everytime the state of the robot changes (i.~e. new
+data from its sensors are received), it compares the new actual values with the
+target values given by the user through the functions above, and if the actual
+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.
+
+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.
+
+Also there has been research to use the distance and angle values that the
+Roomba itself provides (sensor packet~IDs \magicnumber{0x13} and
+\magicnumber{0x14}). However, according to the \ac{ROI} Specification these
+values are integer values, and the value is reset to zero every time it is read.
+By using the \cmd{Stream} command on the \ac{ROI} and therefore reading these
+values every 15~ms, the Roomba cannot move fast enough to increment these values
+to \magicnumber{1}, so everytime \magicnumber{0} is read. It is obvious that
+these sensor values are not suited for such rapid evaluations, and can only be
+used for larger distances and angles. Nevertheless, since the Wiselib Roomba
+control needs to keep track of the Roomba's current position and orientation as
+fast as possible to maintain a certain accuracy in movement, the distance and
+angle values as provided by the Roomba itself cannot be used. On the other hand,
+working with the Roomba's wheel encoder counts (sensor packet~IDs
+\magicnumber{0x2b} and \magicnumber{0x2c}) has proven itself quite acceptable.
+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.
+
\todo{cite Wisebed book chapter on Roomba code}
\todo{which roomba sensors were used?}
\ No newline at end of file
projects / bachelor-thesis / written-stuff.git / commitdiff