\documentclass[a4paper,12pt]{article}
\usepackage{fancyheadings}
\usepackage{natbib}
\usepackage{pstricks}

\oddsidemargin0.5cm
\textwidth15.5cm
\topmargin0cm
\textheight23cm
%\headsep2cm
\setlength{\parskip}{1ex plus0.5ex minus0.5ex} % Abstand zwischen zwei Absaetzen
\parindent0cm % Einrueckung der ersten Zeile eines Absatzes

%---------------------------------  DOCUMENT  --------------------------------
\begin{document}

\title{New Soccer Server Initiative}
\author{Artur Merke, Oliver Obst, Martin Riedmiller, ...}

\maketitle

\section{Main Statement}

The current soccer-server is a suited testbed for principle research
on noisy, dynamic, multi-agent environments. However, with respect to
the goal in 2050, it lacks of important features like 3D, correct
physical modelling, flexiblity in sensor and actor modelling.

Therefore, we propose the following

\begin{itemize}
\item Freeze the current simulator. Keep it as a testbed for
  challenging multi-agent research.  Idea: if we keep the soccer
  environment stable as it is, we can really measure scientific
  progress from year to year. Evaluation will become meaningful.  This
  competition could become 'simulator classic' and can continue for
  say, the next 10 years.  If the RoboCup organization or community
  decides not to support this any more, also an independent
  competition could be organized.
\item Develop a new simulator from scratch (Features below)
\end{itemize}

\section{Features of the New Simulator}

Central Idea: Open-Source Development of a new simulator environment
in the following basic steps:

\begin{itemize}
\item basic environment, based on correct physical modelling, 3D
\item step-wise refinement of sensors and actors
\item finally, simulation of  humanoid robots
\end{itemize}

To be suited as a scientific testbed, the simulator should show the basic features:

\begin{itemize}
\item easy and reliable communication between clients and server (if
  noise in communication is desired as a feature of reality, it should
  be added explicitly)
\item flexible time managemement: the simulator can both be
  accelerated (asynchronous mode) to allow learning and other cycle
  consuming scientific activities and slowed-down (to allow running on
  slow machines or via the internet)
\item flexible modelling of physical objects and environments
\item 3 D
\end{itemize}

\section{Requirements and Directions}

\begin{itemize}
\item 3D- Monitor
\item Simulator Base-System
\item Sample Clients
\item physical modelling
\end{itemize}


\subsection{Simulator Base System}
\label{sec:sbs}

The simulator base system contains the basic infrastructure for the
core simulator of soccer server 3D. The key idea to gain flexibility
with respect to the simulated robots, sensors, actuators and
environment is to have a small number of extensible base entities by
which the entire world model is made up. Base entities required are 3d
physical objects, sensors, actuators and a representation of the
terrain. Extensibility of soccer server 3D is achieved by using the
concept of factories (from object-oriented programming) for each of
these entity types and by deriving the needed entities from these
entity base classes. A \emph{class server} is used to manage these
factory classes; an approach like this and some of the additional
modules to gain flexibility below have been described in
\cite{ABF+02}\footnote{It's in German, so a summary of the concepts
  follows}. 


\subsubsection{Console Subsystem}

The console subsystem is used for online configuration of soccer
server 3D and for scripting facilities. % (eventually). 
The console subsystem is also responsible for printing and redirecting
(error and warning) messages and uses a \emph{variable subsystem} to
store configuration variables. 


\subsubsection{Variable Subsystem}

The variable subsystem stores the console variables and provides
access to them via a variable server. Within this context, a variable
is an object that stores type, value and other attributes of the
variable.  Console variables also allow referencing other (C++)
variables so that they can be used to access variables of other
modules of soccer server 3D. The console variable callback mechanism
can execute methods within soccer server 3D whenever the value of the
respective console variable changes.

\subsubsection{Forwarder Subsystem}

The forwarder subsystem is used to print and redirect messages
intended to be read by humans. 

\subsubsection{Scene Graph (Tree)}

Entities and their spatial relation are stored in a tree
structure (scene graph), where each node contains an entity, the pose
of the entity with respect to the entity of the parent node and
possibly a number of links to child nodes. To represent for instance a
simple robot on a soccer field we use a terrain, a cylinder-like
physical object, a visual sensor and a kick device (actuator). In the
scene graph, the root node contains the terrain entity and one link to
a child node, the robot representation. This child node contains the
cylinder-like physical object, the relative pose of the physical
object wrt the terrain, and two links to child nodes representing the
actuator and the sensor of the robot. Each of the child nodes stores
one entity again plus the pose of the respective entity wrt the
robot. If the physical representation of the robot moves on the
terrain, the actuator and the sensor of the robot keep their relative
pose without further changes within the scene graph.



\subsubsection{World Objects}

\begin{itemize}
\item entity\\
  A base class for all entities occurring in the simulated world. All
  entities have a name and can be stored in the scene graph.

\item object3d\\
  A base class for representation of three dimensional objects in the
  world; derived from the entity base class. object3d and derived
  classes describe for instance (FIXME) the shape and the weight of 3d
  objects (but not the pose of the object in the world).
  
\item sensor\\
  A base class for sensor devices, derived from the entity base class.
  A sensor device consists at least of a method that, given a certain
  pose in the world, creates some data simulating output from a sensor
  device. A sensor has no spatial extension or other physical
  properties like weight by itself. To represent for instance a
  camera, a 3d physical object entity representing the camera and a
  sensor entity have to be used together.
  
\item actuator\\
  A base class with a method creating a force that is applied to 3d
  physical objects for some time, derived from the entity base class.
  Actuators have a method for changing their current state, possibly
  for some time only. Like a sensor, an actuator alone does not have a
  spatial extension on its own.
  
\item terrain \\
  A representation of the terrain (i.e. the soccer field), derived
  from the entity base class. A possible representation of the terrain
  is for instance a height map, a two dimensional array where each
  value stands for the height at a certain position.
\end{itemize}

\bibliography{simulator3d}

\bibliographystyle{plain}

\end{document}
%-----------------------------------------------------------------------------
