smarts-design by xiaopangnv

VIEWS: 0 PAGES: 18

									                                 SmartS design – phase I∗
                            M. Dynia, A.Kumlehn, J. Kutylowski,
                         F. Meyer auf der Heide and C. Schindelhauer
                                               December 7, 2006



Contents
1 Architecture overview                                                                                                                                                    3

2 Simulation Manager                                                                                                                                                       3
  2.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                         4
  2.2 Round . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                          4
  2.3 Global data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                          5

3 Robots                                                                                                                                                                    5
  3.1 Robot collection . . . . . . .               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
  3.2 Robot state . . . . . . . . . .              .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
  3.3 Creation of action commands                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
  3.4 Robot generation . . . . . . .               .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
      3.4.1 Setup . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
      3.4.2 ScriptedGenerator . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    8
      3.4.3 RandomGenerator . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
  3.5 Visualization . . . . . . . . .              .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10

4 Terrain                                                                                                                                                                  10
  4.1 Initialization of terrain . . . . .              .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   10
  4.2 Showing environment to robots                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
      4.2.1 Checking visibility . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
  4.3 Check new robots . . . . . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
  4.4 Treasures . . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
  4.5 Handling of action commands .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
  4.6 Visualization . . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14

5 Communication                                                                                                                                                            14
  5.1 Initialization . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
  5.2 Rounds . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   14
  5.3 Global communication         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  5.4 Local communication .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  5.5 Messages . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15
  5.6 Visualization . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   15

6 Configuration                                                                                                                                                             16
  6.1 Example file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                                                          16
  ∗ Document   Revision : 1.10




                                                                       1
7 Visualization canvas                                                                             17
  7.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   17




                                                  2
                                                              << interface >>
                                                                 Runnable
                                                           (from java::lang)




                                                     SimulationManager
                                                 (from org::upb::smarts::main)
                               −terrain:Terrain
                               −robots:RobotCollection                                                            RoundDescription
                               −communication:Communication                                                  (from org ::upb ::smarts ::main )
                                                                                                             −roundNumber :int
                               +performRound(number:int):void
                               +visualizeRound(number:int):void
                               +getActionCommandsFromRobots():Collection<RobotActionCommand>
                               +run():void

                                                                                           UniqueID


            GlobalSimulationData
     −numberOfRobots :int

     + init ():void
     + getInstance ():GlobalSimulationData
     + increaseNumberOfRobots (n:int ):void
                                                         RobotID                        LandmarkID                         TreasureID
                                                  −counter:int                   −counter:int                      −counter:int

                                                  +getInstance():RobotID         +getInstance():LandmarkID         +getInstance():TreasureID




                                                    Figure 1: Main classes


1    Architecture overview
The simulation is governed by the main.SimulationManager which initializes the simulation pa-
rameters and defines the control flow through each round.
    Two main functionality frameworks aid the simulation manager to perform its task: ter-
rain.Terrain and communication.Communication. The first one controls the terrain, positions
of robots, treasures, obstacles and landmarks. The second one manages communication structures
and provides communication services to robots.
    The robot.Robot abstract class is the interface to user-defined behavior algorithms for robots.
    The default package is org.upb.smarts, all provided class names within the project are relative
to this package.
    Figure 1 shows ID classes which are used to generate IDs for several types of objects. The
getInstance static method of these classes always creates a unique ID by incrementing a counter.
The IDs are unique only in the context of one of these classes.
    The simulation is run by a GUI class, the visualization.SmartS object. This class constructs
a thread running the main.SimulationManager class and provides an interface between the GUI
and the simulation by means of the visualization.VisualizationCanvas object.


2    Simulation Manager
The simulation manager is represented by the class main.SimulationManager Figure 1 shows some
associated general classes.
   It implements the Runnable interface.




                                                                        3
2.1   Initialization
The initialization is performed by the main.SimulationManager.init method. It consists of the
following steps

   • initialization of configuration by executing configuration.SimulationConfiguration.readConfi-
     guration (see 6),

   • initialization of global system information by executing main.GlobalSimulationData.init (see
     2.3),

   • creation of robot collection object robot.RobotCollection,

   • initialization of terrain by executing the static method terrain.Terrain.getInstance (see 4.1),

   • initialization of communication by executing the static method communication.Communication.-
     getInstance (see 5.1),

   • initialization of generators by executing the static method generator.RobotGenerator.getInstance
     (see 3.4.1),

   • creation of robots by SimulationManager.StartGenerator.getNewRobots (see 3.4.2 for further
     information),
   • checking validity of all new robots by terrain.Terrain.checkNewRobots (see 4.3),

   • adding new robots to collection and triggering the “new robots added” event (see 3.1),

The visualization.VisualizationCanvas object (see 7) is set in the simulation manager by the GUI
class visualization.SmartS.

2.2   Round
One round consists of the execution of the methods main.SimulationManager.performRound and
main.SimulationManager.visualizeRound. The main.SimulationManager.performRound method
executes the following steps:

   • robots are informed about their environment by terrain.Terrain.showEnvironmentToRobots.
     (see 4.2),

   • communication is executed by communication.Communication.performCommunication (see
     5.2),

   • action commands are obtained from the robots by main.SimulationManager.getActionCommands-
     FromRobots, grouped by the robot which returned them within action.RobotActionCommand
     (see 3.3),

   • action commands are dispatched to be executed by terrain.Terrain.executeActionCommands
     (see 4.5),

   • information about new robots is gathered from the SimulationManager.RoundGenerator.-
     getNewRobots method (see 3.4.2),

   • the possibility to add the new robots to the terrain is checked by terrain.Terrain.checkNew-
     Robots (see 4.3),

   • valid robots are added to the main.SimulationManager.robots collection, their state is up-
     dated by invoking robot.RobotState.setAdded,
   • the number of robots in the global state information is updated (see 2.3).


                                                 4
                                                             TerrainElement                                           << interface >>
           << interface >>
                                                      (from org ::upb ::smarts ::terrain )                               SafeRobot
           SafeRobotState                                                                                                                                               Skill
                                                       −position :Position                                     (from org ::upb ::smarts ::robot )
    (from org ::upb ::smarts ::robot )                                                                                                                      (from org::upb::smarts::robot)
                                                                                                         + getPosition ():P
    + isAdded ():boolean                               + getPosition ():Position
                                                                                                         + getSafeState ():SafeRobotState                   −name:String
    + isChangedPosition ():boolean                                                                       + getRobotSkills ():Collection<RobotSkill>
                                                                                                                                                            +getName():String




              RobotState
                                                                                                 Robot
    (from org ::upb ::smarts ::robot )
                                                                                   (from org::upb::smarts::robot)
    −added :boolean                                                                                                                                                   RobotSkill
    −changedPosition :boolean                          −inBuffer:Collection<RobotCommunicationMessage>
                                                                                                                                                << use >>   (from org ::upb ::smarts ::robot )
                                         << use >>     −skills:Collection<RobotSkill>
    + flush ():void                                                                                                                                         −workSpeed :int
                                                       −state:RobotState
    + setAdded ():void
    + setChangedPosition ():void                       << create >>+Robot(xmlConfiguration:Element):Robot                                                   + getWorkSpeed ():int
                                                       +getMessagesToSend():Collection<RobotCommunicationMessage>
                                                       +addMessagesToBuffer(messages:Collection<RobotCommunicationMessage>):void
                                                       +draw(canvas:VisualizationCanvas):void




                                                     Figure 2: Robot and associated classes

   The visualization is performed on a visualization.VisualizationCanvas object. The method
main.SimulationManager.visualizeRound performs the following steps:
    • clearing the canvas by invoking visualization.VisualizationCanvas.erase
    • renders the terrain by invoking terrain.Terrain.draw (see 4.6), this also includes calls to
      robots to draw themselves (see 3.5),
    • renders the communication framework by invoking communication.Communication.draw
    • releasing canvas for drawing visualization.VisualizationCanvas.draw

2.3        Global data
Some information about the current system state is stored globally and can be accessed by all
frameworks (terrain, communication) and robots without any communication.
    The information is stored in the main.GlobalSimulationData object. There exists only one
instance of this object and it can be obtained by the static method main.GlobalSimulationData.-
getInstance. Pior to the first call to this method, the object should be initialized by invoking
main.GlobalSimulationData.init.


3       Robots
Robots are represented by the abstract class robot.Robot. The actual implementation is chosen
and instantiated by one of the robot generators depending on the simulation parameters (see 3.4).
The interface robot.SafeRobot allows to read certain parameters of a robot, but not to change it.
An overview of the classes and interfaces is shown in Fig.2.

3.1        Robot collection
The collection of all robots has to be accessible in many places within the simulation framework.
Especially the terrain.Terrain and communication.Communication classes need a collection of all
robots to perform their tasks.
   As the collection should not be changed anywhere else than by the main.SimulationManager
the robot.RobotCollection class with a set of interfaces has been developed. The interfaces al-
low the main.SimulationManager to access all methods of the robot collection (by means of the
robot.ModifyableRobotCollection interface) and to allow other parts of the simulation framework
to work on a read-only copy of the collection (by means of the robot.RobotCollection interface).
Figure 3 depicts this schema.


                                                                                             5
            << interface >>                    Collection<Robot>                 << interface >>
           Collection<Robot>                     (from java::util )             Iterable<Robot>
             (from java::util )                                                  (from java::lang )




               << interface >>                                                 << interface >>
         ModifyableRobotCollection                                           SafeRobotCollection
        (from org ::upb ::smarts ::robot )                              (from org ::upb ::smarts ::robot )
                                                                         + getAt (index :int ):void




                                               RobotCollection
                                         (from org ::upb ::smarts ::robot )




                                       Figure 3: Robot collection


3.2    Robot state
Whenever changes occur to the collection (by new added robots) the code adding the robots should
set their state within the robot robot.Robot.state to added in this round. This can be accomplished
by invoking robot.RobotState.setAdded.
    The same applies to all code which changes the position of a robot, which should change the
appropriate flag by invoking robot.RobotState.setChangedPosition.
    The robot state class should be updated by the robot after its properties are changed – i.e. the
robot.RobotState.setChangedPosition method should be invoked by the constructor of the robot and
the robot.RobotState.setAdded method should be invoked every time the robot.Robot.setPosition
method is invoked.

3.3    Creation of action commands
Within each round each robot can execute action commands: one round action command and
several landmark action commands.
    There are three possible round action commands: action.Work, action.Move and action.DoNothing,
all subclasses of action.RoundActionCommand. Only one of them can be specified by a robot per
round.
    The action.Work specifies on which work package of a treasure a robot wants to work at the
current round. The robot must specify which treasure to work at and which work package from
this treasure to work at (the work package is identified by the skill it requires, since there might
by only one work package with a certain skill required in a treasure).
    Additionally there are action commands which perform actions on landmarks, all of them are
subclasses of action.LandmarkActionCommand. A robot can specify more than one landmark
action commands per round. The following landmark action commands are possible:



                                                      6
                                                                               ActionCommand
                                                                         (from org ::upb ::smarts ::action )




                                                                   RoundActionCommand
                                                               (from org ::upb ::smarts ::action )                            LandmarkActionCommand
                                                                                                                            (from org ::upb ::smarts ::action )




                 Work
                                                        Move                                DoNothing
   (from org ::upb ::smarts ::action )                                                                                                             CreateLandmarkActionCommand
                                          (from org ::upb ::smarts ::action )     (from org ::upb ::smarts ::action )
      −work :RobotSkill                                                                                                                              (from org ::upb ::smarts ::action )
      −treasureID :TreasureID                                                                                                                     −landmarkID :LandmarkID
                                                                                                                                                  −data :LandmarkData




                                                                                     DeleteLandmarkActionCommand                   ModifyLandmarkActionCommand
                                                                                      (from org ::upb ::smarts ::action )           (from org ::upb ::smarts ::action )
                             RobotActionCommands
                                                                                    −landmarkID :LandmarkID                      −landmarkID :LandmarkID
                         (from org ::upb ::smarts ::action )
                                                                                                                                 −data :LandmarkData
         −robot :Robot
         −landmarkCommands :Collection<LandmarkActionCommand>
         −roundActionCommand :RoundActionCommand

         + getRobot ():Robot
         + getActionCommands ():Collection<ActionCommand>
                                                 Created with Poseidon for UML Community Edition. Not for Commercial Use.




                                                                  Figure 4: Action commands


   • action.CreateLandmarkActionCommand creates a landmark and places it in the current
     robot’s position (prior to executing movement commands from the current round),

   • action.DeleteLandmarkActionCommand deletes a landmark. Landmarks are identified by
     their attribute terrain.Landmark.ID.

   • action.ModifyLandmarkActionCommand modifies a landmark, by changing the terrain.Land-
     mark.data field.

In case of more than one robot deleting/modifying one landmark, the output of the operation is
undeterministic – i.e. one of the operations will be chosen for execution.

3.4        Robot generation
The main.SimulationManager knows two generators. A start generator which creates all robots
during the initialization of the simulation framework. And a round generator that can inject new
robots in every round.
We provide three implementations of robot generators. The scripted robot generator (3.4.2), a ran-
dom generator (3.4.3) and a generator which creates no robots at all (generator.EmptyGenerator ).
All these three generators can be used as start and as round generator. The generators are im-
plemented as subclass of the abstract superclass generator.RobotGenerator which ensures the
implementation of the method generator.RobotGenerator.getNewRobots(). Invoking this method
means to generate new robots.


3.4.1        Setup
The generators are initialized by running the static final method generator.RobotGenerator.-
getInstance. This method creates the appropriate generators depending on the configuration



                                                                                              7
                       StartRobotGenerator                                                                   RoundRobotGenerator
                 (from org ::upb ::smarts ::generator )                                                 (from org ::upb ::smarts ::generator )
    −terrain :SafeTerrain                                                   −terrain :SafeTerrain

    + getInstance ():void                                                   + getInstance ():void
    + getNewRobots ():ModifyableRobotCollection                             + getNewRobots (round :RoundDescription ):ModifyableRobotCollection
                                                                            + addMessagesToBuffer (msgs :Collection<GeneratorCommunicationMessage>   ):void



                         SimpleGridStartRobotGenerator                                                 EmptyRoundRobotGenerator
                        (from org ::upb ::smarts ::generator )                                      (from org ::upb ::smarts ::generator )




                                            Created with Poseidon for UML Community Edition. Not for Commercial Use.




                                                                 Figure 5: Robot generation


parameter robot-generation.start and robot-generation.round. An example for a XML configura-
tion of generators can be found in 3.4.3.

3.4.2      ScriptedGenerator
The ScriptedGenerator reads all robots from a list of robots. The path to the file is specified in
the configuration tag robot-generation.start or round.scripted.robotlist. An example list of robots
could look like this:

<list-of-robots>
<Round number="’0"’>Several Robots</Round>
<Round number="’1"’>Several Robots</Round>
<Round number="’3"’>Several Robots</Round>
<list-of-robots>

When we use the ScriptedGenerator as start generator, then it reads all entries from round
number 0. Used as round genererator, the scripted type reads the entries according to the ac-
tual round. The generator may loop this whole round list depending on the parameter robot-
generation.round.scripted.loop.
A robot entry in one of the rounds should look like this:

<robot x="20" y="10">
    <class>org.upb.smarts.user.robot.KarlsruheExpressRobot</class>
    <robot-config>
      <important-data1/>
      <important-data2>
         <not-so-important-data/>
      </important-data2>
    </robot-config>
    <robot-skill skill="digging" speed="2"/>
    <robot-skill skill="pushing" speed="1"/>
</robot>

A robot entry is described by the robot tag. Each of these entries has the attributes x and y
which define the position of the robot on the grid. The attribute quantity is optional and if
defined it states how many (identical) robots as described here should be placed on the terrain
on the same place (this only makes sense if terrain.one-robot-per-node is not set). The robot tag
has furthermore a child tag class which defines the class implementing the robot behavior and a
robot-config tag which is passed as a tree to the robot upon construction as the xmlConfiguration
parameter. The robot tag has also several robot-skill tags which have a skill attribute and a speed
attribute – this are used to initialize robot.RobotSkill objects.


                                                                                   8
3.4.3   RandomGenerator
The RandomGenerator creates all robots randomly based on functions. The functions generate
values for for the generation of robots. For example the amount of robots to inject, positions of
the new robots, type and skills.
Every function has to extend the abstract superclass Function. By invoking the method generator.Function.-
getValue() a function generates a new value. The created value must be between Function.lowerBound
and Function.upperBound. A function can have further parameters which are passed to the con-
structor as xmlConfiguration. We provide some functions out of the box, but new functions can
be added easily.
The functions for the random generator must be specified in the configuration. A specific function
entry can look like this:

<function>
<class>org.upb.smarts.generator.Average</class>
<lower>25</lower>
<upper>50</upper>
<parameters>
<first parameter/>
<second parameter/>
</parameters>
</function>

    When the method generator.RandomGeneratr.getNewRobots() is called, the generator first
draws an amount value from a function to know, how many robots should be injected. Afterwards
the generator repeats the following steps for each new robot: first the position is generated by
calling the position function two times. Then the type of the new robots is determined by choosing
a string from a list of possible types. These strings are names of implemented robot classes in the
package smarts.robot. Afterwards the number of skills is drawn and then the skills from a set of
possible skills.
The set of types and the set of skills have to be defined in the configuration.

   The folling example for the generator part of the configuration defines a scripted start generator
and a random round generator.

<robot-generation>
<start>
<scripted>
<loop>true | false</loop>
<robotlist>path to file</robotlist>
</scripted>
</start>
<round>
<random>
<amount>function</amount>
<position>function</position>
<type>function
<set-of-types>
<robot class="’org.upb.smarts.robot.SuperRobot"’>
<robot-config>
        <data1/>
     </robot-config>
</robot>
<class>org.upb.smarts.robot.SlowRobot</class>
</set-of-types>


                                                9
                                                << interface >>
                                                   SafeTerrain
                                         (from org ::upb ::smarts ::terrain )
                     + getCommunicationDistance          (p1 :Position ,p2 :Position ):double




                                                      Terrain                                                                              Position
                                         (from org ::upb ::smarts ::terrain )                                                   (from org::upb::smarts::terrain)
                                    −robots :SafeRobotCollection

                                    + showEnvironmentToRobots ():void
                                    + draw (canvas:VisualizationCanvas ):void



                                                                                                                   PlanarPosition                               GridPosition
                    PlanarTerrain
                                                                                   GridTerrain             (from org ::upb ::smarts ::terrain )        (from org ::upb ::smarts ::terrain )
            (from org ::upb ::smarts ::terrain )
                                                                        (from org::upb::smarts::terrain)   −positionX :double                           −positionX :int
      −obstacles :Collection<PolygonObstacle>                                                              −positionY :double                           −positionY :int
      −treasures :Collection<Treasure>                                  −grid:int[][]
                                                                                                           + getX ():double                             + getX ():int
                                                                                                           + getY ():double                             + getY ():int




                         PolygonObstacle
                  (from org ::upb ::smarts ::terrain )
             −coordinates :Collection<PlanarPosition>




                                                                                        Figure 6: Terrain


</type>
<skills>function
<set-of-skills>
<robot-skill skill="’drilling"’ speed="’5"’\>
<robot-skill skill="’recharging"’ speed="’1"’\>
</set-of-skills>
</skills>
</random>
</round>
</robot-generation>

3.5        Visualization

4       Terrain
The terrain is represented by the abstract class terrain.Terrain and its subclasses, depicted in
Fig. 6. In the first phase, only the constructor of the planar terrain class will be implemented,
thus all further information described in the following subsections defines the behavior of the
terrain.GridTerrain class.

4.1        Initialization of terrain
The static method terrain.Terrain.getInstance constructs an instance of a subclass of terrain.Terrain
and initializes it. The actual interface constructed depends on the terrain.type parameter – for
“planar” the terrain.PlanarTerrain and for “grid” first the terrain.PlanarTerrain object is con-
structed and then a terrain.GridTerrain object is constructed.
    The initialization is thus first performed by the constructor of terrain.PlanarTerrain. The
constructor of the planar model performs the following steps



                                                                                                   10
   • reads the size of the terrain from the parameters terrain.size-x and terrain.size-y,

   • reads the definitions of the obstacles from the subtree terrain.obstacles where each obstacle
     tag contains a series of at least three point tags with attributes x and y defining the corners
     of a polygonal obstacle. The definition of the obstacle can be read by the constructor of the
     terrain.PolygonObstacle class,

   • reads the definitions of treasures from the subtree terrain.treasures where each treasure tag
     contains the attributes x and y and several work tags. Each work tag contains one skill at-
     tribute with the name of the skill required and the amount attribute containing the number of
     work units required. The treasure tag can be read by the constructor of the terrain.Treasure
     class. Each of the work tags can be read by the constructor of terrain.TreasureWorkPackage.
     The value of the skill attribute is used to define the name of a robot.Skill object.
     All work packages of one treasure should have different skills. If the configuration file does
     not obey this rule, the configuration is invalid.

    If a terrain.GridTerrain object is to be constructed, its constructor is invoked with a reference
to the already constructed object of class terrain.PlanarTerrain. The constructor of the grid
terrain performs the following steps

   • reads the cell size of the grid from parameter terrain.cell-size. The cell is a square and the
     parameter defines its edge length. The size of the grid on each axis is then defined by the
     size of the planar model divided by the cell size.

   • the plane created within the terrain.PlanarTerrain is divided into cells of size read in the
     previous step. Each cell is defined as an obstacle if at least 1/2 of its area is covered by
     obstacles.

   • each treasure is assigned to the cell in which its position lies.

The cells create a grid – cells are nodes of the graph and nodes are connected by an edge if the
corresponding cells are edge-wise neighbors.
   This sample XML describes a part of the configuration file

<terrain>
  <type>grid</type>
  <size-x>1000</size-y>
  <size-y>1000</size-y>
  <cell-size>0.8</cell-size>
  <obstacles>
     <obstacle>
        <point x="5" y="10"/>
        <point x="10" y="10"/>
        <point x="20" y="20"/>
     </obstacle>
  </obstacles>
  <treasures>
     <treasure x="30" y="20">
        <work skill="digging" amount="5"/>
        <work skill="brushing" amount="1"/>
     </treasure>
  </treasures>
  <view-distance>
     <landmark>1</landmark>
     <obstacle>1</obstacle>
     <robot>1</robot>


                                                 11
                                  << interface >>
                                                                                                                    TerrainElement
                                    SafeTreasure
                                                                                                             (from org ::upb ::smarts ::terrain )
                           (from org ::upb ::smarts ::terrain )
                                                                                                       −position :Position
   + getPosition ():Position
   + getTreasureWorkPackages ():Collection<SafeTreasureWorkPackage>                                    + getPosition ():Position



                                                                     TerrainValuable
                                                              (from org ::upb ::smarts ::terrain )


                                                                                                                              << interface >>
                                                                                                                                                                                 TerrainItem
                                                                                                                               SafeLandmark
                                                                                                                                                                       (from org ::upb ::smarts ::terrain )
                                                                                                                    + getLandmarkData ():LandmarkData
                                                                                                                    + getPosition ():Position




                            Treasure                                                            Landmark
                (from org ::upb ::smarts ::terrain )                                 (from org ::upb ::smarts ::terrain )
      −ID:TreasureID                                                         −ID:LandmarkID                                                                       Earth                                           Obstacle
      −workPackages :Collection<TreasureWorkPackage>                         −data :LandmarkData                                                    (from org ::upb ::smarts ::terrain )              (from org ::upb ::smarts ::terrain )
                                                                             + getLandmarkData ():LandmarkData
                                                                             + setLandmarkData (data :LandmarkData ):void



                                                                                    << interface >>
        << interface >>
                                                                                     LandmarkData
   SafeTreasureWorkPackage
                                                                             (from org ::upb ::smarts ::terrain )
   + getRequiredSkill ():Skill
   + getWorkUnitsLeft ():int




       TreasureWorkPackage
   (from org ::upb ::smarts ::terrain )
   −requiredSkill :Skill
   −workUnitsLeft :int



                                                                           Created with Poseidon for UML Community Edition. Not for Commercial Use.




                                                                       Figure 7: Environment shown to robot

     <treasure>1</treasure>
   </type>
   <movement-distance>1</movement-distance>
</terrain>

4.2         Showing environment to robots
Each robot obtains an instance of an terrain.Environment object, which contains a list of ele-
ments of the environment. These elements corresponds to “special” elements located on the grid,
represented by subclasses of terrain.TerrainElement. The possible elements are:
   • treasures terrain.Treasure which must be processed by robots,
   • landmarks terrain.Landmark which can be modified by robots to store data on terrain,
   • obstacles terrain.Obstacle,
   • robots robot.Robot which are also terrain elements.
All elements which are within the configured distances are shown. This distances are given by the
configuration parameters terrain.view-distance.treasure, terrain.view-distance.landmark, terrain.view-
distance.obstacle, terrain.view-distance.robot.
    If the parameter terrain.obstacle-hide-view is set, then obstacles hide the environment behind
them. This is accomplished by checking the visibility between points as described in 4.2.1.
    The robot does not get the actual objects for terrain.Treasure, and robot.Robot. The framework
passes read-only interfaces of these objects: terrain.SafeTreasure and robot.SafeRobot. It should
be noted that the interface robot.SafeRobot allows to view the ID of the robot it represents. The
terrain.Obstacle object is immutable, thus it is not necessary to pass safe interfaces.
    The landmark object undergoes a cloning of its contents, thus each robot gets a copy of the
actual terrain.Landmark with the associated data. The cloning is deep, i.e. all contained data is
cloned recursively too. Thus any changes made by a robot on the landmark data won’t have any
effect on other robots.


                                                                                                                        12
4.2.1   Checking visibility
Checking visibility between two points (x1 , y1 ) and (x2 , y2 ) is defined as follows. We create a line
between these two points as if they were located on a plane. Then we find all grid nodes which are
in distance d/2 to the line, where d describes the distance between two grid nodes on the plane.
If all these grid nodes do not contain obstacles, then points (x1 , y1 ) and (x2 , y2 ) are within sight.

4.3     Check new robots
Checking whether new robots can be added is performed by the terrain.Terrain.checkNewRobots
method. Its task consists primarily of checking whether the places at which robots are to be placed
are not occupied by obstacles. Additionally, if the terrain.one-robot-per-node parameter is set, the
method must check whether the robots are not placed at nodes already occupied by other robots.
Also, the newly added robots cannot be placed at the same positions, even if the positions have
been empty beforehand.
    The terrain.Terrain.checkNewRobots method returns a collection of robots which can be safely
added not breaking any of the mentioned rules. If there are more than one robot which are to
be placed at the same nodes, only one of them is returned within the final collection. It is not
specified which one of them will be chosen.

4.4     Treasures
Treasures terrain.Treasure represent something to be processed by robots. To process a treasure
a set of operations by appropriately skilled robots must be performed. Formally, a treasure is
defined as a set of tuples (S, w) where S defines a needed skill and w defines the number of work
units to be executed for this skill.
    These tuples are represented by objects of type terrain.TreasureWorkPackage, the skills are
represented by robot.Skill and the number of work units is stored as an (non-negative) integer.
    Any work on the treasure is performed by the robot if it decides to stay within range (the
definition of this range depends on the underlying grid or planar model) of the treasure and to
work on a particular work package. Only one work package is processed at one round and the
number of work units processed by the robot depends on the robot’s speed with a particular skill,
denoted in robot.RobotSkill.
    A skill is uniquely defined by its name. There are two places within the configuration file where
skills are defined. First, when the skills of robots are declared. The second time is when the skills
needed for work packages are defined. Thus if we want to refer to the same skill within these two
places we must use exactly the same name.

4.5     Handling of action commands
The method terrain.Terrain.executeActionCommands checks the correctness of all action com-
mands and applies the correct ones to the terrain. We describe the handling of landmark com-
mands and round commands separately. The landmark commands are handled first.
    For each action.CreateLandmarkActionCommand the created landmark is placed on the respec-
tive place on the terrain. The action command already contains an ID for the terrain.Landmark ob-
ject to be created, thus no ID assignment is necessary here. For each action.DeleteLandmarkActionCommand
the landmark is deleted from the terrain. If it does not exist (any more) a log message of level
INFO should be written.
    The handling of round action commands is sequential. If it is a movement command, it is
checked for correctness and found correct it is applied to the terrain. Thus, commands which
come later can be incorrect, because of changes to the terrain performed by earlier commands. If
a command is incorrect, a log message of level INFO should be written. A movement command
is considered correct if it moves the robot onto a node which is

   • not an obstacle,


                                                   13
                                                                                  CommunicationMessage                                                                             Communication
                                                                           (from org ::upb ::smarts ::communication )                                                 (from org ::upb ::smarts ::communication )
                                                                        −senderRobotID :RobotID                                                       −robots :SafeRobotCollection
                                                                                                                                                      −terrain :SafeTerrain
                                                                                                                                                      −roundRobotGenerator :RoundRobotGenerator

                                                                                                                                                      + getInstance ():void
                                RobotCommunicationMessage                                    RobotGeneratorCommunicationMessage                       + performCommunication ():void
                                                                                                                                                      #getReachedRobots (message :CommunicationMessage ):SafeRobotCollection
                           (from org ::upb ::smarts ::communication )
                                                                                                                                                      + draw (canvas:VisualizationCanvas ):void




                                                                                                                     GlobalCommunication                                                                           LocalCommunication
                                                                                                             (from org ::upb ::smarts ::communication )                                                   (from org ::upb ::smarts ::communication )



                                                                                          + getReachedRobots (message :CommunicationMessage ):SafeRobotCollection                   + getReachedRobots (message :CommunicationMessage ):SafeRobotCollection
                                                                                                                                                                                    + draw (canvas:VisualizationCanvas ):void


             PointToPointMessage                                 BroadcastMessage
    (from org ::upb ::smarts ::communication )        (from org ::upb ::smarts ::communication )
    −receiverRobotID :RobotID



                                                                                             Created with Poseidon for UML Community Edition. Not for Commercial Use.




                                                                                  Figure 8: Communication framework


    • not occupied by another robot, if the terrain.one-robot-per-node parameter is set,
    • its distance from the last node occupied by the robot is not more than terrain.movement-
      range measured in the L1 norm.
   The action.Work action command determines on which treasure (terrain.Treasure) and on
which work package (terrain.WorkPackage) the robot works. His speed described in the robot.RobotSkill.-
workSpeed property determines the number of work units subtracted from the terrain.WorkPackage.-
workUnitsLeft during this round. If the robot does not posses the skill stated in the action.Work
the command is not executed.

4.6           Visualization
The visualization of the terrain consists of two main steps. First the terrain is visualized by
drawing all obstacles, treasures and landmarks. Obstacles are drawn as black squares, treasures
are drawn as circles with color red if there are any work packages left to be processed and with
green color if they are finished. Landmarks are drawn as light grey small circles. Earth is not
drawn (stays white).
    After the terrain itself has been drawn, every robot is required to draw a representation of
itself by invoking robot.Robot.draw.


5         Communication
5.1           Initialization
The initialization of the communication framework is performed by the communication.Communication.-
getInstance method, which first constructs an appropriate subclass of the communication.Communication
abstract class. The choice of the subclass depends on the parameter communication.type. If it is
“local” then the communication.LocalCommunication object is constructed, if it is “global” then
the communication.GlobalCommunication object is constructed. The constructor of the commu-
nication.Communication class requires a pointer to a terrain.SafeTerrain instance.
    For the global communication model no parameters are read.
    For the local communication model, the constructor of communication.LocalCommunication
reads the parameter communication.transmission-range. It defines the maximum distance in which
two robots can communicate with each other. The distance is defined as a floating point value.

5.2           Rounds
The communication is performed by method communication.Communication.performCommunication.
This includes invoking many communication rounds, each consisting of the following steps:


                                                                                                                                     14
   • invocation of robot.Robot.getMessagesToSend to obtain the messages which should be sent,

   • checking whether there are any messages to be sent – if there are no, the communication
     rounds are ready,

   • messages of type communication.RobotGeneratorCommunicationMessage are dispatched to
     the robot generator by invoking generator.RoundRobotGenerator.addMessagesToBuffer (if
     the property communication.Communication.roundRobotGenerator is set),

   • for messages of type communication.RobotCommunicationMessage collecting the robots which
     should be reached by each message by invoking communication.Communication.getReachedRobots
     (abstract method, defined by either the global or local communication scenario). The
     communication.Communication.getReachedRobots should also consider whether the message
     is a subclass of communication.PointToPointMessage – if yes, only the receiver robot should
     be considered when checking the set of robots which should be reached,

   • constructing a set of messages to be transmitted to each robot,

   • putting the messages into receive buffer of robot by invoking robot.Robot.addMessagesToBuffer.

5.3    Global communication
The global communication scenario is implemented by the class communication.GlobalCommunica-
tion. The method communication.Communication.getReachedRobots is overloaded and always
returns all robots for a communication.BroadcastMessage and only the one receiver robot for
communication.PointToPointMessage.

5.4    Local communication
The local communication scenario maintains a communication graph implemented within the
communication.LocalCommunication class. Robots are the nodes within this graph, and the the
nodes are connected by an edge if and only if the positions of the corresponding robots are in a
distance at most communication.transmission-range.
    As the local communication maintains a communication graph it relies on state information
within the robots to check whether their positions have been changed within this round and
whether new robots have appeared.
    The measurement of the distance between two robots is performed by the terrain.SafeTerrain.-
calculateCommunicationDistance.

5.5    Messages
The robot.Robot class may generate messages to be sent by the communication framework. These
messages are subclasses of the communication.CommunicationMessage class. There are two gen-
eral types of messages: subclasses of the communication.RobotCommunicationMessage are trans-
fered between robots and subclasses of the communication.RobotGeneratorCommunicationMessage
are transported from robots to the round start generator (if there exists any).
    All messages to be received by one robot are found and send to it by invoking the robot.Robot.-
addMessagesToBuffer method, which appends all the messages to the input buffer (which acts as
a FIFO queue).

5.6    Visualization
The global communication schema does not perform any drawing.
   The local communication draws the communication graph by drawing thin blue lines between
robots which are connected within the underlying communication graph.



                                                15
                               SimulationConfiguration
                          (from org::upb::smarts::configuration)



                       +read(f:File):void
                       +getInstance():SimulationConfiguration
                       +getBooleanParameter(name:String):boolean
                       +getIntParameter(name:String):int
                       +getDoubleParameter(name:String):double
                       +getStringParameter(name:String):String
                       +getTree(name:String):Element




                                              Figure 9: Configuration


6     Configuration
The configuration data is encapsulated by an object of class configuration.SimulationConfiguration.
The static method configuration.SimulationConfiguration.readConfiguration reads the configura-
tion from a file and saves a global instance of the configuration.SimulationConfiguration object
which can be accessed via the static method configuration.SimulationConfiguration.getInstance
    The configuration is read from a XML file having a tree structure. Access to the tree structure
is possible in two ways:

    • access to single values of types String, double, int and boolean is possible with help of the
      methods configuration.SimulationConfiguration.get*Parameter. It is necessary to specify the
      name of the parameter in the form of a simple XPath query, with tag names separated by
      dots. It is assumed that the first part of the name is a child of the root tag (thus the name of
      the root tag must not occur in the name). As an example, asking for terrain.cell-size would
      produce the result 0.8 basing on the example file.

    • whole DOM subtrees of the configuration file can be accessed by configuration.SimulationConfiguration.-
      getTree. The naming convention is as with the previous method. As an example, asking for
      terrain.view-distance would return a DOM tree with the tag view-distance as its root.

6.1    Example file
<smarts>
  <communication>
    <type>local/global</type>
  <communication>
  <terrain>
     <type>planar/grid</type>
     <cell-size>0.8</cell-size>
     <view-distance>
         <landmark>1</landmark>
         <obstacle>1</obstacle>
         <robot>1</robot>
         <treasure>1</treasure>
     </type>
     <movement-distance>1</movement-distance>
  </terrain>
</smarts>




                                                                   16
             VisualizationCanvas                                                Zoom
      (from org::upb::smarts::visualization)                     (from org::upb::smarts::visualization)

                                                                 −type:int
                                                                 −factor:int
      +erase():void
      +draw():void
      +draw*():void
      +setZoom(zoom:Zoom):void




                    SmartS
      (from org::upb::smarts::visualization)




                                          Figure 10: Visualization


7     Visualization canvas
The visualization canvas class provides an abstract layer between the graphic context of the actual
canvas displayed within the GUI and the drawing operations of the various simulation parts.
    The canvas allows several vector graphics operations to be executed: drawing lines, rec-
tangles, polygons, circles and arcs. Additionally it allows the simulation to start drawing a
round’s view by running visualization.VisualizationCanvas.erase and finish drawing by invok-
ing visualization.VisualizationCanvas.draw. The simulation is required to draw the view of the
simulation scene always with the same 1:1 zoom.
    This operations should be stored by the canvas in a collection so that they can be processed
several times.
    Each time drawing the canvas is required, it should retrieve the last collection, scale and trim
it properly according to the current parameters and display it on-screen. Drawing the canvas
is required every time a new round has finished and the visualization.VisualizationCanvas.draw
method has been invoked or if one of the parameters defined in the next subsection is modified by
the user.

7.1     Parameters
The visualization canvas should have access to the following parameters:

    • size of canvas,

    • zoom type: automatic fit to size of canvas or manually set zoom,

    • in case of manually set zoom: zoom factor

If the zoom is set manually, then the visualized scene may be larger then the size of the display
canvas. In this case the visualization canvas will draw a larger scene, which must be scrolled.
Thus the canvas is embedded in a org.eclipse.swt.custom.ScrolledComposite control which provides
appropriate handling of scroll bars.


                                                    17
   This parameters are set by the GUI (by the visualization.Smarts object). Thus the parameters
can change several times every round.




                                              18

								
To top