\documentclass[12pt, fleqn]{report}
\title{{\textbf{{{\Large PK Programmierpraktikum II\\SS 1999}\\[1cm]\Huge Robot Construction Kit}\\{\large Version 0.3}}}}

\author{ \textbf{Team 1} \\ ECKSCHLAGER Manfred (mekschl@cosy.sbg.ac.at)\\GANGL Thomas (tgangl@cosy.sbg.ac.at)\\ HUSKIC Zenon (zhuskic@cosy.sbg.ac.at)\\WOLACEWICZ Mateusz (mwola@cosy.sbg.ac.at)\\[0.5cm] \textbf{ Coordinator} \\ Mr. SCHWAIGER Roland}

\date{March 25, 1999}


\begin{document}

\maketitle
\begin{abstract}
This paper presents planning and implementation of Robot Construction Kit (RocKit!), that enables the user to construct different types of agents(robots) in 3D environment. Implementation should be done by means of Java and Java3D.
\newline
\newline
Keywords: agent (robot), 3D environment, construction.


\end{abstract}
\tableofcontents

\chapter{Introduction}


As a part of our education here at the University of Salzburg we are obliged to
 take part in a project and implement the same. The project should be implemented through the team effort, as well as with help of our coordinator, Mr. SCHWAIGER, Roland. One of the main reasons why we are implementig this product is DiMAS.

\section{What is DiMAS?}
DiMAS stands for Distributet Multi Agent Simulator, which is simulation software for representation of several agents(robots) in predefined environment. 
DiMAS resulted from Number5, which was developed during the last few years by several people under the supervision of HUBER, Reinhold. It is written in Java, and for the time being it is enabled only for 2D representation.


\section{What is robotics?}
This section serves to define the words robot and robotics, as well as to explain where the word 'robot' origins from. You should also get an idea what you can do with RocKit!.

\subsection{Definition of robot}
The word 'robot' was first pronounced by Karel Capek, the Czech playwright, and it comes from the Czech word for forced labor or serf. There are few definitions of a robot, and here are some of them:

\begin{quote}
A reprogammable, multifunctional manipulator designed to move material, parts, tools, or specialised devices through various programmed motions for the performance of a vaiety of tasks.\emph{Robot Institute of America, 1979}
\end{quote}
Here is another one:

\begin{quotation}
Force through intelligence.
\end{quotation}
And another one:
\begin{quotation}
Where AI (Artificiall Inteligence) meet the real world.
\end{quotation}

According to the Webester's dictionary: 

\begin{quotation}
An automatic device that performs functions normally ascribed to humans or a maschine in the form of a human.
\end{quotation}

The term 'robotics' refers to the study and use of robots. The word was first used by Russian-born American scientist and writer Isaac Asimov, who wrote many books of science fiction.
\newline
One definition of robotics is
\cite{itor}: 
\newline
\begin{quotation}
Robotics is the intelligent connection of perception to action. 
\end{quotation}
\subsection{Robot classification}
A robot can be decomposed into a set of functional subsystems: mechanical, electrical, sensor, software, process, planning and control.\newline
According to \cite{itor} robots have been classified according to their generation, their intelligence level, their level of control, and their programming language level. The generations are:
\begin{itemize}
\item Playback robots
\item Sensor-controlled robots
\item Vision-controlled robots
\item Adaptively controlled robots
\item Artificially intelligent robots
\end{itemize}
\subsection{Mobile - stationary robots}
Regarding mobile-stationary robots can be classified as follows:
\newline
\newline
\textbf{Mobile:}
\begin{itemize}
\item Robots with wheels
\item Robots with tracks
\item Robots with legs
\item Robots that can fly 
\end{itemize}
Most mobile robots use either wheels or legs to move around. These are usually attached to a base to form a vehicle, and equipment to perform other functions is mounted on the base. Few mobile robots have manipulator arms, partly because of their function and partly because of the lack of suitable arms. Arms for mobile robots have to be small, strong and reliable.
\newline
\newline
\textbf{Stationary} robots are usually implemented as manipulator arms, which means that they perform a predifined set of actions that can be programed.

\subsection{Sensors}
Sensors are grouped into two classes: internal and external sensors\cite{itor}. Internal sensors measure variables within the robot - e.g. joint angle, wrist force and platform velocity. 
\newline
External sensors measure the environment - e.g. range, vision, and voice. Sensor installation poses a number of problems for the robot designer. Often sensors have to be mounted in awkward positions, such as on the fingers of a gripper, where they have to be protected from impact, dust, and moisture.
\newline
In robotics, sensors are used for:
\begin{itemize}
\item measuring robot parameters for control loops
\item finding the location of objects
\item correcting for errors in the robot's models of itself and of the world
\item detecting and avoiding failure situations
\item monitoring interaction with the environment such as forces during compilant motion
\item monitoring the environment for changes (such as temperature) that may affect the task
\item inspection the results of processes
\end{itemize} 

\subsection{Robot Characteristics}
There are six major robot characteristics. These are:
\begin{itemize}
\item looks
\item sensing
\item movement
\item manipulation
\item energy
\item intelligence.
\end{itemize}
Each characteristics gives rise to one or more questions:
\begin{itemize}
\item Looks: What does the robot look like? Is there a reason for it to look as it does?
\item Sensing: How does the robot know or figure out what�s in its environment? If it were put in a different environment, would it be able to figure out this new environment?
\item Movement: How does the robot move within its environment? If it were put in a different environment would it still be able to move within this new space?
\item Manipulation: How does the robot move or manipulate other objects within its environment? Can a single robot move or manipulate more than one kind of object?
\item Energy: How is the robot powered? Can it have more than one energy source?
\item Intelligence: How does the robot think? 
\end{itemize}
It is important to mention that not all robots have to have all six characteristics. For example some robots do not need to manipulate things, so they have no manipulating characteristics. Some robots have more than one manifestation of a characteristics. For example, a robot may be able to sense its environment using both a vision system and sonar.
\subsection{Things to think about before and while designig a robot}
Before you start designig your own robot, you might want to think about:
\begin{itemize}
\item Whether it is going to be a mobile or stationary robot?
\item How many arms is it going to have?
\item How many legs is it going to have?
\item What about actuators?
\item Where do you want to place sensors?
\item What about energy sources?
\item How is it going to be manipulated? 
\item ...
\end{itemize}
\section{Requirements}
Our task is to write a program for designing agents(robots), and it should be done in 3D representation by the means of Java and Java3D.
The following are the most important requirements, that were given by Gerhard Katstaller, who personally participated in DiMAS development (the first  considerations):

\begin{itemize}
\item Construction of an agent (that is a Robot) should be inplemented by using interactive 3D interface. Physical properties should be enabled for editing. 
(for example: sensitivity of a light-sensor).
\item Regarding light and sound (infra-red); it should be checked how is it solved in Java3D. 
\item  The file format should comply with the KIF (Knowledge Interchange Format).
\item RocKit! should be applicable for other elements as well, just like obstacles, light, lamp, sound source, etc.
\item A Robot, that was constructed by the means of the RocKit! should be available for modifications later on as well. This means that save function should be enabled to save all changes in 3D environment. Load function should be able to restore the 3D-Graphics.
Import function should be available for DiMAS, too.
\item An improvement of DiMAS could be reached if a reasonable format is produced (it is reasonable due to Java3D).
\item The following basic elements could be used for construction: cube, rectangle, circle, cylinder, pyramid, cone, sphere, wheel...
\item What about the movable parts just like: wheels, robot arms, etc?
Attributes: measurment, position, colour, transparency, friction?
\item Sensors: light, infra-red, heat, hearer.
\item Actors: Light(colour), sound, heat, displays, motors together with wheels, arms, speaker
\end{itemize}
Original e-mail message from Gerhard Katstaller can be found as an attachment to this document.

\section{Graphics User Interface}

One Main window.
The window is split into following frames:
\begin{itemize}
\item  Drawing Screen
\item  Button bar
\item  Menu bar
\item  Drag and Drop
\end{itemize}
%\newline
The Drawing screen is placed in the middle of the window and shows the agentto be designed.
\newline
The button bar holds several buttons:
\begin{itemize}
\item  File items (new, load, save, import)
\item  Control items (view(angle, zoom), properties, settings, ...
\item  Drag and Drop select (switch the drag and drop section between basic elements, sensors, actuators, ...)
\end{itemize}
%\newline
The menu bar holds the program menu, from which it should be possible to use all commands of the program. Only the Drag and Drop cannot be implemented here.
\newline
The Drag and Drop section holds the basic structures, from which the robot will be designed. It is depending on the mode, which is set in the button bar.
%\newline
  Available buttons depending on the mode are:
\begin{itemize}
\item Basic structures: sphere, cylinder, cube, ...
\item Sensors: ir, light, bumper, sonic, ...
\item Actuators: light sources, wheels, ...
\item   ...
\end{itemize}
%\newline
This is only the first draft of the GUI and is still to be developed!

\section{Introduction to KIF}
This was taken from: http://logic.stanford.edu/kif/Hypertext/node1.html
\newline
\newline
Knowledge Interchange Format (KIF) is a formal language for the interchange of knowledge among disparate computer programs (written by different programmers, at different times, in different languages, and so forth). 
\newline
The definition of KIF is highly detailed. The following general features are essential in the definition of KIF. 
\begin{enumerate}
\item The language has declarative semantics. It is possible to understand the meaning of expressions in the language without appeal to an interpreter for manipulating those expressions. In this way, KIF differs from other languages that are based on specific interpreters, such as Emycin and Prolog. 
\item The language is logically comprehensive - it provides for the expression of arbitrary sentences in predicate calculus. In this way, it differs from relational database languages and Prolog-like languages. 
\item The language provides for the representation of knowledge about the representation of knowledge. This allows us to make all knowledge representation decisions explicit and permits us to introduce new knowledge representation constructs without changing the language. 
\end{enumerate}
%\newline


\subsection{The KIF/ACL language}
The following  was taken from: http://dutcu15.tudelft.nl/~marcel/mapping/kif/top.html
\newline
\newline
The agent communication language (ACL) is centred around the knowledge interchange format (KIF). ACL/KIF was originally developed to exchange distinct information between applications,following the messaging paradigm, but due to the diversity of the tools to be integrated, translation was also a major topic of research. ACL/KIF identifies two kinds of translation problems: 
\begin{itemize}
\item vocabulary translation as it arises from the differences of the abstractions inherent in the implementation of different agents (mapping in the sense of this paper) and 
\item the logical translation dealing with the consequences of the problems arising from the limits imposed by agents on the logical structure of messages. 
\end{itemize}
The use of this language and the supporting agent-based architecture attempts to take software integration beyond the exchange of data files or the sole use of database management systems.
As the language has to handle bidirectional mappings between the messages sent by the different agents in their native conceptualization, it canpartly be considered as a formal mapping notation (KIF).

\appendix

\chapter{Gerhard's letter}
From: gerhard.katstaller@sbg.ac.at Thu Mar 11 12:34:15 1999
Date: Thu, 11 Mar 1999 07:53:30 +0100
From: Gerhard Katstaller <gerhard.katstaller@sbg.ac.at>
To: Roland Schwaiger <rschwaig@cosy.sbg.ac.at>
Subject: Re: PPKT II

    [The following text is in the "iso-8859-1" character set]
    [Your display is set for the "US-ASCII" character set]
    [Some characters may be displayed incorrectly]

Anforderungen an das Roboter Construction Kit:
(erste �berlegungen dazu)
\newline
%\newline
- Die Definition eines Agenten soll graphisch (3D) interaktiv erfolgen.
Dies gilt auch f�r physikalische
  Eigenschaften (z.B. die Winkelabh�ngige Empfindlichkeit eines Lichtsensors).
\newline
- bez�glich Licht und Sound (Infrarot) sollte man sich ansehen wie das in
Java 3D gel�st wurde.
\newline
- Man sollte bez�glich des externen Austausch-Formates sich auch die
"Roboter Definition Language" 
  ansehen (sofern es die irgendwo doch real (und nicht nur als Mythos:-)
gibt).
\newline
- Das Konstruktion-Kit soll nicht nur f�r Roboter (Agenten) verwendbar
sein, sondern auch f�r andere
  Elemente der Simulationswelt: Hindernisse, Licht, Ampel, Tonquelle, etc.
\newline
- Nachdem ein mit dem Konstruktion Kit erstellter Roboter sp�ter damit auch
wieder modifizierbar
  sein soll, ist es n�tig, den aktuellen Zustand abzuspeichern und auch
wieder einzulesen und
  daraus z.B. auch die 3D-Graphik wieder aufzubauen. Der abgespeicherte
Zustand sollte sinnvollerweise
  auch dem Austauschvormat entsprechen. Das Einlesemodul soll auch im DiMAS
einsetzbar sein.
\newline
- Wenn ein vern�nftiges Format entsteht, dann kann ich eine Erweiterung
davon als Speicherformat f�r 
  die DiMAS-Simulationen verwenden. (wegen Java 3D ist es sowieso sinnvoll
ein anderes als das
  bisherige zu verwenden)
\newline
- Folgene Grundelemente f�rs Konstruieren fallen mir ein:
  K�rper: Quader, Rechteck, Kreis, Zylinder, Pyramide, Kegel, Kugel, Torus,
Rad, ...
\newline        
- was ist mit bewegbaren Teilen wie R�der, Roboterarme, etc.?
\newline 
- Attribute: Abmessungen, Position, Farbe, Transparenz, Reibung? (rauhe
glatte Oberfl�che)
\newline 
 Sensoren: Licht, Infrarot, W�rme, Hearer
\newline  
- Aktoren: Licht(Farbe), Ton, W�rme, Displays, Motoren in Zusammenhang mit
R�dern, Armen., Speaker


\chapter{Records}
Important note: Special thanks go to GANGL, Thomas, who agreed to take all records that follow.
\section{Briefings' Records}


\subsection{11.03.1999}
Present are: SCHWAIGER Roland, KATSTALLER Gerhard, BRAUNEIS Wolfgang, ECKSCHLAGER Manfred, GANGL Thomas, HUSKIC Zenon, WOLACEWICZ Mateusz.
\newline
Time: 14 00  -  15 00.
\newline
Place: Briefing's room. 
\newline
Introduction to the project and the first requirements;
\newline

As it was arranged on Wednesday, March 3, 1999, our team toghter with the coordinator met Gerhard Katstaller and Wolfgang Brauneis in order to get an insight regarding DiMAS. Members of the team got a copy of the e-mail message sent by Gerhard Katstaller to our coordinator with the first considerations listed. Gerhard and Wolfgang explained the purpose of DiMAS and set some other requirements for our project as well (movable parts of a robot, etc.). The meeting resulted in the following items:
\begin{itemize}
\item Members of the team should get the DiMAS source code and ``try'' it out (source code should be sent per e-mail to each member from our coordinator)
\item The next briefing should be held on March, 17, 1998 at 16 15 HRS (time has been fixed for Wednesdays at 16 15 HRS)
\item Report regarding project should be submitted to the coordinator weekly, no later then 13 00 HRS Tuesdays
\item Report should be written in a document preparation system: \LaTeX\
\end{itemize}

\subsection{17.03.1999}
Present are: SCHWAIGER Roland, GANGL Thomas, HUSKIC Zenon, WOLACEWICZ Mateusz.
\newline
Time: 16 15  -  17 00.
\newline
Place: Schwaiger's office.

\begin{itemize}
\item Discussing about the sturcture of the document
\item Discussing content of the document
\item Appending the e-mail message regarding the requirements
\item Discussing new items
\end{itemize}

Modification of the document:
\begin{itemize}
\item It should get a title page
\item Abstract must be imported
\item Briefing's record should be prepared as appendix
\item We should finally bring photos for the www-page
\end{itemize}
New items:
\newline

To introduction:
\begin{itemize}
\item What kinds of robots are there(mobile, static)?
\item What kinds of sensors are there?
\end{itemize}
  We should search in the Internet regarding RocKit!K (3D-game  Decent should have something like that - Altavista)
 We should get in touch with Conrad Lang regarding the ``Knowledge Interchange Format'' (KIF). He made a work about it.
Other sources are available at the Stanford University Server.
\newline
Design of the GUI should be started. 
\newline
Requirements:
\begin{itemize}
\item It should be possible to use RoCK for other objects and not only for agents(robots). 
\item What attributes could be appointed to an object.
\item Representing the system in the UML (Unified Modelling Language)
\item Gerhard's e-mail message should be analysed once more
 
\end{itemize}

\subsection{24.03.1999}

\textbf{Time:} 16:25 - 16:50
\newline
\textbf{Persons present:}
\begin{itemize}
\item  Roland Schwaiger
\item  Manfred Eckschlager
\item  Thomas Gangl
\item  Zenon Huskic
\item  Matheus Wolacewicz
\end{itemize}
\textbf{Place:}
\newline
Schwaiger's Office
\newline
Department of Computer Science
\newline  
University of Salzburg, AUSTRIA
\newline
\textbf{Important:} We have a name for our project:
\textbf{RocKit!} (fabulous, isn't it)
\newline
\textbf{Record:}
\begin{enumerate}
\item   reformat document
\item  refine classification
\item   discussing the GUI
\item   next step: object orientated design
\item   UML(!): todo: UseCases, ClassDiagrams
\end{enumerate}

\textbf{New points:}
\begin{itemize}
\item refine classification of robots regarding mobile - stationary
\item  design of the Graphical User Interface
\item  split into two groups:  
\begin{enumerate}
\item GUI:      Eckschlager, Gangl
\item LowLevel: Huskic, Wolacewicz
\end{enumerate}
\item  Design of UseCases with regard to the designed GUI
\end{itemize}
\bibliographystyle{ieeetr}
\bibliography{projekt_III}

\end{document}

































































