R
C
R
-T
S
L
C
C
:
TTIT62 / TDDB47
UTHORS
EAL
TIME
YSTEMS
ABORATORY
EPARTMENT OF
OMPUTER AND
NFORMATION
CIENCE
INKÖPING
NIVERSITY
WEDEN
ECEMBER

1 Overview 3
1.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2 Lab assignments and passing requirements . . . . . . . . . . . . .
3
1.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2 Lab environment 9
2.1 High-level controller . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Task scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Road-map to successful labs
4 Application programming interface
18
19
5 Starting the system 23
5.1
Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2
Testing the schedulers . . . . . . . . . . . . . . . . . . . . . . . . 24
A Appendix
References
28
30
2

This section gives a general overview of the lab by presenting its goal (section
1.1), lab assignments and requirements for passing (section 1.2), and the scenario under which the lab exercises are performed (section 1.3).
After these lab exercises you will have learned how the scheduling theory that you studied in the course can be used in a pseudo-realistic setting. This will be done by writing the code for the following types of schedulers:
1. cyclic executive,
2. earliest deadline first scheduler (EDF), and
3. rate monotonic scheduler (RMS).
Lab assignments
Your task is to do the following.
1. Implement three schedulers: cyclic, EDF, and RMS.
2. Implement one performance metrics for analyzing the behavior of your EDF and RMS schedulers. You can either choose to implement the metrics that you have devised, or implement one of the performance metrics typically used for analyzing behavior of real-time systems, such as deadline miss ratio, average response time, or system utilization.
Passing requirements
In order to pass this lab you are required to pass the practical and the theoretical part of the lab examination. Practical part of the lab examination is a demonstration of working solutions of schedulers (cyclic, EDF and RMS) to the lab assistant.
Theoretical part of the examination involves a discussion with the assistant on a set of questions related to the lab assignments. The questions are divided in two categories: preparatory and qualifying questions. Preparatory questions are devised to increase your understanding of the lab assignments and competence for doing the lab, and, therefore, shorten the time needed to successfully complete the lab. You should know the answers to these questions before starting the lab, i.e.,
3

after you read this compendium and before you actually start to write the code of your schedules. Please write down your answers to the preparatory questions in the blank spaces that follow after each of the question.
The next set of questions are qualifying questions, which are devised to complement the practical part of the examination. These questions serve as means for deepening your understanding of the scheduling problems in real-world settings as they require you to relate the simulations results (performance of your schedulers) with the theory studied in the course.
Note that all members of the group should be present during the practical and theoretical part of the examination and should equally participate in every segment of the examination.
Preparatory questions
Your should write down the answers to the preparatory questions into provided space in the compendium. Note that the answers to the preparatory questions are the starting point in the discussion on the lab with the assistants.
1. Explain the mechanism behind the cyclic scheduling. What does cyclic schedule consist of?
What is the difference between a minor and a major cycle in a schedule?
4

How are they determined?
Outline the cyclic schedule for the RoboCup task set. What is the major and minor cycle?
2. What is the difference between RMS and EDF scheduling with respect to implementation and performance?
5

3. Outline the steps in the RMS and EDF scheduling process, preferably with a sequence chart (or a pseudocode, or a flowchart).
6

What has to be done off-line (i.e. before you run the scheduler) and on-line
(i.e. during run-time)?
4. Where and how do you look for deadline overruns in RMS and EDF?
What has to be done when a deadline overrun has occurred?
5. Why does the planner need to be restarted in the scheduler?
7

Is there a difference between a way the planner is restarted in different schedulers (cyclic schedule, RMS, and EDF)?
Where and how should the planner be restarted in each of these schedulers?
Qualifying questions
1. What criteria did you use when determining the minor and major cycle in your cyclic schedule and why?
2. What can you conclude about the cyclic scheduling in dynamic environments? Have you experienced any drawbacks or benefits of this type of scheduler in the RoboCup environment? Compare the results with the theory on cyclic scheduling.
3. Compare the result of your simulations with the theoretical performance of the scheduling algorithms.
4. If you were the real-time system designer asked to implement a scheduler for an environment similar to RoboCup lab environment, what scheduling algorithm would you use? Motivate your answer based on your lab experiences.
8

This lab is inspired by the Robot world Cup (RoboCup) soccer games [2]. In general, the RoboCup initiative represents an attempt to foster artificial intelligence and intelligent robotics research by providing a standard problem, in this case the soccer game, where wide range of technologies can be integrated, examined, and used for integrated project-oriented education.
A small-size soccer game, which is a part of RoboCup and the focus of this lab, involves two teams of robots playing soccer on a green carpeted field. An overhead camera attached above the playing surface is typically used to identify and track robots as they move around the field. The vision information is then processed by the off-field computer. The off-field computer is responsible for the communication with the robots, i.e., their coordination and control. This communication is wireless and done using transmitter/receiver units. For the robots to remain responsive in a dynamic environment of the soccer game, correct scheduling of the tasks that are involved is vital.
The small-size RoboCup soccer game setup of this lab is given in figure 1.
Here, RoboCup is played by two teams consisting of three robots each. Each team of robots is controlled from a dedicated off-field computer. Images from the camera overviewing the soccer field are fed into both computers and processed there.
The physical scenario of robots, the field on which they play, and the overviewing camera can be replaced with a simulator called soccer server (see figure 2).
The simulator provides a graphical user interface, referred to as monitor, to portray a playing field and robots’ movements on the field. The computers, in this simulated scenario, are coordinating and controlling the robots through the communication with the simulator.
Software that is controlling the RoboCup soccer game is distributed between computers controlling the robots, and the robots that are being controlled. Software located on the robots is shown in figure 3, and consists of a low-level controller which processes the instructions from a computer. The processing capabilities of the low-level controller are limited to packet processing and motor control. A robot is moving on the field using the power from two on-board motors. The motors are controlled by setting the motor powers according to the motor control variables, namely LeftRobotMotor and RightRobotMotor .
Software located on the computers is shown in figure 4. It consists of the three major parts, namely image processing, high-level controller, and actuator. Im-
9

Information flow
Camera
Team 1
Computer 1
Computer 2
Team 2
Figure 1: Physical scenario of the RoboCup age processing processes images that are fed into the computer from the camera.
The high-level controller analyzes the outputs from image processing and makes various computations, including game analysis, strategy acquisition, multi-robot collaboration, and plan generation. It consist of two parts: a planner and a reactor. The planner analyzes the current state of the game, i.e., robots’ positions on the field, and computes abstract high-level plans for each robot. The reactor is responsible for breaking down the plans generated by the planner further into lowlevel actions. Finally, the actuator wraps up the low-level actions into a protocol and transmits them to the robots. On-board each robot, the low-level controller decodes the protocol and extracts the low-level actions, which are then carried out.
If the simulated scenario is used instead of the physical one, the actuators communicate with a simulator instead of the physical robot. Furthermore, images fed by a camera to the computers in the physical scenario are, in the simulated scenario, fed to the system by the simulator.
Hence, the computation tasks involved in the RoboCup soccer game in the lab setup corresponding to the major software parts of the system are image processing , planner , reactor and actuator . These tasks are scheduled and executed by the scheduler in a suitable order. Note, there is only one copy of image processing and actuator, while there are three copies (one for each robot) of planner and reactor, i.e., high-level controller.
In the remainder of this section we give a detailed description of the lab environment with the focus on high-level controller, i.e., the intelligent part, and the scheduling.
10

Simulator
Camera
Team 1
Team 2
Information flow
Computer 1
Computer 2
Figure 2: Simulated scenario of the RoboCup
11

Hardware Software
Low-Level Controller
Robot
Figure 3: Software components corresponding the the physical environment of a robot
Hardware
Computer x
Software
Image Processing
High-Level Controller
Planner
Reactor
Actuator
Figure 4: Software components corresponding the the physical environment of a computer
12

The high-level controller, i.e., an agent architecture, chosen for the labs is a variant of the conventional hybrid deliberative/reactive architecture. In this architecture, each agent has both a planning and a reactive part, i.e., planner and reactor.
Planner
The planner is responsible for the abstract, high-level reasoning of the agent. It outputs a plan step that should be executed by the reactor. The plan step can be thought of as the next step in the plan that the planner has devised to meet the planned goal. Moreover, the plan step represents the abstract action, i.e., command, that a planner devises and sends to the reactor. For example, if the planner devises a plan with a goal to achieve score , then the plan may consist of the consecutive steps: goToBall , kickToGoal , and celebrate . To achieve the goal for which the plan was devised, the planner first sends the command goToBall to the reactor. This plan is valid until the robot reaches the ball (this may involve a number of cycles). Only after the robot is in the position near the ball, the planner shall send the command kickToGoal until a goal is scored. Finally, when the score is made, the planner sends celebrate command.
The planner is an any-time planner , which implies that at any point in time the planner can provide a plan step for the the reactor to carry out. The plan steps are provided until the plan is fully carried out. Hence, the property of this type of planner is that the more time it is given, the better plans it will produce, i.e., closer to the fulfillment of the planned goal it gets. In other words, the computation time given to the planner is proportional to the ability to achieve more plan steps.
Our any-time planner is implemented with six plan steps. As more steps of the planner are carried out, better plans are achieved, i.e., chances of scoring become higher. Execution of each new plan step implies new invocation of the planner.
The planner typically runs in a given time slot within every cycle. However, the planner is not always guaranteed a time slot within a cycle as the scheduler grants the time slot to the planner only if it finds that there is enough time to execute the planner, i.e., one or more plan steps.
The computation of the plans devised by the planner is rather expensive as it is based on tree search algorithms. Generally, it takes a significant amount of time for the planner to decide on an abstract action (at least 1 second). Additionally, the planner’s choice of an abstract action depends on the current state of the environment (at least more abstract parts of the environment state). However, more abstract parts of the environment do not change that often, e.g., the role of a robot does not (usually) change from defensive to attacking, and back, within half a second. This, in turn, implies that the planner does not have to make a new decision
13

at every cycle and it is typically the case that the planner takes several cycles to make a decision.
Due to the dynamic nature of the soccer game, the planner needs to reevaluate its planning periodically. As the planning is based on a tree search algorithm, reevaluation of the planning implies that the search needs to restart at the top of the tree, i.e., the root, and continue in the tree downwards. The planner, therefore, needs to be restarted every second.
Reactor
The reactor takes an abstract action given by the planner and decides on concrete low-level actions, e.g., motor speeds, that should be taken to achieve the planned goal. The reactor produces commands that are expected to be executed by the robot in a single cycle (approximately 50ms). These commands are fed to the actuator (outside the high-level controller), which transmits them to the robot.
Note, invoking a reactor after the actuator results in the command from the reactor to be sent at the next invocation of the actuator. Hence, in order to achieve good performance the reactor should be complete before the actuator starts.
The reactive system deals both with the details of the environment and the basic control of the robot. To deal with uncertainty and errors that originate from the dynamic environment, the reactor needs to reevaluate its course of action, i.e., commands, every cycle. For example, if ball velocity changes during the game, then the reactor needs to adjust motors’ speed to slightly change the position of a robot chasing the ball in order to match it to the new ball position.
Note that the reactor is fairly independent from the planner as the planner does not necessarily have to produce new plans every time something changes in the world. However, the reactor must be run after image processing is completed, since its performance depends on the freshness of the data describing the environment.
The scheduler in the RoboCup system is in charge of scheduling all tasks involved, according to a particular scheduling policy. As mentioned, the tasks involved in the RoboCup soccer game are image processing, planner, reactor and actuator.
These are periodic tasks, characterized by parameters describing their temporal behavior, such as period, deadline, worst-case execution time, etc. Table 1 lists the tasks in the system and their temporal properties. Each tasks temporal behavior is described by an estimated worst-case execution time (WCET), period and relative deadline. Observe that image processing task has estimated WCET longer than its
14

Task Name
Image processing 100000 50000
Planner (all 6 steps) 12000 (2000 per step) 1000000
Reactor
Estimated WCET ( µs ) Period ( µs ) Relative deadline ( µs )
1000 50000
50000
1000000
50000
Actuator 3500 50000 50000
Table 1: Temporal properties of the tasks in the RoboCup system period. This is due to the fact that given execution time estimates are the worstcase one. The execution time of image processing is typically between 20000 µs -
50000 µs . Only on very rare occasions, the execution time of image processing exceeds this execution bound and reaches the worst-case bound.
As can be noted from the description of the main software parts of the RoboCup system, and their interactions, it is clear that the tasks in the system are not independent. Rather, they are inter-dependent and have precedence constraints, which need to be enforced by the scheduler.
Cyclic scheduling
Since the tasks in the system are fixed and periodic, it is possible to layout the complete schedule using cyclic scheduling [1]. Cyclic scheduling implies that the schedule is constructed as a pre-defined sequence of calls to tasks, where each call gives control to the called task. The whole sequence of non-repetitive calls represents the major cycle, and it consists of a number of minor cycles with fixed duration. The scheduler should make sure that all tasks for a given robot, except the planner, are run to completion in each of the minor cycles. The time slot given to a planner for a robot in a minor cycle should correspond to the execution of one or more plan steps, i.e., one or more invocations of the planner. Recall that to complete a plan for a robot, the planner needs to be invoked six times. Once the plan is executed and all steps in planning are performed, the scheduler should reset the planner so it can start a new plan (see description of the planner in section
2.1). Note that it is your task to determine which is the appropriate place in the cyclic schedule where the planner should be restarted. The quality of the game when doing cyclic scheduling also depends on the ability of planners of different robots to interact, i.e., the game is better if the planners of each robot are able to execute their steps in each minor cycle in parallel.
Note that the image processing task in our lab environment has estimated
WCET longer than its period, while its execution is typically between 20000 µs -
50000 µs . Hence, to be able to construct a cyclic schedule that meets the deadlines
15

Scheduler dispatch
released preempted
waitForNextPeriod
Figure 5: The life cycle of a task in the system of all tasks, you should consider image processing to have execution time fixed to a number between 20000 µs -50000 µs , e.g., you can chose 30000 µs as exact
WCET, and use the chosen number as an exact WCET of the image processing task in your cyclic schedule. This assumption that image processing will always run for the chosen number, e.g., 30000 µs , is allowed for the following reasons.
Firstly, your task is to do cyclic scheduling which implies that the scheduling should be done based on the known task temporal attributes off-line, i.e., before running the system. Secondly, assuming the WCET of 100000 µs for image processing in the schedule would greatly under-utilize CPU as these worst-case scenarios for image processing occur seldom.
Priority driven scheduling
The life cycle of a task in the system is shown in figure 5. The task can be in one of the three states: ready , running , and suspended . When the system is initiated all tasks are in the suspended state. The scheduler, thus, first needs to check if any of the suspended tasks are ready to be released, and, consequently, their state changed to ready. In the priority driven scheduling schemes, the scheduler chooses the ready task with the highest priority for execution. An executing task is in the running state. If the task that is currently executed is preempted during its execution by another, higher priority, task its state changes back to ready (see figure 5). After the task has finished execution, it goes to the suspended state.
The scheduler maintains two types of sorted lists, namely ready and suspended lists. The ready list(s) can be sorted according to the scheduling policy chosen, e.g., EDF or RMS, while the suspended list(s) are sorted by the release times such that a task with the earliest release time is first in the list. Initially, all the tasks are placed in the suspended list, i.e., suspended state. The scheduling then involves
16

managing of tasks in the sorted lists. Namely, the scheduler needs to check if any of the suspended tasks is ready to be released, and releases it if needed. The scheduler releases a task by putting it to the ready list(s), and it dispatches, i.e., starts executing, the task from the ready list(s) that has the highest priority. When the task has finished, the scheduler puts it back in the suspended list.
In the current implementation of the RoboCup system, due to the constraints of the lab environment (see section 2.3), the preemption of the tasks can only be done at certain pre-defined pseudo-preemption points, referred to as yield points .
Since each task always runs until one of its yield points is reached, it might happen that the task misses its deadline. Hence, the scheduler also needs to detect the possible deadline misses and needs to deal with them by invoking a so-called
DeadlineMissHandler. The DeadlineMissHandler sets the appropriate flag, i.e., isFinished=true , to indicate to the scheduler that the task has finished executing. It is then up to the scheduler to set a new deadline and a release time for the task, and place it back into the suspended list from where it will be moved to the ready list when its next release time occurs.
Observe that the scheduler should also make sure that the planner is appropriately restarted, and that it is you task to determine which is the appropriate way to restart the planner for priority driven scheduling.
Your task is to make the above described schedulers. To place the focus on the scheduling problem and not on skilled programming and elaborative coding, you are asked only to fill in the code needed for task manipulation in the skeleton files of the schedulers that we provide (section 5.1 contains details on how to obtain skeletons).
In your scheduler you also need to make sure that there are no busy loops. That is, when there are no tasks available for running, you should put your schedule to sleep until a task becomes available. The sleep function that is provided in the skeleton file of the scheduler can be used for this purpose.
For real-time courses (given for ca 150 students per year) we need to build our labs in the regular IDA student lab environments (currently using Solaris or Windows
2000 machines). These environments do not allow full control of the computational tasks as we would wish to exercise in a real-time lab course. Also, we wish to run the labs in a high level of abstraction and therefore avoid C or assembler programming in these courses.
Prior to these simulation-based labs a physical robot environment, with a camera, radio communication and handyboard-controlled lego robots has been developed. To be compatible with the physical robots, so that in the future some student
17

lab programs can be loaded into the physical test bed and run in real-world, we have developed the simulation-based lab environment on Windows machines.
To satisfy these constraints, and still run meaningful labs that provide you with a deeper understanding of the theory of scheduling we have developed an environment in which you program in Java. To ensure that the other Windows tasks do not interfere with the Java computations, and omit giving the control of the threads to Java, we do not use Java threading. All the computation tasks, including your scheduler will be running as one task on the JVM. The question would then be: how do we program schedulers that implement preemption, and how do we model tasks that are interrupted due to overrun?
The "trick", which you can ignore for the purpose of developing your schedulers, is that all the computation tasks that you are going to schedule are already given, and they are written with predefined "yield" points that act as pseudopreemption points. Your scheduler will therefore decide that a task is to be preempted or interrupted (as usual) but in reality the running task will be stopped at its next coming yield point.
To complete the labs you need to perform the following steps.
• Get familiar with the football playing robot problem statement and the development environment for your scheduler by reading and understanding the whole compendium.
• Download the skeletons that have been prepared for the two first schedulers
(cyclic and EDF), and prepare the code for implementing each algorithm.
• Set-up the test environment for running your algorithms. You can either test your algorithms against another student team, or against the three reference schedulers that have been prepared for this purpose 1 . Details of how to setup the test environment (soccer server, monitor, opponent) are given later in this document.
• Once you are finished with the implementation and testing of each scheduler, ask the course assistant to check your demo and discuss your finding with the assistant.
• Prepare a listing of your scheduler code together with the frontpage details
(IDA:s labomslag) to be examined by the assistant.
1 The reference schedulers have the suffix Ref in the name of a particular scheduler class.
18

• Join a final demo of some actions taking place in the physical environment
(date to be announced) and have some fun!
This section gives an overview of the application programming interfaces (APIs) needed for completion of the lab exercises. The APIs given here are primarily related to the scheduling facilities provided by the system.
The complete documentation of all APIs available for RoboCup can be found at: http://www.ida.liu.se/ ∼ m_reap/RoboCup/API/.
A set of classes facilitating time is provided within the package soccorob.rt.time , as follows :
• HighResolutionClock ,
• HighResolutionTime ,
• AbsoluteTime , and
• RelativeTime
HighResolutionClock class provides the system clock. It gives the current time, method getTime() , with resolution of 2 microseconds. The format of the time is:
, where
= minutes,
= seconds, and
= microseconds.
HighResolutionTime is the base time class. It supports minutes, seconds and microseconds. It provides a method for comparison, isGreater() , which compares this instance with another instance of the HighResolutionTime class.
AbsoluteTime is a subclass of HighResolutionTime , and provides the additional methods add() and subtract() . The usage and semantics of these methods is as follows: a.add(b,c) means c=a+b , and should be interpreted as
“add a and b and put result in c ”. Observe that HighResolutionClock has to be called with an instance of the AbsoluteTime as an argument.
HighResolutionClock sets the the instance of AbsoluteTime to the current time.
19

RelativeTime is a subclass of HighResolutionTime and is used to measure periods of time.
RelativeTime method, toMicroseconds() translates time format from
to the microseconds format.
The package soccorob.rt
contains the majority of the classes that facilitate task management. Following are some of the most relevant classes provided by this package.
RLThread class represents the tasks in the system. In fact, all the tasks in the system are implemented as RLThread s. Some of the methods provided by this class include:
• isFinished() , which allows the scheduler to probe the system in order to determine if the task has finished its execution,
• setReady() , which allows the scheduler to make the task ready for execution (e.g., when moving the task to the ready list), and
• getDeadlineMissHandler() , which returns the deadline overrun handler of a task.
ReleaseParameters is a base class which allows the scheduler to manipulate with the cost (computation time) and the deadline of each task, using the methods get / setCost() , and get / setDeadline() .
PeriodicParameters is a subclass of ReleaseParameters class. It allows manipulation of two more parameters, period and start. Start here refers to the absolute time when the thread must be released, i.e., made ready, for the first time.
Parameters period and start can be obtained through methods getPeriod() , and getStart() .
Scheduler is the base class for all schedulers. Subclasses of this class are used to derive all other alternative scheduling policies.
Scheduler provides several important methods, of which some are abstract:
• getThreads() , which allows the scheduler to obtain all tasks that need to be scheduled, and
20

• fireThread() , which allows the scheduler to dispatch a task giving it some CPU time (burst); this method returns when a yield (preemption) point of the task is reached, i.e., this method executes tasks in pieces determined by preemption points (e.g., applying this method on a planner ensures that the planner executes one plan step and applying it on the image processing ensures that image processing task is executed only until its next yield point).
The method start() is called in order to start the (cyclic, EDF and RMS) scheduler.
BaseCyclicScheduler is a subclass of Scheduler class and, together with methods inherited from Scheduler , it provides methods to implement cyclic scheduling policy:
• fireUntilFinished() , which allows the cyclic scheduler to run the task till it finishes its execution, beyond all yield points.
• setSchedulerStart() , which is used in the cyclic scheduler to signal the start of the scheduler, so that the underlying infrastructure knows when the first cycle started (and thus all the next cycles) should start. Hence, this method should be invoked only in the cyclic scheduler, before the major cycle is started.
• setMinorCycle() , which enables setting the length of the minor cycle of the cyclic scheduler.
• setMajorCycle() , which enables setting the length of the major cycle of the cyclic scheduler. Recall that the major cycle should be a multiple of the minor cycle. If the length of the major cycle is not specified correctly (as a multiple of the minor cycle) this method automatically sets the length of the major cycle to the value that is the highest multiple of the minor cycle that is smaller than the length of the major cycle specified within the method.
• waitForCycleInterrupt() , which is used at the end of every minor cycle in order wait for the proper starting point of the next minor cycle.
Priority lists are used in the priority based scheduling policies. A package soccorob.rt.util
abstracts the priority lists and enables the implementation of dynamic scheduling algorithms. The classes available for list manipulation are the following.
21

ThreadNode is class of a node in the sorted list.
ThreadNode consists of a reference to the next node, and an instance of RLThread .
RMThreadNode is a subclass of the ThreadNode . It provides additional variables, namely nextRelease and deadline , which are useful when implementing priority based scheduling algorithms.
SortedThreadList
ThreadNode is the abstract class of a list of sorted instances of a class with respect to a specific, typically scheduling, criteria. Abstract methods within this class include:
• getFirst() , which returns a reference to the first ThreadNode in the list,
• insert() , which inserts a ThreadNode into the sorted list,
• isEmpty() , which returns true if the list is empty,
• isGreater() , which compares two instances of ThreadNode ,
• remove() , which removes an instance of ThreadNode ,
• removeFirst() , which removes the first ThreadNode in the list and returns a reference to it, and
• toString() , which returns a string containing the IDs and the names of the tasks in the sorted list.
Other classes, such as EarliestDeadlineSortedList , PrioritySortedList , PeriodicitySortedList , and EarliestReleaseSortedList are subclasses of the SortedThreadList class and represent lists sorted according to different policies, e.g., deadline, static priority, periodicity, and release times.
OBS!
The standard way a list is implemented differs from this implementation. We know that creation of objects is costly and also we want to prevent the garbage collector from being invoked, since this will cause overhead in the system.
Instead of creating a node when we want to insert an object into a list, we can pass on the whole node to be inserted. This way we do not need to create new nodes.
Also this will allow the developers to implement subclasses of ThreadNode and add additional methods or variables and still use the SortedThreadList for their purposes (polymorphism). Note that an instance of a ThreadNode may only exist in one list.
Due to the specific implementation of the sorted lists, when moving threads from one list to another in the scheduler, you first need to remove the thread from one list and then insert it into another (other way around will not work).
22

A package soccorob.ai.agent
represents the part of the system that represents the agents. A part of this package is Planner class that embodies the deliberative system, which is, in turn, wrapped in a PlannerControl object, making it easier to switch planners. The method restart() from PlannerControl class is used to reset the planner so it can start executing a new plan. Note that PlannerControl is a subclass of the RLThread , and that you can apply restart() method on an object of type RLThread (with appropriate typecasting).
To successfully write and test your schedulers you should first do a preparation step (described in section 5.1) and then start the RoboCup system (described in section 5.2).
If you are interested in finding out more on how different parts of the
RoboCup lab environment are programmed, you can find details about that in the appendix.
Before you start doing the lab exercises you need to download an .exe
file named studentFiles.exe
into your home directory ( z: \ ). The file can be found at: http://www.ida.liu.se/ ∼ m_reap/RoboCup/StudentFiles/. Execution of the studentFiles.exe
from your home directory results in the following sequence of actions:
• z: \ robolab
• z: \ robolab \ setenvvar.bat
• z: \ robolab \ startserver.bat
• z: \ robolab \ startteam1.bat
• z: \ robolab \ startteam2.bat
• z: \ robolab \ rt
• z: \ robolab \ rt \ CyclicScheduler.java
23

• z: \ robolab \ rt \ EarliestDeadlineFirstScheduler.java
.
This implies that when the .exe
file is executed a directory named robolab is created (in the home directory) containing a set of .bat
files and a subdirectory rt with two .java
files.
Files CyclicScheduler.java
and EarliestDeadlineFirstScheduler.java
contain skeletons for the schedulers you need to write. Skeleton for
RMS scheduler is not included in the package, thus, requiring you to write it from scratch.
If you choose to download and extract the studentFiles.exe
on different directory than your home directory as specified above, then you need to know Java classpaths and know how to modify the skeletons to compile with RoboCup environment.
Bat files are used for setting the environment variables ( setenvvar.bat
), starting up the server ( startserver.bat
), and starting the game ( startteam1.bat
and startteam2.bat
) in a manner described in the following section.
In order to test the schedulers you have written, you need to perform the following four steps.
STEP 1: configuring the RoboCup environment
Executing the setenvvar.bat
file in a command prompt configures the RoboCup game environment by setting up the necessary environment variables.
Environment variables set by setenvvar.bat
file are only valid for commands started in the same command prompt session in which the file is executed, implying that the value of environment variables are set only for the current session. This means that when you close cmd.exe you will loose the changes. Typically, for successful game simulation you need four command prompts: one for the soccer server, two for starting teams, and one for starting the monitor; for each of the command prompts you need to execute the setenvvar.bat
file.
If you would like to permanently configure the environment and make changes to the variables persistent, you can find the list of variables that should be configured, together with the instructions on how they can be configured in the appendix.
24

STEP 2: starting the soccer server
After configuring the RoboCup environment it is safe to start the server by simply executing the file startserver.bat
in the command prompt.
Please note that if you did not configure the environment as specified in the step 1, the soccer server will start anyway but you will experience quite strange behavior from the robots.
STEP 3: starting two competing teams
Assuming that you have started the server and want to test your scheduler, which you have previously written and compiled, then you need to connect the teams that will play the game, by executing the startteam1.bat
and startteam2.bat
.
Executing these file results in starting the teams.
If you would just like to run the default schedulers, to see how they play and the system works, before you implement your own schedulers you need to edit the .bat
files and make sure that default schedulers are specified in both of them.
Each of the .bat
files contains a command for starting one of the teams. For example command: java soccorob.SoccoRob -simulator -teamname DAREDEVILS
-scheduler rt.SchedulerName -serverhost "127.0.0.1"
-init c: \ programs \ RoboLab \ settings \ init2.txt
, would result in executing a scheduler with the name SchedulerName on the local computer. The following is a description of arguments that can be used when starting the teams.
-simulator argument is needed when you are using a simulator instead of the physical scenario of the RoboCup.
-teamname XXX is used to specify the team names.
XXX is the name of your choice. Observe, however, that two teams must have different names.
-scheduler rt.SchedulerName
is an optional argument. If no scheduler is specified, a default scheduler based on cyclic scheduling policy is used. It is necessary that you specify the full path of the class, e.g., if you want to specify the reference EDF scheduler EarliestDeadlineFirstSchedulerRef from package soccorob.rt
you have to explicitly specify:
-scheduler soccorob.rt.EarliestDeadlineFirstSchedulerRef
.
The reference schedulers, against which you can test your scheduler, are located in directory C: \ programs \ Robolab \ soccorob \ rt .
25

disconnect from server connect to server start the game
Figure 6: The menu of the monitor
-serverhost [IP address] is also an optional argument, and is used for specifying the IP address on the machine where the soccer server is started. If nothing is specified, it assumed that the soccer server is located on the same machine. You can use this option to play with each other.
-init [settingFile] specifies the location of the file containing the settings used by the simulation.
STEP 4: starting the monitor
To start the game and to observe what happens on the field, you have to do the following.
• Start the monitor by simply executing monitor.exe
from the directory
C: \ programs \ Robolab \ monitor . Resize the window area occupied by the monitor to be approximately 600 x 500. It is necessary to resize the window so that the processing power that CPU gives to the monitor does not influence the processing power given to the rest of the running system.
• Connect to the soccer server using the first menu button from left (see figure
6). A pop-up menu will appear, and you have to specify the IP address of the server. Typically the server is running on the same computer, and the IP address you need to input in that case is 127.0.0.1.
• Start the game using the third menu button from the left (see figure 6).
To stop the game, you need to brutally kill the server process (CTRL+C). To restart the game, you need to restart the server, and then do the above steps again.
If you kill one of the teams, you have to restart the server and both teams.
26

The second menu button from left disconnects you from the server. You typically need to use it if you restarted the soccer server.
27

This appendix gives a list of environment variables that should be configured for RoboCup game simulation, and an example of how you can set the environment variables in Windows 2000. Additionally, details about installation of the
RoboCup lab environment are discussed at the end of the appendix.
RoboCup environment variables need to be configured before you can actually start the game simulation, i.e., you have to specify a number of directory paths in the CLASSPATH , PATH , and HOME variables, as follows:
• In CLASSPATH you have to add the following directory paths: c: \ programs \ Robolab c: \ programs \ Robolab \ sim \ K-agent c: \ programs \ Robolab \ sim \ K-coach z: \ robolab
• In PATH you have to add the following directory path: c: \ programs \ Robolab \ lib c: \ programs \ Robolab \ settings c: \ Program Files \ Java \ jdk1.5.0_03
\ bin
Note that the path to Java, as well as the Java version, on your machine can differ form the path and the version given here (due to Java updates or sometimes different placement of files on each individual machine). Therefore, before setting the path to Java first check on your machine where Java can be found, and then set the path accordingly.
• In HOME you have to add the following directory path: c: \ programs \ Robolab \ rcssserver
Variable configuration using Windows 2000 GUI is done by first right-clicking on "My Computer", then clicking on "Properties", followed by a click on "Advanced", and a click on "Environment Variables". Once the "Environment Variables” tab is reached CLASSPATH , PATH and HOME variables can be chosen and modified; changes to these variables are made permanent by clicking on "Ok”.
Note that the changes to the variables are visible only in command prompts started after the change.
RoboCup Installation on PCs The RoboCup lab environment is pre-installed on the PC machines in the lab rooms at IDA, in the C: \ programs \ Robolab directory. The RoboCup lab environment is open source, in the sense that all
28

the souce files (except the reference schedulers), are available for viewing. If you are interested in looking into how different parts of the lab environment are programmed, you can find the sources in C: \ programs \ Robolab \ src directory.
29

[1] Alan Burns and Andy Wellings.
Real-Time Systems and Programming Languages . Addison Wesley, third edition, 2001.
[2] Robot world cup soccer games. http://www.robocup.org/.
30