%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % (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 % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \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}