%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% (c) Andreas Hofmeier
%       http://www.lgut.uni-bremen.de/an-h/
%       http://an-h.de/
%       http://an-h.de.vu/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%    This document is free software; you can redistribute it and/or
%    modify it under the terms of the GNU General Public License as
%    published by the Free Software Foundation; either version 2 of
%    the License, or (at your option) any later version.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% v1.0b final revision
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass[12pt]{article}

%PDF \usepackage[final]{ps4pdf}

%%%%%%%%% GERMAN
%\usepackage{a4,german}
\usepackage{a4}

\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}

%%%%%%%%% GERMAN
%\usepackage{ngerman}

%%%%%%%%% PDF-Latex:
%PDF \ifpdf
%PDF   \usepackage[pdftex]{graphics}
%PDF   \usepackage{ae}
%PDF   \usepackage{graphicx}
%PDF   \usepackage[
%PDF      pdftex,
%PDF      a4paper,
%PDF      bookmarks,
%PDF      bookmarksopen=true,
%PDF      bookmarksnumbered=true,
%PDF      pdfauthor={Andreas Hofmeier  --  an-h.de},
%PDF      pdftitle={Final Year Project: Communication between Robots and a Computer via the Internet: Final Report},
%PDF %     colorlinks=true,
%PDF %     linkcolor=black,
%PDF %     filecolor=black,
%PDF %     urlcolor=black
%PDF   ]{hyperref}
%PDF \else
%PDF   \usepackage[dvips]{graphics}
%PDF \fi

%NOTPDF
  \usepackage[dvips]{graphics}
%PDF

%\usepackage[dvips]{graphics}
\usepackage{latexsym}
\usepackage{exscale}
\usepackage{amssymb,amsmath}
%\documentclass[11pt]{report}
%\usepackage{isolatin1}
%\usepackage{german}
\usepackage{epsf}
\usepackage[dvips]{rotating}

\usepackage{longtable}
\usepackage{dcolumn}

\usepackage{listings}

%\usepackage{eurosym}
%\EUR{300}

\usepackage{multicol}
%\usepackage[dvips]{rotating}

%ENDHEAD

\parindent=0pt
\parskip=\baselineskip

\newcommand{\hhref}[1]{section \ref{#1} (page \pageref{#1})}
\newcommand{\ahref}[1]{(appendices, section \ref{#1} on page \pageref{#1})}


%\setcounter{tocdepth}{4}
%\setcounter{secnumdepth}{4}

%\pagestyle{empty}
\pagestyle{plain}
\pagenumbering{roman}
%\pagestyle{myheadings}
%\markright{\mbox{\bf A. Hofmeier, Final Year Project: Final Report}}
\begin{document}
\begin{titlepage}
\title{
  \centerline{
%WAS NOT IN REPORT     \epsffile{../LSBULogo.eps}
  }
\vspace{2cm}
%WAS NOT IN REPORT-- Final Year Project --\vspace{1cm}\\
Communication between\\Robots and a Computer via the Internet\vspace{1cm}\\Final Report}
\author{Andreas Bernhard Max Hofmeier}
%\date{12. Mai 2003}
\date{}
\end{titlepage}


%\begin{document}
\maketitle

\begin{center}
\begin{tabular}{rl}

%WAS NOT IN REPORT Supervisor: & Dr. Shuwo Chen\\
Submission Date: & 26.04.2005\\
%WAS NOT IN REPORT \\
%WAS NOT IN REPORT Student: & Andreas Bernhard Max Hofmeier\\
Student ID: & 2406108\\
%WAS NOT IN REPORT Address: & Dante Road Student Residence\\
%WAS NOT IN REPORT  & Room 2G3\\
%WAS NOT IN REPORT  & 2 Dante Place\\
%WAS NOT IN REPORT  & London SE11 4RX \\
%WAS NOT IN REPORT Tele Number: & 0870 036 5618 \\
%WAS NOT IN REPORT eMail: & an-h@an-h.de
%WAS NOT IN REPORT \\
%WAS NOT IN REPORT Course: & Computer Systems and Networks (2388), \\
%WAS NOT IN REPORT  & 3 Year, BEng, FT \\

\end{tabular}
\end{center}

\vspace{4cm}
{\small
This report has been submitted for assessment towards a Bachelor of
Engineering Degree in Computer Systems and Networks (2388) BEng in the
School of Engineering, South Bank University.

This report is written in the author's own words and all sources have
been properly cited.

\hspace{3.26cm}
Author's signature: 
\begin{tabular}{rr}
& \hspace{7cm} \\
\hline
\end{tabular}
}


\newpage
{\bf Acknowledgements}
%\section*{Acknowledgements}
%\addcontentsline{toc}{section}{\numberline {}Acknowledgements}

I would like to thank my supervisor, Dr. Shuwo Chen, who supervised
this project and was always ready to answer my questions.

Thanks are also given to other people from London South Bank
University and the University of Applied Science Bremen, who offered
their assistance to me while doing this project. Dr. Chris Merridan,
the technical assistant and Mr. Jianzhong Shang, who supported me in
dealing with the robot experiment. Dr. Thomas Risse who helps me to
organise of my overseas-term. My German class mates stood on my side
with advice and encouragement. All peoples who provided help in form
of materials such as free software (GNU Linux), free documents
(web-sites), articles, and books.

\newpage


%\begin{abstract}

%\addcontentsline{toc}{section}{\numberline {}Abstract}

%\hspace{-0.685cm}
%\hspace{-0.69cm}
{\bf Abstract}

This report describes the final year project done by Andreas
Hofmeier. The project is aimed to develop the software tool for the
communication between robots and computers on the Internet to realise
the remote control of robots via the Internet.

The feasibility study of controlling robots on the Internet was
re-examed, identifying the certain restrictions affecting the
communication and hence control on the Internet. One conclusion has
been drawn that the time delay is the most important restriction is
caused by the local network but not by the Internet. Several
approaches to the restrictions were studied and a promising method,
the line monitor, was developed.

A software platform in form of a library for GNU Linux was developed
to provide the necessary tools for implementing robot control on the
Internet. The platform is successfully used to control a Cartesian
robot in laboratory test.

The results have proven that design methodology for the project are
correct and the theoretical results will benefit future development.

%\end{abstract}
\newpage

\pagestyle{headings}
%\pagestyle{myheadings}
%\markright{\mbox{\bf A. Hofmeier, Final Year Project: Final Report}}


{\footnotesize
\tableofcontents
}
\newpage


%\pagestyle{headings}
\pagestyle{myheadings}
\markright{\mbox{\it AIM AND OBJECTIVES}}



\section*{Aim and Objectives}
\addcontentsline{toc}{section}{\numberline {}Aim and Objectives}

\subsection*{Aim}

The aim of the project is to develop a software platform on GNU Linux
systems (in the form of a library) for the communication between a
server and robots to realise remote control of robots over the
Internet. The communication between robots is allowed as well.

\subsection*{Objectives}

\begin{enumerate}

\item

\begin{enumerate}

\item Feasibility study of real-time control of robots on the Internet.

%\item Establishment of realistic levels according to the Internet
%overloading

\item A block diagram of the architecture of an example system which can
control a robot remotely

\end{enumerate}

\item

\begin{enumerate}


\item Developing the library

\item Developing the simulator and the user interface (UI)

\item Demonstrating the platform by using a simulation. Showing that
it is possible to control the simulated robot over an Internet
connection.

\end{enumerate}

\item

\begin{enumerate}

\item Developing an interface to the real robot

\item Demonstrating the platform by means of the real robot. Showing
that it is possible to control the real robot over an Internet
connection.

\end{enumerate}
\end{enumerate}



\newpage

%\pagestyle{headings}
\pagestyle{myheadings}
\markright{\mbox{\it DELIVERABLES}}

\section*{Deliverables}
\addcontentsline{toc}{section}{\numberline {}Deliverables}

The objectives have been met and the deliverables include,

\begin{enumerate}

\item The Library (the Software Platform)

\item Documentation of the Library (API; description of the functions;
how to use)

\item User Interface

\item Documentation of the User Interface (User manual)

\item Simulator

\item Documentation of the Simulator (User manual)

\item Interface between Library and real Robot, for Demonstration.

\item Interim Report

\item Presentation

\item Final Report


\end{enumerate}



\newpage
\setcounter{page}{1}
\pagenumbering{arabic}
\pagestyle{headings}
%\pagestyle{myheadings}
%\markright{\mbox{\it DELIVERABLES}}



\section{Introduction}

Robots become more and more important because the technical progress
allows economic and useful applications. Controlling robots over a
short distance with cables or wirelessly is quite popular, but more
often robots need to be controlled at a remote site far away from the
scene. For example a robot as security guard or a pizza-robot is
operating at home while controlled from the office. To meet this
demand a communication network is required.

One of the most flexible and economical solutions is to control robots
on the Internet that works packet-oriented. All data have to be
fragmented before it can be transmitted. The transmission process on
the Internet can be compared with the postal service (Ball et
al. 1999). ``The packet should be there within two days'' is a possible
answer to the question how long the delivery takes. This little word
``should'' is the problem. It should, but there is no guarantee. If many
packets are handed in, it may take a week or more time to deliver
them. The Internet has the similar problem.  Even if a packet does not
need a week to reach a recipient, it is still difficult to predict a
delay time because huge amount of users are at random using the
resources on the Internet. Therefore as a user of the Internet, a
controlled robot may encounter a statistic time delay. (Elhaji et
al. 2000).

Through this project the feasibility of controlling robots remotely
over the Internet was studied. A software platform on GNU Linux which
provides this functionality was developed.

This platform in form of a network library provides the tools to
utilise the Internet as a communication link to control a robot. An
example of using the network library is given by a simple
demonstration on a real robot. The demonstration includes a user
interface, a simulator, and an interface to the robot.

The analysis has shown that under certain circumstances it is possible
to actually control a robot on the Internet. One of the possibilities is
to observe the network connection and initiate appropriate actions
when the line (connection) becomes unusable for the remote
control. This idea was adapted from Andreu et al (2003) and
implemented. In this report it is called the line monitor.

The report is structured in the following way: the first two sections
define the aim, the objectives, and the deliverables of the
project. The next section introduces the technical background. After
this the technical approach will be explained in detail. The results
of the analysis and the tests are given in the next chapter named
``Results and Discussion''. The conclusions and recommendations for
further work are given in Chapter \ref{conrec}. After that the
Bibliography is listed. It is followed by details about the planning
of the project compared with its actual realisation. The last parts of
the report are the appendices which include the software and its
documentation (user's manual and application programmer interface).











%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% start
\section{Technical Background and Context}

\subsection{Modes to Control a Robot}

Han et al (2004) distinguishes between three modes to control a robot
which were adapted. This three points are extreme examples only. A
robot in the ``real world'' will be somewhere between those extreme
points. This depends highly on the application.

\subsubsection{Direct Control}

Within this control mode the hardware is controlled at lowest level
over the network. There is no intelligence or data processing on the
robot's side.

For example: the robot receives a bit stream which represents its
outputs. The robot receives a package of n bits analogous to n
output-bits. These outputs can be simple actors which can only be
switched on or off (one bit) or complex solutions with
digital-to-analogue converters which are controlling a DC-motor (maybe
12 bits).

This mode requires strict time constraints because the controlling is
time based. If the robot should move one meter in a direction the
corresponding motor for this direction has to be switched on for
exactly the time which is necessary to cover this distance. If the
motor is switched on longer the robot will cover a greater distance
and vise versa. The engines has to be switched ``in time'' but this is
almost impossible if the time for transmitting a bit (or a package if
more than one motor has to be controlled) varys from one command to
the next one. If the time-delay would have been constant, it could be
simply subtracted in the calculation.

Another problem occurs if the connection breaks down. When the robot
receives a ``start moving'' command just before the connection fails
it may move until the battery is empty. This can be a hazard if, for
example, the robot hits someone.

\subsubsection{Supervisory Control}

This control mode controls the robot on a much higher level. For this
reason more intelligence is needed on the robot's side.

A target is transmitted to the robot. The robot has to evaluate this
target and calculate the appropriate action to reach it. The target
can be transmitted in relative ($\Delta x$, $\Delta y$) or in in
absolute ($x$, $y$) coordinates (In this case it is assumed that the
robot has two degrees of freedom -- can move in two dimensions.) In
the first case the robot has to calculate which actors have to be
switched on and for how long to cover the given distance in the right
direction. In the second case the robot has to know its current
position to calculate the $\Delta x$ and the $\Delta y$ which can be
used to move to the target.

The calculation of $\Delta x$ and $\Delta y$ may include
considerations like:

\begin{itemize}

\item What is the fastest way?
\item What is the way which needs the fewest resources (energy)?
\item Which way causes no hazards or damages? Are they any hindrances?

\end{itemize}

In this mode the time constraints are not as strict as in the direct
control because the robot will stop moving if the target is reached
and no new targets are receive in time. Normally hazards only occur
if something is moving or is ``in action''.

\subsubsection{Job Scheduling}

Within the Job Scheduling Mode a whole sequence of targets or jobs is
transmitted to the robot at once.



\subsection{Levels of Processing}

To be able to ``teleoperate'' something (for example to control a
robot from far away) at least three levels of data-processing are
necessary. These three levels are the human operator, the User
Interface (UI), and the robot control program. They are illustrated in
figure \ref{fig-intel}.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Levels_of_Inteligenze.eps}
\caption{Different Levels of Processing which are necessary to Control
a Robot Remotely.} \label{fig-intel}
\end{figure}


\begin{itemize}

\item The human operator makes the decisions and gives the system its
purpose. There will be no systems without a human operator at some
level because there is no point in doing something without gaining an
advantage. This human interaction can be within a wide range from
``switching it on to get a cup of hot coffee out of it'' to ``control
a space-explore-robot to explore what is out there''. The human
operator always gives the commands to an User Interface.

\item The user interface has to read the commands from the user and
transmit it through some kind of network to the
robot-control-program. The program which performs the necessary
operations to handle this job runs on computer in front of the
user. This can be a kind of robot-control-server if it is taken as a
central control station.

\item The robot control program receives the commands from the user
interface and applies them to the hardware of the robot. This job is
done by a piece of software which runs on a computer on (or near to)
the robot.

\end{itemize}



\subsection{Adaptability of the Program which Controls the Robot}

In these days the requirement of multi-functionality becomes more
important. The robot should be as flexible as possible to be used in a
wide spectrum of applications.

To use a robot for a new application the program which controls it has
to be changed. As discussed above this program is made up of three
components. (If it is assumed, that there is some kind of ``program''
in our brain.)

In case that the ``technical system'' is very primitive it may be
enough to train the human operator to do other things with it. An
example could be a simple remote control of a crane which switches
actors remotely.

An important improvement of our technology today is that it helps us
to perform our tasks. The time of a human operator is valuable and
should not be wasted in doing things which can be done by a
computer. Many calculations can be processed much faster and more
accurate by a computer than a human.

The consequence of this is that it may not be enough to train the
human operator to do new things with the robot. In this case two
components are left: The GUI\footnote{GUI stands for Graphical User
Interface.} (Server) and the robot control program.

One solution is to keep the robot control program as simple as
possible and transfer all intelligence into the GUI (the Server). In
this case the direct control is in use. As discussed this can be a
problem because of safety considerations. If the network link breaks
down no server or human operator can stop the robot. There must be
some processing on the robot's side. At least an emergency stop
function has to be implemented. This solution makes it possible to
change the behaviour of the technical system only by changing the
server/GUI side. This can be an advantage.

On the other hand it is possible to perform one part of the processing
on the robot's side. This moves the classification of the system
closer to the supervisory control. The GUI/server transmits a job or a
target to the robot and monitors its execution. It might be necessary
to change both, the GUI/server and the robot control program in order
to change the behaviour of the system. Advantages of this solutions
are: distribution of processing work on both sides, probably less
bandwidth requirements, and a possible gain in safety.



\subsection{Feedback}

Another important issue needs to be considered: the feedback. This is
the difference between operating or affecting something and
controlling it. Affecting means to do something without getting a
response. There is no guarantee that everything happens the way as it
was intended to happen. Controlling applies a feedback which closes
this (response-)loop.  For example, it can be seen what the robot
does. In this case it is likely that the bandwidth of the feedback
connection is much bigger than the control connection because of the
video data. Figure \ref{fig-intel-fb} illustrates this
example. Unfortunately these meanings are often confused. In this
report the word ``controlling'' is used for both.


\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Levels_of_Inteligenze_Feedback.eps}
\caption{Different Levels of Processing which are necessary to Control
a Robot Remotely: A Closed-Loop-System with Feedback.}  
\label{fig-intel-fb}
\end{figure}



\subsection{Real Time and Bandwidth Constrains}

The term ``real time'' is used for systems which have to complete a
task in a certain time. This time depends on the application but it
can be said that the (reaction-)time must be short enough to perform
an in-time control of the environment. In this case the transfer of
data over a network has to be finished within a certain time-limit.

Bandwidth describes how much data a network is able to transfer in a
certain time. The time delay will increase if more data is transmit
because the data has to be buffered until the line is free. If
continuously more data is transfered the network can no longer
transfer all the data without loosing some of it.

Both terms are interdependent. This will be explained in the following
section.


\subsubsection{How the Internet Works}

\label{osi}

Before it is possible to explain what the problem causes it is
necessary to provide an overview about ``how it works''. If detailed
information is requested please refer to a textbook, for example,
Forouzan (2001) from which this overview was condensed.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_NetworkLayers.eps}
\caption{Comparison between OSI-Model and the real Internet}
\label{fig-osi}
\end{figure}

Figure \ref{fig-osi} shows an overview of the different levels of
data-processing which have to be passed before a communication is
possible. The diagram illustrates these levels on a Hyper Text
Transfer Protocol (HTTP) request. Those requests are generated if a
web-page is opened. In the case of the example it was\\{\tt
http://www.lgut.uni-bremen.de/an-h/en/papers/lsbu/}. The OSI-model
(left hand side) is a general description of the network layers. These
OSI layers assigned to real layers which are used in the Internet. The
right hand side lists the different types of protocol data units
(PDUs) (packages) which are created by each layer. Each layer adds
management information (a header) which are shown as gray
extension. In this report the general term package is used for
different PDUs.

To understand the idea behind these levels of layers it can be
compared to telling someone a long story who is on the other side
of the world. The narrator (the application) starts writing it and
gives the script its secretary (the transport layer, TCP). She knows
that the postal service accepts letters up to a maximum of 80g. For
this reason the story has to be segmented into pieces which fit on
less than 80 grams of paper. In order to make it easier to recombine
the story on the other side of the world, supporting information like
a segment-number is added to each letter. This letter is given to the
next secretary (the network layer, IP). In this step the letter will be
placed in an envelope. This envelope on which the source and
destination address is written will be handed in to the nearest post
office (the data link layer). Within the post office the letter will
be packed into a bag which is transported to another post office. This
office may resort the bags and send it to the following post
office. This process (which can be compared with the routing and
transferring data over a line [physical layer]) will be continuing
until the letter reaches the mail box of the receiver. Then the
reverse process takes place.

\subsubsection{Changing Behaviour and Delay}

The problems which arise from this process are: the system must work
transparently. That means that the higher levels do not know what the
lower levels are doing. For this reason the behaviour of the lower
levels may vary. An example for this is a replacement of one
secretary.

The same problem occurs during the transport. There is no guarantee
that the letter will always take the same route. It is unknown which
way a letter will take. This depends on the environment and on the
network load or utilisation. If, for example, an earthquake destroys a
road, the mail must take another way. The workload of the system may
change faster than the environment. During the rush-hour it takes
longer to cover a distance than on a ``normal'' daytime. This can be
compared with school hours -- all students using the network. This
both phenomena cause the random time delay.

\subsubsection{Carrier Sense Multiple Access with Collision Detection}

The next problem arises from the way in which the physical layer
transmits data. Ethernet is used in most of the end-user networks of
the Internet. Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) is in use within Ethernet.  This protocol tries to broadcast
when nobody else is sending data. If the network load increases it
becomes harder to find a gap to send the data. Because of physical
limitations (transmission speed) computers do not recognise fast
enough if data is sent and start sending by them selfs. This causes
collisions. Data is destroyed and has to be sent again. Because of
this the delay increases with rising workload. These both are reasons
for the unpredictability of the transport time.  This is not
applicable to modern switching networks. (Fairhurst 2004)


\subsubsection{Level to Use}

To use the high-level Transmission Control Protocol (TCP) or the User
Datagram Protocol (UDP) to control robots is not the most efficient
way. It is possible to bypass the official transport layer by replacing
it with an own protocol that is optimised for real time traffic. Liu et
al (2004), for example, developed the ``trinomial protocol''. This is
a semi-real-time-protocol. It works much better than the TCP or UDP
but it cannot change the lower levels. These levels have to be used if
the Internet should transport the data. They are prescribed by the  
Internet itself as a standard.



\subsubsection{Monitor the Line}
\label{linemonitor-t}

Another possibility, which was adapted from Andreu et al (2003), is to
observe the network-connection and take appropriate actions if the
connection becomes unusable for the purpose of remote
controlling. This strategy assumes that the network is normally usable
for the job. Without any further actions this method is not well
suited for direct control. Instead it is very suitable for an
additional usage.



\subsubsection{Buffer to Compensate Random time Delay}

Andreu et al (2003) explored the possibility of using a buffer or a
stack as a ``Delay Regulator'' to smooth up the random component of
the transport delay. This is done by delaying the data on the receiver
side (buffer) in a way that the overall delay stays constant. For
example, if one command has to be processed in one second, one command
per second has to be ready for processing on the robot's
side. Assuming that the maximal time delay for the transmission is 5
seconds, the sender starts transmitting 5 seconds before the robot
starts executing commands. All data which is received earlier will be
stored in a buffer. If the sender sends one command in one second, the
robot reads one command a second from the buffer, and the maximal
time-delay does no exceed 5 seconds, the commands are constantly
delayed by 5 seconds. This is the way to suppress the random component
of the time delay by extending the delay to a maximal value.

This solution is suited to be used for direct control but has the
disadvantage that the transmission takes longer than necessary. If
everything works well all commands are delayed by the same time. It
makes sense to combine this solution with a line-monitor to take
appropriate actions if the maximal delay was exceeded.


\subsubsection{Use a Simulator}

One idea to fit a robot-control-system into existing bandwidth
constrains is to prevent the large bandwidth-consumption of the
video-data-stream by using a simulator. This simulator simulates the
environment of the robot on the GUI/server side. Figure
\ref{fig-fb-sim} gives an example of this. (Belousov 2004; Han et
al. 2001)

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Levels_of_Inteligenze_Feedback_Simul.eps}
\caption{Different Levels of Processing which are necessary to control
a Robot remotely: A Closed-Loop-System with Feedback through a  
Simulator.}
\label{fig-fb-sim}
\end{figure}

This solution makes a simulation of the reality necessary. However,
the best simulation is still just a simulation and not reality
itself. For this reason reality and simulation may differ. Maybe the
physical attributes of an object are calculated in a wrong way or the
feedback is not accurate enough and an object is pictured in an other
place than it really is. This can be a safety risk which has to be
considered.


\subsection{Safety}

According to the British Standard (1992) Industrial robots --
Recommendations for safety, a single point of failure must not cause
any hazards. For this reason it is very important to stop the robot if
the network link breaks down. The technique of monitoring the line is
well suited to this application.


%\subsection{Context}
%
%This project tries to develop a a software platform
%
%\subsection{The Reason for this Project}
%
%This project was done to explore the 
%
%Why this project
%
%Contribution


















%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\section{Technical Approach}

\subsection{The Ping Measurement}

To explore the feasibility of using the Internet for remote control of
robots the ping measurement was conducted. Over one week the round
trip time (RTT) to the destinations was measured every minute. The
gathered data was analysed statistically. A second ping measurement
was conducted to proof the assumption that an overload of the local
network causes the majority of the time delay.

\subsubsection{Ping}

Ping is a tool which sends ICMP\footnote{The Internet Control Message
Protocol works at the same level as the UDP and TCP -- it uses the
Network Layer, the Internet Protocol (IP). It is used for
troubleshooting and to announce network errors and timeouts. Please
refer to RFC 792 (Postel 1981) for details.} echo requests to the
destination. The destination computer echos the request package (sends
it back to the sender). The initiator of the ping request measures the
time between sending the ping and receiving its echo. This is the RTT,
the time which is necessary to transfer data to the destination and
back.  The additional processing time on the destination is
immanent. This value can be neglected because it is very short in
comparison to the transfer time. The fault caused by neglecting this
time minimises when the whole ping time increases.

By default a ping package has an overall size of 84 bytes and contains
the following parts: the IP header (20 Bytes) which specifies the
source and target (IP) address and some network management
information. The ICMP header (8 Bytes) contains a sequence-number, a
checksum, and an identifier. The last part is the data part (56 Bytes)
which contains a timestamp and filling-bytes. (Forouzan 2001;
Kozierok 2004; Berkeley 1996) Over one week $10080$ pings were sent
which correspond to $846720$ Bytes or $826$ kByte in one direction per
destination. The same amount of data was sent back.


\subsubsection{Source -- Destinations}

The pings were sent from the author's private server which is located
in the 'Schulzentrum Utbremen' a school in Bremen, Germany. It is
connected through the local school network and the network of the
University of Bremen to the Internet. This server was used because the
network of the LSBU does not allow to send pings to external
computers.

All distances were calculated by using Global Positioning System (GPS)
coordinates. The short overview about GPS coordinates given by Guthrie
(2004) was used. All GPS coordinates were obtained from Maptech (2005)
except the Unisa one which was adapted from Kennington (2000). It was
not possible to obtain any exact GPS coordinates from the servers
which were utilised. Coordinates from the home city or near objects
were used. For this reason the accuracy lays far beyond the GPS
accuracy. In addition to this the calculation results are air-line
distances and not the real lengths of the cable of the transmissions.

To calculate the distance the following steps needed to be
performed. Calculation of the difference between the latitude of the
destination and the latitude of Bremen and the difference between the
longitudes. After this the Pythagorean Theorem was used to calculate
the distance (the hypotenuse). The following formula was used:

$distance = \sqrt{(latitude_1 - latitude_2)^2 + (longitude_1 -
longitude_2)^2}$

The destinations were selected to give a wide spectrum of
distances. It was assumed, that the servers of the destination
organisations were located within the organisation's main building or
near to it. It was not possible to locate a LSBU server which echoes
pings. For this reason the LSBU did not become a destination.

\begin{table}[h]
\begin{tabular}{|l|l|r|}
\hline
Servername & Name of Organisation & Distance \\
\hline
\hline
www.unisa.edu.au & University of South Australia & 17,000 km \\
www.harvard.edu & Harvard University (USA) & 8,800 km \\
www.nationalgallery.org.uk & National Gallery of United Kingdom & 1,000 km \\
www.tu-dresden.de & University of Dresden (Germany) & 460 km \\
mail.hs-bremen.de & Mailserver of the University of & 2 km \\
 & Applied Science Bremen (Germany) & \\
\hline
\end{tabular}
\caption{Destinations which were used in the Ping Measurement.} 
\label{ping-dests}
\end{table}

For details about the results and analyse of the ping measurement
please refer to the \hhref{sec-pingana}.



\subsection{Basic Concept}

The first thing which was developed during this project was the basic
concept. The network library provides the communication tools to the
robot and to the server control program. A user-command takes the
following way:

A user enters a command into the user interface of the GUI/server. The
server control program reads a command from the user through the user
interface, evaluates it, and sends it through the IP network (the
Internet) to the other side by using the functions of the network
library.  The network library on the robot's side receives the command
and hands it over to the robot control program. The robot control
program executes the command and controls the robot. The feedback from
the robot follows this way in the other direction.

It is difficult to clearly distinguish between these levels. For
example: there is no boarder between the GUI and the server control
program in this project. In addition to this the robot's side includes
a GUI to. This GUI is implemented to simulate the assumed position of
the robot. (In the real world at least an emergency stop key has to be
implemented on this side.) The name of this program (robot and its
GUI) is {\tt guirobot}. The name of the server control program (and
its GUI) is {\tt guiserver}.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPInterimReport-basicstructure.eps}
\caption{Basic Structure (Concept) which is assumed in this Project}
\label{fig-basic}
\end{figure}

This communication has to be bidirectional. It must be possible to
request data from the robot. This could be the acknowledgement for a
command, obtaining data of the robots environment, and to monitor the
robot.


\subsection{Implementation of the Library}


The library was implemented on the free operating system
GNU Linux because of the following reasons:

\begin{itemize}

\item It is free software. The term ``free software'' is defined by
the Free Software Foundation (2004) as these four rights:

\begin{enumerate}

\item ``The freedom to run the program, for any purpose.

\item The freedom to study how the program works, and adapt it to your
needs. Access to the source code is a precondition for
this.

\item The freedom to redistribute copies so you can help your neighbour.

\item The freedom to improve the program, and release your
improvements to the public, so that the whole community
benefits. Access to the source code is a precondition for this.''

\end{enumerate}

\item Because of these four rights a complete Linux system is available
for free (without charge).

\item Special versions of Linux which are working on small computers,
like Real-Time-Linux (RTLinux) on embedded systems, are available. ``A
Linux system can actually be adapted to work with as little as 256 KB
ROM and 512 KB RAM'' (Addison 2001). This is essential because the
robot control program often has to run on this kind of computer.

\end{itemize}


% STOP last REVIEW


\subsubsection{Network Layers}

After the basic concept was clarified, the network library was
implemented. The picture \ref{fig-basic} does not show the entire
truth. The network library by itself cannot transfer data through a
network. It has to use lower levels.

During this project it was decided to used TCP for the data
transmission. (Please refer section \ref{osi} on page \pageref{osi}.)
The TCP and the levels underneath had to be implemented as well. This
is not part of this project. Fortunately this was done before and it
is now possible to use the implementation in the
Linux-Network-Stack. In addition to the network implementation in
Linux there must be some hardware in form of a Network Interface Card
(NIC) and some network facilities like cables and hubs. Figure
\ref{fig-osi2} gives an overview about the network layers which were
used in this project.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_NetworkLayers2.eps}
\caption{Overview of the used Network Layers}
\label{fig-osi2}
\end{figure}

\subsubsection{Usage of the Linux Network Implementation}

The Linux kernel provides an interface in form of system calls to
allow (user mode) programs to use its facilities. This section gives
an overview about these system calls and the way in which they were
used in this project. For more detailed information please refer to
IBM (1995).

Figure \ref{fig-socket} shows on outline of the steps which are
necessary to establish, to use, and to disconnect a communication link
-- a TCP socket stream.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Sockets.eps}
\caption{Life Cycle of a TCP Socket Stream}
\label{fig-socket}
\end{figure}

It is possible to {\tt accept()} more than one connection on a bound
port. For this reason it is necessary to distinguish between the
socket which is bound to the port and those for incoming
connections. For each new connection a new socket is generated and
given back by this system call.

The communication (in {\tt Open / Usage}) between both sides is duplex
(bidirectional). The duplex mode (pseudo-, half-, or full-duplex)
depends on the underlying network equipment. There is no prescribed
order in which the sides have to call {\tt send()} and {\tt recv()}.

The functions {\tt accept()}, {\tt recv()}, and {\tt send()} will
block\footnote{If a system call cannot be completed because not
all necessary data is received it waits until it can be
completed. This causes a suspending of the calling function. This is
called: ``the function is blocked''.} by default if there is no
connection to accept, no data to receive (no data was sent), or the
sent-buffer is full (cannot absorb more data). This behaviour can be
changed with {\tt fcntl()}.

For a detailed description of the system calls used please refer to
the manual pages within the 'Linux Programmer's Manual'.

To simplify the process of establishing a socket-stream connection
the following functions were implemented:

\begin{itemize}

\item {\tt socket\_accept()}: Start a new thread, wait for connections,
and call a function when someone connects (server side).

\item {\tt socket\_bind()}: Bind a socket to a port (server side).

\item {\tt socket\_connect()}: Connect a TCP-stream to a server
(client side).

\end{itemize}

In addition to this it was necessary to implement several
sub-functions. All these functions can be found in the file {\tt
src/lib/libcomm.c} \ahref{libcomm.c}.

For a detailed description with parameters and return values of the
listed functions please refer to the Application Programmer Interface
(API) of the network library -- libcomm -- in the appendices
\hhref{libcomm-api}.

Please refer to \hhref{test-lib-basic} for details about the tests
which were conducted to proof the correct behaviour of this functions.



\subsubsection{Block Transfer Functions}

Any data which is sent to a socket that is connected to a TCP stream
will be transfered to the socket on the other side of this stream. The
lower levels take care about the integrity of the data. The TCP
monitors and corrects the order of the data and its integrity. This is
important because data packages may follow different routes through
the network or packages are lost and must be retransmitted. In both
cases the packages need to be re-sorted on the receiver's side. If the
connection is broken due to a network fault, {\tt recv()} and {\tt
send()} will return an error.

For control purposes often blocks need to be transfered. A block in
this context is a unit of data. For example: target coordinates if
form of two integers for x and y. If the size of the datablock is
constant it is simple to receive or transmit it:

{\tt recv(fd, buf, n, MSG\_WAITALL);}

{\tt send(fd, (void *) buf, n, 0);}

In this example {\tt fd} describes the used socket, {\tt buf} is a
pointer to the block, and {\tt n} the number of bytes to be sent or
received.

{\tt MSG\_WAITALL} tells the function to wait until all n bytes are
received. A problem may occur at this point: TCP is a stream protocol
and acts in this manner. It guarantees that the bytes are in the right
order. But it does not guarantee that if m * n bytes were sent, it will
be received as m * n bytes. If, for example, two blocks with 10 bytes
each were transmitted it is possibly received in one block of 20 bytes,
two blocks with 5 and 15 bytes, or three blocks ...

This problem is caused by the transparency of the network stack. The
higher levels do not know what the lower ones do. In addition to this
TCP buffers incoming and outgoing data. Once the {\tt send()} is
called the behaviour of the network stack depends on many things. For
example: buffer size, network load, and speed. On the receiver's side
all received data is stored in a buffer. {\tt recv()} can load already
received data from this buffer or it has to wait for some data to be
received. This behaviour can be configured as mentioned earlier.

If different size blocks are possible it can be tricky to
distinguish between two blocks because there is no way to know what
block-size was used. To bypass this problem the block functions were
implemented.

The block functions are transferring blocks according the following
protocol. This list shows the transmitted parts and their order.

\begin{enumerate}

\item 2 Bytes$^*$: Type: type of the datablock, can be chosen by the user
of the function.

\item 2 Bytes$^*$: Length: length of the datablock. 

\item n Bytes: The datablock itself.

\end{enumerate}

$^*$) These are two byte-values used as a 16 bit integer. For this
reason these values can vary in the range between 0 and 65535. A
consequence of this is that the maximal size of a datablock is 65535
bytes. In addition to this the integer must be organised in the same
way on both sides (GUI/server and robot). This can be tested be the
test-program {\tt src/tests/test002integer.c}
\ahref{test002integer.c}.

In the programming language C data blocks are handled as pointers to
the first unit (in this case a byte). There is no possibility to know
how many units need to be processed if only the pointer is given. For
this reason the block functions need to handle the size as
well. Figure \ref{fig-blockf} gives a schematic of the basic block
function.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Blockf.eps}
\caption{Basic Concept of the Block Functions}
\label{fig-blockf}
\end{figure}

Implemented functions:

\begin{itemize}

\item {\tt block\_send()}: Send a datablock. The function
blocks until the whole block is transfered to the buffer. If the
buffer is full, data has to be sent first before it can continue.

\item {\tt block\_receive()}: Receive a block. This function blocks
until a whole block is received.

% stop review II

\item {\tt block\_ifdata()}: Tests if there is data in the receiving
buffer. The result of this test is returned.

\item {\tt block\_receive\_poll()}: Starts receiving a block if there
is any data in the buffer. The function waits until the whole block is
received. If there is no data in the buffer, an error-code is
returned.

\item {\tt block\_call()}: Starts a thread (goes to background, the
calling function can continue) and waits for a block to be
received. When this event occurs a given function is called to process
this received datablock.


\end{itemize}

In addition to this several subfunctions were implemented. All these
functions can be found in the file {\tt src/lib/libcomm.c}
\ahref{libcomm.c}.

For a detailed description with parameters and return values of the
listed functions please refer to the API of the network library --
libcomm -- in the appendices
\hhref{libcomm-api}.

Please refer to \hhref{test-lib-block} for details about the tests
which were conducted to proof the correct behaviour of this functions.



\subsubsection{Line Monitoring Functions}

In this project it was decided to implement a set of functions to
observe the network link (line). As explained in \hhref{linemonitor-t}
this functions should be able to recognise if the network link becomes
too slow to be used for remote controlling. In this case a function
which takes appropriate actions (stop the robot) must be called.

The basic concept of these functions was adapted from ping. A data
packet is sent to the other side which echoes it (sends it back to the
original sender). The time between the ``ping'' launch and the arrival
of its echo is measured. If this time exceeds a specific value a
exception-function is called.

This implementation uses a TCP socket streams (not ICMP which is used
by the original ``ping'') to transmit one-byte messages. Because of
the different layers which are in use (TCP, IP, and Ethernet) the size
of the data package increases to 67 bytes (1 byte data, 32 byte TCP,
20 byte IP, and 14 byte Ethernet).

It can be helpful to distinguish between two levels of real time
exceptions (timeouts):

\begin{enumerate}

\item Soft Real Time Exception: If this time was exceeded no
serious consequences can occur. It can be ignored but it is an
indicator that something is going wrong, possibly a forewarn. If too
many of these timeouts occur together they can become a hard real time
exception.

\item Hard Real Time Exception: If this time limit is exceeded an
uncorrectable error is assumed. An appropriate action is to shut the
system down (in particular the robot) to a safe state.

\end{enumerate}

The following functions were implemented:

\begin{itemize}

\item {\tt linemonitor()} this function connects the given server on
the given port and starts sending ``pings''. After one byte (used as a
ping) was lunched, the function calls {\tt poll()}\footnote{This is a
system call which suspends the current function until data is received
or a given timeout is exceeded. Please refer to the 'Linux
Programmer's Manual' for a detailed description.} to determine if the
answer (echo) arrives within the soft-timeout. If this was not the
case a specified exception function is called and {\tt poll()} will be
called again. It determines if the answer is received within
hard-timeout (hard-timeout is used as an offset value based on
soft-timeout). If this answer was received in time the function waits
a specified time before is sends the next ping. If this does not
happen the exception function is called.

In addition to this the exception-function is called if the connection
breaks down, an emergency-stop-code was received, or an invalid answer
(answer (echo) differs from request (ping)) was received. This
function should run on the dangerous side (robot side) because the
real-time-timeouts are more accurate than within the server function.

\item {\tt linemonitor\_server()} this function is the server
counterpart to the earlier mentioned function. It opens a specified
port, waits for a connection and echoes (sends back) all received
data. This function is less accurate in recognising timeouts because
the wait-time (time before the next ping is sent by the {\tt
linemonitor()}-function) has to be included. As mentioned this
function should run on the less dangerous side because of this
fact. This function does not send pings by itself, it only echoes the
received data.

After one ping is echoed the function calls {\tt poll()} to determine
if the next ping arrives within wait-time plus soft-timeout. If the
time-limit was exceeded it calls the exception function and repeats
this procedure for the hard-timeout. The function repeats this until
it is terminated.

% 17.4. 22.36 Uhr

\item {\tt linemonitor\_emergencystop()} sends an emergency-stop code
which causes an exceptions within the {\tt linemonitor()}-function.

\end{itemize}

In addition to this, the function {\tt linemonitor\_thread()} as
``background''-part of the {\tt linemonitor()}-function was
implemented. All these functions can be found in the file {\tt
src/lib/libcomm.c} \ahref{libcomm.c}.

{\bf Problems with the implementation} It was planned to provide the
accurate round trip time (RTT) which was taken by the ``ping''. The
system call {\tt select()} which waits for an event (for example
incoming data) was used to realise this. This system call provides a
possibility to request the time which the calling function was
suspended. This functionality can be used to determine an exact value
for RTT but it did not work. Maybe the function is not compatible with
sockets. There was no direct hint about this in its manual page. For
this reason the system call {\tt poll()} was used instead. This system
call does not allow to determine the exact time. It only states if the
timeout was exceeded or not.

For a detailed description with parameters and return values of the
listed functions please refer to the API of the network library --
libcomm -- in the appendices
\hhref{libcomm-api}.

Please refer to \hhref{test-lib-linemonitor} for details about the
tests which were conducted to proof the correct behaviour of these
functions.


\subsubsection{Authentication}

It is essential that the robot can only be controlled by an authorised
person. It must not be possible for anyone else to give commands to
the robot. For this reason it is necessary to implement some kind of
authentication. This was done by including the following functions in
the library: {\tt socket\_md5auth()}, {\tt getauthinfo()}, and {\tt
free\_authinfo()}. These functions were tested (please refer to
\hhref{test-lib-block} for details) but not used in the
demonstration. Because of the last point it was forgone to describe
the used protocol in detail.

For a detailed description with parameters and return values of the
listed functions please refer to the API of the network library --
libcomm -- in the appendices \hhref{libcomm-api}.

The mentioned functions can be found in the file {\tt
src/lib/libcomm.c} \ahref{libcomm.c}.


\subsection{Demonstration with a Real Robot}

One objective of this project was to demonstrate the function of the
library on a real robot. The following section describes how this was
done.

\subsubsection{The Robot}

It was decided to use a Cartesian robot with two degrees of
freedom. The robot itself is attached to a certain place but can move
a platform in horizontal (x) and vertical (y) direction. The robot is
driven by a pneumatic system which is controlled through electronic
valves. There are four valves, one for each direction in both
dimensions. To move the platform in a direction the assigned valve has
to be opened. A valve opens at an operation voltage of 24V. The figure
\ref{fig-robot} gives a basic overview about the structure of the
robot.


\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Robot.eps}
\caption{Basic Structure of the Robot}
\label{fig-robot}
\end{figure}


Unfortunately there was no interface, neither hardware nor software to
control the robot with a Linux machine. Both was implemented in this
project.

\subsubsection{Hardware-Interface to the Robot}

\label{impl-hwint}

It was decided to use the parallel port to control the robot because
only four actors needed to be switched on or off. A feedback from the
robot was not intended. As mentioned earlier the valves to control the
robot are driven by 24V. The valves consume about 100mA. This value
was measured under operation at 24V.

The parallel port is neither able to deliver 100mA nor 24V. It works
with 5V and can provide a few milliamperes. To connect the valves to
the parallel port an amplifier is required.

\begin{figure}[h]
\includegraphics[width=14.52cm]{FYPFinalReport_Robot_Inter.eps}
\caption{Circuit of the Hardware-Interface}
\label{fig-circuit}
\end{figure}

Figure \ref{fig-circuit} shows the amplifier circuit which was
designed to control the valves by using the parallel port. If the
output of the parallel port is low (0 = 0V), $U_R$ is zero either. If
$U_R$ is zero, no current flows into the base of the transistor. The
transistor is closed, $U_{CE} \approx 24V$ and $U_{Vlave} \approx
0V$. The valve is closed. If the output is high (1 = 5V), $U_R \approx
4.3V$, $U_{BE} \approx 0.7V$. The transistor is open: $U_{CE} \approx
0V$ and $U_{Vlave} \approx 24V$. The valve is open. (Please refer to
the following calculations.)

Calculation of the substitution resistor for the values. Used in the
simulation.  This value is only an approximation because of the
inaccuracy cased by the power supply which generates $U_L$ and the
measurement of $I_L$.

$R_L = \frac{U_L}{I_L} = \frac{24V}{100mA} = 240\Omega$

Calculation of $R$. Assumption: parallel port is operating (Hight = 1)
and generates $U_0 = 5V$; 1mA is sufficient to open the transistor
entirely.

$R = \frac{U_0 - U_{BC}}{I_B} = \frac{4.3V}{1mA} = 4300 \Omega$

The calculated resistor value is not available (in E1 series). For
this reason it was decided to use $4700\Omega$. The reverse
calculation:

$I_B = I_R = I_{parallel-port} = \frac{U_0 - U_{BC}}{R} = \frac{4.3V}{4700}
= 0.91mA$

This value is acceptable.

Worst case calculation: if the transistor generates a short-circuit
between C and B, 24V on B. (Parallel port delivers zero, 0V.)

$I_R = I_{parallel-port} = -\frac{24V}{4700V} = -5.11mA$

The parallel port should not be damaged by this current if this
happens.

The diode ({\tt D}) is used to protect the transistor in case of a
high self-induction voltage. The magnetic field in an inductive
element depends on the current through it and vice versa. If an
inductive load is switched off, the magnetic field (which does not
disappear in an infinitely short time) forces a current. If the
transistor is closed the current cannot flow and charges are
divided. A high voltage is generated which can destroy the
transistor. The diode allows the current to flow, no charges are
divided, no problem occurs. The induced current flows in the opposite
direction as the operation current. The diode allows the current only
in this direction to pass. Because of this the transistor is not
bypassed during normal operation.

The circuit as shown was built four times, one time for each
valve. The main challenge in this part of the project was to built
this four amplifiers small enough to fix them info the parallel port
plug. Table \ref{int-con} explains in which way the interface to the
robot is wired.

\begin{table}[h]
\begin{tabular}{|l|l|l|}
\hline
PIN & Bit & Operation \\
\hline
\hline
2 & 0 & Move Up \\
3 & 1 & Move Down \\
4 & 2 & Move Right \\
5 & 3 & Move Left \\
18 & - & GND$^a$ \\
\hline
\end{tabular}
\caption{Connection between the Parallel Port and the Robot's Actors.} 
\label{int-con}
\end{table}

\begin{itemize}

\item $^a$) GND is an abbreviation for Ground which describes the common
0V-level.

\end{itemize}


Please refer to \hhref{test-inter-hard} for details about the tests
which were conducted to proof the correct behaviour of this functions.


\subsubsection{Software-Interface to the Robot}

The software part of the interface was implemented to control the
robot by using the hardware-interface.

According to Messmer and Dembowski (2003) the basis IO-port of the
parallel port is by default located on the IO-address {\tt 0x378}. The
eight output bits can be directly accessed through this address. The
following eight addresses can be used to control other features of the
parallel port.

% 19.4. 22.03

Normally these IO-ports are only accessed by kernel drivers. These
drivers provide an interface (for example, some special files in {\tt
/dev}) to user level programs. User programs access the hardware only
through the kernel. This is done due to security aspects. If any
program could access the hardware directly, it could bypass the access
permission management of the system. For example: copying private
files by directly accessing the harddrive.

To be able to directly access IO-ports under Linux the program has to
have the right to do this. This right is reserved for programs which
run with root (system administrator) privileges. Those programs can
enable the access to the IO-ports by calling the system-call {\tt
iopl(3)}. After this was successful the IO-ports can be accessed by
using {\tt inb()} and {\tt outb()}. {\tt inb(p)} reads one byte from
port p and returns it. {\tt outb(v, p)} writes the value v to the port
p. (Linux Programmer's Manual)

To prevent collisions between the software interface and conventional
Linux drivers these drivers have to be unloaded:

\begin{itemize}

\item {\tt parport\_pc}: low level driver for the parallel port of a PC
\item {\tt parport}: general driver for parallel ports
\item {\tt lp}: driver for Line Printers

\end{itemize}

The software interface calculates the $\Delta x$ and the $\Delta y$ on
the basis of given target coordinates and the stored position. The
interface has to remember the last coordinates of the robot's platform
because there is no feedback from the robot. There is no possibility
for it to request the current position of the platform.

To know the start position of the platform the interface moves the
y-axis to zero during the initialisation process. Because the
position in y-direction is not known the interface assumes $y =
100\%$. If y is not 100\%, the platform will hit its physical
limit. This does not cause any problem. This procedure is not applied
to the x-axis because it would physical damage the component if it is
pushed beyond the given limit. It is for that reason why the x-axis
is not moved during the initialisation process. $x = 50\%$ is assumed.

The interface assumes linear behaviour of the robot. This means that
50\% of the time necessary to cover the whole distance is required to
cover exactly 50\% of the total range (independent from start-point
and direction). Unfortunately the robot is not accurate enough. For
this reason the process of moving the robot's platform to some target
coordinates will produce a great discrepancy between the stored and
the real values. This discrepancy increases with every movement
because of the assumption that the stored coordinates (the result of
the previous movement) were correct.

The following functions were implemented:

\begin{itemize}

\item {\tt interface\_init()} to initialise the interface

\item {\tt interface\_driveto()} drives the robot to absolute
coordinates.

\item {\tt interface\_stop()} shuts the interface down.

\end{itemize}

Several subfunctions needed to be implemented to realize this
functionality. These functions can be found in the file {\tt
src/example/interface.c} \ahref{interface.c}.

Please refer to \hhref{test-inter-soft} for details about the tests
which were conducted to proof the correct behaviour of this functions.

% Ende 19.4. 23.26

\subsubsection{GUI and Simulator}

Some kind of user interface is necessary to control the robot. After
Allegro (Hargreaves 2004), TCL (Unknown 2004), and GTK
were considered, it was decided to use {\tt GTK-2.0} to implement a
Graphical User Interface (GUI). GTK is the GIMP Toolkit, a set of
tools and libraries to implement GUIs. GIMP is the free GNU Image
Manipulating Program. Both, GIMP and GTK are under LGPL\footnote{GNU
Lesser General Public License, please refer Free Software Foundation
(1999)}. (Blandford et al. 2004)

After a basic understanding of the functionality of GTK was gained an
illustration of the robot was implemented. This illustration is used
as an input to control the robot and as a simulation. This was
realized as two GUIs: one on the server side ({\tt guiserver}) which
allows to manipulate the position of the robot's platform by clicking
on in and moving it. The other on the client/robot side ({\tt
guirobot}) which shows (simulates) the current (assumed) position of
the platform. There is no possibility to influence the position of the
platform on this side.

The GUIs are using the functions of the network library to transfer
the commands (destination position) over a network from the server to
the robot. In addition to this the line monitor is used to observe the
quality of the network connection. An emergency stop can be applied
through the line monitor. If an emergency stop code is transmitted or
the connection performance falls below a certain level (hard timeout
occurs) the interface of the robot is shut down. The robot stops all
movements immediately.

These function can be found in the following files:

\begin{itemize}

\item {\tt src/example/guicommon.c} \ahref{guicommon.c} draws the
sketch of the robot and calculates the new coordinates which were
given by mouse-inputs.

\item {\tt src/example/guirobot.c} \ahref{guirobot.c}: implementation
of the robot control program and the simulator. This implementation
uses the interface to the robot.

\item {\tt src/example/guiserver.c} \ahref{guiserver.c}:
implementation of the remote control program. It reads commands from
the user and transmits them over the network to the {\tt guirobot}.

\end{itemize}

Please refer to the \hhref{GUI-user-man} for a more detailed
description of the implemented GUIs.

The main challenge during the implementation of the GUIs was the
re-drawing of the simulation (on the robot's side). A thread
independent from GTK receives the new position from the server and
calls the function which plots the sketch of the robot. Because of
this GTK does not recognise that something was changed. The result of
this is that the changes were not applied to the screen. It was
difficult to find an appropriate solution to this problem. Many
redraw-function do not work and the others were causing a 'Xlib:
unexpected async reply' -- a crash of the program. This happens
because the GTK-thread and the independent thread were not
synchronised. This synchronisation is now restored by calling {\tt
gdk\_thread\_enter()} before drawing the sketch of the robot.Then {\tt
gdk\_window\_process\_all\_update()} forces all components to be
redrawn. After this {\tt gdk\_thread\_leave()} unlocks the main
thread. To use this functions the gdk-library (extension of GTK for
platform independence) needs to be loaded and initialised.

Please refer to section \hhref{test-gui} for details about the tests
which were conducted to proof the correct behaviour of these
functions.

























%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Results and Discussion}


\subsection{Analysis of the Ping Measurement}

\label{sec-pingana}

The ping measurement was conducted twice:

\begin{enumerate}

\item from Mon, 01. November 2004 00:00 to Sun, 07. November 2004 23:59 -- normal school week.

\item from Mon, 26. December 2004 00:00 to Sun, 01. January 2005 23:59 -- holiday period.

\end{enumerate}

The table \ref{tab-ping2} outlines the average of the results. It
faces the distance to the destination with the minimum ({\tt Min}),
average ({\tt Avg}) and maximum ({\tt Max}) values for each
destination and conducted measurement ({\tt Try}). In addition to this
the number of lost pings ({\tt Lost [n]}) and the percentage related
to the total number of pings ({\tt Lost [\%]}) is given for each
destination and measurement.

\begin{table}[h]
\begin{tabular}{|l|r|r|r|r|r|r|r|}
\hline
Servername & Distance & Try & Min & Avg & Max & Lost & Lost  \\
Organisation & [km] & & [ms] & [ms] & [ms] & [n] & [\%] \\
\hline
\hline
www.unisa.edu.au & 17,000 & 1st & 358 & 431 & 9326 & 1432 & 14.21 \\
Uni South Australia & & 2nd & 350 & 370 & 712 & 40 & 0.40 \\
\hline
www.harvard.edu & 8,800 & 1st & 120 & 158& 1754 & 16 & 0.16 \\
Harvard University (USA) & & 2nd & 121 & 137 & 470 & 2 & 0.02 \\
\hline
www.nationalgallery.org.uk & 1,000 & 1st & 47 & 83 & 1673 & 15 & 0.15 \\
National Gallery of UK & & 2nd & 48 & 64 & 401 & 3 & 0.03 \\
\hline
www.tu-dresden.de & 460 & 1st & 21 & 59 & 1571 & 2 & 0.02 \\
Uni Dresden (Germany) & & 2nd & 21 & 36 & 374 & 2 & 0.02 \\
\hline
mail.hs-bremen.de Uni & 2 & 1st & 6 & 39 & 1632 & 145 & 1.44 \\
A.S. Bremen (Germany) & & 2nd & 6 & 11 & 204 & 61 & 0.61 \\
\hline
\end{tabular}
\caption{Overview of the Results of the Ping Measurement.} 
\label{tab-ping2}
\end{table}


The data was displayed in a diagram (on page \pageref{fig-ping}) to
gain a better understanding. The one week time span of the measurement
is plotted on the x-axis with a main interval of one day. The unit of
the y-axis is milliseconds. This axis represents the time which was
required by the ping (RTT) to travel to the destination and back. The
graphs were shifted on the y-axis in order to show all destinations in
one diagram. The arrangement of the graphs is equal to the order of the
above listed destinations. The upper graphs where shifted by 6000$^*$,
4000$^*$, 2000$^*$, and 1000.

$^*$) The 0-level of these graphs were shifted to a grid line.

The first expected result of this measurement was that the time delay
depends on the distance to the destination. This can be seen in the
average values (table on page \pageref{tab-ping2}) as well as in the
first diagram on page \pageref{fig-ping}. The minimum, average, and
maximum values on each measurement increase with the distance. The
graphs in the diagram represent this by being shifted higher according
to the distance.

The second observation was that the time delay for all destinations
increased to very high values from around 8am to about noon and
decreases from noon to 7pm to ``normal'' values. All graphs are
following almost the same pattern. It was assumed that there is a
change in the time delay depending on the daytime. However, the
increases should have been shifted by the time difference to the time
zone of the destination if the destination was to causes a countable
amount of the time delay.

All curves have almost the same shape. Because of this it was assumed
that the same reason caused the time delay for all destinations. When
translating this to network-language, it means that all pings went
through the same sub-network. There is only one sub-network which
matches this characteristic: the local school and university
sub-network through which the server sending the pings is connected to
the Internet. After this network the pings took different routes.

To proof this assumption, that the workload of local school and
university network was causing the majority of the time delays, a
second measurement was conducted. To exclude the possibility of high
work loads this measurement was conducted during the holiday period.

In comparison to the first measurement the time delay is almost
stable. Except of some peaks on Monday which might have been caused by
network maintenance.

\subsection{Result of the Ping Measurement}

As a conclusion of the ping measurement it can be said that the
Internet can be used for remote control quite well as long as some
assumptions are made:

\begin{enumerate}

\item The network link and the possible time delay must be explored
before a statement about its usability can be made. The levels of time
delay are changing from network link to network link and often even
from hour to hour. This has to be well considered. After this analysis
the behaviour (time delay) becomes well known. However, there is still
a large random component because it is unpredictable how the unknown
part of the network link will behave. Most of the network link is
unknown.

\item There must be a possibility to observe the network link quality.
Appropriate actions must be taken if the network link becomes unusable
for remote control purposes. This is essential for safety reasons.

\item The bandwidth to the Internet must be wide enough to carry the
workload without causing unacceptable time delays. The definition of
unacceptable depends on the real time requirements of the remote
control system. It is not a good idea to share the network-access with
other parties because these parties may cause unpredictable workloads
and time delays.

\item If the bandwidth is shared with some other parties, it may help
to implement some priority system.

\end{enumerate}



\newpage
\includegraphics[width=13cm]{FYPFinalReport_Ping1_Overview.eps}
\\\\
\includegraphics[width=13cm]{FYPFinalReport_Ping2_Overview.eps}
\begin{figure}[h]
\caption{Results of the Ping Measurements. Top: First Measurement, Normal
School Week. Bottom: Second Measurement during Holiday period.} 
\label{fig-ping}
\end{figure}


\subsection{Test of the Library}

\subsubsection{Basic Functions}

\label{test-lib-basic}

To test the basic functions ({\tt socket\_bind()} and {\tt
socket\_connect()}) the test-program {\tt src/tests/test001sockets.c}
\ahref{test001sockets.c} was implemented. The function {\tt
socket\-\_accept()} was tested by the program {\tt
src/tests/test003block.c} \ahref{test003block.c}, please refer to
\hhref{test-lib-block}.

The program {\tt test001sockets.c} implements a server and a client to
test the network-functions on the loop-back-network\footnote{This
network is in use if a computer establishes a connection to itself.} 
of the local machine. The server binds a port, receives one
8192-byte-block, inverts it, and sends it back. The client side
connects to the server, sends a random-block, inverts it, receives a
second block, and compares both. If both blocks (received and local
inverted one) are equal it is assumed that the test was successful.

% 20.4. 23.01

\begin{table}[h]
\begin{tabular}{|l|l|l|}
\hline
Destination & Test & Result \\
\hline
\hline
127.0.0.1$^a$ & connect to IP & OK \\
localhost$^b$ & resolution of a local name$^c$ & OK \\
lblacky$^d$ & resolution of a local name$^c$ & OK$^*$ \\
hofmeira.student.sbu.ac.uk$^e$ & Resolution by DNS$^f$ & OK$^*$ \\
\hline
\end{tabular}
\caption{The Test-Results of the Basic (Socket) Function of the Network Library} 
\label{tab-libcomm-bas}
\end{table}

\begin{itemize}

\item[$^*$)] These tests will only work, if the name of the local
machine is equal to the mentioned name.

\item[$^a$)] This IP-address exists on every computer and points 
to the loop-back-network to the local machine.

\item[$^b$)] This name should exist on every computer and is in any
case an alias of the local machine.

\item[$^c$)] Uses /etc/hosts a host-IP-table to resolve the name of a
computer to its IP address.

\item[$^d$)] Name of the local computer (on which the tests were executed).

\item[$^e$)] Name which is allocated to the local computer by the
DNS$^f$ of the LSBU network.

\item[$^f$)] DNS stand for Domain Name Server. This is a system to
manage unique global names.

\end{itemize}


\subsubsection{Block Transfer Functions}

\label{test-lib-block}

The test-program {\tt src/tests/test003block.c} \ahref{test003block.c}
which tests block transfer functions works in almost the same way as the
test-program for the basic socket functions. Changes are: the program
connects localhost and uses the block transfer functions to transfer
blocks.

The server-side program uses and tests this functions (in the
following order)

\begin{enumerate}

\item {\tt block\_receive()},
\item {\tt block\_receive\_poll()},
\item {\tt block\_receive\_call()}, and
\item {\tt socket\_accept()} (which calls {\tt block\_receive\_call()})

\end{enumerate}

to receive a block. {\tt block\_receive\_send()} is used to send this
block back. The client side only uses {\tt block\_receive\_send()} and
{\tt block\_receive\_receive()}.

After these four tests are done, the authentication (functions {\tt
socket\_md5auth()}) is tested as well. This is done by running one
test and authenticating the connection before the block-transfer
starts.

After some troubleshooting all functions worked properly. During the
test 3 and 4 the error ``recv(): Bad file descriptor'' occurs because
the thread still tries to receive after the client closes the
connection. The thread will recognise (through this exception) if the
connection is closed and terminate. This event is documented by the
message ``(server: connection terminated.)'', which was perceived
during the test.



\subsubsection{Line Monitoring Functions}

\label{test-lib-linemonitor}

A small test-program {\tt src/tests/tes005realtime.c}
\ahref{tes005realtime.c} which only implements the
linemonitor-functions was used to test these functions. This program
starts either the server or the client of the linemonitor-system
depending on the parameters which were given:

\begin{itemize}
\item Client Mode:\\{\tt run\_tes005realtime server port soft\_msec hard\_msec wait\_msec}
\item Server Mode:\\{\tt run\_tes005realtime port soft\_msec hard\_msec wait\_msec}
\end{itemize}

The client needs to know which {\tt server} on which {\tt port} has to
be connected, while the server only needs to know which {\tt port} to
bind (and wait for incoming connections). Please refer to
\hhref{gui-param} for a description of the remaining parameters.

To test if the line monitor detects when the time-limit was exceeded,
the quality of the line was lessened by overloading the connection
with pings\footnote{The ping-program can be configured to send pings
without the default time delay of one second. This was used to overload
the network link.} and by breaking the network connection trough
unplugging it.


% STOP of the LAST REVIEW

\subsection{Test of the Interface to the Robot}

\subsubsection{Hardware-Interface}

\label{test-inter-hard}

Before the hardware-interface was implemented the circuit was tested
with Multi\-SIM$^{TM}$ 2001. The result of the simulation validated the
results of the calculations in \hhref{impl-hwint}. This simulation
used a substitution resistor (calculated as $R_L$) to simulate the
valve.

Table \ref{test-hwint} lists the measurements which were conducted to
test if the hardware was implemented properly.

\begin{table}[h]
\begin{tabular}{|p{9.75cm}|l|}
\hline
Test & Result \\
\hline
\hline
Connection from +24V to the valves & OK (low-resistance) \\
\hline
Connection from +24V to other components (Valves not connected) & OK (none) \\
\hline
Connections between the GNDs & OK (low-resistance) \\
\hline
Connection between parallel output bits and GND (both directions
because of the diode in the transistor) & OK (high-resistance) \\
\hline
Connection between parallel output bits and the input of the valves (C
of transistor), both directions & OK (high-resistance) \\
\hline
Connection between parallel output bits & OK (none) \\
\hline
Connection between valve inputs (Cs) & OK (none) \\
\hline
\end{tabular}
\caption{Results of the First Test of the Hardware-Interface.} 
\label{test-hwint}
\end{table}

After this test was completed, the valves were connected and the
hardware was tested by setting the bits on the parallel port
manually. In this test the robot was not moved, the pneumatic supply
was off-line. It was tested if the valves were switching on when a bit
was set. The valves indicate this by a red light and by
switching-noise. The result of these tests was that the interface
worked properly. All valves can be controlled.

\subsubsection{Software-Interface}

\label{test-inter-soft}

The software-interface was tested by monitoring the bits of the
parallel port. At this time the hardware-interface was not
connected. After some troubleshooting the interface seemed to work
properly.

To be able to run the final test on the entire interface a
test-program ({\tt src/ example/test001interface.c})
\ahref{test001interface.c} was written. This program initialises the
interface ({\tt interface\_init()}) first. After this it reads (x,y)
coordinates from the keyboard and hands them over to the interface
({\tt interface\_driveto()}). After a few mistakes were eliminated the
interface worked properly.

The major mistake in this phase of the development was a
misinterpretation of the parameter of {\tt
usleep()}\footnote{System-call which suspends the calling function for
a given time (unit: microseconds).}. Milliseconds instead of
microsecond were used. As mentioned earlier, the movements of the
robot's platform are not linear. For this reason the interface does
not work accurately.

\subsection{Test of the GUI and the Simulator}

\label{test-gui}

The implementation and the testing of the GUI were running almost at
the same time. All newly included details were checked when they were
ready. These tests were conducted by the author personally because
there is no point in writing a test-program to test the interface to
the user. The user has to decide if the interface works properly or
not.

The GUI was implemented and tested in these steps:

\begin{enumerate}

\item Open a (program) window and draw the sketch of the robot in it.

\item Read the commands from the user. The new position of the robot's
platform can be entered by moving the sketch (with the mouse) on
the screen.

\item Transmit the new coordinates over a network to the other side
and apply them to the simulated sketch.

\item Apply the new coordinate to the robot by using the interface.

\end{enumerate}

All these steps are fully implemented now. The system works.


%\subsection{Discussion of the Results}
%
%The sections above can be condensed to two words:
%
%``It works.''
%
%After all components were fixed together and some mistakes were
%corrected, it simply works.
%
%The project met its aim and all its objectives. All deliverables were
%delivered.
%
%Einschränkungen? Linearität?
%























%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusions and Recommendations for Further Work}
\label{conrec}

\subsection{Project Conclusions}

\begin{itemize}

\item During this project the possibility of using the Internet for
remote controlling of robots was re-examed. This was done by conducting
an analysis of an example connection over the Internet. One conclusion
has been drawn that the majority of the time delays (the most
important restriction) were caused by the local network but not by the
Internet. This theoretical result may be useful to future study in
this field.

\item Several approaches to the restrictions were studied and a promising
method, the line monitor, was implemented.

\item This project implements a network library which makes it
possible to control a robot over the Internet. This library was
demonstrated on a real robot by implementing a Cartesian robotic
system. It includes a server side which reads commands from the user
and transmits them through the Internet to the robot's side, where the
commands are received to control the robot.

\end{itemize}

\subsection{Personal Conclusions}

\begin{itemize}

\label{conclu-per}

\item The three most challenging aspects for me during this project
were to organise myself (take responsibility), to document my work
well (write logbook and reports), and to do this in English. I have
gained the confidence to pursue future studies in the proper ways.

\item After completing this project I have realised that an aim and
plan is vital for a project. The good plan will help the student to
elaborate the study direction.

\end{itemize}

\subsection{Recommendations for Further Work}

\begin{itemize}

\item Porting the library to other platforms. All system calls which
were used should be available within GDK (platform independent
development library, extension of GTK). For this reason it should be
possible to use this library and make the network library platform
independent. But this has to be well considered because of the
performance. It may not be recommendable to use a platform independent
implementation on the robot's side because of the overhead which is
caused by this independency. If the robot uses an embedded system with
Real-Time-Linux, maybe there are not enough resources to use GDK. On
the other side -- the server side -- this is completely different
because of the performance of today's computer.

\item Implementation of other strategies to bypass the random time
delay. This can help to make the library more useful for additional
applications.

\item Students spent a lot of work and time to produce reports like
this. It might be a great contribution to provide them on the Internet 
and it could help a lot of other people.

\end{itemize}
















\newpage
%NOTPDF

%PDF
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Bibliography and References}

{\bf Addison, D.} (2001) Embedded Linux applications: An overview\\ 
{[Online] Available at}\\
{\tt http://www-106.ibm.com/developerworks/linux/library/l-embl.html}\\
(accessed 20. October 2004)

% use stack/buffer to smooth up the random time delay to a constant
% (but hight) time delay
% problem: transmission slower  than necessary
{\bf Andreu, D.; Fraisse, P.; Roqueta, V.; Zapata, R.} (2003) Internet
enhanced teleoperation toward a remote supervised delay regulator {\it
IEEE International Conference on Industrial Technology} 10-12 December
2003 p663-668 volume 2 [Online] Available at\\
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/9059/28746/\\01290733.pdf}
(accessed 9. December 2004)

{\bf Ball, P.; Farnham, J; Iraca, S.} (1999) Transmission Control
Protocol/Internet Protocol TCP/IP [Online] Available at\\
{\tt http://cne.gmu.edu/itcore/internet/tcpip/tcpip.html}\\(accessed 11.
December 2004)

% 3d simulation of the robot on the controller side. This saves a lot
% of bandwidth because you do not need to transmit so much sensor
% data like pictures.
{\bf Belousov, I.} (2004) Internet Robotics [Online] Available at\\
{\tt http://www.keldysh.ru/pages/i-robotics/operidea.html}\\(accessed
26. November 2004)

{\bf Berkeley Distribution} (1996) Ping Manual Page [Online] Available
at\\{\tt http://snowhite.cis.uoguelph.ca/course\_info/27420/ping.html}\\
(accessed 12. November 2004)

{\bf Blandford, J; Clasen, M; Janik, T; Lillqvist, T; Quintero, F.M.;
Rietveld, K; Sandmann, S; Taylor, O; Wilhelmi, S} (2005) GTK+ -- The
GIMP Toolkit [Online] Available at\\{\tt http://www.gtk.org/} (accessed
28. March 2005)

{\bf British Standard} (1992) Industrial robots -- Part 6:
Recommendations for safety; BS 7228-6:1992; EN 775:1992; ISO
10218:1992 [Online] Available at\\{\tt http://bsonline.techindex.co.uk/}
(accessed 28. October 2004)

{\bf Chen, Y.-M.; Chen, Y.-B.} (2004) Research reform on real-time
operating system based on Linux {\it WCICA 2004. Fifth World Congress
on Intelligent Control and Automation} 5-19. June 2004 p3916-3920
Volume 5 [Online] Available at
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/9294/29576/\\01342230.pdf}
(accessed 20. October 2004)

{\bf Elhaji, I.; Tan, J.; Xi, N.; Fung, W.K.; Liu, Y.H.; Kaga, T.;
Hasegawa, Y.; Fukuda, T.} (2000) Multi-site Internet-based cooperative
control of robotic operations. {\it Proceedings 2000 IEEE/RSJ
International Conference on Intelligent Robots and Systems}, 2, 31. Oct
- 5. Nov 2000 p826-831 [Online] Available at
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/7177/19309/\\00893121.pdf}
(accessed 20. October 2004)

{\bf Engelen, P.} (2004) GTK-Drawing Demo on Win32 [Online] Available
at\\
{\tt http://mail.gnome.org/archives/gtk-app-devel-list/2004-October/\\msg00105.html}
(accessed 28. March 2005)

{\bf Fairhurst, G.} (2004) Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) [Online] Available at\\
{\tt http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/csma-cd.html}\\
(accessed 11. December 2004)

{\bf Feibel, W.} (1990) Using ANSI C in Unix. Berkeley: Osborne
McGraw-Hill

{\bf Forouzan, B. A.} (2001) Data Communication and Networking, 2$^{nd}$
edition. New York: McGraw-Hill.

{\bf Free Software Foundation} (1999) GNU Lesser General Public
License.\\{[Online] Available at}\\{\tt http://www.gnu.org/copyleft/lesser.html}
(accessed 28. March 2005)

{\bf Free Software Foundation} (2004) The Free
Software Definition\\{[Online] Available at}\\{\tt http://www.gnu.org/philosophy/free-sw.html}
(accessed 28. March 2005)

{\bf Gale, T.; Main, I.} (2000) GTK+ 1.2 Tutorial: Chapter
25. Scribble, A Simple Example Drawing Program [Online] Available at\\
{\tt http://www.johnmalone.org/gtk/tutorial/sec-eventhandling.html}\\
(accessed 28. March 2005)

{\bf Guthrie, J} (2004) Understanding GPS Coordinates [Online]
Available at\\
{\tt
http://www.co.lincoln.wa.us/GIS\%20Data/Understanding\%20GPS\%20Coordi\\nates.pdf}
(accessed 04. February 2005)

%$\backslash$\\

\newpage


% - Simulating the robot on the client's side
% - Three modes to control a Robot
%   - Direct Control - Start/Stop
%   - Supervisory Control - give target
%   - Job scheduling - give a list of jobs/targets
{\bf Han, K.-H.; Kim, S.; Kim, Y.-J.; Lee, S.-E.; Kim, J.-H.} (2001)
Implementation of Internet-based personal robot with Internet control
architecture. {\it Proceedings 2001 ICRA. IEEE International
Conference on Robotics and Automation} 2001 p217-222 volume 1 [Online]
Available at\\
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/7423/20179/\\00932556.pdf}
(accessed 20. October 2004)

{\bf Hargreaves, S.} (2004) Allegro -- A game programming
library.\\{[Online] Available at}\\{\tt http://www.talula.demon.co.uk/allegro/}
(accessed 28. November 2004)

{\bf Heesch, D.} (2004) Doxygen: Introduction [Online] Available at\\
{\tt http://www.stack.nl/~dimitri/doxygen/} (accessed 20. December 2004)

{\bf IBM Corporation} (1995) TCP/IP Tutorial and Technical Overview:
Ports and Sockets [Online] Available at\\
{\tt http://www.auggy.mlnet.com/ibm/3376c210.html} (accessed 22. December
2004)

{\bf Kennington, A} (2000) Alan Kennington's recommendations and
suggestions [Online] Available at\\{\tt http://www.topology.org/reco/}
(accessed 04. February 2005)

{\bf Kernighan, B. W.; Ritchie, D. M.} (1988) The C Programming
Language, 2$^{nd}$ edition. London: Prentice Hall ISBN 0-131-10362-8

{\bf Kozierok, C. M.} (2004) The TCP/IP Guide [Online] Available at\\
{\tt http://www.tcpipguide.com/free/index.htm} (accessed 12. November
2004)

% Random Time Delay - Jitter
% Protocols: TCP, UDP
% - creates an own protocol "trinomial protocol" semi-real-time (buffered)
{\bf Liu, P. X.; Meng, M.Q.-H.; Gu, J.; Yang, S.X.; Hu, C.} (2003)
Control and data transmission for Internet robots {\it Proceedings
ICRA 2003. IEEE International Conference on Robotics and Automation}
14-19 September 2003 p1659-1664 volume 2 [Online]
Available at\\
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/8794/27834/\\01241832.pdf}
(accessed 21. October 2004)

% suffer from random time delay, bandwidth constraints
% non-time-based reference system in the control algorithm
% controlling over web-browser
% consider worst case - max-time-delay
{\bf Liu, Y.; Chen, C.; Meng, M.} (2000) A study on the teleoperation
of robot systems via WWW {\it Canadian Conference on Electrical and
Computer Engineering} 7-10. March 2000 p836-840 volume 2  [Online]
Available at\\
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/6844/18402/\\00849583.pdf}
(accessed 20. October 2004)

{\bf LRAV/AVDAY} (1985) Computer in Control, 01: Introducing the
Robot. [Video]

{\bf Maptech, Inc.} (2005) Online Maps: Map Server [Online] Available
at\\{\tt http://mapserver.maptech.com/} (accessed 04. February 2005)

{\bf Mattis, P.} (1998) The GIMP Toolkit (GTK Documentation) [Online]
Available % at
{\tt http://www.csa.iisc.ernet.in/old-website/Department\_Resources/\\
Hypertext/gtk/gtk\_toc.html} (accessed 28. March 2005)

{\bf McKerrow, P. J.} (1991) Introduction to Robotics. Singapore:
Addison-Wesley. ISBN: 0-201-18240-8

{\bf Messmer, H.-P.; Dembowski, K} (2003) PC-Hardwarebuch (German:
PC-Hardwarebook) 7$^{th}$ edition. Munich: Addison-Wesley. ISBN
3-827-32014-3.

{\bf Mitchell M.; Oldham J.; Samuel A.} (2001) Advanced Linux
Programming,  New Riders Publishing [Online] Available at\\
{\tt http://docs.linux.cz/programming/other/ALP/\\advanced-linux-programming.pdf}
(accessed 20. December 2004)

{\bf Plauger, P.J.; Brodie, J.} (1989) Standard C - A
Reference. London: Prentice Hall. ISBN 0-134-36411-2

{\bf Postel, J.} (1981) RFC 792 -- Internet Control Message Protocol\\
{[Online] Available at}\\{\tt http://www.freesoft.org/CIE/RFC/792/index.htm}\\
(accessed 11. November 2004)

{\bf Sato, H.; Yakoh, T.} (2000) A real-time communication mechanism
for RTLinux {\it IECON 2000. 26th Annual Conference of the IEEE
Industrial Electronics Society} 22-28. October 2000 p2437-2442 volume
4 [Online] Available at\\
{\tt http://0-ieeexplore.ieee.org.lispac.lsbu.ac.uk/iel5/7662/20956/\\00972379.pdf}\\
(accessed 19. October 2004)

{\bf Schwarzenbach, J.; Gill, K.F.} (1992) System Modelling and
Control, 3rd edition. London: Edward Arnold. ISBN: 0-340-54379-5

{\bf Unknown} (2004) TCL Developer Xchange: tcl/tk [Online] Available
at\\{\tt http://www.tcl.tk/software/tcltk/} (accessed 28. November 2004)

{\bf Wilson, G.} (2001) OSI Model Layers [Online] Available at\\
{\tt http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html}\\
(accessed 11. December 2004)

%new??
% {\bf } MD5-Authentication -- lecture (accessed 08. January 2005)
% {\bf } http://www.soe.uogoelph.ca/webfiles/engg4420/lab2.html (accessed 28. March 2005)
% {\bf } http://www.gtk.org/tutorial/ch-advancedeventandsignals.html (accessed 28. March 2005)





















\newpage
%NOTPDF
%\newpage
%PDF
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%NOTPDF
\begin{multicols}{3}[][0cm]
%PDF

\section{Project Planning}

This section compares the planing of the project with its actual
realisation. After the work breakdown structure is given, the final
version of the Gantt char is shown. This is followed by the
comparison of the Gantt charts and action plans from the beginning,
the middle, and the end of the project. In the end the milestones and
some explanations about the project and it's planning are given.
%NOTPDF
\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\
%PDF

\subsection{Work \mbox{Breakdown}}
%\vspace{1cm}
%NOTPDF
\includegraphics[width=5.5cm]{FYPFinalReport_WorkBreakDown.eps}
%PDF
%PDF \includegraphics[height=14.52cm]{FYPFinalReport_WorkBreakDown.eps}

%NOTPDF
\end{multicols}
%PDF

\subsection{Gantt Chart of Final Stage}

\newpage

\includegraphics[height=22cm]{FYPFinalReport_GanttChart0.eps}

\newpage

\subsection{Project Schedule}

\subsubsection{Comparison: Pre and After Interim Stage}

{\bf Action Plan Pre Interim Report}

\begin{tabular}{|l|l|c|c|}

\hline
\multicolumn{2}{|l|}{} & Estimated Duration & \\
\multicolumn{2}{|l|}{Task} & in Weeks & Precedence \\
\hline
\hline
A & Interim Report & 3 & - \\
B & Final Report & 15 & Feedback A \\
C & Clearing Project Aim/Objectives & 5 & - \\
D & Literature Search & 8 & - \\
E & Feasibility Study & 3 & C \\
F & Prepare Presentation & 2 & C,(E) \\
G & Interface to Robot & 4 & C \\
H & Design Structure & 4 & C \\
I & Build Library & 8 & (G) \\
J & Write Documentation (Library) & 9 & (I) \\
K & Build User Interface & 7 & (I) \\
L & Build Robot Simulator & 7 & (I) \\
M & Write Documentation (UI/Simulator) & 5 & (K),(L) \\
N & Interface between Robot and Library & 3 & G,(M) \\
\hline

\end{tabular}


{\bf Action Plan After Interim Report}

\begin{tabular}{|l|l|c|c|}

\hline
\multicolumn{2}{|l|}{} & Estimated Duration & \\
\multicolumn{2}{|l|}{Task} & in Weeks & Precedence \\
\hline
\hline
A & Interim Report & 3 & - \\
B & Final Report & 8 & Feedback A \\
C & Clearing Project Aim/Objectives & 5 & - \\
D & Literature Search & 9 & - \\
E & Feasibility Study / Ping Measurement & 8 & C \\
F & Prepare Presentation & 2 & C,(E) \\
I & Build Library & 4 & C \\
K & Build User Interface & 5 & (I),(N) \\
L & Build Robot Simulator & 5 & (K) \\
N & Interface between Robot and Library & 3 & (I) \\
\hline

\end{tabular}

\includegraphics[height=22cm]{FYPFinalReport_GanttChart1.eps}

\newpage

\subsubsection{Comparison: After Interim Stage and Final Stage}


{\bf Action Plan After Interim Report}

\begin{tabular}{|l|l|c|c|}

\hline
\multicolumn{2}{|l|}{} & Estimated Duration & \\
\multicolumn{2}{|l|}{Task} & in Weeks & Precedence \\
\hline
\hline
A & Interim Report & 3 & - \\
B & Final Report & 8 & Feedback A \\
C & Clearing Project Aim/Objectives & 5 & - \\
D & Literature Search & 9 & - \\
E & Feasibility Study / Ping Measurement & 8 & C \\
F & Prepare Presentation & 2 & C,(E) \\
I & Build Library & 4 & C \\
K & Build User Interface & 5 & (I),(N) \\
L & Build Robot Simulator & 5 & (K) \\
N & Interface between Robot and Library & 3 & (I) \\
\hline

\end{tabular}


{\bf Final Action Plan}

\begin{tabular}{|l|l|c|c|}

\hline
\multicolumn{2}{|l|}{} & Estimated Duration & \\
\multicolumn{2}{|l|}{Task} & in Weeks & Precedence \\
\hline
\hline
A & Interim Report & 3 & - \\
B & Final Report & 8 & Feedback A \\
C & Clearing Project Aim/Objectives & 5 & - \\
D & Literature Search & 9 & - \\
E & Feasibility Study / Ping Measurement & 8 & C \\
F & Prepare Presentation & 5 & C,(E) \\
I & Build Library & 6 & C \\
K & Build User Interface / Simulator & 6 & (I),(N) \\
N & Interface between Robot and Library & 5 & (I) \\
\hline

\end{tabular}

\includegraphics[height=22cm]{FYPFinalReport_GanttChart2.eps}


\begin{itemize}

\item Precedence (in action plans):
\begin{itemize}

\item [X:] Task X has to be completed before the task can start.

\item [(X):] Task X has to be semi-completed before the task can
start. That means that task X has to be in a state in which it is
possible to start a new task simultaneous. Tasks which run
simultaneous can have an influence among each other.

\end{itemize}

\item The scale which was used to measure the duration (weeks) is
inaccurate because of the fact that the work load was not allotted
constantly over the project time. Often the time was shared between
different tasks which were conducted at the same time. These tasks
included project tasks, other study related tasks, and private
tasks. However, it can be said, in all conscience, that at least 300
hours were spent in this project.

\item The holidays were scheduled as a reserve in case that the
project-work would take longer than expected. During the project it
was decided to move some work into the holiday periods.

\item It was chosen to condense the number of tasks to simplify the
project planning. During this process the ``write
documentation''-tasks were included into the corresponding programming
(building) task, the design of the structure was embedded into the
library building process, and the ``Interface to Robot'' development
task was included in the task ``Interface Robot -- Library''.

\item The development of the ``Interface to Robot'' was moved from the
beginning of the project to its middle because the decision about
which robot should be used for the demonstration was delayed.

\item After beginning the development of the GUI it was decided
to use almost the same GUI for both sides. One (server-side) to input
the new position of the robot's platform and the other (robot's side)
to show (simulate) the behaviour of the robot. For this reason, both
development phases were condensed to one.


\end{itemize}

\newpage

\subsection{Milestones}

\begin{enumerate}

\item On Tuesday, 9 November 2004, the project is defined by now and
has been started. This is reflected by the interim report which is
completed and handed in.

\item At this point (9$^{th}$ week of first semester) of the project
it is possible to control the robot with a little experimental
program. The interface to the robot is well understood.

\item In week 14 (first semester) an early simulation with library,
user interface and simulator shows the basic function of the system.

\item At the end of week seven (second semester) the system works. It
is now possible to control the robot over the Internet by using the
library. This will be demonstrated. The simulation works as well.

\item On Tuesday, 26 April 2005, the project and final report are
completed and handed in. 

\end{enumerate}

The milestones one and three were met. The last milestone will be
also be met in time.

The milestones two and four were missed. As mentioned earlier the
decision about the robot was delayed. This caused the missing of the
second milestone. The fourth milestone was missed by almost three
weeks because of the fact that the work was delayed by some
neglected factors. The development of the
interface to the robot was delayed. The time which was
necessary to prepare the presentation was underestimated. And external events
like exams interfered with the initial plan.



%%NOTPDF
%%\newpage
%%PDF
%\subsection{Project Schedule}
%\label{pp}
%\centerline{
%%NOTPDF
%\includegraphics[height=23cm]{FYPInterimReport-GanttChart.eps}
%%PDF
%%PDF \includegraphics[height=20.7cm]{FYPInterimReport-GanttChart.eps}
%}



%\end{document}

% export RTFPATH=/usr/anhtmp/latex2rtf-1.9.16a/cfg/
% /usr/anhtmp/latex2rtf-1.9.16a/latex2rtf  FYPFinalReport.tex
% <CUT here>
















%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\newpage
\appendix
%\addcontentsline{toc}{chapter}{Appendices}
%\section{Appendices}


\section*{Appendix A: User's Manual GUI for Robot and Server}
\setcounter{section}{1}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix A: User's Manual GUI for Robot and Server}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX A: USER'S MANUAL GUI FOR ROBOT AND SERVER}}
\label{GUI-user-man}

\subsection{Both Programs ({\tt guirobot} and {\tt guiserver}) explained}

\begin{itemize}


\item {\tt guirobot}: This is the robot control program. It can run in
two modes:

\begin{itemize}

\item Simulation only: If no access to the hardware is possible (the
program does not run under {\tt root} (with system administrator
rights), access to the IO-ports is not possible. The program recognise
this and shows (simulates) the robot's movements only on the screen.

\item Simulation and Controlling: The IO-ports can be accessed, the
interface is fully active. The program will show the new position of
the robot on the screen and drive the robot to this position.

\end{itemize}

\item {\tt guiserver}: This is the server or the remote control
station. It allows the user to input the new position of the
robot. This new position will be transmitted to the {\tt guirobot} by
using {\tt libcomm}.

\end{itemize}

The robot is shown (simulated) in both programs. The black rectangle
pictures the platform of the robot which can change its position.

The {\tt guirobot} has to be started first. In the second step the
{\tt guiserver} connects to the {\tt guirobot}. After this connection
is established, the {\tt guirobot} connects to the {\tt guiserver} to
monitor the stability and the speed of the line with the {\tt
linemonitor()}. Both programs are looking almost identical:

% 118
\begin{figure}[h]
\includegraphics[width=110pt]{guirobot0.ps}
\includegraphics[width=110pt]{guiserver0.ps}
\caption{Both Programs {\tt guirobot} (left) and {\tt guiserver}
(right) directly After Startup.}
\end{figure}

Their lookout (title line, buttons) depends on the used window manager
and its configuration. In this case AfterStep is in use.

The difference between these two Graphical User Interfaces (GUIs) is
that only the {\tt guiserver} allows manipulations of the position of
the robot's platform. The {\tt guirobot} shows the actual position and
drives the platform of the robot to the required position if the
interface is active and can access the hardware.

\subsection{Manipulate the Position of the Robot's Platform}

Click (with the left mouse-button) on the robot's platform (sketched
as black rectangle) and move it with held mouse button to the new
position. Release the button. An example of the result of this can be
seen in the following screenshot:

\begin{figure}[h]
\includegraphics[width=110pt]{guirobot1.ps}
\includegraphics[width=110pt]{guiserver1.ps}
\caption{Both Programs {\tt guirobot} (left) and {\tt guiserver}
(right) After a Movement of the Robot.}
\end{figure}

\subsection{Stopping the Robot}

Both programs are able to stop all movements of the robot by clicking
``Emergency Stop''. This emergency stop is also executed if the window
is closed or the program receives a terminate signal.

In addition to this the linemonitor stops the robot if the the
connection breaks down or if the server does not answer within a given
time period.


\subsection{Starting both Programs, Parameter}

\label{gui-param}

As mentioned the {\tt guirobot} has to be started first. This program
receives the following parameters:

{\tt guirobot port-to-bind soft\_msec hard\_msec wait\_msec}

\begin{itemize}

\item {\tt port-to-bind} describes the port on which {\tt guirobot}
has to listen for connections from the {\tt guiserver}. The {\tt
guirobot} will connect to the home address of the {\tt guiserver} and
{\tt port-to-bind + 1} to establish a linemonitor connection.

\item {\tt soft\_msec} tells the program how long it has to wait before
a soft-timeout is assumed. A soft-timeout causes a message on the
terminal. The value is specified in milliseconds.

\item {\tt hard\_msec} tells the program how long it has to wait after
a soft-timeout has occurred, before a hard-timeout is assumed. A
hard-timeout causes an emergency-stop of the robot. The hard-timeout
is assumed if there is no response after {\tt soft\_msec +
hard\_msec}. The value is specified in milliseconds.

\item {\tt wait\_msec} specifies the time which has to past after
the last response was received before a new enquiry is
sent. The value is specified in milliseconds.

\end{itemize}

The interface initialises the robot. That means driving the robot's
platform to the (x=50,y=0) coordinates. The interface assumes that the
robot is already in the position x=50. The x-position will not
change. However, this takes some time. The program is ready when the
window is displayed.

After the window is displayed the {\tt guiserver} should be started
with the following parameters:

{\tt guiserver robot-address port soft\_msec hard\_msec wait\_msec}

\begin{itemize}

\item {\tt robot-address} specifies the address of the computer on
which the {\tt guirobot}-program runs. This can be an IP-Address
(Internet Protocol Address) or the name of the computer which must be
resolvable by the used Domain Name Server (DNS).

\item {\tt port} correlates to {\tt port-to-bind} from {\tt guirobot}
and must be the same.

\item {\tt soft\_msec} correlates to {\tt soft\_msec} from {\tt guirobot}
and should be the same.

\item {\tt hrad\_msec} correlates to {\tt hard\_msec} from {\tt guirobot}
and should be the same.

\item {\tt wait\_msec} correlates to {\tt wait\_msec} from {\tt guirobot}
and should be the same.

\end{itemize}



%\end{document}


\section*{Appendix B: API of the Network Library}
\setcounter{section}{2}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix B: API of the Network Library}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX B: API OF THE NETWORK LIBRARY}}
\label{libcomm-api}
\input{libcomm.c.3}

%\section{Appendix C: Source Code of the Network Library (libcomm)}
\section*{Appendix C: Source Code of the Network Library}
\setcounter{section}{3}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix C: Source Code of the Network Library}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX C: SOURCE CODE OF THE NETWORK LIBRARY}}

\subsection{src/lib/libcomm.h}
%NOTHTML
\input{libcomm.h}
%HTML
%HTML \Link[../../src/lib/libcomm.h]{}{}libcomm.h\EndLink

\subsection{src/lib/libcomm.c}
\label{libcomm.c}
%NOTHTML
\input{libcomm.c}
%HTML
%HTML \Link[../../src/lib/libcomm.c]{}{}libcomm.c\EndLink

\section*{Appendix D: API of the Interface}
\setcounter{section}{4}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix D: API of the Interface}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX D: API OF THE INTERFACE}}
\label{interface-api}
\input{interface.c.3}

\section*{Appendix E: Source Code of the Interface}
\setcounter{section}{5}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix E: Source Code of the Interface}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX E: SOURCE CODE OF THE INTERFACE}}

\subsection{src/example/interface.c}
\label{interface.c}
%NOTHTML
\input{interface.c}
%HTML
%HTML \Link[../../src/example/interface.c]{}{}interface.c\EndLink

\section*{Appendix F: Source Code of the GUI}
\setcounter{section}{6}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix F: Source Code of the GUI}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX F: SOURCE CODE OF THE GUI}}

\subsection{src/example/guicommon.c}
\label{guicommon.c}
%NOTHTML
\input{guicommon.c}
%HTML
%HTML \Link[../../src/example/guicommon.c]{}{}guicommon.c\EndLink

\subsection{src/example/guirobot.c}
\label{guirobot.c}
%NOTHTML
\input{guirobot.c}
%HTML
%HTML \Link[../../src/example/guirobot.c]{}{}guirobot.c\EndLink

\subsection{src/example/guiserver.c}
\label{guiserver.c}
%NOTHTML
\input{guiserver.c}
%HTML
%HTML \Link[../../src/example/guiserver.c]{}{}guiserver.c\EndLink


\section*{Appendix G: Source Code of the Tests}
\setcounter{section}{7}
\setcounter{subsection}{0}
\addcontentsline{toc}{section}{Appendix G: Source Code of the Tests}
\pagestyle{myheadings}
\markright{\mbox{\it APPENDIX G: SOURCE CODE OF THE TESTS}}

\subsection{src/tests/test001sockets.c}
\label{test001sockets.c}
%NOTHTML
\input{test001sockets.c}
%HTML
%HTML \Link[../../src/tests/test001sockets.c]{}{}test001sockets.c\EndLink

\subsection{src/tests/test002integer.c}
\label{test002integer.c}
%NOTHTML
\input{test002integer.c}
%HTML
%HTML \Link[../../src/tests/test002integer.c]{}{}test002integer.c\EndLink

\subsection{src/tests/test003block.c}
\label{test003block.c}
%NOTHTML
\input{test003block.c}
%HTML
%HTML \Link[../../src/tests/test003block.c]{}{}test003block.c\EndLink

%\subsubsection{src/tests/test004md5.c}
%\label{test004md5.c}
%\input{test004md5.c}

\subsection{src/tests/tes005realtime.c}
\label{tes005realtime.c}
%NOTHTML
\input{tes005realtime.c}
%HTML
%HTML \Link[../../src/tests/tes005realtime.c]{}{}tes005realtime.c\EndLink

\subsection{src/example/test001interface.c}
\label{test001interface.c}
%NOTHTML
\input{test001interface.c}
%HTML
%HTML \Link[../../src/example/test001interface.c]{}{}test001interface.c\EndLink


\end{document}
