\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 makes Nao an attractive development platform, suitable for the task
of playing soccer. However, 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 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
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 of the 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 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.