Ausarbeitung/roomba.tex

   1 \section{iRobot Roomba}
   2 Originally, the \definition{Roomba} is an autonomous vacuum cleaning robot,
   3 manufactured by the US-based company \definition{iRobot}. The 500 series
   4 currently represents the third generation of iRobot's cleaning robots, and the
   5 first generation of robots controllable over an external interface.
   6
   7 \subsection{Hardware design}
   8 The Roomba lives in a cylindrical case with diameter of about 34~cm and height
   9 of about 7~cm, so it can crawl easily under furniture for cleaning.
  10 \todo{diagram?}
  11 \paragraph{Wheels}
  12 The Roomba has two rubberized main wheels which are positioned slightly behind
  13 the centerline, so the Roomba leans forward due to gravity, and a small caster
  14 on the front to prevent it from sliding on the floor. The main wheels can be
  15 controlled over two independent motors, each one allowing to turn the connected
  16 wheel with a minimum of 10~mm/s and a maximum of 500~mm/s in each direction. One
  17 of the main wheel motors consumes about 300~mA in their slowest rotation speed,
  18 and about 1000~mA when driving with normal speed. Each wheel is also equipped
  19 with a drop sensor that tells if the respective wheel has dropped into a hole or
  20 similar, and does not reach the ground anymore. These sensors are realized with
  21 a spring pushing the wheel towards the ground, with the spring force adjusted to
  22 the Roomba's weight, and a micro switch which triggers if the wheel drops below
  23 a specified level. Furthermore, both wheels feature rotating, toothed discs,
  24 which in conjunction with an LED and a photo-electric resistor act as an optical
  25 interrupter. This system can be used to measure the wheel's current speed by
  26 counting the optical interruptions the wheel causes while moving.
  27
  28 \paragraph{Brushes}
  29 In addition to the wheel motors, the Roomba has a motor which operates the
  30 vacuum brush, and a small motor on the front connected to a side brush, to allow
  31 cleaning of room corners.
  32
  33 \paragraph{Bumper shield}
  34 Since the main movement direction in normal operation is forward, the front of
  35 the Roomba consists of a crecent-shaped bumper shield which contains several
  36 sensors. This bumper\index{Roomba!bumper} is spring-loaded and on the one
  37 hand absorbs shock to reduce damage, on the other hand, it allows the Roomba to
  38 detect obstacles in front of it, both via infrared sensors as well as by
  39 mechanical means. There are two sensors for mechanical bump detection, located
  40 30° to the left and to the right of the bumper's center, each implemented as
  41 photo-electrical interruptors. Additionally, six infrared sensors are unevenly
  42 distributed over the bumper, facing away from it in a star-like manner. Each one
  43 of them allows the Roomba to recognize objects in a maxmimum distance of 10~cm.
  44 Finally, the bumper shield contains four infrared sensors facing downwards,
  45 acting as cliff sensors \index{Roomba!cliff sensor} to recognize steps or
  46 similar chasms which could be dangerous for the Roomba to drive towards.
  47
  48 The back part of the Roomba contains the main vacuum brush\index{Roomba!vacuum
  49 brush}, and the reservoir for holding dirt. Both of them can be removed, though
  50 the removal of the main brush reduces the Roomba's weight and slightly
  51 unbalances the Roomba so the springs used for the wheel drop sensors are not in
  52 balance anymore and push the Roomba upwards, so it tilts more to the front when
  53 accelerating forwards. There is also a sensor on the underside
  54 \index{Roomba!dirt sensor} for detecting particularly dirty regions of the
  55 floor, which is implemented as a capacitive touch sensor.
  56
  57 \paragraph{Battery}
  58 The battery\index{Roomba!battery} is placed in the front part behind the bumper,
  59 it is a rechargeable \ac{NiMH} battery and holds a capacity of 3300~mAh which
  60 lasts for about 90 to 120 minutes under normal operation. The Roomba can also
  61 find its home base and charge itself when it has finished cleaning or runs out
  62 of energy by using a special infrared sensor mounted on top of the Roomba. This
  63 sensor can see in all directions and is able to detect the home base by looking
  64 for a special infrared signal the home base\index{Roomba!home base} emits. The
  65 same principle is used for so-called ``virtual walls''\index{virtual wall} which
  66 can be placed by the user in regions the Roomba should not move into.
  67
  68 \subsection{Behaviour}
  69 \paragraph{Original Behaviour}
  70 The Roomba normally follows its own, non-customizable algorithm to detect dirt
  71 and clean rooms. It is kind of a random walk\index{random walk}, controlled by
  72 the internal logic, which tries to keep the Roomba away from dangers like
  73 stairs and walls (by evaluating the cliff and bump sensors), and direct it to
  74 the more dusty regions of the room (by using the dirt sensor). The random walk
  75 concept allows a more or less complete coverage of the room, given the time for
  76 cleaning is large enough, while at the same only needing very little information
  77 about the environment. Of course, that concept is not very efficient when it
  78 comes to cleaning rooms, but cleaning time is not neccessarily the constraining
  79 factor, and the robot still saves the human some time.
  80
  81 \paragraph{Roomba Open Interface}
  82 However, robots of the Roomba 500 series are also easily controllable over a
  83 serial port, which provides a two-way communication at 5~V TTL levels over a
  84 Mini-DIN connector, with a speed of either 19,200 or 115,200 Baud. Over this
  85 serial port, the Roomba speaks a specified protocol, called the
  86 \ignoreoutput{\ac{ROI}}\definition{\acl{ROI}} (\acs{ROI})~\cite{irobot-oi},
  87 which allows the user to interact with the robot's internal logic, reading its
  88 sensor values, and control its movements and cleaning behaviour.
  89
  90 After starting the communication with the Roomba by sending the \cmd{Start}
  91 command, the robot is in a state called \definition{Passive mode}. In this mode,
  92 the user cannot control the robot by himself, but the internal logic defines
  93 icants behaviour. However, the user is able to read the internal sensors. The
  94 \ac{ROI} then allows the user to set the Roomba into two different modes:
  95 \begin{itemize}
  96   \item In \definition{Safe mode}, the Roomba monitors the wheel drop, cliff
  97     and internal charger sensors, and reverts into Passive mode if safety
  98     conditions occur, so the Roomba is not harmed.
  99   \item In \definition{Full mode}, the user has full control over the Roomba,
 100     and has to take care not to harm the Roomba by evaluating the wheel drop,
 101     cliff and internal charger sensors by himself.
 102 \end{itemize}
 103
 104 In particular, every command is assigned an \ac{opcode} of one byte length,
 105 followed by a fixed amount of bytes as parameters which depend on the opcode.
 106 For example, to start the communication with the Roomba, the \cmd{Start}
 107 command has to be sent, which has the \opcode{0x80} and takes no parameters. The
 108 \cmd{Safe} command to put the Roomba into safe mode has \opcode{0x83}, and like
 109 the \cmd{Full} command with \opcode{0x84}, it takes no parameters.
 110
 111 For example, to start the communication with the Roomba and set it into Safe
 112 mode, one would send the following bytes over the serial interface:
 113 \begin{verbatim}
 114 0x80,             // Start command
 115 0x83              // Safe command
 116 \end{verbatim}
 117 Then, additional commands can be sent over the \ac{ROI}, like actuator commands
 118 for controlling the Roomba's driving behaviour.
 119
 120 \paragraph{Actuator commands}
 121 The \ac{ROI} specifies various actuator commands to control the Roomba's wheels,
 122 brushes and \ac{LED} displays, and let the Roomba play tunes. However, the
 123 central command needed for the experiments in this thesis is the \cmd{Drive}
 124 command, \opcode{0x89}, which takes 4 additional bytes as parameter: the first
 125 two bytes specify the velocity that the Roomba's centerpoint should travel with
 126 while driving, and the third and fourth bytes specify the radius of the arc the
 127 Roomba's centerpoint should describe. The Roomba then calculates the required
 128 right and left wheel velocities internally without further interference of the
 129 user.
 130
 131 The velocity is interpreted in mm/s, the value can range from -500~mm/s to
 132 500~mm/s, with negative values implying backwards movement. The radius is
 133 interpreted in mm, ranging from -2000~mm to 2000~mm. Negative values make the
 134 Roomba turn toward the right, whereas positive values make it turn toward the
 135 left. There are also four special values for the radius: \magicnumber{1} makes
 136 the Roomba turn on the spot in counter-clockwise direction, \magicnumber{-1}
 137 makes the Roomba turn on the spot in clockwise direction, and
 138 \magicnumber{0x7fff} and \magicnumber{0x8000} make it drive straight.
 139
 140 For example, to drive straight with a velocity of 1000~mm, one would send the
 141 following bytes over the serial interface:
 142 \begin{verbatim}
 143 0x89,             // Drive command
 144 0x03, 0xe8        // parameter velocity: 0x03e8 == 1000
 145 0x80, 0x00        // parameter radius: special value "straight"
 146 \end{verbatim}
 147
 148 A little disadvantage of the \ac{ROI} \cmd{Drive} command is that the robot is
 149 modeled without a time awareness. In the previous example, the Roomba would keep
 150 on driving until it runs out of energy, or a safety condition occurs which
 151 causes the Roomba to revert into Passive mode, or a new \cmd{Drive} command with
 152 the velocity parameter set to zero is sent. Thus, if the user wants to drive a
 153 specific distance, he has to calculate the time the robot needs to travel that
 154 distance, measure the time, and stop the robot after that time interval has
 155 passed. When using inaccurate timers or the system controlling the Roomba is
 156 overloaded, this can lead to errors in movement. Because of that, it is
 157 appropriate to monitor the Roomba's movement, for example with its internal
 158 sensors.
 159
 160 \paragraph{Input commands}
 161 The Roomba~500 series features a total of 49 different sensor values. Among the
 162 sensors mentioned above, there are also some internal values concerning battery
 163 charge, capacity, and temperature, motor currents, and even some more (or less)
 164 useful variables like the characters read from the infrared remote control, the
 165 current \ac{ROI} mode or the currently playing song. Anyway, there is also the
 166 possibility to query the travelled distance, the turned angle and the internal
 167 encoder counts ("`ticks"') for the left and right wheel. Each sensor value is 1
 168 or 2 bytes long and is assigned a specific \definition{packet ID}. Some packet
 169 IDs also describe groups of multiple sensor values sent together.
 170
 171 Sensor values can be retrieved either by explicit polling or by enabling a
 172 stream of values that is sent every 15~ms. Explicit polling works through the
 173 \cmd{Sensors} command (\opcode{0x8e}), which takes the packet ID of a single
 174 sensor as parameter, or through the \cmd{Query List} (\opcode{0x95}) command,
 175 which takes multiple packet IDs headed by the total number of requested packets
 176 as parameter. Both of these functions send back the requested values directly.
 177
 178 By using the \cmd{Stream} command (\opcode{0x94}), it is possible to receive
 179 the requested sensor values every 15~ms. This is very convenient for real-time
 180 behaviour, when the sensor values have to be evaluated very often. As the
 181 \cmd{Query List} command, the \cmd{Stream} command takes the total number of
 182 packet IDs followed by the requested packet IDs as parameter. It sends back the
 183 sensor values in packets using the following format:\\
 184 \verb|0x13|, $n, p_1, v(p_1), p_2, v(p_2), \ldots, p_n, v(p_n), c$\\
 185 where:
 186 \begin{description}
 187   \item[$n$] is the number of bytes sent back, excluding $n$ and $c$,
 188   \item[$p_i$] is a requested packet ID, $i = 1, \ldots, n$
 189   \item[$v(p_i)$] is the value of the packet with the packet ID $p_i$
 190   \item[$c$] is a checksum, with
 191     $\sum_{i=1}^n\left(p_1 + v(p_1)\right) + c + n \equiv 0 \mod 256$
 192 \end{description}
 193
 194 Example: The following byte sequence requests data from the left cliff
 195 signal (packet~ID \magicnumber{0x1d}) and virtual wall sensor (packet~ID
 196 \magicnumber{0x0d}):
 197 \begin{verbatim}
 198 0x94,         // Stream command
 199 0x02,         // parameter: 2 packets following
 200 0x1d, 0x0d    // parameter: request packets 0x1d and 0x0d
 201 \end{verbatim}
 202
 203 The Roomba then returns the following bytes every 15~ms:
 204 \begin{verbatim}
 205 0x13,         // Header byte
 206 0x05,         // 5 bytes following, except checksum
 207 0x1d,         // Packet ID 0x1d following
 208 0x02, 0x19,   // Data for Packet ID 0x1d (2 byte)
 209 0x0d,         // Packet ID 0x1d following
 210 0x00,         // Data for Packet ID 0x0d (1 byte)
 211 0xb6          // checksum: 0x5 + 0x1d + 0x2 + 0x19 + 0xd + 0x0 + 0xb6 = 256
 212 \end{verbatim}
 213
 214 In our setup, an iRobot Roomba~530 is used as an instance of an autonomous,
 215 mobile robot to conduct the experiments described afterwards. For that, the
 216 Roomba's movements are controlled over a netbook mounted on top of the Roomba
 217 (cf.~Figure~\ref{fig:roombasetup}), which is running Wiselib code. The Wiselib
 218 code in turn uses the \ac{ROI} and especially the \cmd{Stream} and
 219 \cmd{Drive} command to control the Roomba.