assigned the portions

documentation/Yuankai/bdetect.tex

@@ -0,0 +1,40 @@
+\section{Ball Detection}
+\label{p sec ball detection}
+
+The very first task that needed to be accomplished was to detect the ball,
+which is uniformly red-colored and measures about 6 cm in diameter. We decided
+to use a popular algorithm based on color segmentation \cite{ball-detect}. The
+idea behind this algorithm is to find the biggest red area in the image and
+assume that this is the ball. First, the desired color needs to be defined as
+an interval of HSV (Hue-Saturation-Value) \cite{hsv} values. After that, the
+image itself needs to be transformed into HSV colorspace, so that the regions
+of interest can be extracted into a \textit{binary mask}. The contours of the
+regions can then be identified in a mask \cite{contours}, and the areas of the
+regions can be calculated using the routines from the OpenCV library. The
+center and the radius of the region with the largest area are then determined
+and are assumed to be the center and the radius of the ball.
+
+\begin{figure}[ht]
+  \includegraphics[width=\textwidth]{\fig ball-detection}
+  \caption[Ball detection]{Ball detection. On the right is the binary mask}
+  \label{p figure ball-detection}
+\end{figure}
+
+It is sometimes recommended \cite{ball-detect} to eliminate the noise in the
+binary mask by applying a sequence of \textit{erosions} and \textit{dilations},
+but we found, that for the task of finding the \textit{biggest} area the noise
+doesn't present a problem, whereas performing erosions may completely delete
+the image of the ball from the mask, if it is relatively far from the robot and
+the camera resolution is low. For this reason it was decided not to process the
+binary mask with erosions and dilations, which allowed us to detect the ball
+even over long distances.
+
+The advantages of the presented algorithm are its speed and simplicity. The
+major downside is that a careful color calibration is required for the
+algorithm to function properly. If the HSV interval of the targeted color is
+too narrow, the algorithm might miss the ball; if the interval is too
+wide, other big red-shaded objects in the camera image will be detected as
+the ball. A possible approach to alleviate these issues to a certain degree
+will be presented further in the section \ref{p sec field detect}. To
+conclude, we found this algorithm to be robust enough for our purposes, if a
+sensible color calibration was provided.

documentation/Yuankai/tools.tex

@@ -0,0 +1,84 @@
+\chapter{Hardware and Software}
+
+\section{Robot}
+
+The aforementioned Nao \cite{nao} is a small humanoid robot, around 60
+cm tall. Some of its characteristics are:
+
+\begin{itemize}
+
+\item Two HD-cameras on the head
+
+\item An ultrasonic rangefinder on the body
+
+\item An inertial navigation unit (accelerometer and gyroscope)
+
+\item Internet connectivity over Ethernet cable or 802.11g WLAN
+
+\item Single-core Intel Atom CPU and 1 GB of RAM
+
+\item Programmable joints with overall 25 degrees of freedom
+
+\item Speakers
+
+\item 60 to 90 minutes battery life.
+
+\end{itemize}
+
+It can be seen from the specifications list, that the multitude of sensors and
+interfaces make the Nao an attractive development platform, suitable for the task
+of playing soccer. However, a relatively weak CPU and a low amount of RAM require
+the programs running on the robot to be resource-efficient, which had to be
+taken into account during our work on the project.
+
+\section{Software}
+
+In our project we used \textit{NAOqi OS} as an operating system for the robot.
+This is a standard operating system for Nao robots based on Gentoo Linux, and
+it can handle all aspects of robot control, such as reading the sensors, moving
+the robot and establishing the network connection.
+
+As a framework for the implementation of the desired behavior we chose the
+official \textit{NAOqi Python SDK} \cite{naoqi-sdk}. We found this framework
+easy to use, well documented and also covering most basic functionality that
+was necessary for us to start working on the project. A further advantage of
+this SDK is that it uses Python as the programming language, which allows for
+quick prototyping, but also makes maintaining a large codebase fairly easy.
+
+Finally, the third-party libraries that were used in the project are
+\textit{OpenCV} and \textit{NumPy} \cite{opencv, numpy}. OpenCV is a powerful
+and one of the most widely used open-source libraries for computer vision
+tasks, and NumPy is a popular Python library for fast numerical computations.
+Both of these libraries, as well as the NAOqi Python SDK are included in the
+NAOqi OS distribution by default, which means that no extra work was necessary
+to ensure their proper functioning on the robot.
+
+\section{Rejected Software Alternatives}
+
+Here we will briefly discuss what alternative options were available for the
+choice of the base framework, and why we decided not to use those. One
+available option was the official \textit{NAOqi C++ SDK}. Being based on the
+C++ language, this SDK can naturally be expected to have better performance and to be more resource-efficient, than the Python-based version. We still chose the
+Python SDK, because C++ is not particularly suitable for fast prototyping,
+because of the complexity of the language. It is also worth noting, that we
+never really hit the performance constraints, that couldn't have been overcome
+by refactoring our code, but in the future it might be reasonable to migrate
+some portions of it to C++.
+
+Another big alternative is \textit{ROS} \cite{ros} (Robotic Operating System).
+ROS is a collection of software targeted at robot development, and there exists
+a large ecosystem of third-party extensions for ROS, which could assist in
+performing common tasks such as camera and joint calibration, as well as in
+more complex tasks such as object detection. ROS was an attractive option, but
+there was a major downside, that there was no straightforward way to run ROS
+locally on the robot, so the decision was made not to spend time trying to
+figure out how to do that. However, since Python is one of the main languages
+in ROS, it should be possible in the future to incorporate our work into ROS.
+
+Finally, as was already mentioned in the introduction, \textit{B-Human
+  Framework} is a popular choice for beginners, thanks to the quality of the
+algorithms and good documentation. However, B-Human has been in development
+over many years and is therefore a very complex system. The amount of time needed
+to get familiar with the code, and then to incorporate our changes would have
+been too big. For this reason we decided to use the simpler option as a
+starting point.