rattracker - a functional-reactive approach to flexible control of behavioural conditioning...
TRANSCRIPT
Diploma Thesis
RatTracker
A Functional-Reactive Approach to
Flexible Control of
Behavioural Conditioning Experiments
submitted by
Clemens Oertel
Wilhelm-Schickard-Institute for Computer Science at the University of Tübingen
and
medimod pharmacology services GmbH, Reutlingen
Submitted May 2nd, 2006
Supervised by Prof. Dr. Herbert Klaeren and Prof. Dr. Jochen Wol�gramm
A copy of this work can be obtained at
http://download.oertel.ch/university/diploma_thesis.pdf
Copyright c©2006 by Clemens Oertel. This material has been released under
and is subject to the terms of the Common Documentation License, v.1.0, the
terms of which are hereby incorporated by reference. Please obtain a copy of the
License at http://www.opensource.apple.com/cdl/ and read it before using
this material. Your use of this material signi�es your agreement to the terms of
the License.
THE DOCUMENT IS PROVIDED 'AS IS' BASIS, WITHOUT WARRAN-
TY OF ANY KIND, AND THE COPYRIGHT HOLDER EXPRESSLY DIS-
CLAIMS ALLWARRANTIES AND/OR CONDITIONSWITH RESPECT TO
THE DOCUMENT, EITHER EXPRESS, IMPLIED OR STATUTORY, IN-
CLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND/
OR CONDITIONS OF MERCHANTABILITY, OF SATISFACTORY QUAL-
ITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF ACCURACY, OF
QUIET ENJOYMENT, AND OF NONINFRINGEMENT OF THIRD PARTY
RIGHTS.
Attributed source code, included in this document or contained in separate
�les, is distributed under the term of the GNU General Public License version 2.
It may be redistributed and/or modi�ed under the terms of the GNU General
Public License as published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version. A copy of the GNU General
Public License may be found at http://www.gnu.org/copyleft/gpl.html.
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich diese Arbeit selbstständig verfasst und keine ande-
ren als die angegebenen Quellen und Hilfsmittel benutzt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch
noch nicht verö�entlicht.
Tübingen, den 2. Mai 2006 Clemens L. Oertel
Contents
1 Introduction 1
1.1 Conditioned Avoidance Response (CAR) . . . . . . . . . . . . . . 1
1.1.1 CAR Control Systems . . . . . . . . . . . . . . . . . . . . 6
1.2 Motivation for RatTracker . . . . . . . . . . . . . . . . . . . . 7
1.3 A User's Expectations . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Requirements & Task . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Technical Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Environment 13
2.1 CAN Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Shuttle Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Activity Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Integration of RatTracker . . . . . . . . . . . . . . . . . . . . 17
2.4.1 E�ect Devices . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Software Background 23
3.1 Functional Programming . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1 The Other Side: Imperative Languages . . . . . . . . . . 24
3.2 The Language Haskell . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Why Haskell? . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Functional Reactive Programming . . . . . . . . . . . . . . . . . 30
3.3.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Technical Remarks . . . . . . . . . . . . . . . . . . . . . . 32
3.3.3 Why FRP? . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 YaMPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 Why YaMPA? . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Implementation 37
4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Data �ow . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Experiment Description Language . . . . . . . . . . . . . . . . . 38
iii
iv CONTENTS
4.2.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 Condition Expressions . . . . . . . . . . . . . . . . . . . . 43
4.2.3 Statements . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Initialization & Con�guration . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Experiment Description . . . . . . . . . . . . . . . . . . . 46
4.3.2 System Con�guration . . . . . . . . . . . . . . . . . . . . 47
4.4 Data Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.1 Data Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.2 Simulation Modules . . . . . . . . . . . . . . . . . . . . . 54
4.5 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.1 Position Tracking . . . . . . . . . . . . . . . . . . . . . . . 55
4.5.2 Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6.1 E�ects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.6.2 Graphical Output . . . . . . . . . . . . . . . . . . . . . . 73
4.6.3 Output Files . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.7 Runtime Con�guration . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.1 Technical Con�guration . . . . . . . . . . . . . . . . . . . 76
4.7.2 Trial Con�guration . . . . . . . . . . . . . . . . . . . . . . 77
5 Experiment 79
5.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6 Conclusions 85
6.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1 Functional Reactive Programming . . . . . . . . . . . . . 86
6.2 What have we learned? . . . . . . . . . . . . . . . . . . . . . . . 87
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Bibliography 97
List of Figures 99
User Manual, in German 101
Chapter 1
Introduction
In this thesis we1 present a computer-assisted control system, called
RatTracker, for the description, control and monitoring of behavioural an-
imal experiments. Unlike systems that are already available, RatTracker
combines two main functionalities into one system: high-resolution analysis of
the test subjects' locomotion paired with direct and automated control of the
conducted experiment. Further distinguishing features of the system include
a �exible and extensible experiment description language, interfaces tailored
to di�erent user-skill levels, and adaptability to new hardware components for
both in- and output. A technical novelty is the use of the funtional reactive
programming paradigm, a programming technique often used in user interfaces
and robotics.
We show how RatTracker was integrated into an existing environment of
experiment apparati and how external e�ect devices such as signal lights are
controlled by our system. In order to verify the practicality, reliability and
usability of our system, we also conducted a speci�c behavioural experiment,
a conditioned avoidance response (CAR) experiment, under normal laboratory
conditions.
1.1 Conditioned Avoidance Response (CAR)
The conditioned avoidance response method (also referred to as traumatic avoid-
ance response in the literature, e.g. [1]) is used primarily in learning and memory
experiments on animals (e.g. [2, 3]). In CAR experiments, similar to Pavlovian
learning[4], an animal learns to associate an originally neutral (conditioned)
1In North America, it is considered good practice to honour one's supervisors by writing athesis in �rst person plural.
1
2 CHAPTER 1. INTRODUCTION
stimulus2 with an aversive (unconditioned) one3, which is presented shortly af-
ter the conditioned one[2]. This association allows the animal to respond to
the conditioned stimulus before the aversive stimulus is presented in order to
avoid the aversive one.
An early explanation of CAR relies on the �ndings that fear, or anxiety, can
be learned or conditioned[4, 5]. Fear has been described as the anticipation of
traumatic or painful events[6]. At the end of the 19th century, the dominating
opinion was that fear is instinctive, or ideopathic, as claimed for example by
James[7] in 1890. Studies and publications in the early 1900s however, showed
that at least in part, an individual's fears depend on his or her own experiences.
One example of this is Watson's[8] experiments which showed that infants' fear
of loss of support or loud sounds was based on their previous experiences.
Freud explained that anxiety is �the expectation of the trauma on the one
hand, and on the other, an attenuated repetition of it�, anxiety is therefore
�undeniably related to expectation, one feels anxiety lest something occur�[5].
According to Freud[5], the unconditioned stimulus will thus become a �danger
signal� that triggers anxiety; an animal tries to react to this anxiety with a be-
haviour which reduces the anxiety most e�ectively. Miller[9] provided empirical
support for this hypothesis of anxiety reduction by showing that rats learned
new habits to escape an environment that had previously been associated with
aversive stimuli, even if no such further stimuli were presented. Mowrer[6] sum-
marized:
In short, anxiety (fear) is the conditioned form of the pain reaction,
which has the highly useful function of motivating and reinforcing
behavior that tends to avoid or prevent the recurrence of the pain-
producing (unconditioned) stimulus.
The concept of �conditioned fear� and its neurobiological background are still
subject to active research (e.g. [10]).
Today fear is not the only explanation being discussed for CAR. Already
in the 1960s reinforcement learning was introduced as a possible explanation
for conditioned avoidances ([11] cited after [12]) and has been a candidate ever
since ([13, 14]). According to this approach, the aversive shock leads to a pos-
itive reinforcement4 of the avoidance. A survey of recent publications (using
PubMed) indicates that the underlying mechanisms of conditioned avoidance
response are not yet fully understood.
2I.e. a stimulus that does not trigger a similar response in untrained animals.3I.e. a stimulus that triggers similar behaviour in untrained animals.4The terms negative reinforcement and positive reinforcement do not describe whether
a stimulus is pleasant (i.e. �positive�) or aversive (i.e. �negative�), but whether the stimulusincreases of decreases the occurrence rate of a response.
1.1. CONDITIONED AVOIDANCE RESPONSE (CAR) 3
The CAR method was �rst applied to rats in the early 1930 by Warner[2]
and is still in use today (e.g. [15]). It has also been used in experiments with
other animals, such as mice[3], gold�sh[16], dogs and monkeys[17].
Applications
The CAR paradigm is used as a general method for learning and memory re-
search. Some examples are acquisition and extinction of memory (e.g. [2, 18]),
short and long term memory[3], learning enhancement e�ects of drugs (e.g. [19])
or genetic in�uence on learning and memory[20]. A number of measurements
may be used for analyzing an animal's response, including
1. How fast did the animal learn to avoid the aversive stimulus (e.g. [21])?
2. How often did the animal successfully avoid the aversive stimulus
(e.g. [21])?
3. How long does the animal show an acquired avoidance behaviour upon
the conditioned stimulus, even if no aversive stimulus follows on failure
to avoid, i.e. how quickly does the conditioned response become extinct
again (e.g. [1])?
4. How quickly did the animal respond to the conditioned stimulus (e.g. [22])?
5. How often did the animal show spontaneous avoidance behaviour without
being presented the conditioned stimulus (e.g. [1])?
The CAR method has been shown to be useful useful for screening sub-
stances for antipsychotic e�ects: In various studies (e.g. [15, 17, 23]) a positive
correlation between the administration of antipsychotics and a selective sup-
pression of the acquisition of the avoidance response could be shown. Under the
in�uence of such a substance, the animal would show less avoidance responses,
but still try to escape the aversive stimulus itself like an untreated animal. The
discussion of the interpretation of these results and the rationale, however, is
still ongoing[24, 25]. The use of the CAR method has also been suggested for
anti-Parkinson drug research[26], but the results are inconclusive as recent publi-
cations indicate (e.g. [27]). Recently, the CAR method was used for behavioural
phenotyping of animal strains (transgenic and knockout mice)[28, 29], reviewed
in [30].
Procedure
As described above, the general idea behind CAR experiments is that the animal
has to show active avoidance behaviour in order to not experience an aversive
4 CHAPTER 1. INTRODUCTION
(unconditioned) stimulus. This active behaviour is a response to a normally
neutral (conditioned) stimulus, which the animal is to learn in the course of
the experiment[2]. We describe a traditional trial procedure as introduced by
Warner[2] and re�ned among others by Levine and Broadhurst[31] using rats
in two-compartment boxes with a crossable barrier (i.e. shuttle boxes, a more
detailed descriptions of these boxes follows shortly).
Trial Run. A rat is placed in any of the two compartments of a shuttle box.
After a certain amount of time t1, the rat is presented the conditioned stimulus,
usually a light (e.g. [20]) or a buzzing sound (Salmi et al.[32] used white noise at
70dBA). t1 can either be a randomly chosen interval (often a value between 15
to 60 seconds is used, see for example [2, 19, 33]) or an interval of �xed length
(see for example [21]). The rat is now given a certain amount of time t2 (about
10 seconds, see for example [32, 33]) to move into the other compartment. The
rat can now behave in two ways[2]:
• If the rat passes through the opening in the separating wall within this
time, the conditioned stimulus disappears and no further consequence oc-
curs.
• If the rat fails to shuttle to the other compartment within the given time,
it will be administered the unconditioned stimulus (footshock) in addition
to the ongoing conditioned stimulus (e.g. sound or light). The aversive
nature of the footshock normally causes the rat to try to escape it.
� If the rat then passes through the opening while being shocked, the
footshock and the conditioned stimulus will be turned o� immedi-
ately.
� If the rat does not move to the other compartment within some time
t3 (usually 10 to 60 seconds[19, 34]), the stimuli will be turned o�.
After the stimuli have been turned o�, the next iteration begins with a short
recovery period followed by the conditioned stimulus and so on. A schematic
representation of the CAR procedure can be found in Figure 1.1.
The rat's response can be classi�ed as a) avoidance if the rat shuttles while
being presented the conditioned stimulus, b) escape if the rat shuttles during
the footshock, or c) failure if the rat fails to switch compartments during the
stimuli presentation[2, 15].
Shuttle Boxes. Conditioned avoidance response experiments are often con-
ducted in shuttle boxes5, in which the rat can shuttle between two compartments5The experimental setup may vary among experimenters, the given description primarily
represents the setup used for this thesis.
1.1. CONDITIONED AVOIDANCE RESPONSE (CAR) 5
Figure 1.1: CAR procedure
(e.g. [2, 31, 35]). These boxes are usually of rectangular shape, with a �oor area
of approximately 50cm to 60cm in length, 20cm to 30cm in depth and 20cm to
30cm in height (e.g. [32] or [34]). In the middle of the longitudinal side, the
box is divided into two equally sized compartments by a crossable barrier. For
example, such a barrier can be a full-height wall with a hole (e.g. [20]) or a
surmountable wall of about the animal's height (e.g. [1] using dogs or [33] using
rats) � the animal can freely switch compartments, but those switches will be
noticed as switching by the animal. The material of the shuttle boxes is usually
transparent, for example Plexiglas (e.g. [20, 32, 34]). An example for shuttle
boxes as used by Salmi et al.[32] is depicted in Figure 1.2 on page 7.
With these boxes, a mechanism is used to determine which compartment
the rat is residing in. This mechanism could be a tiltable �oor with switches
to record the tilts caused by the rat's weight (e.g. [20, 34]), photo sensors along
the longitudinal side (e.g. [32]) or a video camera installed above the box.
A source for the conditioned stimulus, for example a light bulb (e.g. [20])
or a speaker (e.g. [32]), is usually mounted on the lid of the box or above the
box. As unconditioned stimulus, a footshock that is implemented as an electric
metal grid as �oor is often used (e.g. [20]).
Variations. In the past century, various alterations of the schedule developed
by Warner have been suggested (refer to [16] for a tabular comparison). Hunter
devised a procedure in which the aversive stimulus (the shock) would terminate
6 CHAPTER 1. INTRODUCTION
independently of the animals response to it[36].
Sidman develop the so-called continuous conditioned avoidance method, in
which the animal must press a lever at certain intervals in order to avoid being
shocked and is given no warning signal prior to the shock[37]. He later extended
this method by adding a light as conditioned stimulus[22]. Sidman referred to
the two variations as nondiscriminated versus discriminated avoidance. Yet
another method was described by Sidman, the anxiety avoidance procedure,
where no avoidance was possible once the conditioned stimulus came on[38].
Conditioned avoidance experiments can be conducted as either Pavlovian
trace- or delay-conditioning (see for example [1] and [39]). In the former, the
conditioned stimulus is presented only brie�y and turned o� before the onset
of the unconditioned stimulus. In the latter, the conditioned stimulus is main-
tained until the onset or even until the o�set of the unconditioned stimulus.
With respect to learning speed, the delayed method has been reported superior,
for example by Brush et al.[21].
Parameter Optimums. Much e�ort has gone into determining the optimal
parameters for CAR experiments (e.g. [1, 33, 39, 40]). In these studies, it was
shown that the experiment's parameters can in�uence the animals' learning
process. Behrend and Bitterman[40] reported a positive correlation between
the interval and the rate of avoidances for gold�sh using delay-conditioning.
Kamin[1] found that trace-conditioned dogs show better performance for shorter
intervals. Brush et al.[21] found no signi�cant relevance of the interval for the
range from 5 to 20 seconds, and Church et al.[39] claimed that the interval is
irrelevant for speed of acquisition. The intensity of the aversive, unconditioned
stimulus is also of importance[41]: A stronger shock has been reported to result
in a higher avoidance rate. A comparison of studies on di�erent test subjects
shows that the e�ects of parameter values vary among species (see for example
[1], [17] and [40]). Van Gaalen and Steckler[42] as well as Bovet et al.[3] also
reported optimal parameters to be strain dependent. Bauer[43] showed that
rats' avoidance behaviour acquisition is dependent on gender and age.
1.1.1 CAR Control Systems
In their conditioned avoidance studies with gold�sh in the early 1960s, Horner
et al. used hard-wired electronic circuits to control the experiments[16]. In
order to alter the experiment schedule, switches had to be �ipped, therefore the
operator needed at least a basic understanding of electronics in order to change
experiment settings.
To perform CAR experiments, Salmi et al.[32] developed a computer-control-
1.2. MOTIVATION FOR RATTRACKER 7
Figure 1.2: CAR setup from Salmi et al. using 4 photo sensors for each com-partment, taken from [32]
led apparatus which used photo sensors for detection of a rat's location (see
Figure 1.2). Their setup consisted of 4 horizontally mounted photo cells on
each side of the dividing wall which determined the rat's position. They do not
describe the used software or rat box to PC connection in further detail.
Wadenberg et al.[34] returned to using microswitches, claiming more reliable
measurements than the ones obtained with photo sensors (see Figure 1.3). The
connection of the boxes to the controlling computer was done via a multi-port
digital I/O card. National Instruments' (Austin, Texas, USA) software
package LabView was used to control and monitor the experiments. Their
setup is not susceptible to false positives caused by the rat's tail, a common
source of misinterpretation when using photo sensors when only a small number
of sensors and a single layer of sensors are used. However, due to the use of
microswitches, their setup only allows for distinguishing which compartment the
rat resides in but not for determining the precise location of the rat.
1.2 Motivation for RatTracker
The need for automated conduction of many behavioural experiments such as
conditioned avoidance response is obvious. Experiments based on the CAR
paradigm require very quick response times. It is necessary to ensure that
a rat does not experience any aversive stimulus even if it crosses the barrier
only milliseconds before the time granted for crossing runs out; one wrongly
administered aversive stimulus can undo all learned behaviour and thus make
8 CHAPTER 1. INTRODUCTION
Figure 1.3: CAR setup from Wadenberg et al. using a tiltable �oor with mi-croswitches, taken from[34]
the experiment inconclusive[18]. Therefore, external reactions in response to
a rat's behaviour must happen immediately6 and consistently. Furthermore,
experiments might run over a long period of time.
When looking at systems to conduct behavioural experiments such as CAR,
one can identify two major groups each of which focuses on di�erent aspects of
the experiments:
• Control systems. The �rst type focuses on the control of such experi-
ments. Such systems actively intervene with the experiment over its course
and interact with the test subject. However they only allow for a limited
resolution of the recorded data, i.e. with respect to CAR experiments of-
ten only �rat is in the left or in the right compartment� data is available.
The systems described by Salmi et al.[32] or Wadenberg et al.[34] fall into
this category.
• Acquisition systems. The second kind of system is meant for recording
the animal's movements and actions in greater detail, and thereby allows
for conclusions about the animal's behaviour. One example for such a
system are activity boxes that are commercially available and track the
animal's position at high resolution by means of photo sensors or video
cameras. Those systems usually do not provide for direct and automated
interaction with the test subject.
As the CAR procedure requires interaction with the animal, control systems are6Here: immediately in terms of neurobiology, that is within tens of milliseconds (personal
communications with Prof. Wol�gramm).
1.2. MOTIVATION FOR RATTRACKER 9
typically used. To our knowledge, all currently available CAR-capable systems
allow recording of only the compartment the rat is residing in, due to their use
of either microswitches or a limited number of photo sensors. One can easily
imagine, however, circumstances that would make greater resolution desirable.
For example, as we realized in personal discussions prior to experiments, one rat
might remain sulkingly sitting in a corner when the conditioned stimulus occurs,
whereas another rat may run around in the compartment looking for a way to
avoid the footshock but does not �nd one. Traditional setups such as the ones
described by Salmi et al.[32] and Wadenberg et al.[34] are not able to distinguish
between these two behaviours, as neither rat switches compartments. The main
incentive to develop RatTracker was to combine the functionality of control
systems with that of acquisition systems.
Furthermore, as seen in the above description of the conditioned avoidance
response procedure, experimental parameters, such as the interval between the
two stimuli, must be easily adjustable. This is especially the case since the opti-
mum for the parameters can depend on strain, gender or age, and the system's
settings may therefore have to be changed frequently. The great variety of the
CAR methods (for example trace versus delay or nondiscriminated versus dis-
criminated avoidance) necessitates a control system with �exibility beyond the
simple adjustment of timing parameters as well.
Ultimately, a number of requirements that are not present in any available
system we know of, led to the development of RatTracker.
1. Primarily, we needed a system that combines the features of both kinds of
systems mentioned above: the ability to interact directly with the animal
in an automated fashion as well as the ability of a high-resolution recording
of the animal's movement so that its behaviour can be analyzed in detail.
2. A �exible experiment layout with the ability to adjust all parameters is
desirable. The behaviour of rats, which are our primary test subjects,
strongly depends among other factors on strain, gender, age, handling
and housing. It is thus mandatory that all aspects of an experiment setup
can be adjusted to meet these di�erences among rats.
3. A system for use under laboratory conditions must primarily re�ect the
needs of the researchers and the operating sta�.
4. Given the cost of CAR apparati (tens of thousands of euros), laboratories
want to be able to use the tracking boxes for multiple types of behavioural
experiments, such as CAR variations or CAR unrelated procedures.
Using shuttle boxes with a high-resolution photo sensor setup will allow us to
determine the rat's overall activity and locomotion, its precise position during
10 CHAPTER 1. INTRODUCTION
the entire course of the experiment and whether a rat tries to escape or avoid
a shock by jumping up or standing up. This information allows us to come to
more detailed conclusions about the rat's behaviour.
1.3 A User's Expectations
Any computer-based system is only as good as a user perceives it. This is
especially the case in a laboratory application, where operators normally do not
have special IT training and therefore, a simple and intuitive mode of operation
is a must.
Three di�erent classes of users can be identi�ed:
1. Users responsible for the hardware setup (�administrators�).
2. Users concerned with experiment layouts (�researchers�).
3. Users conducting the actual experiments (�conductors� or �operators�).
Each user class brings a di�erent level of technical understanding and must
therefore be treated di�erently. An administrator can be expected to have
certain computer-related background knowledge. Researchers have ample expe-
rience in their scienti�c domain and want to be able to interact with a system
in terms of this domain. Conductors have to work under tight time constraints
and want to use a computer system as a mere tool such as a scale � thus they
need a clean, intuitive and pragmatic interface.
Much of the laboratory control software we encountered in the last months
shows many shortcomings when it comes to usability. Administrators cannot
tune the software to cope with changed hardware setups, researchers have to
twist their brains in order to express their experiments in the terminology and
syntax imposed by the software system, and conductors are overstrained by the
buttons, and the knobs, and the �elds, and the sliders, and all the other elements
of the user interface. All these shortcomings inescapably lead to ine�ciency and
mistakes.
1.4 Requirements & Task
The scope of this thesis is to describe, develop and test a reliable software
system that controls the conduction of behavioural experiments. This system is
to continuously receive information about a test animal's position, and interact
with the animal according to rules speci�ed by the user. The recording of the
animal's position and movement is done by a secondary software system that is
not part of this thesis.
1.5. TECHNICAL OVERVIEW 11
The following requirements are imposed upon the system:
• The system must provide the means to specify the layout of di�erent exper-
iments in a �exible and appropriate manner. The experiment descriptions
should be readable and their structure should not deviate too much from
verbal descriptions.
• The system must integrate into the existing setup of photo sensor boxes
and recording equipment.
• The system must reliably and consistently react to input within certain
time constraints.
• The system must record all of the animal's actions of interest and all
reactions it performs itself.
• It must be possible to combine the recorded actions and reactions with
the recording of the animal's position in order to associate movement with
the according actions.
• The user must be able to de�ne conditions for early aborts of the experi-
ment.
• The transformations performed on the data must be traceable and well
de�ned (for example: how does the system determine the rat's position?).
The behaviour of the system in cases of ambiguous input data must be
well de�ned (i.e. �if you don't know for sure where the rat is, don't assume
anything, just do nothing�).
• The hardware con�guration must be �exible with respect to the number
of shuttle boxes, number of photo sensors etc. Extending the system to
use other input sources for tracking, such as video cameras, should be easy
to implement.
• The interaction with the (experiment conducting) user must be intuitive
and limited to a minimum.
As a concrete example of a behavioural experiment, the conditioned avoid-
ance response is to be realised and conducted to verify the system's functionality
and usability.
1.5 Technical Overview
The system is initialized with a set of rules describing the course of the experi-
ment to be conducted. During execution, it continuously receives raw input from
12 CHAPTER 1. INTRODUCTION
a tracking device from which the animal's position is extracted. The position
information is fed to the rule set where the data and its change over time are
matched against user-de�ned conditions. Depending on the outcome of these
rules external e�ects can be triggered.
Our current setup uses shuttle boxes with two layers of photo sensors as
tracking devices. The boxes are attached over a CAN bus to the controlling
computer. For e�ect devices, our system uses speakers, signal lights and foot-
shock devices.
Please refer to Figure 4.1 on page 39 for a schematic overview of Rat-
Tracker.
Chapter 2
Environment
When the work on this thesis started, the technical environment was already
determined and just being set up. Various aspects of this environment, especially
the choice of protocols and variability in hardware setups, had a profound impact
on the contents of the thesis. The relevant aspects are described in this chapter.
The shuttle boxes and the software for turning them on and o� and for recording
movement data were already designed in cooperation with Hölle & Hüttner
AG (Tübingen, Germany). Their speci�cations and how they in�uence the
integration of RatTracker are described in this chapter.
2.1 CAN Bus
The connection of the shuttle boxes and the control software is done using CAN
technology.
CAN (Controller Area Network) is a serial bus system, which was
originally developed for automotive applications in the early 1980's.
The CAN protocol was internationally standardized in 1993 as ISO
11898-1 and comprises the data link layer of the seven layer ISO/OSI
reference model. CAN [. . . ] provides two communication services:
the sending of a message (data frame transmission) and the request-
ing of a message (remote transmission request, RTR). [. . . ]
The equivalent of the CAN protocol in human communication are
e.g. the Latin characters. This means a CAN controller is compara-
ble to a printer or a type writer. CAN users still have to de�ne the
language/grammar and the words/vocabulary to communicate.1
1From http://www.can-cia.org/can/.
13
14 CHAPTER 2. ENVIRONMENT
Devices (nodes) that are connected over a CAN bus can send each other
messages containing up to 8 bytes of data over this bus. Each message is tagged
with an ID number. The assignment and interpretation of these ID numbers is
left to the user, with two main exceptions:
• All nodes on a CAN bus are equal (multi-master hierarchy). The priority
of message is determined on a per-message-pair basis by comparing the
messages' IDs.
• A message ID of 0 denotes a network management telegram (NMT) used
to send start- and stop-messages to devices attached to the bus.
Depending on the length of the bus, the transmission speed of the bus can
be up to 1 megabit per second.
Please note that the characteristics of the CAN technology are described in
only as much detail as needed to read this thesis, for further in-depth information
refer to http://www.can-cia.org/.
Why CAN Bus? The decision to use the CAN technology was made by
Hölle & Hüttner AG who provided the shuttle boxes. It was chosen for
communication between the boxes and the control systems for a number of
reasons:
• An arbitrary number of boxes can be attached to the bus, and multiple
computer systems used for controlling and monitoring purposes may also
be attached to the bus.
• The boxes are connected in series, not in parallel. This reduces the amount
of used cables and thus the risk of faulty wiring.
• Message IDs can be used to convey additional data such as the originating
box of a message.
• Messages can be prioritized to ensure faster transmission for more impor-
tant messages.
2.2 Shuttle Boxes
The initial setup consists of a battery of up to 12 custom-built shuttle boxes.
The boxes are connected to a computer running control software responsible
for starting and stopping the boxes and for recording the rats movements; the
software for these tasks is referred to as activity monitor (see �2.3).
Each box has two frames of photo sensors in the default con�guration, of
which each has 40 sensors along the X- and 40 sensors along the Y-axis (see
2.2. SHUTTLE BOXES 15
Figure 2.1: Shuttle box viewed from front with supporting cage and 2 layersof photo sensor bars (the sensors are mounted on the inside of the middle twovertical bars on each side, the top and bottom vertical bars are for stabilizationonly)
Figures 2.1 and 2.2). A single box thus features 160 photo sensors in total.
The two frames are connected to a controller device attached to the box that is
responsible for triggering the sensors' reading at given intervals and sending the
sensors' data to the activity monitor. It is possible to move photo sensor frames
among boxes, therefore the number of two frames per box is not �xed; however,
the controllers can only handle two frames each, therefore multiple controllers
might be needed for a single box if it has more than two frames.
Just as in other systems, our boxes allow us to determine which compartment
the rat is residing in. However, due to the high resolution of our sensor layout,
we are also able to monitor aspects of the rat's behaviour, such as locomotion,
precise position and whether the rat is standing up.
The boxes are connected in series, with one end of the chain being attached
to the activity monitor system which will be described in the next section. The
CAN protocol is used to regulate the communication of multiple nodes (the
boxes' controllers and the activity monitor) over a single bus. As mentioned
above, the CAN protocol is message based. Each message is assigned a message
id, a number that is used to determine the message's priority and it's sender.
16 CHAPTER 2. ENVIRONMENT
Figure 2.2: CAR box with supporting cage, 2 layers of photo sensor bars ande�ect devices in box lid (viewed from top)
Each box is assigned a unique ID number starting at 1. Those numbers
are used to indicate the origin of the CAN messages by including them in the
message IDs as the last octal digit. The messages originating from box number
7 for instance carry messages such as 0x187.
Every box controller has a 24ms cycle, that is every 24ms a controller samples
all photo sensors and sends the combined data over the bus to the activity
monitor as a sequence of CAN messages. The sensors' states are sent as a
bit string, with one bit representing one sensor, a 1 meaning sensor's ray is
interrupted. Those interruptions are caused as objects in the rat box block the
rays of the sensors and thus cast shadows. The shadows appear as successive
1s in the conveyed data. With 160 sensors per box, 20 bytes of data need to
be transmitted in every cycle, or 3 CAN messages of 8 bytes each (4 bytes are
unused). The lower frame is represented by the �rst 10 bytes, the upper frame
by the last 10 bytes. Within each of those two 10 byte blocks, the sensors along
the Y-axis (given from back to front) occupy the �rst 5 bytes, the ones along
the X-axis (given from left to right) the last 5. The distribution of the data over
multiple CAN messages is illustrated in Figure 2.3.
A common problem with photo sensors mounted closely to one another is
that one sensor's ray may not only be received by its own receiver, but also
2.3. ACTIVITY MONITOR 17
lower frameY−axis sensors 1 − 40X−axis sensors 1− 40 Y−axis sensors 1 − 40X−axis sensors 1− 40
upper frame
5 bytes 5 bytes 5 bytes 5 bytes
CAN message 1 CAN message 2 CAN message 3
4 * 40 bitssensor data
Figure 2.3: Distribution of sensor data over multiple CAN messages
by adjacent ones. This problem is avoided by polling the sensors of each frame
sequentially, one after the other. Therefore, even if a ray hits additional receivers
by mistake, this is without consequence as those receivers will not be active at
that moment. Another possible problem is interference between sensors of the
two frames. Even though one frame's sensors are sampled sequentially, rays
may hit receivers in the other frame that could be read at this very moment by
chance. To prevent such interferences, adjacent frames are mounted with a 180
degree shift � one frame's senders is facing the other frame's sender, not its
receivers.
2.3 Activity Monitor
The boxes are controlled by the activity monitor software supplied by Hölle &
Hüttner AG. It allows the user to start and stop the sampling of the sensors
and to monitor the sensors' states, i.e. areas of ray disruption.
In the context of conducting experiments, the activity monitor is used to
select the participating boxes and the experiment's duration. Upon start of the
experiment, the activity monitor sends a start message to each selected box (an
NMT message). Once the experiment is �nished, it sends the corresponding
stop message. During the experiment, the activity monitor sends messages with
timestamps over the bus to allow other computer systems that might be attached
to operate synchronously with the activity monitor. The software also records
all changes in the sensors' states to log �les and to a database.
The activity monitor does not directly react to the rat's behaviour or change
the rat's environment during experiments.
2.4 Integration of RatTracker
The RatTracker system is designed to handle di�erent kinds of behavioural
experiments, with CAR just being one example. The integration of Rat-
Tracker into the given environment of boxes and activity monitor is therefore
designed to be independent of any particular kind of experiment. RatTracker
taps into the communication between the boxes and activity monitor and uses
18 CHAPTER 2. ENVIRONMENT
the received information to perform the user-speci�ed experiment. The activ-
ity monitor starts and stops the experiments, while the RatTracker controls
what happens to the rat during the experiments.
To interact with the rat and to alter its environment, RatTracker can
make use of various attached e�ect devices (e.g. signal light or buzzer, see be-
low) that it controls. Communication with these devices happens over a sep-
arate CAN bus comprised of the RatTracker system and the e�ect device
controllers.
The RatTracker system listen only on the data-carrying CAN bus that
connects the boxes with the activity monitor, it does not send any message on
this bus to ensure it does not interfere with the activity monitor's operations.
2.4.1 E�ect Devices
E�ect devices, also called e�ectors, are devices that can be used to interact with
the test subject, such as lights, sound devices etc. Every rat box has its own
set of e�ect devices, which are controlled separately.
What kinds of devices are used depends on the experiment to be conducted.
To implement the conditioned avoidance procedure, we currently use three dif-
ferent kinds of e�ects: light, sound and footshocks. The RatTracker system
merely switches them on and o�, whereas the respective settings of each device
(e.g. strength, frequency, etc.) are adjusted on the devices themselves.
Light
As possible conditioned stimulus (see �1.1), the boxes are equipped with two
light sources built into the lid. At 2.2 Watts, these light sources only have
signalling character, they are not strong enough for signi�cant illumination.
Sound
As another possible conditioned stimulus, the boxes also have a speaker embed-
ded in the lid. These speakers are standard built-in computer speakers that were
taken from old PCs. The speakers provide 0.5 Watts at 8 Ohms. A frequency
generator is used to supply the speakers with an input signal to produce a tone
of about 400 Hertzs. Tests conducted at our lab showed that rats respond to
this frequency.
Footshock
As aversive unconditioned stimulus (see �1.1), a footshock device is used. Such
a footshock device consists of two components, a controller and a shock grid
2.4. INTEGRATION OF RATTRACKER 19
����
����������������������������������������������������
����������������������������������������������������
����������������������������������������������������
����������������������������������������������������
� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �
����������������������������������������������������
� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �
FootshockController
ControllerEffector
+ −
18
1 8
CAN−Bus
Figure 2.4: Footshock device consisting of controller and metal grid. The deviceis addressed over a CAN bus with a separate CAN/E�ector controller. Thediagonally striped bars represent currently activated bars.
�oor which is placed in the cage for the rat to walk on.
We use a Coulbourn Instruments (Allentown, Pennsylvania, USA) pre-
cision-regulated controller (device number E13-14). This controller supports
scanned output, that is the grid's bars are divided into sets of 8, and the same
bars of each set are simultaneously active (see Figure 2.4). As the 8 bars are
activated and deactivated in series, a replicated wave of active bars is generated.
The footshock device is controlled by means of a control voltage � the
footshock setup is active i� the control voltage is applied (this voltage only
turns the controller on and o�, the speci�c characteristics of the applied shock
such as frequency are determined by the controller's settings). The e�ect device
controller provides this control voltage upon corresponding input.
CAN Bus Connection
Every rat box has its own e�ect device setup, consisting of a CAN controller to
receive messages, a relay board to adjust currencies and voltages and the devices
themselves (see Figure 2.6). The controllers are connected to the RatTracker
system using a dedicated bus, entirely separate from the bus carrying the photo
sensor data. Each CAN controller can be addressed individually; they carry the
same ID number as their respective rat box.
20 CHAPTER 2. ENVIRONMENT
Similar to the status reports from the box controllers, the messages sent
from RatTracker to the e�ect devices are encoded as bit sequences of 8 bits.
Each device is associated with a certain position in the bit sequence � if that
position holds a 1, the device is turned on, otherwise it is turned o�. Those bit
sequences are sent as CAN messages, and each rat box's set of e�ect devices is
controlled by separate messages. Every message sent to the devices contains the
desired status for all devices associated with one rat box, whether this status
has changed since the last messages or not (this is due to the way in which the
CAN controller maps incoming messages to signals). In the current layout, the
�rst two bits in a message describes the desired state of the two light bulbs in a
box's lid, the 3rd bit refers to the footshock device, and the 8th bit targets the
frequency generator responsible for producing auditory output. The remaining
bits are currently unused.
Example of an e�ect message. A rat box with box number 7 has a foot-
shock as associated e�ect device. The footshock is controlled by the bit at
position p in the outgoing CAN messages. When the footshock is to be turned
on during the experiment, RatTracker sends a message over the dedicated
CAN bus that has a 1 at position p in the bit sequence. The other positions
remain unchanged from the previous message to this device set. To ensure the
footshock device of the correct rat box is turned on, the message has the re-
cipient box's number encoded in the message ID, for example 0x207 (all e�ect
device controlling messages have an ID starting at 0x200). When the targeted
CAN controller receives the message, it sets its digital output channels (of which
it has one for every device) according to the bit values from the message. In
this example, the pth channel's voltage level is switched from high-voltage to
ground, thereby producing a potential di�erence2. The relay board relays this
potential to the footshock controller, which responds to it by turning on the
footshock grid.
Technical Details. The CAN bus controllers3 are responsible for connect-
ing the e�ectors to the CAN bus and thereby to the RatTracker system.
Each controller provides 4 digital output channels (on or o�) and one frequency
output channel. Each of these channels can be turned on or o� by means of
programmable CAN messages4. The controller can gate di�erent voltages on
the output channels using open collectors and pull-up resistors. As the output
2The voltage states may seem to be reversed. However, due to the use of an open collectorwith pull-up resistors, the voltage level corresponding to �o�� is high, not low.
3To control the e�ect devices over the CAN bus, we use Digital 1 controllers by Peak-
System Technik GmbH (Darmstadt, Germany).4Using a software tool, one can program the node controller to turn a channel on or o�
depending on a certain bit in a received CAN message with a certain ID.
2.4. INTEGRATION OF RATTRACKER 21
CANInterface
Light
Sound
Footshock
CAN Controller
Relay Board
Light
Sound
Footshock
CAN Controller
Relay Board
Light
Sound
Footshock
CAN Controller
Relay Board
RatTracker
Rat Box 1 Rat Box 2 Rat Box n
Figure 2.5: Overview of the connection scheme for multiple shuttle boxes' e�ectdevices and the RatTracker system using CAN bus.
channels provide a current of 300 milliamperes at most, another relay step, the
relay board5, is placed between the controller and the e�ect devices. This relay
board allows for gating greater currents by means of relays. It also provides
LEDs for each used channel to indicate whether a channel is active (to facilitate
troubleshooting).
A diagram of the connection scheme for the e�ect devices is shown in Figure
2.5, the actual setup can be seen in Figure 2.6. The circuit layout for the relay
boards is shown in Figure 2.7.
5The relay boards are custom made; design and soldering of them was part of this thesis.
22 CHAPTER 2. ENVIRONMENT
Figure 2.6: E�ect devices of a single shuttle box used to conduct CAR experi-ments, and their CAN bus connection setup.
−
+V1
D1
RL1
Light1
R1
L1
RL2
Light2
R2
L2
D2
Footshock
L3
R3 R5
Sound
R4
L4
Figure 2.7: Circuit of a relay board used to transform the CAN controller'sdigital output into voltages/currents needed by e�ect devices.
Chapter 3
Software Background
3.1 Functional Programming1
Functional programming languages are based on the notion of mathematical
functions. Mathematical functions map a set of values (the domain) to a second
set of values (the range). For example, the function
f : x → x + 1
maps every number x to its successor. One important feature of such functions
is uniqueness: Given the same arguments, a function will always return the
same result. Another distinctive characteristic is that the order of evaluation of
the arguments does not matter:
(1 + 1) + (2 + 2)
evaluates to 6, whether (1 + 1) is calculated �rst or (2 + 2).
Iterative functions are achieved by recursion: In each iteration, a function
performs one calculation step towards the result and has the remaining steps
done by calling itself again with the arguments adjusted accordingly.
Example. A classic example for recursion is the factorial function. The fac-
torial of a number n, written as n!, can be calculated by
n! :=
{1 if n ≤ 1
n · (n− 1)! otherwise
1This section is based on [44].
23
24 CHAPTER 3. SOFTWARE BACKGROUND
This function only performs one of the many multiplications � the remaining
multiplications are done by the following executions of the function.
Functional programming languages follow this concept of mathematical func-
tions closely. Computations are expressed in terms of functions operating on
arguments. Variables do not exist in functional languages2, and iterations are
normally performed by means of recursion. The above recursion example trans-
lates one-to-one into an imaginary functional language:
f u n c t i o n n ! = i f n > 1 then n ∗ ( n − 1 ) ! e l s e 1
With functional programming languages, one tells the computer what to do,
not how to do it (functional languages are also called declarative languages).
In functional languages, functions are �rst-class entities: They can be stored,
passed as arguments to other functions or be returned as the result of a function.
One may even say: Everything is a function, values such as numbers are simply
constant functions.
These characteristic of functional programming languages allow a program-
mer to work in a problem-oriented fashion: The programmer can focus on ex-
pressing the problem at hand at a high level, and does not have to bother with
low-level aspects � she or he can concern her- or himself with how to solve
a problem logically and elegantly instead of the technical details of an imple-
mentation. The fact that functions always return the same value for the same
arguments, called referential transparency, greatly simpli�es the veri�cation of
programs, as single parts of a program can be veri�ed in isolation (due to refer-
ential transparency, functions cannot depend on anything but their arguments).
3.1.1 The Other Side: Imperative Languages
Imperative languages such as C or Basic are tightly coupled to the von Neumann
computer architecture, where both program instructions and data are stored in
memory. Computations are performed by retrieving an instruction as well as
the required data from memory, executing the instruction on the data in the
central processing unit, and writing the result back to memory; computations
are memory modi�cations. Memory access happens explicitly: the instructions
include the memory locations to be read from or to be written to. To a pro-
grammer, this fact is not always obvious as these locations are often referred to
by means of variables.
Storing a value at a memory location (i.e. assigning it to a variable) is a side
e�ect of an expression without a return value:
2Readers unfamiliar with functional programming please note: No �variables� beyond theones introduced by function arguments exist, even though, to be precise, those are boundidenti�ers that cannot be altered within the function.
3.2. THE LANGUAGE HASKELL 25
x = 1
instructs the computer to store the value 1 at the memory location referred to
by x. The assignment instruction itself has no return value (the statement y =
(x = 1) does not make sense3, what should y be afterwards?4). But even after
the actual assignment is performed, the memory location of x still holds the
value 1; the e�ects outlive the expression.
If a later statement then refers to x, such as in
y = x + 1
the �nal value of y will depend on the value held by the memory location referred
to by x. Since the value of x in the above statement depends on whatever
operations were performed on it previously, one cannot predict what value v
will hold without knowing the entire context the assignment is executed in.
3.2 The Language Haskell5
Haskell, named after the logician Haskell B. Curry, is a functional program-
ming language that was designed around 1988[46]. It is a pure functional lan-
guage, meaning there are no variables and no assignment statements6, no side
e�ects and no other imperative features.
Haskell uses lazy evaluation, that is, values are not computed until they
are needed. Consider a rather silly function with two arguments of which only
one is actually used:
−− Inc t a k e s two i n t e g e r s and re turns a t h i r di n c : : I n t −> I n t −> I n t
i n c a b = a + 1
If one calls this function inc with an incomputable second argument, such as
inc 6 (1/0) where a is bound to 6 and b is bound to 1/0, languages using eager
evaluations will fail since they try to evaluate the arguments before calling the
function, and 1/0 cannot be evaluated. Haskell on the other hand does not
evaluate the arguments until they are needed; since the second argument is not
used, it will simply be ignored. Furthermore, the call inc 6 (1/0) does not return
7 as one might think, but 6+1 � which will not be evaluated until the �nal
value is needed.3Here, the symbol = represents assignment, not comparison for equality.4Some programming languages such as C allow such statements, but they are merely
syntactic sugar.5This section is based on [45]6Many functional languages are impure, meaning they have some imperative features such
as variables.
26 CHAPTER 3. SOFTWARE BACKGROUND
It is considered good practice in Haskell to precede each function de�nition
by its explicit signature, given as the function's name and its type separated by
a double colon. inc :: Int -> Int -> Int for example is a function that takes two
integers (the �rst two Ints in the signature) and returns another integer (the
last Int). To be precise, the signature should be read as inc :: Int -> (Int ->
Int), that is, inc is a function that takes an Int value and returns a new function,
which in turn takes another Int value and returns an Int value.
One convenient feature of Haskell, possible because of lazy evaluation, is
inde�nite lists and list comprehensions. As an example of inde�nite lists in the
world outside computers, consider the set of natural numbers: They start with
1, but are unbounded7. However, most users of these numbers do not bother
with this in�niteness, they only concern themselves with an arbitrarily large
yet bounded subset and ignore the in�nite rest. Haskell treats inde�nite lists
similarly: it will only produce as many elements of this list as are needed. A
most simple list of this kind, the natural numbers, is written as [1..] (in contrast,
a bound list of numbers from 1 to 10 would be written as [1..10]). If one needs
an arbitrary amount of number-successor pairs, one can write: pairs = [ (x, x+1)
| x <- [1..] ] � to have a list of the �rst ten pairs, one can then use: take 10
pairs. The notion of inde�nite lists allows the programmer to concern himself
with the bounds where they actually occur in the logical �ow of the program,
if at all.
Another distinguishing feature of Haskell is pattern matching. Instead of
using if-statements to react to special input values, one can deal with those
special values using separate de�nitions. The factorial function, for example,
could be realized in Haskell as follows:
f a c t o r i a l : : I n t −> I n t
f a c t o r i a l 0 = 1f a c t o r i a l 1 = 1f a c t o r i a l n = n ∗ f a c t o r i a l ( n − 1)
Each pattern is tried in order until the �rst matching one is found, and its
de�nition is then used. Identi�ers in the matching pattern are bound to the
current value. factorial 10 for instance produces a match in the third line, so
n will be set to 10. If an argument's value is not needed within the de�nition
belonging to a pattern, one can use an underscore instead of an identi�er name:
i s N u l l : : I n t −> Bool
i s N u l l 0 = True
i s N u l l _ = Fa l s e
7For some people, natural numbers start with 0.
3.2. THE LANGUAGE HASKELL 27
Even more complicated matching is possible using pattern guards. Another,
slightly shorter (but less e�cient) way to write the factorial function is
f a c t o r i a l : : I n t −> I n t
f a c t o r i a l n | n <= 1 = 1| o the rw i s e = n ∗ f a c t o r i a l ( n − 1)
The term n <= 1 serves as guard, ensuring that the expression following the
equal sign is only used when the guard's condition is met. Once a matching
guard is found, its expression is used and no further matching is done. Otherwise
is simply a synonym for True � it always matches (if all the previous guards
failed).
Systems interfacing with the real world, however, have to cope with side
e�ects, for example when dealing with I/O operations, exceptions or stateful
computations. Haskell encapsulates such operations in monads8. Moggi[48]
and Wadler[49] introduced them to programming languages, where they are
used to distinguish between computation and their produced values[50]. Je�
Newbern9 explains10 Monads as follows:
A monad is a way to structure computations in terms of values and
sequences of computations using those values. Monads allow the pro-
grammer to build up computations using sequential building blocks,
which can themselves be sequences of computations. The monad de-
termines how combined computations form a new computation and
frees the programmer from having to code the combination manually
each time it is required. It is useful to think of a monad as a strategy
for combining computations into more complex computations.[...]
The IO monad is a familiar example of a one-way monad in Haskell.
[...] The wonderful feature of a one-way monad is that it can sup-
port side-e�ects in its monadic operations but prevent them from
destroying the functional properties of the non-monadic portions of
the program.
Thus, in using Monads, Haskell disposes of side e�ect tainted operations despite
its purely functional nature by encapsulating them in monads.
Another famous monad besides IO is Maybe:
data Maybe a = Just a| Nothing
8Monads have their origin in category theory, where they are described as the compositionof a pair of adjoint functors[47].
9See http://www.nomaware.com/monads/.10From www.haskell.org: Monads are known for being deeply confusing to lots of people.
28 CHAPTER 3. SOFTWARE BACKGROUND
For instance, a function that returns Maybe String either returns a string or
Nothing. To be precise, it does not return a value of type String but of Just
String, as in Just "foo" � the actual string "foo" has to be extracted using
pattern matching or the fromJust function. One might argue that this is not
much of an advancement over what other programming languages have to o�er,
such as NULL, Void etc. However, using Maybe, a programmer does not have to
check for a Nothing value after every operation
−− A func t i on t ha t a lways re tu rns ' Nothing 'no th i ng_func t i on : : Maybe I n t
no th i ng_func t i on = Nothing
−− A func t i on t ha t a lways re tu rns ' Jus t something 'j u s t o n e_ fun c t i o n : : Maybe I n t
j u s t o n e_ fun c t i o n = Just 1
−− A func t i on t ha t t a k e s an i n t and g i v e s an i n ttimes_two : : I n t −> I n t
times_two a = a ∗ 2
−− Bring a va lue in t o the world o f Maybemaybefy : : a −> Maybe amaybefy x = do r e t u r n x
use_noth ing : : I n t −> Maybe I n t
use_noth ing = noth i ng_func t i on >>= maybefy . times_two
use_something : : I n t −> Maybe I n t
use_something = ju s t on e_ fun c t i o n >>= maybefy . times_two
Both nothing_function and justone_function return a value of type Maybe Int.
times_two is a function that takes an integer as argument and returns an integer.
The maybefy function takes an argument of any kind (hence the type placeholder
a), and returns it encapsulated in a Maybe. The �= operator simply passes the
result of the left-hand monadic function to the right-hand monadic function
(there's more going on under the hood, but this shall be of no concern now).
What happens now is nothing short of magic:
• If the left function produces Nothing (as nothing_function does), the right
side of �= is simply by-passed and the whole expression evaluates to Noth-
ing, without using a single if (a == Nothing) . . . . In the above example,
use_nothing is thus simply Nothing, no matter what function would be
used on the right-hand side.
• However, if the left side produces Just Something (as justone_function
does: Just 1), the value Something (in this example: 1) is passed to the
function on the right-hand of the operator, and the expression evaluates
3.2. THE LANGUAGE HASKELL 29
to the result of this function. use_something produces therefore Just 2
(not only 2, because of maybefy).
Thus, the Maybe monad allows one to describe �no value�-values, and to handle
them transparently.
In Haskell, expressions are not necessarily terminated by semicolons or
by line breaks. In cases where consecutive expressions could cause ambiguity,
indentation is used. A line indented further than the previous line is considered
to be a continuation of that previous line. Type and module names begin with
a capital letter, while function names begin with a lower case letter.
Various compilers and interpreters are available for Haskell, we used
GHC11 Version 6.4.
3.2.1 Why Haskell?
The software part of this thesis was to be researched and written by a single
programmer within strict time constraints. Thus a programming language that
supports the programmer as much as possible seemed appropriate, especially
with respects to writing correct code and minimizing debugging time. We con-
sidered the following characteristics of a programming environment as important
in this context:
• To ensure a certain degree of correctness12 as early in the development
cycle as possible, we believe a static typesystem that attaches types with
names instead of values and performs type checking at compile time is
a must. Type safety must also be ensured by the compiler or the run
time system. In Java for example, many type checks occur at run time,
possibly leading to cast errors and program abortion � since these errors
are only detected at run time, testing and debugging becomes more time
consuming.
• Automatic garbage collection is mandatory.
• The programming language must support modularization with export and
import declarations as well as enforcement of module interfaces. The ab-
straction achieved with module interfaces allows one to devise preliminary
versions of modules at �rst and re�ne them later as need and insight arises.
The implicit documentation of code dependencies and functionalities pro-
vided by a module make it easier to write the system iteratively instead
11See http://www.haskell.org/ghc/.12One might argue that something is either correct or not, and correctness thus has no
degrees. For complex structures such as computer programs, one can easily sub-divide thequestion of a programs correctness into various aspects.
30 CHAPTER 3. SOFTWARE BACKGROUND
of monolithically, a situation not uncommon in one-person projects. Sep-
arately compilable modules result in shorter compilation runs and as such
facilitate easy testing and debugging.
• For communication with external hardware, such as the CAN bus inter-
faces, integration of drivers only available in other programming languages,
especially C, must be easily doable.
• Libraries and tools must be available for various tasks, such as user inter-
faces or parser and lexer generation.
Many programming languages support these features to varying degree, such
asModula, Ada, Eiffel or Haskell (given the number of available program-
ming languages13, this list can obviously not be complete).
We decided to use Haskell to implement RatTracker because among the
languages that meet our requirements, it features the most suitable implemen-
tation of the functional reactive programming paradigm, YaMPA (which will
both be o�cially introduced and accounted for in the following sections). The
decision in favour of Haskell was co-derived with the decision to use functional
reactive programming.
The use of the functional programming paradigm has a further advantage:
The principle of referential transparency allows for easy parallelization, as every
called function only relies on its arguments, but not on a shared state which
would require synchronisation of access. This is especially useful in the case
where the number of shuttle boxes exceeds the computational capacity of a
single-processor installation.
3.3 Functional Reactive Programming
Many computer applications interacting with the real world are most adequately
modelled as reactive systems. Reactive systems continually receive input from
external sources and respond to them, the �ow of control is thus determined by
the outside world as the sequence of input events is not predictable, neither in
occurrence nor in content. Typical domains of such applications are robotics[51]
and graphical user interfaces[52].
Functional reactive programming (FRP)[52] is a paradigm that allows reac-
tive programs to be written in a high-level declarative fashion. FRP is usu-
ally added as an extension to a functional host language, such as Scheme or
Haskell[53]. FRP extends its host language by addings the means to model
13At the time of writing, the website 99 bottles of beer lists 939 di�erent languages, notincluding domain speci�c languages. See http://www.99-bottles-of-beer.net/.
3.3. FUNCTIONAL REACTIVE PROGRAMMING 31
time �ow in order to accommodate reactive systems' use of both discrete events
in time and continuous time-varying values[54], often called �behaviours�14 or
�signals�.
Behaviours are similar to functions and represent values that can be sampled
at any point in time and are updated automatically according to the systems
input. Behaviours can also be thought of as values that are updated automati-
cally and continuously as the behaviours (i.e. values) they rely on change. Using
system-provided behaviours (the nature of available behaviours depends on the
application domain), users can de�ne functions resulting in new behaviours.
Changes to one behaviour are automatically propagated to all dependent be-
haviours, making loops and similar control structures often obsolete. One can
summarize this characteristic of FRP as �all values are automatically kept up-
to-date�.
Example. Imagine a �shing rod automation system written in a language with
an FRP extension. The FRP framework together with the low-level hardware
interface would de�ne time-varying values (i.e. behaviours) such as line-tension,
cast-line-length, etc. Using these values one can de�ne other values or discrete
events such as �sh-bites upon which the system can react again. The di�erence
between this approach and traditional systems is that all values are updated
automatically: The tension value always re�ects the current tension and the
�sh-bites event is triggered as soon as line-tension increases at a certain rate.
In a functional pseudo language, such an automization program could be
l i n e−t e n s i o n : : Behav iou r F l o a t
cas t− l i n e−l e n g t h : : Behav iou r F l o a t
r e e l−i n : : ( ) −− No r e t u r n v a l u e
f i s h−b i t e s : : Eventf i s h−b i t e s = r a i s e E v e n t I f ( d e r i v a t i v e l i n e−t e n s i o n
> some−c r i t i c a l −v a l u e )
main = onEvent f i s h−b i t e s do r e e l−i n
Without FRP, a complex sequence of loops and if-statements would be needed.
3.3.1 History
FRP was �rst devised in the �eld of computer animations. One of the earli-
est independent implementations is the reactive animations library Fran[52] for14In this context, the term �behaviour� has not the comprehensive meaning known from
biology, it refers to a single changing yet quanti�able property of a system that can be sampledcontinuously.
32 CHAPTER 3. SOFTWARE BACKGROUND
Haskell. Other computer graphics based systems include the graphical user in-
terface toolkit Fudgets[55], and the visual tracking library FVision[56]. With
these systems, elements of the graphical user interface are de�ned as behaviours
dependent on user input.
A second major area of application is robotics. Frob[51] is an example for a
control language for robots realized using FRP. The robot's actions are de�ned
as behaviours that depend on input from various sensors.
To make an FRP system's resource consumption predictable, an extended
implementation called RT-FRP[57] (Real-Time FRP) that allows one to make
guarantees about time and space behaviour has been devised. E-FRP[58]
(Event-Driven FRP) aims at providing a small implementation suitable for mi-
crocontrollers.
A non-Haskell implementation is the PLT Scheme based FrTime lan-
guage[59], which uses mutation to model signals.
3.3.2 Technical Remarks
Early Haskell-based implementations of the functional reactive programming
paradigm made use of synchronized stream processors[45]: Input values were
encoded as lazy lists of time-stamped samples. Transformation functions would
take a single value o� the input stream, transform it and pass the result on over
an output stream. Such an implementation brought about certain disadvan-
tages: The synchrony was implicit to the type declarations, every input sample
had to be processed as change detection is not available, and �rst class continua-
tions of transformation functions could not be realized natively in Haskell[53].
The functional reactive animations toolkit Fran[52] modelled behaviours as
�residual behaviours� which returned pairs of output values and new behaviours.
The returned behaviours are used to process the next input sample.
This approach has been re�ned in recent research, yielding a new realization
using continuations[53]. The primary notion of this approach is the use of signal
functions, which transform input to output samples. Along with the output
sample, a signal function returns a new signal function for the next sampling
step, i.e. its continuation. This new function, as functions are �rst-class citizens
in Haskell, can be stored for later use, composed, transformed, etc.
3.3.3 Why FRP?
Functional programming in general is strongly suited for our application domain.
RatTracker is a reactive system that receives input from rat boxes with
unpredictable contents and its main task is to respond to this input. Also,
3.4. YAMPA 33
input data reaches the processing stage at changing frequency. The programs
control �ow strongly depends on the input.
Behavioural experiments such as CAR can be modelled as a chain of isolated
logical steps, each one evaluating the current status and deciding which step to
take next (see Figure 1.1 on page 5). This leads to a perception of experiments
in a data-�ow oriented fashion with three main steps:
1. The rats position is used as system input.
2. The input is transformed by a time- and context-varying sequence of signal
functions.
3. The signal function sequence results in an output specifying the environ-
mental change to be applied in response to the input.
By modelling the various steps of the experiments as signal functions which
can be composed to form a sequence (or pipeline) of transformations, a system
capable of processing experiment descriptions at run-time can easily be devised.
Using a functional reactive system brings various advantages over other ap-
proaches, such as imperative style programming:
1. The programming logic is primarily expressed in terms of events and re-
actions to these events, not in explicit �ow statements such as if or when.
This allows us to more easily structure the code into independent blocks,
which greatly facilitates the writing of a program whose data �ow is to
be determined at run time. Functional reactive programming allows us to
transform logic into code more easily and directly than traditional imper-
ative language.
2. State is maintained implicitly and automatically, which is very convenient
for programs with a dynamic data �ow path as the environment for every
�ow module is maintained implicitly.
3. FRP systems have an inherent notion of time, input data is continuously
routed through the system while time intervals between samples are au-
tomatically accounted for.
3.4 YaMPA
YaMPA is an FRP implementation for Haskell with three main characteris-
tics[53]:
1. Signal functions (transformation functions) are �rst-class citizens, the sig-
nals themselves are second-class entities. Programmers have no direct
34 CHAPTER 3. SOFTWARE BACKGROUND
access to the signals directly, only to the values carried by them from
within the signal functions. This ensures an implementation free of time
and space leaks.
2. YaMPA uses continuations to implement signal functions.
3. YaMPA is based on the arrow combinators[60], a generalisation of mon-
ads. Signal functions are arrows, that is di-functors on input and output
type.
A signal function from signals of type A to signals of type B is written as
aSignalFuncFromAToB : : SF a baSignalFuncFromAToB = proc inSample −> do
pat1 <− anotherSF −< inSamplepat2 <− yetAnotherSF −< inSamplereturnA −< doSomethingWith exp1 exp2
With proc inSample one opens an arrow-style computation on an input value
bound to inSample (which is of type A). The following two lines pass the input
sample to two further signal functions, anotherSF and yetAnotherSF and bind
the respective output values using the patterns pat1 and pat2. The last line
produces the output value (of type B) by processing values acquired in the
previous steps, here exp1 and exp2 which in this example shall be bound by
pat1 and pat2.
A global loop-instruction, reactimate, is responsible for acquiring input sam-
ples from external sources, feeding them into signal functions, and processing
the �nal output values. A single iteration is of the form: receive an input sam-
ple, feed it to the main signal function, pass out the obtained output value,
and repeat. The required I/O operations are thus separated from the signal
functions, as I/O access is only needed for processing of in- and output-samples
at the top level. The source of input values, for example a keyboard sampling
device, is also responsible for providing the amount of time elapsed between two
samples. Since only these time values are used for time-dependent operations
within signal functions (such as computation of derivatives), synchrony of time
sources is not an issue.
On the name �YaMPA�. YaMPA doesn't really mean anything, but this
work started at Yale, ended with Arrows, and had Much Programming in the
middle. Yampa is also a river in Colorado that combines continuous, placid
sections with an occasional abrupt transition � a perfect metaphor for hybrid
systems. We used to call this AFRP, but that's too hard to pronounce.15
15From http://www.haskell.org/yampa/.
3.4. YAMPA 35
3.4.1 Why YaMPA?
At the time of writing, two suitable production quality implementations of FRP
were available: FrTime for PLT Scheme[59] and YaMPA for Haskell[53].
Theoretical evaluation of these two systems showed that our data�ow based
design does not gain as much from FrTime's advantages compared to what
YaMPA's signal functions have to o�er (obviously, not all arguments listed
here are entirely objective, as they cannot be):
• YaMPA uses a synchronous processing method, whereas FrTime oper-
ates asynchronously. Since the input from the boxes arrives sequentially
at intervals of 20 milliseconds, but ought to be processed within certain
time constraints, in our opinion a synchronous processing model is more
suitable.
• Because of the �xed intervals of CAN bus data, real time features are not
required.
• The use of arrows and the associated notation increase the readability of
YaMPA code.
• FrTime's simpli�ed access to impure features does not bring an advantageover YaMPA for our system. The reactimate approach (read � process �
write, where no I/O operations should be performed during the processing
stage) suits our needs perfectly.
• YaMPA provides a set of stateful functions (such as the value of a signal
function at the previous time step or integrals). This proved su�cient for
our purposes, further access to the systems state is not required (which
would have been possible using FrTime's impure features).
• YaMPA ensures that at each timestep, all signal values are consistent.
• We did not see a need for a distributed layout of our system. Thus Fr-
Time's ability to work with distributed signals is of no use to us.
In order to make a more educated decision, we implemented a very sim-
pli�ed version of RatTracker in both FRP languages for comparison. This
showed that both language provide all required features, including the mech-
anism needed for interaction with the CAN bus interface. FrTime, however,
proved inferior with respect to performance when graphical output was involved.
Haskell's polymorphic type system with static checking greatly simpli�ed
the implementation process, especially of the signal function pipeline. This
is because it provides an additional means of ensuring that only �tting signal
functions are sequenced.
36 CHAPTER 3. SOFTWARE BACKGROUND
The use of Haskell and YaMPA brings multiple layers of abstraction:
1. The declarative character of Haskell itself allows for high-level program-
ming.
2. The YaMPA signal functions with arrow combinators[60] and Paterson's
notation[61] abstract from state and time.
3. Having small, composable components that each describe one aspect or
step of a possible experiment abstracts from the stage of primitive signal
functions.
4. The �nal level of abstraction is achieved by giving a description language
to the user to communicate with the system.
For these reasons that we decided to use the Haskell-based YaMPA lan-
guage.
Chapter 4
Implementation
The implementation of RatTracker was done in Haskell, using the Func-
tional Reactive Programming paradigm. The rational for this choice has been
given in the previous chapter.
A current version of the source code can be obtain with Darcs1 from http:
//darcs.oertel.ch/repos/thesis/. A browsable online version is available
at http://darcs.oertel.ch/?r=thesis.
4.1 System Overview
RatTracker's main operation is to react to a rat's behaviour according to user
speci�ed rules. The basic form of those rules is if the rat does a, react with b,
and the rules may be nested to represent more complex situations or sequences
of events that lead to a reaction.
The rules describing the experiment are read from a user-speci�ed �le, writ-
ten in a language called RatTracker Control Language (RTCL). From
the contents of this �le, a sequence of data processing modules is assembled
together (the pipeline). During the course of the experiment, the information
coming from the rat boxes is fed into this pipeline. The pipeline's components
check whether the conditions speci�ed in the experiment description are met
(e.g. Has a timer expired? or Has the rat crossed a line? ) and how to react.
The results from the pipeline processing, along with the rat's position, are then
given to the output modules, which write the data to log �les, produce graphi-
cal output or, depending on the outcome of the pipeline checks, trigger external
e�ects (e.g. a light is switched on).
1Darcs is a source code management system written in Haskell using patch theory. Seehttp://darcs.net/.
37
38 CHAPTER 4. IMPLEMENTATION
4.1.1 Data �ow
The overall data �ow of RatTracker is comprised of the following steps:
1. Data input. Sensor data coming from the rat boxes is received over the
CAN bus.
2. Position tracking. The rat's position is extracted from the raw sensor
data.
3. Pipelining. The rat's position is fed into the experiment pipeline. The
pipeline's output contains information about events that have occurred
and about actions to be taken.
4. Output. The results are written to log �les, the graphical display is up-
dated and e�ect devices may be switched on or o�.
A schematic illustration of the data �ow can be found in Figure 4.1.
4.2 Experiment Description Language
To run behavioural experiments such as CAR in an automated fashion while
describing them in a �exible way, it must be possible to instruct the controlling
system precisely and unambiguously. Based on feedback from the research sta�,
we decided on devising a description language that can be written into plain
text �les for such experiments.
We used the conditioned avoidance response as an example to determine
the required expressiveness that such a language must provide. The language
element most obviously needed is one which describes how to react once certain
events occur. Such events could be expired timers (e.g. do something after 10
seconds) or actions by the animal (e.g. the animal entered a certain region of
the box ). In order for the system to interact with the animal, the language must
provide the means to control external e�ect devices such as footshock devices or
speakers. Repetition of instruction sequences must be possible with conditional
aborts. These four groups of language elements (conditional execution, events,
e�ects and repetition including aborts) are a minimal set of requirements a
language must have to be suitable for our needs.
As we will explain in further detail in the following section, RatTracker
uses a data pipeline that receives the rat's position as input, analyzes this input
and based on the input decides how to react according to the user's speci�cations
(which will be given in the language described in this section). The pipeline con-
sists of various modules that can be combined to represent the layout of di�erent
experiments. To maintain maximum independence of the pipeline modules, we
4.2. EXPERIMENT DESCRIPTION LANGUAGE 39
RatTracker
OutputHandling
ExperimentDescription
HardwareConfiguration
TrialConfiguration
User−suppliedInformation
InterfaceCAN Bus
Data Flow
Figure 4.1: Data Flow Overview
40 CHAPTER 4. IMPLEMENTATION
decided not to use the notion of explicit state in our language, but to express
state implicitly by the sequence of events that led to the state.
Given these considerations, we developed a language named RTCL (Rat-
Tracker Con�guration Language). An experiment description in this lan-
guage is a sequence of statements (�4.2.3), predominantly what happens when
pairs; other possible statements are �ow control instructions or e�ects to be
executed. The what happens when pairs are written as upon E do S, with E
being a condition expression describing a condition to be met (the when), and
S being a statement to be executed once E is met (the what).
We believe that the description of experiments by a sequence of nested event
and reaction pairs is a concept that is simple enough to be quickly understood
and learned, yet powerful enough to express a vast variety of behavioural exper-
iments. The language is strongly based on verbal speci�cations of such experi-
ments, expressions such as �after 10 seconds, do this and when the rat then does
something, do that followed by this, and start all over again� can be one-to-one
mapped to RTCL. Not using explicit states allows the user to easily read RTCL
�les, as the path of events prior to an instruction contains all of the information
about the situation in which the instruction is executed.
A drawback of this approach, however, is that whenever di�erent sequences
of events lead to the same instructions to be executed, those instructions must
be speci�ed multiple times. We are currently devising an extension of RTCL to
allow the use of macros, making such repetitive declarations obsolete.
In the current implementation of RTCL, various condition expressions and
possible e�ects are provided. The set of available language elements can easily
be extended due to the modular implementation. The implementation of the
interpretation of this language is described in �4.5.2. Indentation and line breaks
are irrelevant for the parsing of the control �les and therefore can be used for
purposes of emphasis or clari�cation.
4.2.1 Examples
Before explaining RTCL in detail, we provide a few simple examples of it to
give the reader an overview of its capabilities and syntax.
The simplest possible experiment description is
noth ing
which, as the name implies, does nothing (nothing happens always).
To turn the light on after 10 seconds, one would write
upon t imer 10 .0 do l i g h t on
4.2. EXPERIMENT DESCRIPTION LANGUAGE 41
For clari�cation, we also provide �ow chart diagrams of the examples. Diamonds
are used for decisions (upon statements), rectangles for e�ects and ellipses for
labels. The above example can be depicted as
To turn the light on after 10 seconds and turn it o� after another 5 seconds,
a program would contain a second upon statement, grouped together with the
light on command by parentheses:
upon t imer 10 .0do ( l i g h t on ,
upon t imer 5 .0 do l i g h t o f f
)
or
If this light-on-o�-cycle is to happen repeatedly, one would use a label and
a goto jump to create a loop:
"START" :upon t imer 10 .0 do
( l i g h t on ,upon t imer 5 .0 do
( l i g h t o f f ,goto "START"
))
or
Multiple conditions can be observed simultaneously, the �rst one to be met
will have its associated statement executed and the remaining ones will be dis-
carded. In the following example the light is turned on after 10 seconds, but
only if the rat has not crossed a line at position 5 before the 10 seconds are over,
in which case the program will simply abort.
42 CHAPTER 4. IMPLEMENTATION
upon
( t imer 10 .0 do l i g h t on ,l c d "−" 5 do abor t )
or
A full-featured example describing a conditioned avoidance response exper-
iment is shown in the following code section:
1 ( upon2 // Experiment l a s t s 15min , s top a f t e r t h a t3 t imer 1800 .0 do ( sound o f f ,4 l i g h t o f f ,5 f oo t shock o f f ,6 abor t ) ,7
8 // Labe l f o r main loop9 "START" :
10 // I n i t i a l s t a t e : every th ing ' s o f f11 ( sound o f f ,12 l i g h t o f f ,13 f oo t shock o f f ,14
15 // At random in t e r v a l s , do . . .16 upon random 15 .0 30 .0 do
17 // turn sound and l i g h t on18 ( sound on ,19 l i g h t on ,20
21 // I f . . .22 upon
23 // . . . 10 sec t imer counts down , then24 ( t imer 10 .0 do
25 // turn f oo t s hoc k on and26 ( f oo t shock on ,27 // and go back to s t a r t i f e i t h e r28 // 5 seconds are up or l i n e i s c ros sed29 upon ( t imer 5 .0 do goto "START" ,30 l c d " | " 20 do goto "START"31 )32 ) ,33 // . . . l i n e i s crossed , go back to START34 l c d " | " 20 do goto "START"35 )36 )
4.2. EXPERIMENT DESCRIPTION LANGUAGE 43
37 )38 )
Listing 4.1: RTCL Example for �CAR�
4.2.2 Condition Expressions
Conditional statements upon E do S are composed of a condition expression
E and a statement S. Condition expressions are closely related to boolean
expressions in programming languages; in RTCL expressions are de�ned in terms
of events that occur when a given condition is met (corresponding to true-
values in boolean expression). The conditions are checked constantly while
the conditional statement is being executed. The language elements that raise
events are called eventors. upon E do S is thus to be read as: When eventor E
results in an event being triggered, perform S.
The signi�cant di�erence between events and boolean expressions is that an
eventor triggers an event exactly once, when the conditions is met the �rst time.
A single countdown eventor instance for example raises an event only once when
the countdown has �nished, and will not raise another event after that.
Once triggered, events can be reacted upon with e�ects, �ow control state-
ments or with another eventor, thus creating a chain of conditions.
Recapitulation. An eventor triggers an event once its condition is met for
the �rst time.
Currently, the language includes the following eventors:
• timer duration: Once duration seconds have passed, an event is triggered.
• random min-duration max-duration: A duration between min-duration
and max-duration is chosen randomly; once this duration has passed, an
event is triggered.
• lcd line-orientation line-position: An event is triggered whenever an imag-
ined line at line-position in line-orientation is crossed in the lower frame.
The line position is speci�ed in terms of photo sensors, e.g. 20 describes a
line between the 20th and the 21st sensor. The line orientation can either
be "|" for vertical lines (running from front to back) or "-" for horizontal
lines (running from right to left).
• standup: An event is generated when the rat straightens up and intercepts
photo sensors of the upper frame (if any).
44 CHAPTER 4. IMPLEMENTATION
• con�dencebelowmin-con�dence: An event is triggered when the con�dence
in the determined position for the rat drops below min-con�dence. The
details of the calculation of the con�dence level will be explained later.
Within loops, eventors are restarted on every iteration. Especially timers (timer
and random) start at zero in every cycle.
Multiple eventors
To implement if . . . else if . . . else structures, one can use the upon-statement
with multiple pairs of eventors and associated statements: upon (E1 do S1,
E2 do S2, . . . ). All eventors are initiated and their conditions are observed
simultaneously. The �rst eventor having its condition met triggers an event and
its statement will be executed as a consequence. The other eventor/e�ector-
pairs are discarded (winner takes all).
For example, the following program snippet results in a jump back to "BAR"
if a line is crossed within 10 seconds, and a jump to "FOO" otherwise:
"BAR" :. . ."FOO" :
. . .upon ( t imer 10 . 0 , goto "FOO"
l c d " | " 10 , goto "BAR" )
4.2.3 Statements
Statements are the building blocks of RTCL. They can either be used at the top
level, or as consequential part in upon-statements (which is a statement itself).
The main types of statements are e�ects, jumps and the previously described
upon-statement.
Combining Statements
Multiple statements can be executed simultaneously by writing them as comma-
separated list, enclosed in parentheses: (S1, S2, . . . , Sn). List do not have to
consist of statements of the same type, but may be of mixed elements.
E�ects
The active interaction of the system with the outside world is de�ned by the use
of e�ect elements, also called e�ectors. E�ects are speci�ed in terms of change,
not by state variables: An e�ector causes a external change, and this change
will stay in place until it is undone by another e�ector.
The following e�ects are available (switch is given as either on or o�):
4.2. EXPERIMENT DESCRIPTION LANGUAGE 45
• light switch: The light in the lid is turned on or o�.
• sound switch: The speaker in the lid is switched on or o�.
• footshock switch: The footshock is turned on or o�.
• nothing: Nothing happens.
No assumption should be made about the initial status of external devices,
setting a base state by using the appropriate e�ector statements is recom-
mended.
( f oo t shock o f f ,l i g h t o f f ,sound o f f ,. . .
)
Jumps
To allow iterations in experiment designs, one can specify labels and use them
as reference points to jump back to later in the description �le. Labels are of the
format "Label": (the label's name in double quotes, followed by a colon), jumps
to a label are initiated by goto "Label". Only those labels that were declared
prior to the jump statement within the same branch are available as reference
point for jumps; with respect to jumps, RTCL is block-structured with static
scopes2.
Upon a jump back to a label, the experiment execution continues with the
statement right after the label. If a jump is made from within a group of
statements as depicted in the example below, the jump is performed after the
execution of the group. The other statements of the group are therefore still
executed in the cycle of the jump.
"FOO" :( l i g h t on ,upon t imer 10 .0 do
( goto "FOO" ,l i g h t o f f
))
Even though the light o� statement occurs after the jump, its e�ect will still
be performed. The rationale is to allow the user to write the main statement
of the group �rst (the example can thus be read �goto FOO, and turn o� the
light on your way out�). This can however easily be changed to an interpretation
2Since there are no identi�ers other than jump marks in RTCL, no other scoping issuesoccur.
46 CHAPTER 4. IMPLEMENTATION
where statements following a jump are not executed anymore should the current
implementation prove unfeasible (technical remark: this change would require
a single split of the list of events in the lSwitch signal function in the pipeline
code).
4.3 Initialization & Con�guration
At system start, before the actual experiment trial begins, a variety of tasks are
performed. First, the system's runtime con�guration is established:
1. The experiment description �le is read (resulting in PipelineTree, see
�4.3.1).
2. The system's con�guration �le is read (resulting in AWorld, see �4.3.2).
3. Trial-speci�c parameters are queried from the user (resulting in Runtime-
Con�g, see �4.3.2).
All system con�guration is thus held in the types PipelineTree, AWorld and
RuntimeCon�g.
Once the con�guration parameters have been acquired, the system's initial-
ization is performed by executing the following steps:
1. For every rat box used in the experiment, a RatBox instance is generated
using mkRatBoxes from the RatBox module. These data records contain
next to the ID number of the box and the name of the rat running in
the box, as well as the data pipeline used for processing the position
information received from the box.
2. The CAN bus input device is opened using initialize from the CanBus
module
3. The output channels are initialized (including opening the CAN bus out-
put device and log �les) using initOutput from the Output module.
Once these steps have been performed, the system awaits the start message
which will be sent by the activity monitor (see �2.3) upon experiment begin.
4.3.1 Experiment Description
The experiment description (what to do when) is read from a user-speci�ed
RTCL �le (see �4.2) by the PipelineParsermodule and transcribed into a Pipeline-
Tree instance using parseContentsToTree:
4.3. INITIALIZATION & CONFIGURATION 47
type Fi leName = S t r i n g
par seContent sToTree : : Fi leName −> IO P i p e l i n eT r e e
This function returns an intermediate tree representation of the experiment
description that can later be used to construct the data pipelines.
data P i p e l i n eT r e e = PtLabe l ed S t r i n g P i p e l i n eT r e e| PtAnd [ P i p e l i n eT r e e ]| PtUpon Evento r P i p e l i n eT r e e| P tF i r s tW in s [ ( Eventor , P i p e l i n eT r e e ) ]| PtDo P lE f f e c t Sw i t c h| P tC t r l P lCon t r o l| PtNoop
(To the yet to become Haskell programmer: Read �A PipelineTree is either
a PtLabel with a String and another PipelineTree, or a PtAnd with a list of
PipelineTrees, . . . , or a PtNoop with no further attachments.�) The various
constructors correspond to the elements of the description language.
4.3.2 System Con�guration
Global system parameters such as IDs of available boxes, device paths and
speeds or sensors that are to be ignored are stored in an INI-style con�guration
�le (see �4.7). The functionality to parse and evaluate the con�guration �le is
encapsulated in the TheWorld module. This module also exports the data type
for the global con�guration options, AWorld:
data AWorld = TheWorld {−− Path and speed f o r input CAN dev i c etw InputDev i c e : : St r i ng ,twInputSpeed : : In t ,−− Path and speed f o r output CAN dev i c etwOutputDevice : : St r i ng ,twOutputSpeed : : In t ,. . .
}
(Recall that the double colon notation is a type assignment. For example,
twInputDevice is declared to be of type String.)
In the current implementation, all known con�guration options are retrieved
explicitly. An alternative would have been to represent the �le as an associative
list of sections, which would have been an associative list of name-value-pairs
themselves:
type AWorld = [ ( St r i ng , [ ( St r i ng , S t r i n g ) ] ) ]
User
Main Runt.Config Pipel.Parser Pipel.Lexer TheWorld BAR RatBox Pipeline CanBus CanBusOut Output
starts w/ RTCL−file
parseContentsToTree(RTCL−file)
scanTokens(RTCL−file)
[Token]
PipelineTree
theWorld
parseConfigFile()
AWorld
getRuntimeConfig
loop
Parameter?
Parameter.
RuntimeConfig
mkRatBoxes(PipelineTree)
loop
foreach rat box:
build(PipelineTree)
Pipeline
[RatBox]
initialize()
initOutput()
openCanBusOut
initializeOutCanBus
CanBus handle
openCanBusOutput
Figure 4.2: System Initialization Overview
User
Main Runt.Config Pipel.Parser Pipel.Lexer TheWorld BAR RatBox Pipeline CanBus CanBusOut Output
starts w/ RTCL−file
parseContentsToTree(RTCL−file)
scanTokens(RTCL−file)
[Token]
PipelineTree
theWorld
parseConfigFile()
AWorld
getRuntimeConfig
loop
Parameter?
Parameter.
RuntimeConfig
mkRatBoxes(PipelineTree)
loop
foreach rat box:
build(PipelineTree)
Pipeline
[RatBox]
initialize()
initOutput()
openCanBusOut
initializeOutCanBus
CanBus handle
openCanBusOutput
50 CHAPTER 4. IMPLEMENTATION
Such an implementation would have made the �le parser simpler and more
�exible, however, a syntactic veri�cation of the �les' contents at parse time
would not have been possible, and the need for parsing the string-values to the
needed type (e.g. integer) would have to be handed down to the respective
modules.
Trial Parameters
The trial-speci�c parameters are set using the console in a getline-like fashion.
These parameters include name of the experiment, number of the trial, and the
names of the involved animals. The RuntimeCon�g module is responsible for
the acquisition of this information, it provides the getRuntimeCon�g function
for this purpose.
getRunt imeConf ig : : AWorld −> IO Runt imeConf ig
data Runt imeConf ig = Runt imeConf ig {r t c T r i a l : : St r i ng , −− Tr ia l namer t c T r i a l r u n : : St r i ng , −− Tr ia l numberr t cOpe r a t o r : : St r i ng , −− Operator ' s i n i t i a l s−− Used ra t boxesr t cBoxe s : : [ Runt imeBoxConf ig ]
}
data RuntimeBoxConf ig = RuntimeBoxConf ig {rtcBoxNumber : : In t , −− Box ID numberrtcRatName : : S t r i n g −− Rat ' s name
}
4.4 Data Input
Our system receives input from 12 rat boxes, connected to the computer via a
CAN bus. The input system and the used data structures are general enough
to facilitate other input sources as well, such as a video tracking system.
Overview. Input retrieval is initiated by the reactimate-function that poses
as the primary application loop. At the lowest level we have a C-code segment
to communicate with the CAN-bus driver. This segment provides a retrieval
function that is called synchronously and returns once new data is available. The
input data from the boxes is conveyed as it is received over a shared memory
bu�er. The Haskell-part of the input section transforms the contents of the
bu�er to a more convenient format and returns this presentation for further
processing. Thus the Haskell section of the application only becomes active
when new data has arrived for processing. An overview of the steps performed
4.4. DATA INPUT 51
during data retrieval is shown in Figure 4.3. We decided to implement the
code for receiving data o� the CAN bus and caching data fragments in C for
performance reasons (with 12 attached boxes, data intervals of 20 milliseconds
and various status and heartbeat messages, the CAN-bus produces a great deal
of tra�c). This C-code segment will be referred to as I/O layer (input/output
layer).
4.4.1 Data Retrieval
The �rst step in retrieving an input sample is performed by the CanBus module.
Its getCanData function, which is called by reactimate and is responsible for
accessing the I/O layer, has the signature:
−− Return time e l ap s ed s ince l a s t sample in ms−− and l i s t o f data r e c e i v ed from boxesgetCanData : : AWorld −> IO ( I n t ege r , [ CanOutput ] )
getCanData calls the I/O layer's data retrieval function, retrieves a complete set
of status and sensor data for all boxes and transforms this data into appropriate
data types. The boxes' positional data is transformed from its bit sequence rep-
resentation into lists of boolean values and embedded into a record representing
the current states of the rat boxes.
−− Represent ion o f one photo sensor bar−− which has mu l t i p l e sensorstype SensorData = [ Bool ]
−− Representa t ion o f one photo sensor l a y e r−− ( each s t a t i o n may have mu l t i p l e ones )data FrameData = FrameData {
frXData : : SensorData , −− Data in X dimensionf rYData : : SensorData −− Data in Y dimension
}
−− Representa t ion o f one ra t box s t a t i o ndata CanOutput = CanOutput {
coNo : : In t , −− The s t a t i on ' s IDc o I sOn l i n e : : Bool , −− S ta t i on on l ine ?co I sRunn ing : : Bool , −− S ta t i on a c t i v e ?coFrameData : : [ FrameData ] , −− Stat ion ' s datacoTimestamp : : I n t e g e r −− Stat ion ' s curren t time
}
It then returns the number of milliseconds elapsed since the last data retrieval
and a list of records representing the boxes' data sets. The elapsed time is used
by the YaMPA library as the timing source.
Main CanBus input.c interfact.c CAN Driver controller.c
reactLoop()
reactInput()
getCanData()
get_data(buffer)
loop
[! do_return()]
read()
LINUX_CAN_Read()
raw message
«create» message.c
message
process_message()
copy_data()
«destroy»
do_return()
is_dirty()
has new data?
true iff any controller has a new complete data set
copy_cache(buffer)
loop
foreach controller:
copy_data_to(buffer)
(data in buffer)
convertToCanOutput(buffer)
[CanOutput]
Figure 4.3: Data Retrieval Overview
4.4. DATA INPUT 53
I/O Layer
The I/O layer, written in C, is responsible for the following tasks:
1. Initializing the CAN interface driver and the interface hardware.
2. Receiving incoming packets and �ltering out the relevant ones.
3. Caching partial data until a full data set is received (a box's data for each
cycle is spread over 3 packets).
4. Caching data until a change between the data set and the previous set
occurs.
5. Finalizing tasks such as closing �les and device handles.
To dodge the hazards usually associated with C programming, the CAN
interface has been written making strong use of abstract datatypes. The various
elements of the CAN bus world are represented by opaque types, access to which
is only possible using accordant functions and type handles:
• The interface module represents the interface device. This module encap-
sulates the functionality of accessing the device itself and receiving and
sending messages. Received data packages are wrapped in an instance of
the message type and passed to the respective controller.
• The controller data type represents the CAN controller attached to a rat
box. It stores received data until a full set has been gathered and main-
tains the CAN controller's state and time. It receives messages from the
interface module. The controller also keeps a cached copy of the previ-
ous complete sample that is overwritten once a new complete sample is
available.
• Instances of the message type represent CAN messages. Messages store
the information contained in received packages, such as sender ID, message
sequence number (between one and three) and the actual data. Data
messages are created by the interface module and passed to the respective
controller.
The I/O layer is accessed by means of three functions: initialize, get_data
and �nalize. The �rst function is used to initialize the CAN interface device and
set various parameters such as ID numbers of used boxes and bus speed. The
�nalize function is responsible for closing the interface and freeing memory used
for the various data structures.
The main functionality is provided by get_data. It is called synchronously
and will not return until new data is available. This function uses the interface
module to read incoming packages and process them according to their type:
54 CHAPTER 4. IMPLEMENTATION
• A control message is used to set the respective controller's status �ag
(active or inactive).
• A timestamp package is used to adjust the respective controller's time.
• A data package's contents are stored with the respective controller's in-
stance.
Once one of the controller instances has received a complete sample or a speci�ed
timeout has expired3, all controllers' cached data are copied to the shared bu�er
along with timestamps and status information. Afterwards, get_data returns
with the time elapsed since the last return in milliseconds.
Data Exchange Bu�er
The data exchange between the C-function get_data and the CanBus module,
written in Haskell, is done using a byte string allocated by the caller. This
byte string contains the number of data sets (one for each rat box/controller)
in the �rst byte, the size of a single data segment in the second byte, and the
actual data sets, each one consisting of:
1. The controller's current timestamp (8 bytes),
2. the controller's status (1 byte) and
3. the last complete data sample received by the controller encoded in a single
bit per sensor, with a bit value of 1 representing an interrupted sensor.
In the current hardware con�guration, 40 bits per axis and per frame are
conveyed, which amounts to a total of 20 bytes of sensor data per box.
4.4.2 Simulation Modules
To allow o�ine development and testing (i.e. without attached boxes and CAN
bus) and to verify the system's performance using prerecorded data, various
simulation modules were added to the system. The input to the system, i.e. the
raw data produced by the rat's locomotion, can be simulated in two ways: by
using a random data generator or by evaluating output �les of previous runs.
Output can be simulated using keyboard LEDs.
The random data generator maintains a rat position and applies random
changes to this position (that is, the direction and the speed of the simulated
rat are determined randomly, not the position itself). This data is then distorted
in various ways by simulating failure of single photo sensors (unsteadiness) and
piles of litter (multiple areas of interception).
3The timeout is needed due to the synchronous nature of the get_data function.
4.5. PROCESSING 55
A second module for input data simulation uses previously recorded data
�les. These �les which contain the resulting rat position data in raw binary
notation have been generated using a di�erent type of rat box with only 16 photo
sensors in each dimension. Multiple �les can be used in the same application run
to simulate multiple rats. The module also simulates the time elapsed between
two records and passes on a full set of data for all active �les whenever a change
occurs in any of the �les.
4.5 Processing
After the sensor data has been received via the CanBus module from the I/O
layer, the main processing takes places. RatTracker evaluates the received
information by matching it against the rules from the RTCL experiment de-
scription. At the end of the processing step we have a list of events that have
been detected and actions to be taken in response to these events.
This processing consists of two stages:
1. A position determination stage during which the rat's current location is
extracted from the raw input data.
2. A transformational step in which the rat position and its change over
time is used to execute the user-speci�ed experiment description. The
transformation is done by piping the position data through a sequence
of signal functions, the pipeline. Signal functions continuously transform
input signals (values) into output signal, for example
−− Transform As in to Bsa_s i gna l_ func t i on : : SF A B
Each pipeline component may contribute to the �nal result, mainly by
raising an event noti�cation upon certain conditions (e.g. the rat is stand-
ing up). This step results in a list of such component events, which is used
to control the system's output.
An overview of the processing is shown in Figure 4.4.
4.5.1 Position Tracking
Incoming data from the rat boxes only indicates interrupted photo sensors. This
data, therefore, needs to be interpreted with respect to the rat's position.
The current position tracking implementation is held by the PSTracker mod-
ule. Tracking is implemented as a signal function from a CanOutput list to
YaM
PA
Mai
nC
anB
us[R
atB
ox]
Trac
ker
Pip
elin
e
reac
tLoo
p()
re
actim
ate(
)
loop
[at l
east
one
pip
elin
e is
stil
l run
ning
]
reac
tInpu
t()
getC
anD
ata
[C
anO
utpu
t]
[Can
Out
put]
re
actT
rans
form
er([C
anO
utpu
t])
parC
anO
utpu
t([C
anO
utpu
t])
loop
fore
ach
Rat
Box
:
pipe
(Can
Out
put)
P
ipel
ineI
nput
pi
pe(P
ipel
ineI
nput
)
Out
putD
ata
[Out
putD
ata]
[O
utpu
tDat
a]
reac
tAct
uato
r([O
utpu
tDat
a])
Figure 4.4: Data Processing Overview
4.5. PROCESSING 57
PosTrkOutput. CanOutput records contain the raw data received from the CAN
bus module, PosTrkOutput records describe the extracted position of the rat.
−− A PSTracker i s a type o f p o s i t i o n t r a c k e r .−− I t t rans forms a PSTInput to a PosTrkOutput wi th−− a dd i t i o n a l in format ion s t o r ed in a PSTAddon recordtype PSTracker = SF PSTInput ( PosTrkOutput PSTAddon)
−− The po s i t i o n t racker ' s input i s the CAN bus modules outputtype PSTInput = [ CanOutput ]
−− A po s i t i o n t racker ' s output con ta ins the p i p e l i n e ' s−− inpu t ( PlInput ) and a dd i t i o n a l in format ion (a )−− depending on the type o f the t racker ,−− hence the parametr ic typedata PosTrkOutput a = PosTrkOutput {
p t oP l I npu t : : P l I nput ,ptoAddon : : a
}
The actual translation is done by positionFromData, a signal function which
transforms sensor data (along with the single result cluster representing the
detected rat position from the previous run, if any) into position information. It
takes a list of noise reduction signal functions (see below) and a winner selection
signal function:
pos i t i onFromData : :−− Noise reduc t i on func t ions , may be empty[ E l im i n a t eC l u s t e r s SF ]−− Function f o r s e l e c t i n g the winner−> Re su l tC l u s t e r SF−− We transform raw sensor data t o g e t h e r wi th the−− r e s u l t o f the prev ious run ( i f any ) in t o a−− po s i t i o n f o r one dimension−> SF ( SensorData , Maybe C l u s t e r ) RatOneDimPosData
pos i t i onFromData e l imS f s r e s S f = proc ( rd , p rv ) −> do
−− Turn raw data in t o c l u s t e r sr c l u s t e r s <− c l u s t e r i f y −< ( rd , p rv )−− Apply no i se reduc t i onp c l u s t e r s <− f o l d l (<<<) ( a r r i d ) e l imS f s −< r c l u s t e r s−− Find winner( c l s t , con f ) <− r e s S f −< p c l u s t e r s−− Get raw c l u s t e r s out o f c l u s t e r i n g r e s u l tl e t r a w c l u s t e r s = cpdC l u s t e r s r c l u s t e r s−− Return data wrapped in a RatOneDimPosDatar e tu rnA −< RatOneDimPosData c l s t r aw c l u s t e r s con f
c l u s t e r i f y : : [ Bool ] −> [ ( In t , I n t ) ]
E l im i n a t eC l u s t e r s SF : : SF [ C l u s t e r ] [ C l u s t e r ]
58 CHAPTER 4. IMPLEMENTATION
Re s u l tC l u s t e r SF : : SF [ C l u s t e r ] C l u s t e r
This function is applied to each axis' data separately. The �rst tracking step
consists of clustering the lists' values, that is, �nding contiguous regions of
interrupted sensors. These clusters are represented by their respective �rst
and last sensor position. The resulting list of clusters is then fed to the noise
reduction functions which are folded into one signal function (if no such functions
are given, only the id function is used). These noise reduction functions eliminate
shadow clusters that are most likely not caused by the animal. Finally, the list
of remaining clusters is given to the winner selection signal function that selects
the cluster that will be reported as the rat's position in the respective dimension.
The winning cluster, the raw clusters and the �nal con�dence level are then
reported as a RatOneDimPosData record. Our current implementation uses the
largest cluster in each dimension as the winning cluster.
The result for a single dimension of one sensor frame is returned as
data RatOneDimPosData = RatOneDimPosData {−− Clus t e r r ep r e s en t i n g the rat ' s shadow , i f anyrodpSpread : : Maybe C lu s t e r ,−− Raw c l u s t e r sr o d pC l u s t e r s : : [ C l u s t e r ] ,−− How sure are we about our r e s u l tr odpCon f i d ence : : Con f i d ence
}
with rodpSpread either being the winning cluster or Nothing, if no suitable
shadow could be found, rodpClusters being a list of all raw clusters found in
the input data, and rodpCon�dence being a measurement for the con�dence in
the result (explained below).
All positional data for a single box is combined in a PosTrkOutput record.
Such records consist mainly of two substructures:
1. ptoPlInput :: PlInput. The rat's position in each frame as determined by
the tracking algorithm, together with a calculated con�dence level (the
calculation of the con�dence level will be explained in a later section).
The two pieces of information are used in later steps for the execution of
the experiment.
2. ptoAddon :: a. Additional information from the tracking module. These
data are not used for the experiment, but may be included in the display
or output �les.
The PosTrkOutput is a parametric type (it's full type is PosTrkOutput a) which
allows tracking modules to attach additional information. Thus, using the
4.5. PROCESSING 59
PSTracker module, the output type is PosTrkOutput PSTAddon, with PSTAd-
don containing the raw clusters from the clustering step.
Noise Reduction
In an ideal situation, the input data would show one consecutive segment of
interrupted sensors only, thus making the determination of the rat's position
very simple. In real settings however, various phenomena may cause obfuscation:
• Sensors may fail for di�erent reasons:
1. False positives: Random sensors may report interruption even though
no object blocks their respective rays. This might enlarge existing
shadows or introduce new ones.
2. False negatives: Sensors with interrupted rays may report �clear
view�. This can cause the rat's shadows to be split into multiple
parts and thus complicate or falsify interpretation of the data.
3. Jitter: A common error of photo sensors is to alter the reported state
in rapid succession, thus causing unsteady data. This leads to heavy
data tra�c.
• The rat's tail may cause large jumping shadows.
• The rat may disturb a sensor's ray with saliva or excrements.
• Piles of litter may disrupt multiple sensors in a row, thus casting a large
shadow.
• etc.
To cope with these disturbances, �lter functions can be applied to the de-
tected clusters in order to eliminate the most obvious errors. Currently, the
following �lter functions are implemented:
1. Ignore clusters smaller than a speci�ed minimum size or larger than a
maximum size. It is certainly advisable to ignore clusters that comprise
of only one single sensor.
2. Ignore clusters that appear for the �rst time, i.e. that do not overlap any
cluster from the previous sample, unless the previous sample produced no
winner cluster.
3. If a sample contains clusters that have moved since the previous sample
(i.e. overlap a cluster from the previous sample, but are not identical to
it), ignore all non-moving clusters.
60 CHAPTER 4. IMPLEMENTATION
These functions can be passed on to the position tracking function and used
as �lters. Which �lter functions are used is currently hardcoded, but a �exible
con�gurability could easily be added.
Unfortunately, all of these functions introduce new sources of falsifying the
results, and may make tracking results less comprehensible. For instance, a
rat may keep its body still but move around its tail � by ignoring stationary
clusters once one cluster is moving, the system would choose the tail's shadow
over the body's shadow. Thus it is not possible to implement a noise reduction
scheme that would work equally well for all experiment setups.
In the CAR experiments we conducted as a concrete example of behavioural
experiments we use a metal lattice as �oor for the boxes which means there is
no litter in the boxes. Therefore, we do not have to deal with otherwise possible
piles of litter. Our experiments so far have shown that using the largest cluster
from the input data provides a suitable and accurate method to determine the
rat's position4. In the RatTracker version used for our CAR experiments, we
therefore only used the minimum size criterion and the selection of the largest
cluster for noise reduction.
Con�dence
The noise reduction and winner selection have a certain impact on the expres-
siveness and dependability of the tracking result. It might well happen that the
correct shadow area is dropped in favour of a larger, yet not rat body caused,
one (e.g. by a pile of litter or the rat's tail).
Since in behavioural learning experiments, a single falsely administered aver-
sive stimulus might nullify a trained response, it may be best to not present such
a stimulus if there is no certainty that all conditions for the stimulus are met.
Therefore, a con�dence level is maintained throughout the tracking process and
transmitted together with the found rat's position. This allows the following
steps in the processing sequence to decide whether action is to be taken on
grounds of this data (the pipeline module con�dencebelow, which is described
below, is the primary client of this information).
The con�dence level is a decimal number between 0.0 and 1.0, calculated for
each dimension separately and then combined by multiplication. A value of 1.0
represents complete con�dence in the positional data. Such a con�dence level
is achieved if the input data has exactly one shadowed area of appropriate size,
or shows no interrupted sensors (in which case the con�dence refers to no rat
being found).
4In these experiments, we used rats of approx. 250g � younger rats might lead to di�erentresults.
4.5. PROCESSING 61
The con�dence value, c, for the largest cluster to be the one corresponding
to the rat in a list of clusters is
c =
{1n if s1 = s2
s1−s2s1
·(1− 1
n
)+ 1
n otherwise
with n being the number of clusters in the list, s1 being the size of the largest
and s2 being the size of the second largest cluster. Therefore, the con�dence
value drops with a larger number of clusters but rises when a greater di�erence
in size between the two largest clusters exists.
The current implementation of the con�dence calculation is only prelimi-
nary. It will have to be re�ned as further experiments provide us with more
insight about possible distracting elements and how they should be treated in
the calculation.
4.5.2 Pipeline
The positional data is fed into the experiment processing module, called the
pipeline. Every rat box has its own pipeline instance.
The pipeline is essentially a signal function from PlInput to PlOutput. The
input type PlInput, de�ned in the PipelineInput module, consist of the position
data for all sensor frames of a box and the corresponding con�dence values.
The output (PlOutput from the PipelineOutput module) is a list of PlPartOutput
elements; such partial outputs can come from event sources informing about
their current state (e.g. how far has a timer progressed), from e�ect elements
(e.g. command to turn a footshock device on or o�) or from control components
(e.g. goto commands). The pipeline's output is used in later steps to control
attached devices, produce graphical output or to write log �les.
type P i p e l i n e = SF P l I npu t PlOutput
data P l I npu t = P l I npu t {−− Pos i t i on data f o r a l l framesp l iRa tPo s : : [Maybe Ra tPo s i t i o n ] ,p l i C o n f i d e n c e : : Con f i d ence
}
data Ra tPo s i t i o n = Ra tPo s i t i o n {−− Coordinates o f ra t po s i t i on ' s cen t rerpXPos : : ! Coord ,rpYPos : : ! Coord ,−− Rat ' s shadow arearpXSpread : : C l u s t e r ,rpYSpread : : C l u s t e r
}
62 CHAPTER 4. IMPLEMENTATION
data PlPartOutput = P l oE f f e c t P l E f f e c t| P loEvent P lEvent| P l oCon t r o l P lCon t r o l| P loNoth ing
The pipeline is composed dynamically of available subcomponents as speci�ed
by the user in the experiment description �le (see language speci�cations in �4.2
and the section on pipeline building on page 68). Such components include event
sources, control �ow elements and e�ect modules. Conceptionally, the pipeline
is implemented as a recursive data type: it's primary components (control �ow
elements and e�ect modules) are pipelines themselves. Event sources are not
of the pipeline type as they need to convey a di�erent kind of output; event
sources are only useful in combination with the upon . . . do . . . structure used
to react to detected events, which themselves are pipelines.
Event-Raising Modules
All event modules, also referred to as event sources, are of the type
type PlEven to r = SF P l I npu t P lEvent
that is they transform the pipeline's input into a value of the PlEvent type.
Every event source has its own PlEvent subtype containing information about
its state and whether its event conditions have been met.
Unfortunately, the term event applies to two kinds of events: Those at the
pipeline level (PlEvent) and those implemented by YaMPA. YaMPA events
are parametric types similar to the monadic Maybe type: They are either an
actual event carrying a value of the given type (analogous to Just a), or they
are NoEvent (Nothing):
data Event a = Event a| NoEvent
YaMPA uses those events to initiate switching from one signal function to
another (see below).
PlEvents also contain a YaMPA event to be able to indicate that the events
condition have not yet been met (in which case the YaMPA event �eld will sim-
ply be NoEvent). This way, event sources such as timers can convey information
about their state (such as �time left�) even if no event has occurred.
Timer. The timer module returns a PlvTimer record which contains aYaMPA
event once a speci�ed amount of time has elapsed. The PlvTimer structure also
contains the remaining as well as the total time.
4.5. PROCESSING 63
p l A f t e r : : Time −> PlEven to rp l A f t e r d e l a y = proc p l i −> do
t <− l o c a lT ime −< ()e <− a f t e r d e l a y ( ) −< ()re tu rnA −< PlvTimer d e l a y ( d e l a y − t ) e
data PlEvent = . . .| PlvTimer {
p l v tT o t a l : : Time ,p l v tRema in i ng : : Time ,p l v tT imeout : : Event ( )
}
The time elapsed since the start of the timer is determined by localtime which is
a YaMPA-supplied signal function transforming arbitrary input into the time
elapsed since the signal function was started (localtime does not give the ab-
solute system time or time elapsed since the entire system was started). Once
the speci�ed time (delay) has elapsed, the signal function after raises a YaMPA
event which is bound to e. The plvtTimeout �eld of the returned PlvTimer struc-
ture will thus be NoEvent until delay seconds have elapsed, it will then turn into
an Event for one sampling cycle. Afterwards it will fall back to NoEvent and
stay in this state forever.
Random timer. The random timer module returns a PlvRTimer record that
holds a YaMPA event once a randomly chosen time has elapsed. The random
time value is bound by the user-speci�ed limits min and max. The PlvRTimer
values also contain the lower and upper bound for the random time value and
the time elapsed since the start of the function.
plRandom : : RandomGen g => g −> Time −> Time −> PlEven to rplRandom gen min max = proc p l i −> do
t <− l o c a lT ime −< ()e <− sw i t c h ( con s t an t noEvent &&& a f t e r min ( ) )
(\_ −> plRandomAux ) −< ()re tu rnA −< PlvRTimer min max t ewhere
plRandomAux : : SF a ( Event ( ) )plRandomAux = proc p l i −> do
t <− a f t e r (max − min ) ( ) −< ()e <− o c c a s i o n a l l y gen ( (max − min ) / 2) ( ) −< ()re tu rnA −< t `merge ` e
data PlEvent = . . .| PlvRTimer {
p l v rMin : : Time ,plvrMax : : Time ,p l v r E l a p s e d : : Time ,p l v tT imeout : : Event ( )
}
64 CHAPTER 4. IMPLEMENTATION
The plRandom signal function maintains the time elapsed since its start in t.
Its primary behaviour is split into two segments, used in sequence, that are
controlled by the switch function:
1. Until min seconds have elapsed, it will only return NoEvent. Then, after
min () causes switch to swap to plRandomAux.
2. Once the plRandomAux function takes over, it returns NoEvent until either
the upper bound for an event to be raised occurs (controlled by after), or
occasionally triggers an event by chance.
In either case, the output structure's plvtTimeout �eld will contain an event for
one cycle. Afterwards, it falls back to the NoEvent state.
It should be noted that the YaMPA-supplied function occassionally r f e trig-
gers an event at an average frequency of f (the other two parameters r and e can
be ignored here). As speci�ed in the YaMPA documentation, the probability
p of an event being triggered at time t is
pevent = 1− e−f ·t
YaMPA currently provides no other means for randomly occurring events.
Line crossing detector. The line crossing module's output PlvLCD is con-
taining an event i� the speci�ed line has just been crossed.
p lLcd : : LCDLine −> PlEven to rp lLcd l i n e = proc p l i −> do
e <− a r r p l iRa tPo s >>> mkL ineCros sDetec to r l i n e>>> a r r l c doC ro s s ed >>> a r r ( ` tag ` ( ) ) −< p l i
r e tu rnA −< PlvLCD l i n e e
data PlEvent = . . .| PlvLCD {
p l v l L i n e : : LCDLine ,p l v l C r o s s e d : : Event ( )
}
The function extracts the rat's position from the pipeline input structure (bound
to pli) using pliRatPos. The position is fed to a newly created line crossing
detector for the given line, which will trigger a YaMPA event once the line is
crossed (stored in the lcdoCrossed �eld of its output record). This event is used
to indicate the crossing of the line by the rat in the output value.
The line crossing detection is performed by the LineCrossDetector module.
It uses YaMPA's edgeBy function to detect and signal whether the rat has
switched sides. The edgeBy function encapsulates a stateful computation since
it allows comparison of a signal's value to its previous value.
4.5. PROCESSING 65
Standing-up detector. The standup detector module's output PlvStandup
holds an event i� the rat has just stood up. The corresponding pipeline module
is fairly simple:
p lStandup : : P lEven to rp lStandup = proc p l i −> do
e <− a r r p l iRa tPo s >>> mkStandupDetector>>> a r r sudoStoodup −< p l i
r e tu rnA −< PlvStandup e
The rat position (pliRatPos) is fed into a newly created standup detector (mk-
StandupDetector). The output of the detector is then checked for standup events
using sudoStoodup.
Low con�dence. The low con�dence event module triggers an event as soon
as the con�dence in the position that has been determined for the rat from the
input data drops below a given minimum value.
p lCon f i d e n c e : : Double −> PlEven to rp lCon f i d e n c e minc = proc p l i −> do
l e t cv = p l i C o n f i d e n c e p l ie <− edge <<< a r r (< minc ) −< cvre tu rnA −< PlvMinConf cv minc e
The module's output type PlvMinConf contains as well as the low-con�dence
indicating event, the current con�dence value and the minimum value tested for.
An interesting case of partial function application is the half-done comparison
(< minc) � this expression represents a single-argument function that returns
true when its argument is less then minc, and false otherwise.
Control Flow Modules
Control �ow modules are primarily implemented in a continuation-passing like
style: Until something happens, do this, then do that. To implement the until-
then-swap, YaMPA's switch functions are used. A switch function usually takes
two signal functions a and b (some switching functions work on collections of
signal functions, but the basic functionality remains the same). It then runs as
a to begin with, until it receives an event (the origin of the event varies with
the type of switch function). Upon the event, it switches into function b, and
function a is discarded. The following pseudo code snippet resembles the switch
functionality in an imaginary C++-like language:
function switch (
function a,
function b,
66 CHAPTER 4. IMPLEMENTATION
inputstream is,
outputstream os
)
{
while (! event)
{
input_sample <<< is;
output_sample = a (input_sample);
event = is_that_an_event (output_sample);
os <<< output_sample;
}
os <<< b <<< is;
}
Delay until event. The upon-do RTCL element is realized by the plDoUntil
function. It takes two arguments: an event source ev, and a (sub-)pipeline
pl. Until the event source ev raises an event, plDoUntil passes on ev's output,
afterwards it switches into the continuation pipeline pl.
p lDoUnt i l : : P lEven to r −> P i p e l i n e −> P i p e l i n ep lDoUn t i l ev p l =
sw i t ch sw i t c h e r (\ e −> p l >>> addSwitchPlpo e )where
sw i t c h e r : : SF P l I npu t ( PlOutput , Event PlPartOutput )sw i t c h e r = ev >>> (mkPlOutput &&& mkPartOutputEvent )
mkPlOutput : : SF PlPartOutput PlOutputmkPlOutput = a r r P loEvent >>> a r r ( : [ ] )
mkPartOutputEvent : : SF PlPartOutput ( Event PlPartOutput )mkPartOutputEvent = a r r (\ e −> p l e v e ` tag ` P loEvent e )
The switcher function passes the event source's output to both mkPlOutput and
mkPartOutputEvent and combines their respective outputs to a pair. mkPlOutput
transforms the event source's output of type PlPartOutput to a PlOutput type,
and mkPartOutputEvent turns the output into a YaMPA event needed by the
switch function to cause the switch to pl.
In YaMPA, one can choose between two styles of �switching�: regular (e.g.
switch) and delayed (e.g. dSwitch). As a reminder, in simpli�ed terms, switching
means to �run a given function a, and once a certain event occurs, run function
b instead of a�. The switch function s thus behaves �rst like a, then like b. With
regular switching, the switch-causing event is used to trigger the switching, but
its associated output value from function a is not passed on � in the cycle of
the switch, the value of the switch function s is already that of the function b
4.5. PROCESSING 67
switched into. With delayed switching, the switch occurs in�nitesimally after
the switching event. Therefore, in the cycle of the switch, s still behaves like a,
and becomes b right after the switch cycle.
The problem is that one output value is lost, either a's or b's. However, in
our implementation, we need to pass on both, the event that caused the switch
and the �rst output of the continuing function b (which will most likely contain
a response to the switch-causing event). Therefore, the output is piped through
addSwitchPlpo, which prepends the switching event to this �rst output.
Select upon event. The plDoUntilAny function implements the RCTL ele-
ment upon (. . . ) with multiple event-e�ect pairs. These pairs are handed to
plDoUntilAny as a list in argument ples. Until the �rst event is raised by any
of the event sources, all their output is passed on by plDoUntilAny. Once this
�rst event occurs, it switches into the (sub-)pipeline associated with the event
source.
p lDoUnt i lAny : : [ ( P lEventor , P i p e l i n e ) ] −> P i p e l i n ep lDoUnt i lAny p l e s =
sw i t ch sw i t c h e r (\ ( e , p l ) −> p l >>> addSwitchPlpo e )where
sw i t c h e r : :SF P l I npu t ( PlOutput , Event ( PlPartOutput , P i p e l i n e ) )
sw i t c h e r = proc p l i −> do
e s <− parB (map wrapPa i r p l e s ) −< p l ir e tu rnA −< (map f s t es , mergeEvents (map snd e s ) )
wrapPa i r : : ( P lEventor , P i p e l i n e )−> SF P l I npu t
( PlPartOutput , Event ( PlPartOutput , P i p e l i n e ) )wrapPa i r ( ev , p l ) =
ev >>> ( a r r P loEvent &&&a r r (\ e −> p l e v e ` tag ` ( P loEvent e , p l ) ) )
The event source/pipeline pairs are respectively combined into signal functions
from pipeline input to output/event pairs by wrapPair. The events in those
pairs are used to carry the associated continuation pipeline that is to be used
in case the event source is the �rst one to trigger. The switcher function passes
the pipeline input on to all those signal functions using parB. It then combines
their output (�rst elements of the output/event pairs) to a PlOutput type, and
merges the list of events into one event (second elements of the output/event
pairs). The event parts of the output are usually all NoEvent in the beginning,
i.e. not indicating an event, until an event occurs. Once this �rst event occurs,
the switch function uses this event to extract the carried continuation pipeline
and switch into it. Like plDoUntil, it prepends the event sources' output values
from the cycle the switch occurred in.
68 CHAPTER 4. IMPLEMENTATION
Loops. The label switch function lSwitch is used to implement labels and goto
jumps in RTCL (see the section on jumps on page 45). Recall that labels are used
as targets for backward jumps, and are written as �Label: RTCL code� � when
the label is jumped to, the code following the label is executed. lSwitch is given
the name of the label label and the (sub-)pipeline pl for the code associated with
the label as arguments. It will then run this pipeline pl and watch the pipeline's
output for goto events. If such an event occurs for label, it starts the pipeline
all over again, thus causing a jump back to the label.
l Sw i t c h : : S t r i n g −> P i p e l i n e −> P i p e l i n el Sw i t c h l a b e l p l =
kSwitch p l l a b e l E v (\_ p l o −> ( l Sw i t c h l a b e l p l>>> prependPrev p l o ) )
where
i sLabe lJump : : P lPartOutput −> Bool
i sLabe lJump ( P l oCon t r o l ( PlcGoto l ) ) = l == l a b e li sLabe lJump _ = Fa l s e
hasLabelJump : : [ PlOutput ] −> Bool
hasLabelJump = not . n u l l . f i l t e r i sLabe lJump
l a b e l E v : : SF ( P l Input , PlOutput ) ( Event PlOutput )l a b e l E v = proc (_, p l o ) −> do
e <− edge <<< a r r hasLabelJump −< p lore tu rnA −< e ` tag ` p l o
prependPrev : : PlOutput −> SF PlOutput PlOutputprependPrev p = proc p l o −> do
pe <− now p −< ()re tu rnA −< (( even t [ ] i d pe ) ++ p lo )
The kSwitch function has been chosen in anticipation of future functionality, the
di�erence to switch is not relevant for the understanding of lSwitch. kSwitch runs
the pipeline pl until labelEv returns an event; in this case it will call upon itself
again as continuation. labelEv is a signal function that watches the PlOutput
values received from pl for goto events by testing each partial value of the output
using isLabelJump. Until a jump to the speci�ed label occurs, labelEv returns
NoEvent; upon the jump, it returns an event with the pipeline's output attached
to it (this attached output is used by prependPrev so that in the cycle of the
jump, no output is lost).
Pipeline Building
The user-speci�ed experiment description is transformed into a pipeline during
an initial pipeline building process. To illustrate the recursive nature and the
structure of the pipeline, the intermediate PipelineTree type is shown:
4.5. PROCESSING 69
−− Labe l l e d code segmentdata P i p e l i n eT r e e = PtLabe l ed S t r i n g P i p e l i n eT r e e
−− Execute mu l t i p l e sub−p i p e l i n e s| PtAnd [ P i p e l i n eT r e e ]−− Upon . . . do . . .
| PtUpon Evento r P i p e l i n eT r e e−− Upon ( e1 do f1 , e2 do f2 , . . . )
| P tF i r s tW in s [ ( Eventor , P i p e l i n eT r e e ) ]−− Execute an e f f e c t
| PtDo P lE f f e c t Sw i t c h−− Jump to l a b e l / abor t
| P tC t r l P lCon t r o l−− Nothing
| PtNoop
−− E f f e c t sdata P lE f f e c t Sw i t c h = P l fFoo t shock Bool
| P l f L i g h t Bool
| P l fSound Bool
| P l fNo th i ng
−− Abort the en t i r e p i p e l i n edata P lCon t r o l = PlcAbor t
−− Jump to a l a b e l| P lcGoto S t r i n g
l
The recursion becomes apparent in most elements; a labelled segment is another
PipelineTree with a label, simultaneous execution is represented by a list of
pipeline trees, etc. E�ects are handled using the PtDo type constructor since
the actual type of e�ect is irrelevant at the pipeline execution level, the details
are only needed at the output level.
The building process consists of multiple steps:
1. A lexer (PipelineLexer, generated with Alex5) decomposes the input (nor-
mally read from an experiment description �le) into tokens (words, punc-
tuation marks, etc.). The lexer serves to produce a normalized version
of the input �le by removing comments and excessive white spaces. Mis-
spelled keywords are also detected at this level.
2. The resulting list of tokens is then fed to a parser (PipelineParser, gen-
erated with Happy6). The parser �rst identi�es language elements and
then creates a syntax tree (PipelineTree) representing the experiment de-
scription. The parser can combine consecutive tokens into structures of
the languages, for example an event source with its arguments. Errors in
the experiment description such as wrong numbers of arguments, incorrect
use of parenthesis etc. will be detected at the parser level.5See http://www.haskell.org/alex/6See http://www.haskell.org/happy/
70 CHAPTER 4. IMPLEMENTATION
3. The parser-generated syntax tree serves as a blue print for pipeline build-
ing in the RatBox module.
The last step is performed by the build function of the Pipeline module:
b u i l d : : RandomGen g => g −> P i p e l i n eT r e e −> P i p e l i n eb u i l d gen t r e e = bu i l dAux t r e e
where
−− Turn a Pipe l ineTree in t o a P ipe l i n ebu i l dAux : : P i p e l i n eT r e e −> P i p e l i n e−− Labe l s are handled by l Sw i t chbu i l dAux ( PtLabe l ed l t ) = l Sw i t c h l ( bu i l dAux t )−− Execute mu l t i p l e s ta tements s imu l t aneous l y−− and concat outputbu i l dAux (PtAnd t s ) = ( parB (map bu i l dAux t s ) )
>>> a r r concat
−− More to f o l l ow , one f o r each Pipe l ineTree cons t ruc t o r. . .
The intermediate step of a tree representation has various advantages: First,
a separate pipeline signal function must be created for every rat box. It is more
e�cient to generate a blue print initially and use that for pipeline building
than to repeat the entire parsing process for every box. Second, the separation
of parsing and pipeline building allows for clearer and more comprehensible
responsibilities of the participating modules. Lastly, the pipeline tree structure
can easily be used for debugging output to verify correct parsing.
4.6 Output
The pipelines' output is fed into a central output module along with the infor-
mation on the rat boxes. The various output channels are initialized by this
module using
i n i tOu t pu t : : AWorld −> Runt imeConf ig −> IO [ Output ]
where Output is an opaque data type serving as a handle for an output channel.
The actual output is performed by
output : : [ Output ] −> [ RatBox ] −> [ OutputData ] −> IO ( )
which is called in every cycle after the data has been sent through the pipeline.
output is responsible for sending a RatBox's OutputData to the appropriate Out-
putChannels. The list of RatBoxes and the list of OutputData are expected to be
corresponding, i.e. the ith output sample should be for the ith rat box. This
is not true for the output channels, where every channel is given the full list of
boxes and output samples, and has to take care of the distribution itself:
4.6. OUTPUT 71
c l a s s OutputChannel a where
outputData : : [ RatBox ] −> [ OutputData ] −> a −> IO ( )
A centralized instance for handling output proved necessary as some output
channels require combined input of all rat boxes (mainly the graphical output
module). An overview of the output process is given in Figure 4.5.
4.6.1 E�ects
The output of the e�ect modules (for example light on or footshock o� ) is
transmitted to the respective rat box's controller over the dedicated CAN bus
connection.
Since the desired status of a device is transmitted rather than the change
in status, whereas the pipeline emits events describing this change, the Output-
CanBus module must keep track of the devices current status. The CAN bus
output module provides the CanBusOut type, which servers as a handle for the
physical CAN-bus to be used for output (and thus indirectly to the interface
device for output) and contains a list of the current statuses of the rat boxes7.
data CanBusOut = CanBusOut {cboCanBus : : CanBus ,cboLastMsgs : : [ ( In t , IORef Word8 ) ]
}
i n s t a n c e OutputChannel CanBusOut where
outputData = (\ rb s ods oc −> sendCanMessages oc r b s ods )
sendCanMessages : : CanBusOut −> [ RatBox ]−> [ OutputData ] −> IO ( )
The CanBusOut type is, as all output handles, opaque � it therefore does not
provide access to the contents of the record (since the statuses are modi�able,
special care should be taken that they cannot be altered from the outside).
On an incoming output sample, it overlays the stored messages previously
sent with the changes that might be contained in the sample. The resulting
status description is stored and send out to the node controller using the CanBus
module's
sendCanData : : I n t −> Word8 −> IO ( )
function that takes the ID of the targeted box and the single-byte data, and then
calls the transmitting function of the I/O layer (C code segment) to perform
the actual transmission.7Since Haskell does not have a notion of variables with modi�able content, the IO monad
and the Data.IORef module need to be used. They provide the means to have modi�ablereferences to values. Such a reference to a value of type a is denoted by IORef a.
72 CHAPTER 4. IMPLEMENTATION
YaM
PA
Mai
nC
anB
usO
utpu
tO
utC
hann
elH
GLA
nim
ate
reac
tLoo
p()
re
actim
ate(
)
loop
[at l
east
one
pip
elin
e is
stil
l run
ning
]
reac
tInpu
t()
[Can
Out
put]
re
actT
rans
form
er([C
anO
utpu
t])
[Out
putD
ata]
re
actA
ctua
tor(
[Out
putD
ata]
)
outp
ut([O
utpu
tDat
a])
loop
fore
ach
Out
putC
hann
el:
outp
ut([O
utpu
tDat
a])
an
imat
e([O
utpu
tDat
a])
Figure 4.5: Data Output Overview
4.6. OUTPUT 73
Figure 4.6: Screenshot of RatTracker showing two square boxes with ratsmoving around in them. The white bars represented interrupted sensors in thelower frame, the red areas show the (assumed) position of the rats in the lowerframe, the pink areas the position in the upper frame, and purple areas indicateoverlaps between the rats' shadows in the two frames. A blue bar indicates aline the rat is expected to cross (this output is caused by the lcd event module).The green numbers represent the status of various timer event sources.
The node controller then turns devices on or o� as speci�ed in the received
message.
4.6.2 Graphical Output
We provide a graphical display of the rat boxes for monitoring purposes. Cur-
rently, we use Haskell's HGL library for graphical output.
A screenshot of the graphical output for two active boxes is shown in pic-
ture 4.6.
Drawing of di�erent output types. Our system processes and produces
a variety of data, such as raw sensor information, positional data, statuses of
event sources from the pipelines, etc. To provide a �exible mapping from those
data types to graphical output, we introduced a type class HglDrawable:
c l a s s HglDrawable a where
hglDraw : : AWorld −> HglCanvas −> a −> HGL. Graph i c
Every type a that is to be drawn is made an instance of this class. The type-
speci�c implementation of hglDraw de�nes how this type a is drawn. For com-
posed types, the implementation calls the hglDraw instance functions for the
74 CHAPTER 4. IMPLEMENTATION
subelements. The resulting HGL.Graphic elements are then combined into the
output image.
The drawing instruction for the pipeline output of type PlOutput for example
draws all the contained event source statuses by calling their individual hglDraw
functions and combining the results into one HGL.Graphic element.
−− How p i p e l i n e output i s drawn :i n s t a n c e HglDrawable PlOutput where
hglDraw wor ld canvas p l o =−− Combine the events ' graphsf o l d l ove r HGL . emptyGraphic e v en tg r aph s
where
−− Apply the hglDraw func t i on f o r PlEvent to every evente v en tg r aph s : : [HGL . Graph i c ]e v en tg r aph s = map ( hglDraw wor ld canvas ) numberedevents
−− Assoc t i a t e the even t s wi th consecu t i v e numbers−− which can be used to draw them one below the o ther−− by z i pp in g them with an i n f i n i t e l i s t o f in t ' s−− beg inn ing at 1 ( [ 1 . . ] )numberedevents : : [ ( PlEvent , I n t ) ]numberedevents = z i p e v en t s [ 1 . . ]
−− Retr i eve the even t s from the p i p e l i n e output−− ( which a l s o i n c l u d e s e f f e c t commands e t c . )e v en t s : : [ P lEvent ]e v en t s = p lEv en t s p l o
−− How d i f f e r e n t p i p e l i n e even t s are drawn ,−− us ing pa t t e rn matching :i n s t a n c e HglDrawable ( PlEvent , I n t ) where
−− Draw a timer event source at p o s i t i o n phglDraw wor ld canvas ( ( PlvTimer t t r t e ) , p ) = . . .
−− Draw a random timer event source at p o s i t i o n phglDraw wor ld canvas ( ( PlvRTimer l t ut e t e ) , p ) = . . .
−− Draw a l i n e c ro s s i n g d e t e c t o r ( b l u e bar )hglDraw wor ld canvas ( ( PlvLCD l e ) , _) =
(over combines two HGL.Graphic entities into one, and HGL.emptyGraphic is sim-
ply the null element for a fold of HGL.Graphics).
YaMPA�HGL interaction. One peculiarity about the graphical output
module is that both, the HGL library and the YaMPA library, need to use
a continuously running loop, similar to the main application loop known from
other GUI toolkits such as GTK8. Exploiting the �rst-class entity property
of functions in Haskell, this can easily be worked around by using callback
8See http://www.gtk.org/.
4.6. OUTPUT 75
Main CanBus [RatBox] Pipeline Graphics
run
animate
reactLoop
loops untilexperimentis finished
getCanData
[CanOutput]
parCanOutput
pipe
[OutputData]
[OutputData]
drawCallback
Figure 4.7: Callback Cascade for graphical output loop
functions as depicted in Figure 4.7 (the idea is taken from the Space Invaders
game written as an example for YaMPA by its authors).
Once the Main module's run function is called, it initializes HGL's output by
calling animate. To trigger the data acquisition and pipelining process, animate
calls a callback function supplied by run, reactLoop, while passing on a callback
function itself (drawCallback). When reactLoop has �nished retrieving data from
the CAN bus and sending it through the pipeline, it passes the results to the
HGL subsystem using the callback function drawCallback. Once this function
returns, reactLoop starts a new iteration.
4.6.3 Output Files
All events occurring within the pipeline are logged to �les, one per rat box.
Each line in those �les describes the events that occurred at a certain point in
time. The time value, given at the beginning of each line, represents the number
of milliseconds elapsed since the experiment start.
0 [sound off,light off,footshock off]
35310 [Random Timer: 30.94499999999956/20.0-40.0T,sound on,
light on]
47590 [Timer: -4.999999999864002e-3/10.0T,footshock on]
53540 [Timer: -7.999999999979579e-3/5.0T,go back to START,
ound off,light off,footshock off]
89340 [Random Timer: 31.086999999999616/20.0-40.0T,sound on,
light on]
101510 [Timer: -1.99999999998699e-2/10.0T,footshock on]
76 CHAPTER 4. IMPLEMENTATION
107530 [Timer: -9.999999999977582e-3/5.0T,go back to START,
sound off,light off,footshock off]
142780 [Random Timer: 31.07099999999956/20.0-40.0T,sound on,
light on]
154110 [Timer: -1.5999999999872117e-2/10.0T,footshock on]
160190 [Timer: -1.9999999999793516e-3/5.0T,go back to START,
sound off,light off,footshock off]
193840 [Random Timer: 28.91899999999987/20.0-40.0T,sound on,
light on]
206310 [Timer: -1.899999999987223e-2/10.0T,footshock on]
212330 [Timer: -8.999999999972808e-3/5.0T,go back to START,
sound off,light off,footshock off]
247580 [Random Timer: 31.161999999999555/20.0-40.0T,sound on,
light on]
257590 [Timer: -4.999999999878213e-3/10.0T,footshock on]
The above �le format is designed to be readable. For automated experiment
analysis and evaluation, we use a format more suitable for machine reading;
the events are represented by a bitmask and no additional information (such as
total time for countdowns) is recorded.
4.7 Runtime Con�guration
In addition to the previously described RTCL �le, RatTracker has two further
con�guration steps, one dealing with the technical setup and one regarding the
individual trial's parameters. The con�guration of the system is done in three
stages re�ecting the requirements stated in �1.3.
4.7.1 Technical Con�guration
Note: This section primarily refers to the TheWorld-module described in �4.3.2.
The technical con�guration covers settings related to the CAN bus, the graphical
output and the low-level aspects of position tracking. These settings are stored
in an INI-style �le9, which has the format
[SECTION1]
item1 = value1
9The INI �le-format is used under Microsoft WindowsTMfor various con�guration purposes,under Unix it is known from Samba's smb.conf for example. Complete speci�cations can befound at http://cloanto.com/specs/ini.html.
4.7. RUNTIME CONFIGURATION 77
item2 = value2
[SECTION2]
item3 = value3
Currently, four sections are de�ned: CANBUS (CAN bus related items),
BOXES (box related items), TRACKER (position tracking related items) and
GRAPHICS (graphical output related items). An overview of the available
con�guration options is given in table 4.1.
The devices for the input and the output bus are given as Linux device
nodes. At the time of writing, it was not been possible to identify the CAN-bus
controllers by their serial number or similar means. An auto-detection of which
of the two buses serves as input and which as output bus proved not to be
reliable enough. The bus speeds are speci�ed as (preferably octal) numbers as
de�ned in libpcan.h, provided with the driver package for the CAN interface
controller.
Since the CAN-bus architecture allows for an arbitrary set of boxes to be
used, the id numbers of the involved boxes can be speci�ed as a list. To ac-
commodate di�erent shapes of cages, a list of photo sensors that ought to be
ignored can be given by the administrating user for each dimension.
As the number of photo sensors that are normally intercepted by a rat varies
with the total number of sensors, a minimum and a maximum of interrupted
sensors for the rat detection can be stated in the con�guration �le.
The layout of the graphical monitoring window can be controlled by spec-
ifying its width, height and number of columns (multiple monitored boxes are
displayed in a grid-like fashion).
4.7.2 Trial Con�guration
For each trial, a small number of parameters needs to be set, namely:
1. The name of the overall experiment.
2. The name of the current trial run.
3. The name of the rat (including indication of the group, test group or
control group).
4. The name of the operator.
The values for the parameters are asked from the operator in the console at the
beginning of the trial.
78 CHAPTER 4. IMPLEMENTATION
Item Description Type Default
CANBUS-Sectioninput_device Device path of
input bus (boxes)string /dev/pcan1
input_speed Bus-speed ofinput bus
numeric 0x14
output_device Device path ofoutput bus(e�ects)
string /dev/pcan0
output_speed Bus-speed ofoutput bus
numeric 0x1c
BOXES-Sectionboxes Node IDs of used
boxesnumeric list 1
frames Number of frames numeric 1sensors Number of photo
sensors per frameand dimension
numeric 40
sensormaskx Ignored photosensors inX-dimension
numeric list
sensormasky Ignored photosensors inY-dimension
numeric list
TRACKER-Sectionminsize Minimum number
of interruptedsensors for ratdetection
numeric 2
maxsize Maximim numberof interruptedsensors
numeric 10
GRAPHICS-Sectiontitle Title of output
windowstring RatTrack
width Width of outputwindow
numeric 400
height Height of outputwindow
numeric 400
columns Number ofcolumns in outputwindow (numberof required rowsis determinedautomatically)
numeric 1
Table 4.1: Technical con�guration options
Chapter 5
Experiment
In order to prove our system's practicality, usability and reliability, we conducted
a conditioned avoidance experiment under normal laboratory conditions.
5.1 Methods
Subjects. We used 16 12-week old male Wistar rats. Four of the rats received
a chronic haloperidol decanoate1 treatment prior to the experiment for 4 weeks
in another study, with a no-treatment period of 2 weeks before our experiment.
The other 12 rats participated in the same experiment but received vehicle2
only. We will refer to the haloperidol-treated rats as �H-rats� and to the vehicle
ones as �V-rats� where distinction between the two groups is needed. The rats
were caged in groups of 3 with water and food ad lib under a 12/12 light cycle
with light o� at 6p.m.
Apparatus. We used custom-built shuttle boxes made of Plexiglas as intro-
duced earlier in �2.2. The two compartments of a box are of cubic shape with a
length of 30cm in each dimension and they are separated by a wall of full height.
The animal can shuttle between the two compartments through a 8cm hole in
the wall, placed centrally 2cm above ground. A Coulbourn Instruments
(Allentown, Pennsylvania, USA) E13-14 precision regulated shocker adminis-
tering footshocks over a metal grid in the boxes' �oor served as the uncondi-
tioned stimulus (US). The shocker output electric shocks in the form of a square
wave polarity reversal at 33.3 Hertzs. It operated in �scanned� mode where the
1Haloperidol is a strong neurolepticum that is also used to induce symptoms resemblingParkinson syndrome such as catalepsy. Haloperidol decanoate is a long-acting ester derivativeof haloperidol that shows e�ects over days or weeks[62].
2A vehicle is a carrier used to dissolve a substance in and to inject this substance, forexample salt water (NaCl solution) or sesame oil.
79
80 CHAPTER 5. EXPERIMENT
shocker distributes the polarity reversal across an 8-pole output. The shocks'
current was �xed at 0.1 milliamperes. For conditioned stimuli (CS), we used a
0.5 Watts buzzer and two 2.2 Watts light bulbs mounted to the lid of the boxes.
Design. A one-trial conditioned avoidance response procedure was used to
test for the e�ects of a temporal overlap between the conditioned and the un-
conditioned stimuli on acquisition performance. The rats were divided into two
experimental groups of 8 animals each. Each group consisted of 2 H-rats and 6
V-rats. Both groups were treated similarly, except for the overlap between the
CS and the US:
1. Group 1 �rst experienced the CS by itself, and then the US paired with
the CS until both were turned o� (�US with CS�).
2. For group 2, the onset of the US followed directly on the o�set of the CS,
with no temporal overlap between the two (�US after CS�).
The CS alone was presented for 10 seconds, the US (either by itself or paired
with the CS) for 5 seconds.
Procedure. Each trial took 30 minutes and consisted of multiple runs. During
each run, the CS was presented after a randomly chosen time between 15 and
30 seconds. If the animal crossed the barrier before the onset of the US, the
CS was turned o� and the next run was started. If however the animal failed
to switch compartments within the 10 seconds of CS presentation, the US was
turned on (for group 2 the CS was turned o� the instance of the US's onset, for
group 1 the CS remained active). The US (US/CS pair for group 1) stayed on
until either the animal crossed the barrier or a timeout of 5 seconds occurred.
In either case, the next run would begin.
The animals' reactions to the conditioned and unconditioned stimuli are
categorized as
1. avoidance if the animal shuttles during the presentation of the conditioned
stimuli and thereby avoids being exposed to the aversive unconditioned
stimulus.
2. escape if the animal switches compartments during the presentation of the
unconditioned stimulus.
3. failure if the animal does not shuttle during the entire presentation of
stimuli of one run.
5.2. RESULTS 81
10 20 30 40Run
0
20
40
60
80
100
Acc
umul
ated
Avo
idan
ces
US with CSUS after CS
Avoidances
Figure 5.1: E�ects of temporal overlap of CS and US on the number of accu-mulated avoidances over 40 runs, showing an overall stronger increase rate forgroup �US with CS�.
5.2 Results
The animals with haloperidol experience were discarded in the results as two of
them often reacted to the footshocks with inactivity, one produced 31 failures
in the �rst 40 runs but only one avoidance.
As shown in Figure 5.1, there was a signi�cantly higher rate of avoidances
for the animals exposed to the CS and the US simultaneously (p < 0.05 using
a Mann-Whitney U-test). The animals in group 1 showed a stronger increase
in avoidances than the animals in group 2, especially between runs 30 and 40.
The animals that experienced the US only after the CS showed a higher rate
of escapes (Figure 5.2), however without signi�cance (p = 0.09, rounded to a
hundredth). Both groups show similar escapes rates until run 30 after which
the accumulated number of escapes for group 1 shows less increase compared
to group 2. The number of failures shows no signi�cant di�erence (p > 0.9) asdepicted in Figure 5.3. Both groups reach a plateau in the accumulated number
of failures after run 32, the development of such a plateau becomes already
apparent in run 20.
82 CHAPTER 5. EXPERIMENT
10 20 30 40Run
0
20
40
60
80
100
120
140
160A
ccum
ulat
ed E
scap
es
US with CSUS after CS
Escapes
Figure 5.2: E�ects of temporal overlap of CS and US on the number of accumu-lated escapes over 40 runs, showing a drop in increase for group �US with CS�after run 30.
10 20 30 40Run
0
5
10
15
20
25
Acc
umul
ated
Fai
lure
s
US with CSUS after CS
Failures
Figure 5.3: E�ects of temporal overlap of CS and US on the number of accu-mulated failures over 40 runs, with a plateau formation between runs 20 and32.
5.3. DISCUSSION 83
5.3 Discussion
As the H-rats were given a chronic treatment with haloperidol decanoate, their
poor performance might be caused by long-term e�ects of the treatment. Given
their precondition, we considered it to be acceptable to exclude the 4 rats with
haloperidol experience from the results.
In accordance with previous �ndings[21], we could show that a temporal
overlap of the conditioned (CS) and the unconditioned (US) stimuli facilitates a
higher rate of avoidances in a CAR experiment, compared to separately applied
stimuli. The experience of the CS together with the US appears to help rats to
associate the two.
The results presented in this study suggest that simultaneous exposure to
the conditioned and the unconditioned stimuli facilitates the cognition of the
conditioned stimulus as being a warning signal prior to the unconditioned one.
84 CHAPTER 5. EXPERIMENT
Chapter 6
Conclusions
6.1 Results
In the course of this thesis, we successfully described and implemented a fully
operational system, RatTracker, to control behavioural experiments meeting
the requirements listed in the introduction.
Control and Acquisition. Our system, together with the activity monitor
developed by Hölle & Hüttner (Tübingen, Germany) combines two function-
alities that are not implemented together in other systems: Automated control
of behavioural experiments and a high-resolution recording of the animals po-
sition and locomotion.
Experiment descriptions. We devised an experiment description language,
RTCL, that allows the user to describe the experiments by writing control �les
in a style resembling verbal speci�cation of the experiments. The language
consists of only four types of elements (conditional execution, events, e�ects and
jumps), with one primary building structure (the upon statement). Feedback
from other researchers showed that, after a certain familiarisation phase, this
concept is received well.
We demonstrated the usability of the language by performing a CAR exper-
iment with two slightly di�erent setups � the control �les for the two setups
di�er only in 4 words. In the tutorial section, we also show how to realize other
experiments in RTCL. We are con�dent that RTCL will prove a suitable tool
to describe even more and more complex procedures, even though some func-
tionality remains to be implemented such as continuations of signal functions.
Further applications of RatTracker will have to show whether the state-
free paradigm (with respect to explicit states) can maintain its usability, or
85
86 CHAPTER 6. CONCLUSIONS
whether stateful elements such as mutable values should be introduced for prac-
ticability.
Con�guration. The con�guration and use of RatTracker has been divided
into separate steps to accommodate the di�erent needs and levels of experience
of the involved groups of users. The system can be con�gured to run with any
arbitrary subset of the available shuttle boxes and to exclude photo sensors from
position tracking to compensate for sensors blocked by other objects (such as
the dividing wall of the CAR boxes that blocks a single photo sensor).
Integration. The system has been fully integrated into the existing environ-
ment, namely the CAN bus addressed shuttle boxes and the activity monitor
system. The activity monitor sends start and stop messages over the CAN
bus as well as messages carrying timestamps for output synchronisation. Rat-
Tracker evaluates these together with the regular data messages sent by the
shuttle boxes. The synchronization of the timestamps used for RatTracker's
output �les allows to combine those �les with the activity output acquired by
the activity monitor. RatTracker's actions can thus be correlated to the
activity and locomotion of the rat in later analysis.
Extensibility. By writing RatTracker as a modular application, it can
easily be extended. The entire data acquisition code is encapsulated in one
C-library and one Haskell module, beyond this module the input data is ab-
stracted as detected objects (e.g. the rat) represented by rectangular areas. The
data processing pipeline even goes one step further and only operates on the
extracted position of the rat. Extending the system to new sources of input
such as video tracking systems would only require small changes to the input
layer of RatTracker. The output part of RatTracker is already realized
as a collection of output modules. New types of output such as di�erent �le
formats can be added simply by writting a new output module.
Con�dence. We introduced a con�dence value that is calculated during the
position determination step. If the con�dence in the determined position for
the rat drops below a given value, the program can be for example aborted or
an iteration can be restarted. In this way we can ensure that no stimulus is
administered unless all its prerequisites can be guaranteed.
6.1.1 Functional Reactive Programming
Functional reactive programming (FRP) and especially the FRP implementa-
tion YaMPA have proven to be suitable tools for real-world experiment control
6.2. WHAT HAVE WE LEARNED? 87
systems. RatTracker shows the reactivity needed to ensure the reliable exe-
cution of experiments.
At �rst, the number of possible states a system like RatTracker could be
in and the transitions between them seemed to necessitate a complex control
�ow structure, especially since RatTracker's functionality is not only to work
with CAR procedures but to be applicable to other kinds of experiments as
well. YaMPA with its concept of signal functions allowed us to write the main
processing part of RatTracker as a pipeline composed of modules that divide
this complexity into smaller fragments. The input data is fed into this pipeline
and passed to the various modules which independently detect events that have
occurred and determine what actions need to be taken. The strong type system
of Haskell and the �rst-class citizenship of functions facilitate the assembly
of the pipeline at run time.
The use of functional programming in general and FRP in particular also
introduces abstraction layers that re�ect the various components and aspects
of the application domain (such as hardware layer, data processing pipeline or
output layer); this ensures on one hand extensibility, and on the other hand
facilitates understanding of the system.
However, Haskell has a fairly steep learning curve, and the �rst two months
of this thesis were spent solely getting acquainted with the language. On the
other hand, the C-code section responsible for interfacing the CAN interface
required far more debugging time than the Haskell section of RatTracker,
even though the latter is by far more complex. Interestingly, both code sections
contain about the same number of lines of code, even though the Haskell
section certainly holds more functionality.
We believe that our initial considerations about the advantages of choosing
functional reactive programming for the implementation of RatTracker have
been justi�ed.
6.2 What have we learned?
First of all, I (the primary author) learned Haskell, which I did not know any-
thing about 6 months ago. The same applies to functional reactive programming.
I also learned how to write real-world applications with functional languages �
my prior experiences stop shortly after the calculation of a number's factorial or
implementing the Ackermann function. Even more, I began to learn to program
in a functional style1.
1There is a big di�erence between �programming with a functional language� and �func-tional programming�.
88 CHAPTER 6. CONCLUSIONS
Functional languages are a�icted with a notion of being ine�cient and im-
practicable. Yet we saw that by utilising the combination of Haskell and
functional reactive programming we could write elegant, extremely concise code
that proved to run e�ciently and to show good runtime behaviour.
With respect to the programming itself, we came to realize the following.
• On many occurrences, we experienced that ugly-looking code also proved
ine�cient � we learned, once more, that if it does not look good, it's worth
spending time to make it look good. If it looks ugly, it's been done the
wrong way2 (beauty of code is, of course, not an objective measurement,
but relates to a programmer's experience regarding well-written code).
• An even more striking insight we gained while working on the implemen-
tation is that a strict, statically checked type system such as Haskell's is
a programmer's best friend. Many times the type checker's error messages
seemed like an unsurmountable obstacle. However, in every single one of
these cases a conceptual misunderstanding on our part was the problem �
by restructuring the code accordingly, we could produce cleaner and more
reasoned versions.
Just as many things could be learned with respect to programming as with
respect to the interaction of a program with the real world. When dealing with
live beings, especially animals such as laboratory rats, the input to a system
is hardly predictable (only probabilistically). The scheme devised in front of
a computer screen normally does not re�ect reality very accurately. On-site
experiments and practical veri�cation proved important steps toward usable
software.
6.3 Future Work
Future experiments will certainly bring with them the need for further event
sources or e�ect devices. Thanks to the �exible layout of RatTracker and
the modularity of the code, such extensions can easily be made. Additional
e�ect devices can be added with just as little e�ort.
Some aspects of RatTracker, however, still show room for improvement
which would have been beyond the scope of this diploma thesis:
• For-Loops. There are only counters for time in RTCL, but not for cycles
or occurrences of events.
2However, there are various modern object-oriented languages all code looks ugly in. Theconclusion in the primary author's opinion is not to use those languages at all.
6.4. ACKNOWLEDGEMENTS 89
• Faster GUI library. The toolkit we currently use, HGL, does not provide
su�cient acceleration and optimization. When using six or more boxes,
updating the monitor display at a frequency of more than 2 Hertz caused
severe delays in the execution of the experiment. OpenGL might prove a
better choice.
• Graphical interface to RatTracker. Currently, RatTracker is started
and con�gured over the command line. A simple graphical user interface
might prove more user-friendly.
• Graphical interface to write RTCL �les. For example, The use of �ow
diagrams suggests itself.
• Macros in RTCL to simplify the writing of repetitive sequences of state-
ments.
• Continuation of pipeline branches. Currently, there is no way to express
Has the rat spent so and so long in one compartment, even with inter-
ruptions? in RTCL. Continuations might prove helpful to achieve this
functionality. Mutable values are another alternative but more di�cult to
realize as their violation of the referential transparency principle requires
the use of the IO monad, which would taint the entire pipeline module.
• Con�dence metric. The con�dence metric for the position tracking module
needs to be veri�ed, validated and re�ned.
6.4 Acknowledgements
We would like to thank medimod pharmacological services GmbH for pro-
viding the reason and the infrastructure to write this thesis, and especially to
all the people at medimod for their support. Many thanks to Carola Reinhardt
and Urte Dahm for their input on the usibility and clarity of the experiment de-
scription language. We would also like to acknowledge the team behindYaMPA
for their tremendous work and especially Henrik Nielsson for his interest in our
project. We would like to extend our thanks to Peter Kuhn fromHölle & Hüt-
tner AG for his support with the integration of RatTracker into the existing
framework, and to Michael Maidhof from Peak-System Technik GmbH for
his help and explanations on the setup of the CAN bus controllers.
Last but not least, I would like to personally thank my two supervisors, Prof.
Wol�gramm and Prof. Klaeren, for their continuing support and knowledgable
input. I also owe gratitude to my family for their continued support during my
university years.
90 CHAPTER 6. CONCLUSIONS
A big thank you also goes to Marta Kersten for proof reading this thesis
over and over again.
Appendices
91
Bibliography
[1] L. J. Kamin, �Traumatic avoidance learning: the e�ects of cs-us inter-val with a trace-conditioning procedure,� The Journal of comparative andphysiological psychology, vol. 47, pp. 65�72, 1954.
[2] L. H. Warner, �The association span of the white rat,� The Journal ofgenetic psychology ; child behavior, animal behavior, and comparative psy-chology, vol. 41, pp. 57�89, 1932.
[3] D. Bovet, F. Bovet-Nitti, and A. Oliverio, �Short and long termmemory intwo strains of mice,� Life Sciences, vol. 5, pp. 415�420, 1966.
[4] I. P. Pavlov, Conditioned re�exes. Oxford University Press, 1938.
[5] S. Freud, The problem of anxiety. Norton and Co., 1936.
[6] O. H. Mowrer, �A stimulus-response analysis of anxiety and its role as areinforcing agent,� Psychological Review, vol. 46, pp. 553�565, 1939.
[7] W. James, Principles of Psychology, vol. 2. Netry Holt and Company, 1890.
[8] J. B. Watson, Experimental studies on the growth of the emotions, pp. 37�57. Clark University Press, 1928.
[9] N. E. Miller, �Studies of fear as an acquirable drive: I. fear as motiva-tion and fear-reduction as reinforcement in the learning of new responses,�Journal of Experimental Psychology, vol. 38, pp. 89�101, 1948.
[10] M. R. Holahan and N. M. White, �Conditioned memory modulation, freez-ing, and avoidance as measures of amygdala-mediated conditioned fear,�Neurobiology of Learning and Memory, vol. 77, pp. 250�275, 2002.
[11] D. Anger, �The role of temporal discriminations in the reinforcement of sid-man avoidance behavior,� Journal of the experimental analysis of behavior,vol. 6, pp. 477�506, 1963.
[12] R. J. Herrnstein and P. N. Hineline, �Negative reinforement as shock-frequency reduction,� Journal of the experimental analysis of behavior,vol. 9, pp. 421�430, 1966.
[13] R. J. Beninger, �The role of dopamine in locomotor activity and learning,�Brain Research Reviews, vol. 6, pp. 173�196, 1983.
93
94 BIBLIOGRAPHY
[14] S. Ikemoto and J. Panksepp, �The role of nucleus accumbens dopamine inmotivated behaviour: a unifying interpretation with special reference toreward seeking,� Brain Research Reviews, vol. 31, pp. 6�41, 1999.
[15] M.-L. G. Wadenberg and P. B. Hicks, �The conditioned avoidance responsetest re-evaluated: is it a sensitive test for the detection of potentiallyatypical antipsychotics?,� Neuroscience and Behavioral Reviews, vol. 23,pp. 851�862, 1999.
[16] J. L. Horner, N. Long, and M. E. Bitterman, �A shuttle box for �sh and acontrol circuit of general applicability,� The American Journal of Psychol-ogy, vol. 74, pp. 114�120, March 1961.
[17] R. Clark and G. K. Samuel, �Drug e�ects on a discrete conditioned avoid-ance response in dogs, rhesus monkeys and rats,� Psychopharmacologia,vol. 14, pp. 106�114, 1969.
[18] M. Cammarota, L. R. Bevilaqua, D. M. Barros, M. R. Vianna, L. A.Izquierdo, J. H. Medina, and I. Izquierdo, �Retrieval and the extinctionof memory,� Cellular and Molecular Neurobiology, vol. 25, pp. 465�473,2004.
[19] J. C. Fleming and P. L. Broadhurst, �The e�ects of nicotine on two-wayavoidance conditioning in bi-directionally selected strains of rats,� Psy-chopharmacologia, vol. 42, pp. 147�152, 1975.
[20] D. Bovet, F. Bovet-Nitti, and A. Oliverio, �Genetic aspects of learning andmemory in mice,� Science, vol. 163, pp. 139�149, 1969.
[21] F. R. Brush, E. S. Brush, and R. L. Solomon, �Traumatic avoidance learn-ing: the e�ects of cs-us interval with a delayed-conditioning procedure,�The Journal of comparative and physiological psychology, vol. 48, pp. 285�293, 1955.
[22] M. Sidman, �Some properties of the warning stimulus in avoidance be-havior,� The Journal of comparative and physiological psychology, vol. 48,pp. 444�450, 1955.
[23] J. Arnt, �Pharmacological speci�city of conditioned avoidance response in-hibition in rats: Inhibition by neuroleptics and correlation to dopaminereceptor blockade,� Acta pharmacologica et toxicologica, vol. 51, pp. 321�329, 1982.
[24] M. A. Aguilar, M. I. Mari-Sanmillan, J. J. Morant-Deusa, and J. Minarro,�Di�erent inhibition of conditioned avoidance response by clozapine and dad1 and d2 antagonists in male mice,� Behavioral neuroscience, vol. 114,pp. 389�400, 2000.
[25] M. Li, J. Parkes, P. Fletcher, and S. Kapur, �Evaluation of the motor ini-tiation hypothesis of apd-induced conditioned avoidance decreases,� Phar-macology, Biochemistry and Bevaviour, vol. 78, pp. 811��819, 2004.
[26] J. A. Davies, B. Jackson, and P. H. Redfern, �The e�ect of anti-parkinsoniandrugs on haloperidol-induced inhibition of the conditioned-avoidance re-sponse,� Neuropharmacology, vol. 12, pp. 735�740, 1973.
BIBLIOGRAPHY 95
[27] S. Ahlenius and E. Ericson, �Scopolamine does not restore normal condi-tioned avoidance performance in raclopride-treated rats,� Journal of NeuralTransmission, vol. 108, pp. 415�430, 2001.
[28] J. N. Crawley and R. Paylor, �A proposed test battery and constellations ofspeci�c behavioral phenotypes of transgenic and knockout mice,� Hormonesand Behavior, vol. 31, pp. 197�211, 1997.
[29] J. N. Crawley, �Behavioral phenotyping of transgenic and knockout mice:experimental design and evaluation of general health, sensory functions,motor abilities, and speci�c behavioral tests,� Behavioural Brain Research,vol. 835, pp. 18�26, 1999.
[30] T. Karl, R. Pabst, and S. von Hörsten, �Behavioral phenotyping of mice inpharmacological and toxicological research,� Experimental and toxicologicpathology, vol. 55, pp. 69�83, 2003.
[31] S. Levine and P. L. Broadhurst, �Genetic and ontogenetic determinants ofbehaviour in the rat,� Journal of comparative and physiological psychology,vol. 56, pp. 423�428, 1963.
[32] P. Salmi, J. Samuelsson, and S. Ahlenius, �A new computer-assisted two-way avoidance conditioning equipment for rats: Behavioral and pharmaco-logical validation,� Journal of Pharmacological and Toxicological Methods,vol. 32, pp. 155�159, 1994.
[33] L. A. Low, M. Eliasson, and C. Kornetsky, �E�ect of chlorpromazine onavoidance acquisition as a function of cs-us interval length,� Psychophar-macologia, vol. 10, pp. 148�154, 1966.
[34] M.-L. G. Wadenberg, K. A. Jung, R. A. Trompler, R. A. Zavodny, T. J.Richter, and P. B. Hicks, �A novel computer-controlled conditioned avoid-ance apparatus for rats,� Journal of Pharmacological and ToxicologicalMethods, vol. 38, pp. 211�215, 1998.
[35] R. L. Solomon and L. C. Wynne, �Traumatic avoidance learnung: acquisi-tion in normal dogs,� Psychological Monographs, vol. 67, no. 4, 1953.
[36] W. S. Hunter, �Conditioning and extinction in the rat,� British Journal ofPsychology, vol. 26, pp. 135�148, 1935.
[37] M. Sidman, �Avoidance conditioning with brief shock and no exteroceptivewarning signa,� Science, vol. 118, pp. 157�158, August 1953.
[38] M. Sidman and J. J. Boren, �A comparison of two types of warning stimulusin an avoidance situation,� The Journal of comparative and physiologicalpsychology, vol. 50, pp. 282�287, 1957.
[39] R. M. Church, F. R. Brush, and R. L. Solomon, �Traumatic avoidance learn-ing; the e�ects of cs-us interval with a delayed-conditioning procedure ina free-responding situation,� The Journal of comparative and physiologicalpsychology, vol. 49, pp. 301�308, 1956.
96 BIBLIOGRAPHY
[40] E. R. Behrend and M. E. Bitterman, �Avoidance-conditioning in the gold-�sh: exporatory studies of the cs-us interval,� The American Journal ofPsychology, vol. 75, pp. 18�34, March 1962.
[41] J. J. Boren, M. Sidman, and R. J. Herrnstein, �Avoidance, escape, andextinction as functions of shock intensity,� The Journal of comparative andphysiological psychology, vol. 52, pp. 420�426, 1959.
[42] M. M. van Gaalen and T. Steckler, �Behavioural analysis of four mousestrains in an anxiety test battery,� Behavioural Brain Research, vol. 115,pp. 95�106, 2000.
[43] R. H. Bauer, �Ontogeny of two-way avoidance in male and female rats,�Developmental Psychobiology, vol. 11, no. 2, pp. 103�116, 1978.
[44] R. W. Sebesta, Concepts of Programming Languages. Addison-Wesley,5th ed., 2002.
[45] P. Hudak, The Haskell School of Expression, Learning Functional Program-ming through Multimedia. Cambridge University Press, 2000.
[46] P. Hudak and P. Wadler, �Report on the functional programming languagehaskell,� Tech. Rep. YALE/DCS/RR666, Yale University, Department ofComputer Science, 1988.
[47] Wikipedia.org, �Monads in functional programming.�http://en.wikipedia.org/wiki/Monads_in_functional_programming,Mar 2006.
[48] E. Moggi, �Computational lambda-calculus and monads,� in Proceedings4th Annual IEEE Symp. on Logic in Computer Science, LICS'89, Paci�cGrove, CA, USA, 5�8 June 1989, pp. 14�23, Washington, DC: IEEE Com-puter Society Press, 1989.
[49] P. Wadler, �The essence of functional programming,� in Conference Recordof the Nineteenth Annual ACM SIGPLAN-SIGACT Symposium on Prin-ciples of Programming Languages, pp. 1�14, 1992.
[50] S. L. P. Jones and P. Wadler, �Imperative functional programming,� inConference record of the Twentieth Annual ACM SIGPLAN-SIGACT Sym-posium on Principles of Programming Languages, Charleston, South Car-olina, pp. 71�84, 1993.
[51] J. Peterson, G. Hager, and P. Hudak, �A language for declarative roboticprogramming,� in IEEE Conf. on Robotics and Automation, 1999.
[52] C. Elliott and P. Hudak, �Functional reactive animation,� in InternationalConference on Functional Programming, vol. 32(8), pp. 163�173, 1997.
[53] H. Nilsson, A. Courtney, and J. Peterson, �Functional reactive program-ming, continued,� in Proceedings of the ACM SIGPLAN workshop onHaskell, (Pittsburgh, Pennsylvania, USA), pp. 51 � 64, ACM Press, 2002.
[54] Z. Wan and P. Hudak, �Functional reactive programming from �rst princi-ples,� ACM SIGPLAN Notices, vol. 35, no. 5, pp. 242�252, 2000.
BIBLIOGRAPHY 97
[55] M. Carlsson and T. Hallgren, Fudgets - Purly Functional Processes withApplications to Graphical User Interfaces. PhD thesis, Chalmers Universityof Technology, Mar 1998.
[56] J. Peterson, P. Hudak, A. Reid, and G. Hager, �FVision: A declarativelanguage for visual tracking,� in Proceedings of PADL'01: 3rd InternationalWorkshop on Practical Aspects of Declarative Languages, pp. 304�321, jan2001.
[57] Z. Wan, W. Taha, and P. Hudak, �Real-time FRP,� in International Con-ference on Functional Programming (ICFP'01), 2001.
[58] Z. Wan, W. Taha, and P. Hudak, �Event-driven FRP,� Lecture Notes inComputer Science, vol. 2257, pp. 155+, 2001.
[59] G. Cooper and S. Krishnamurthi, �Frtime: Functional reactive program-ming in plt scheme,� Tech. Rep. CS-03-20, Brown University, apr 2004.
[60] J. Hughes, �Generalising monads to arrows,� Science of Computer Program-ming, vol. 37, no. 1�3, pp. 67�111, 2000.
[61] R. Paterson, �A new notation for arrows,� in International Conference onFunctional Programming, pp. 229�240, ACM Press, 2001.
[62] R. Beresford and A. Ward, �Haloperidol decanoate. a preliminary review ofits pharmacodynamic and pharmacokinetic properties and therapeutic usein psychosis.,� Drugs, vol. 33, pp. 31�49, 1987.
98 BIBLIOGRAPHY
List of Figures
1.1 CAR procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 CAR setup from Salmi et al. . . . . . . . . . . . . . . . . . . . . 71.3 CAR setup from Wadenberg et al. . . . . . . . . . . . . . . . . . 8
2.1 Shuttle Box, viewed from front . . . . . . . . . . . . . . . . . . . 152.2 Shuttle Box, viewed from top . . . . . . . . . . . . . . . . . . . . 162.3 CAN Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Footshock Device . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 E�ect Devices Connection Overview . . . . . . . . . . . . . . . . 212.6 E�ect Devices Setup . . . . . . . . . . . . . . . . . . . . . . . . . 222.7 Relay Board Circuit . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Data Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 System Initialization Overview . . . . . . . . . . . . . . . . . . . 484.3 Data Retrieval Overview . . . . . . . . . . . . . . . . . . . . . . . 524.4 Data Processing Overview . . . . . . . . . . . . . . . . . . . . . . 564.5 Data Output Overview . . . . . . . . . . . . . . . . . . . . . . . . 724.6 RatTracker Screenshot . . . . . . . . . . . . . . . . . . . . . . 734.7 Callback Cascade for graphical output loop . . . . . . . . . . . . 75
5.1 Accumulated Avoidances . . . . . . . . . . . . . . . . . . . . . . . 815.2 Accumulated Escapes . . . . . . . . . . . . . . . . . . . . . . . . 825.3 Accumulated Failures . . . . . . . . . . . . . . . . . . . . . . . . 82
99
100 LIST OF FIGURES
Benutzerhandbuch
The following user manual primarily addresses the research sta� at medimod
pharmacology services GmbH. Since all sta� members are native German
speakers, and no new information is introduced in this chapter, the user manual
is written in German.
Kapitelinhalt
1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . 102
2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.2 Kommentare . . . . . . . . . . . . . . . . . . . . . . 103
2.3 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . 103
2.4 Folgen & E�ekte . . . . . . . . . . . . . . . . . . . . 103
2.5 Wenn-Dann-Paare . . . . . . . . . . . . . . . . . . . 103
2.6 Mehrere E�ekte ausführen . . . . . . . . . . . . . . . 104
2.7 Sequenzen von Ereignissen . . . . . . . . . . . . . . . 104
2.8 Rücksprünge & Wiederholungen . . . . . . . . . . . 105
2.9 Oder-Verknüpfungen . . . . . . . . . . . . . . . . . . 105
2.10 Abbruch . . . . . . . . . . . . . . . . . . . . . . . . . 106
3 Ein erstes Beispiel . . . . . . . . . . . . . . . . . . . 107
4 Schreiben einer Experiment-Kontrolldatei . . . . 108
5 Referenz . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.1 Kommentare . . . . . . . . . . . . . . . . . . . . . . 110
5.2 Listen . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.3 Steueranweisungen . . . . . . . . . . . . . . . . . . . 111
5.4 Ereignisquellen . . . . . . . . . . . . . . . . . . . . . 111
5.5 E�ekte . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6 Tipps . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7 Lösungen zu Übungen . . . . . . . . . . . . . . . . 115
101
102 USER MANUAL, IN GERMAN
1 Einleitung
Der Ablauf von Experimenten, die mit dem RatTrack-System durchgeführt
werden, wird in Dateien mittels einer eigens dafür entwickelten Beschreibungs-
sprache (im Folgenden auch Kontroll- oder Steuersprache genannt) formuliert.
Die Steueranweisungen für ein Experiment werden in einer Textdatei gespei-
chert; Steuerdateien können mit einem beliebigen Texteditor wie beispielsweise
MicrosoftTMNotepad geschrieben werden.
Ist eine Steuerdatei in einem Texteditor erstellt worden und beispielsweise
unter dem Namen meine-steuerdatei.ctrl gespeichert worden, so kann das
Programm in der Kommandozeile des Betriebssystems mit dem Befehl
# rt meine-steuerdatei.ctrl
gestartet werden3. Darauf hin werden noch einige Durchlauf-spezi�sche Para-
meter abgefragt, wie Name der Tiere oder Kürzel des Operators. Anschliessend
wird das Experiment gestartet.
2 Struktur
Angaben in der Steuersprache haben die Grundform �Wenn ein Ereignis E auf-
tritt, dann führe in Folge F aus�. Die verfügbaren Ereignisse E und Folgen
(oder E�ekte) F sind in Tabelle 1 (S. 114) aufgeführt und werden in Abschnitt
5 im Detail beschrieben.
2.1 Syntax
Dezimalzahlen, beispielsweise für Zeitangaben, werden mit Punkt und minde-
stens einer Dezimalstelle geschrieben, auch wenn alle Stellen hinter dem Komma
gleich Null sind (z.B. 13.9, 1.0). Ganzzahlen, beispielsweise für Positionsanga-
ben, werden als solche geschrieben (z.B. 15). Zeichenfolgen (strings) werden in
doppelten Anführungszeichen eingefaÿt (z.B. "abc"). Welcher Typ von Anwei-
sungen jeweils erwartet wird, insbesondere ob Dezimal- oder Ganzzahl, ist in
der Befehlsreferenz (�5) angegeben.
Elemente müssen durch mindestens ein whitespace (Leerzeichen, Zeilenum-
bruch oder Tabulator) getrennt werden, weitere whitespaces können nach Be-
lieben zur besseren Lesbarkeit eingesetzt werden; Zeilenumbrüche sind nur zum
Beenden von bestimmten Kommentare zwingend (siehe nächster Abschnitt).
Ebenso können Einrückungen am Zeilenanfang frei zur Strukturierung verwen-
det werden.3Die Raute zu Beginn der Zeile stellt die sogannte Eingabeau�orderung, das command
prompt, unter Unix dar, und bedeutet �Hier kannst Du Deinen Befehl absetzen�.
2. STRUKTUR 103
2.2 Kommentare
Steuerdateien können durch Kommentare ergänzt werden. Kommentare haben
auf die Ausführung der Steuerdatei keinen Ein�uÿ. Kommentare bis zum Zei-
lenende werden durch zwei Schrägstriche (//) eingeleitet � dies ist der einzige
Sonderfall, in dem Zeilenenden von Bedeutung sind:
. . .
. . . // Ein Kommentar
. . .
Kommentare innerhalb einer Zeile werden in /* und */ eingefasst, nach dem
abschlieÿenden */ können in der selben Zeile weitere Anweisungen stehen:
. . .
. . . /∗ Ein Kommentar ∗/ . . .
. . .
2.3 Ereignisse
Ereignisse, auf die mit einer Konsequenz reagiert werden soll, werden durch be-
stimmte Schlüsselwörter angegeben. Eine Liste der verfügbaren Ereignisse ist im
Referenzteil unter �5.4 oder als Übersicht in Tabelle 1 auf Seite 114 aufgeführt.
Einige der Ereignis-Ausdrücke erwarten weitere Parameter, wie beispielsweise
der Zufallszähler random zwei Zeitangaben benötigt: eine Mindest- und eine
Maximaldauer, zwischen denen eine Zufallsdauer gewählt werden soll.
2.4 Folgen & E�ekte
Die Aktionen, die im Rahmen eines Experiments ausgeführt werden sollen, tre-
ten in den �Wenn E, dann F � als Folge F auf. E steht als Platzhalter für ein
mögliches Ereignis, auf das reagiert werden soll, und F für die entsprechende
Reaktion die in Folge auf das Ereignis ausgeführt werden soll. Mögliche Aktio-
nen sind beispielsweise das An- und Ausschalten eines Lichtes. Solche Aktionen,
die eine Auswirkung auf die Umwelt haben, werden dementsprechend auch als
E�ekte bezeichnet. Die zur Verfügung stehenden E�ekte sind in Abschnitt 5.5
aufgelistet, eine Kurzübersicht ist in Tabelle 1 auf Seite 114 zu �nden.
2.5 Wenn-Dann-Paare
�Wenn E dann F �-Paare werden angegeben als upon E do F . Die Platzhalter
E und F sind durch konkrete Ereignisse beziehungsweise E�ekte zu ersetzen.
Eine Ablaufbeschreibung, um nach 10 Sekunden (E: timer 10.0) das Licht
im Deckel der Box anzuschalten (F : light on), wäre
upon t imer 10 .0 do l i g h t on
104 USER MANUAL, IN GERMAN
Dieses Beispiel stellt bereits eine lau�ähige Anweisungssequenz dar und könnte
in der Form verwendet werden. Bei Ausführung dieser Sequenz würde 10 Se-
kunden nach Start das Licht angeschaltet werden, und bis zum Beenden des
Programmes aktiviert bleiben.
Übung 1 Schreibe eine Controlsequenz, die nach einer zufällig gewählten Zeit-
spanne zwischen 10 und 20 Sekunden den Lautsprecher anschaltet (s.a. Sprach-
elemente in Tabelle 1 auf Seite 114). Lösung auf Seite 115.
2.6 Mehrere E�ekte ausführen
Es lassen sich auf ein Ereignis hin auch mehrere E�ekte ausführen. Die E�ekte
werden hierzu als Komma-separierte Liste und innerhalb runder Klammern an-
gegeben: upon E do (F1, F2, ..., Fn). Die E�ekte werden der Reihe nach
bearbeitet.
Um nach 10 Sekunden sowohl das Licht (F1: light on) als auch einen Fuÿ-
schocker (F2: footshock on) zu aktivieren schreibt man
upon t imer 10 .0 do ( l i g h t on , f oo t shock on )
(wie im Beispiel des vorherigen Abschnitts würden Licht und Fuÿschocker bis
zum Beenden des Programmes angeschaltet bleiben).
Übung 2 Lasse zu Beginn eines Experiments das Licht angehen, um es nach
einer halben Minute wieder ausgehen lassen. Tipp: �Zu Beginn� bedeutet, das
Licht anzuschalten und gleichzeitig einen timer zu starten. Lösung auf Seite
115.
2.7 Sequenzen von Ereignissen
Soll eine Abfolge von Ereignissen zu einer Aktion führen, können die Ereignisse
entsprechend aneinander gereiht werden: upon E1 do upon E2 do F . Rufen wir
uns das allgemeine Format einer upon ... do-Anweisung ins Gedächtnis zurück
(upon E do F ), so sehen wir, dass für die Folge F eine weitere upon ... do-
Sequenz eingesetzt worden ist. Allgemein gilt, dass upon ... do-Sequenzen als
Folge-Ausdrücke verwendet werden können.
Beispielsweise wird mit folgendem Segment das Licht eingeschaltet, wenn
sich die Ratte irgendwann nach den ersten 10 Sekunden aufrichtet:
upon t imer 10 do upon standup do l i g h t on
Um das Licht beim zweiten Aufrichten anzuschalten, kann folgende Anweisung
verwendet werden:
upon standup do upon standup do l i g h t on
2. STRUKTUR 105
Übung 3 Das Überqueren einer Linie (Position und Ausrichtung dürfen frei
gewählt werden) soll dazu führen, dass das zu Beginn eingeschaltete Licht wieder
ausgeschaltet wird. Es sollen jedoch nur Überquerungen nach frühestens nach 5
Minuten berücksichtigt werden. Lösung auf Seite 115.
2.8 Rücksprünge & Wiederholungen
Es können an Befehle Marken angefügt werden, die aus späteren Anweisungen
heraus angesprungen werden können. Solche Marken stehen in Anführungszei-
chen, gefolgt von einem Doppelpunkt, beispielsweise "Start": oder "HAUPT-
TEIL":. Der Name der Marke kann frei gewählt werden, Groÿschreibung ist bei
Marken irrelevant. Der Rücksprung an eine Marke erfolgt durch die Anweisung
goto "Marke" als Folge eines Ereignisses.
Es können in einer Steuerdatei auch mehrere Marken verwendet werden.
Allerdings können nur Marken angesprungen werden, die vor dem Sprung selbst
de�niert worden sind (es sind nur Rücksprünge möglich).
Folgendes Beispiel schaltet im 10 Sekunden-Rhythmus das Licht an und aus
(Licht an, 10 Sekunden warten, Licht aus, . . . ). Ein erster Zähler schaltet
das Licht nach 10 Sekunden an. Gleichzeitig wird ein zweiter timer gestartet,
der nach weiteren 5 Sekunden das Licht wieder ausschaltet und zurück an die
"Start"-Marke springt. Daraufhin beginnt der erste timer erneut, 10 Sekunden
herunterzuzählen, . . . .
" Star t " :upon t imer 10 .0 do (
l i g h t on ,upon t imer 5 .0 do ( l i g h t o f f , goto " Star t " )
)
Übung 4 Erweitere die Lösung zu Übung 3, so daÿ die Sequenz im 10 Minuten-
Takt nach dem Ausschalten des Lichts wiederholt wird. Lösung auf Seite 116.
2.9 Oder-Verknüpfungen
Mehrere Ereignis-Folge-Paare können durch eine oder-Verknüpfung verbunden
werden, wobei nur die Folge des ersten eintretenden Ereignisses ausgeführt wird;
alle anderen Paare werden verworfen. Eine oder-Verknüpfung wird wie die ein-
fache Ereignisabfrage auch durch upon eingeleitet. Die einzelnen Ereignisse
werden mit ihrer jeweiligen Folge durch do verknüpft. Die Paare werden als
Komma-separierte Liste, eingefasst in Klammern, nach dem upon-Schlüsselwort
angegeben: upon (E1 do F1, E2 do F2, ..., En do Fn).
In der folgenden Steuerdatei werden zwei Ereignis-Folge-Paare de�niert:
106 USER MANUAL, IN GERMAN
1. Läuft ein Zähler von 10 Sekunden ab (E1), wird das Licht eingeschaltet
(F1).
2. Überquert das Versuchstier eine von vorne nach hinten verlaufende Linie
bei Lichtschranke 10 (E2), so wird der Ton angeschaltet (F2).
Entscheidend ist, dass nur die Folge ausgeführt wird, die zu dem ersten ein-
tretenden Ereignis gehört. Ist der 10-Sekunden-timer abgelaufen (ohne dass
vorher die Linie überquert worden ist) und das Licht entsprechend angeschaltet
worden, wird das Überqueren der Linie nicht weiter überprüft; anschlieÿende
Überquerungen werden ignoriert. Wird andererseits die Linie überquert, bevor
der timer abgelaufen ist, wird der Ton angeschaltet � der timer wird abgebro-
chen und das Licht (auch nach 10 Sekunden) nicht angeschaltet.
upon ( t imer 10 .0 do l i g h t on ,l c d " | " 10 do sound on
)
Übung 5 Schreibe eine Kontrolldatei, so dass nach 20 Sekunden das Licht an-
geschaltet wird. Wenn sich das Tier innerhalb von 60 Sekunden aufrichtet, soll
das Licht wieder ausgeschaltet werden. Vergehen die 60 Sekunden ohne Aufrich-
ten, soll zusätzlich zum Licht der Ton angeschaltet werden. Lösung auf Seite
116.
2.10 Abbruch
Die Ausführung eines Experiments (trial) kann durch abort als Folge eines Ereig-
nisses beendet werden. Laufen mehrere trials gleichzeitig, wird mit dem letzten
beendeten trial auch die Ausführung des Programmes beendet. Mit dem Been-
den eines Experiments wird die Auswertung eingehender Daten eingestellt.
Das Beenden eines Experiments beinhaltet (noch) nicht das automatisches
Rückstellen des Systems, wie beispielsweise das Abschalten während des Expe-
riments aktivierter Geräte. Eine solche automatische Abschaltung wird in der
nächsten Version von RatTracker enthalten sein.
Um nach 10 Sekunden das Licht anzuschalten und nach weiteren 5 Sekunden
wieder auszuschalten und die Ausführung zu beenden, kann folgende Experi-
mentbeschreibung eingesetzt werden:
upon t imer 10 .0 do (l i g h t on ,upon t imer 5 .0 do ( l i g h t o f f , abor t )
)
3. EIN ERSTES BEISPIEL 107
3 Ein erstes Beispiel
1 ( upon2 // Experiment l a s t s 15min , s top a f t e r t h a t3 t imer 1800 .0 do ( sound o f f ,4 l i g h t o f f ,5 f oo t shock o f f ,6 abor t ) ,7
8 // Labe l f o r main loop9 "START" :
10 // I n i t i a l s t a t e : every th ing ' s o f f11 ( sound o f f ,12 l i g h t o f f ,13 f oo t shock o f f ,14
15 // At random in t e r v a l s , do . . .16 upon random 15 .0 30 .0 do
17 // turn sound and l i g h t on18 ( sound on ,19 l i g h t on ,20
21 // I f . . .22 upon
23 // . . . 10 sec t imer counts down , then24 ( t imer 10 .0 do
25 // turn f oo t s hoc k on and26 ( f oo t shock on ,27 // and go back to s t a r t i f e i t h e r28 // 5 seconds are up or l i n e i s c ros sed29 upon ( t imer 5 .0 do goto "START" ,30 l c d " | " 20 do goto "START"31 )32 ) ,33 // . . . l i n e i s crossed , go back to START34 l c d " | " 20 do goto "START"35 )36 )37 )38 )
Listing 1: Kontrolldatei-Beispiel �CAR�
Das Beispiel zeigt die Steuerdatei für ein conditioned avoidance response-Ex-
periment, bei dem der Ratte nach Präsentation des konditionierten Stimulus
Licht/Ton 10 Sekunden für einen Seitenwechsel gelassen werden, bevor ein Fuÿ-
schock für 5 Sekunden appliziert wird.
Durch das anfängliche upon in Zeile 1 werden zu Beginn zwei Teilausfüh-
rungen gestartet: erstens ein Zähler von 900 Sekunden (15 Minuten), der bei
Ablauf dieser Zeit durch den Steuerbefehl abort die gesamte Ausführung ab-
bricht (Zeile 3), und zweitens der auf die "START"-Marke in Zeile 6 folgende
108 USER MANUAL, IN GERMAN
Hauptteil der Steuerdatei (Zeilen 8 bis 30). Zu Beginn des Hauptteils wird in
Zeilen 8 bis 10 der Grundzustand hergestellt. Anschlieÿend wird in Zeile 13 ein
Zähler gestartet, der nach einer zufällig gewählten Zeitspanne zwischen 20 und
40 Sekunden die Anweisungssequenz für die Stimuli-Präsentation in Zeilen 15
bis 30 ausführt. Als erstes wird hierbei in Zeilen 15 und 16 der konditionierte
Stimulus, Licht und Ton, angeschaltet. Anschlieÿend werden durch upon in
Zeile 19 zwei mögliche Ereignisse und die entsprechenden Folgen de�niert:
1. In Zeile 21 wird ein weiterer timer von 10 Sekunden spezi�ziert. Läuft
dieser ab (ohne daÿ das Alternativ-Ereignis von Punkt 2 geschieht), so
werden die Anweisungen aus Zeilen 23 bis 27 ausgeführt. In Zeile 23 wird
das Fuÿschockgitter angeschaltet. Gleichzeitig werden zwei weitere erwar-
tete Ereignisse de�niert: Das Ablaufen eines 5-Sekunden-Zählers (Zeile 26)
oder das Überqueren der Linie aus Punkt 2 (Zeile 27); in beiden Fällen
wird die "START"-Marke aus Zeile 6 angesprungen.
2. Findet eine Überquerung einer (gedachten) Linie an der 20. Lichtschranke
durch das Versuchstier statt, so wird die "START"-Marke aus Zeile 6 an-
gesprungen; das Herabzählen des timer aus Punkt eins wird hierdurch
ebenfalls abgebrochen.
Sobald ein Rücksprung an die "START"-Marke statt�ndet, wird mit den auf
die Marke folgenden Anweisungen fortgefahren, d.h. zuerst wird durch Zei-
len 8 bis 10 wieder der Grundzustand hergestellt, anschlieÿend wird ein neuer
Präsentationszyklus gestartet.
4 Schreiben einer Experiment-Kontrolldatei
Als Beispiel für das Erstellen einer Kontrolldatei von Grund auf soll ein anderes
Experiment als CAR dienen. Es wird hierbei, wie auch bei CAR, eine Box aus
2 Kompartimenten verwendet, wobei eines der beiden Kompartimente abgedun-
kelt ist. Das Versuchstier wird in das helle Kompartiment gesetzt. Sobald es
das dunkle Kompartiment betritt, erfährt es einen Fuÿschock. Dieser wird bei
Verlassen des dunklen Kompartiments wieder abgestellt.
Die Grundidee des Experiments, dass ein Tier bei Eintritt in das dunkle
Kompartiment einen Fuÿschock erhält, soll als erstes umgesetzt werden. �Ein-
tritt in das dunkle Kompartiment� wird hierbei als Überquerung der Grenze
zwischen den beiden Kompartimenten dargestellt; die Grenze liege für dieses
Beispiel zwischen den beiden Lichtschranken 20 und 21. Somit ist unsere er-
ste Anweisung: �Wenn die Ratte die Linie an Position 20 überquert, soll der
Fuÿschocker angeschaltet werden�; dies setzen wir um als
upon l c d " | " 20 do foo t shock on
4. SCHREIBEN EINER EXPERIMENT-KONTROLLDATEI 109
Um der Ratte eine Chance zu geben, dem Fuÿschock wieder zu entgehen, soll
dieser bei Verlassen des dunklen Kompartiments (entspricht erneuter Überque-
rung der Linie) wieder abgestellt werden. Um dies zu erreichen, erweitern wir
den Folgen-Teil um eine zweite upon . . . do . . . -Anweisung, die dies realisiert.
Die beiden Folgen-Komponenten werden in Klammern zusammengefasst und
durch ein Komma getrennt.
upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do foo t shock o f f
)
Bei dieser Fassung wäre allerdings nach dem ersten kompletten Hinein-Heraus-
Zyklus das Experiment beendet. Daher wollen wir die Ausführung nach dem
Abschalten des Fuÿschocks bei Verlassen der dunklen Seite wieder von vorne be-
ginnen lassen, so dass mit dem nächsten Eintritt wieder der Schocker angeschal-
tet wird. Hierzu versehen wir zuerst den Beginn der Experiment-Beschreibung
mit einer Marke:
" Star t " :upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do foo t shock o f f
)
Diese Marke können wir nun verwenden, um nach Abschalten des Fuÿschocks
wieder an den Anfang zu springen. Wir fügen zusätzlich zu footshock o� eine
goto-Anweisung als E�ekt des zweiten upons ein.
" Star t " :upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do
( f oo t shock o f f ,goto " Star t "
))
Der Übersichtlichkeit und Sicherheit halber geben wir nun einen Grundzustand
an: Es soll sichergestellt sein, dass der Fuÿschock zu Beginn abgeschaltet ist.
" Star t " :( f oo t shock o f f ,upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do
( f oo t shock o f f ,goto " Star t "
))
)
110 USER MANUAL, IN GERMAN
Hierzu haben wir als auf "Start" nicht nur upon folgende Anweisung geschrieben,
sondern eine Liste von zwei Anweisungen: "Start": (footshock o�, upon . . . ). So-
mit wird, bevor die erste upon-Anweisung ausgeführt wird, der Schocker explizit
abgestellt (unabhängig davon, ob er vorher an oder aus war). Dies geschieht
auch, wenn die "Start" durch eine goto-Anweisung erneut angesprungen wird.
Der Befehl direkt vor der goto-Zeile, den Fuÿschock auszuschalten, ist somit
über�üssig geworden, da dieser ja nach Ansprung von "Start" generell deakti-
viert wird (hätten wir anstatt dessen (footshock o�, "Start": . . . ) geschrieben,
wäre dies nicht der Fall). Deshalb können wir unsere Steuerdatei vereinfachen
zu (diese Vereinfachung ist aber nicht zwingend � mehrfache Anweisungen, den
Schocker wieder auszuschalten, wären kein Fehler):
" Star t " :( f oo t shock o f f ,upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do goto " Star t "
))
Abschlieÿend wollen wir festlegen, dass das Experiment insgesamt 10 Minuten
laufen soll. Hierzu fügen wir einen Zähler ein, der nach Ablauf von 600 Sekunden
eine abort-Anweisung auslöst. Dieser Zähler muss auÿerhalb des Anweisungs-
blocks nach der "Start"-Marke stehen, da er sonst bei jeder Iteration erneut
gestartet werden würde.
( upon t imer 600 .0 do abort ," Star t " :
( f oo t shock o f f ,upon l c d " | " 20 do
( f oo t shock on ,upon l c d " | " 20 do goto " Star t "
))
)
5 Referenz
Eine Übersicht der verfügbaren Schlüsselwörter ist in Tabelle 1 zu �nden.
5.1 Kommentare
Kommentare können im C++-Stil angegeben werden: Kommentare bis zum
Ende der Zeile werden durch // eingeleitet, Kommentare innerhalb einer Zeile
werden in /* und */ eingefasst.
5. REFERENZ 111
5.2 Listen
Zur gleichzeitigen Ausführung mehrerer E�ekte oder Steueranweisungen werden
diese als Komma-separierte Liste, eingefasst in Klammern, geschrieben.
5.3 Steueranweisungen
Wenn-dann (upon . . . do . . . )
Syntax: upon E do F
E: Ereignisquelle,
F : FolgeBeschreibung: Löst Ereignisquelle E ein Ereignis aus, wird als Folge F aus-
geführt. Als Folge können E�ekte (�5.5), Steueranweisungen
(�5.3), ein weiteres wenn-dann-Paar oder eine Liste mit eben
diesen Elementen verwendet werden.
Syntax: upon (E1 do F1, E2 do F2, . . . )
Ei: Ereignisquelle,
Fi: Zu Ei gehörige FolgeBeschreibung: Die angegebenen Ei/Fi-Paare werden entweder-oder-verknüpft.
Löst eine der angegebenen Ereignisquellen Ek ein Ereignis aus,
so wird als Folge das zugehörige Element Fk ausgeführt. Alle
anderen Ei/Fi-Paare werden verworfen.
Sprung (goto)
Syntax: goto M
M : Anzuspringende MarkeBeschreibung: Springt die angegebene Marke an.
5.4 Ereignisquellen
Zeitgeber (timer)
Syntax: timer Z
Z: Zeitspanne in Sekunden als DezimalzahlBeschreibung: Löst ein Ereignis nach Z Sekunden aus.
112 USER MANUAL, IN GERMAN
Zufälliger Zeitgeber (random)
Syntax: random Zmin Zmax
Zmin: Mindest-Zeitspanne in Sekunden als Dezimalzahl,
Zmax: Höchst-Zeitspanne in Sekunden als DezimalzahlBeschreibung: Löst ein Ereignis nach einer zufällig gewählten Zeitspanne aus.
Die Zeitspanne liegt zwischen Zmin und Zmax.
Linienüberquerung (lcd)
Syntax: lcd D P
D: Ausrichtung der Linie als Zeichenfolge,
P : Position der Linie als GanzzahlBeschreibung: Löst ein Ereignis aus, wenn das Versuchstier eine Linie in Rich-
tung D an Position P überquert. Die Richtung wird angegeben
als "|" (für von vorne nach hinten verlaufende Linien) oder "-
" (für von links nach rechts verlaufende Linien). Die Position
wird mit Bezug auf die Lichtschranken angegeben, die Linie
liegt hinter der P ten Lichtschranke. Die Linie gilt als über-
quert, wenn sich der Mittelpunkt der erkannten Ratten�äche
von der einen auf die andere Seite der Linie bewegt hat.
Aufrichten (standup)
Syntax: standup
Beschreibung: Löst ein Ereignis aus, wenn sich das Versuchstier aufrichtet.
Das Tier wird als aufgerichtet angesehen, wenn Lichtschranken
beider Lichtschranken-Ebenen unterbrochen sind und sich die
Mengen der unterbrochenen Lichtschranken beider Dimensio-
nen überschneiden.
Mindest-Vertrauen in Positionsbestimmung (con�dencebelow)
Syntax: con�dencebelow M
Beschreibung: Löst ein Ereignis aus, wenn der Kon�denzwert für die be-
stimmte Position des Tieres unter M fällt. Mögliche Werte
liegen zwischen 0.0 und 1.0 (jeweils einschlieÿlich), wobei 1.0
absolutes Vertrauen in die bestimmte Position darstellt.
6. TIPPS 113
5.5 E�ekte
Licht (light)
Syntax: light on/off
Beschreibung: Schaltet das Licht im Deckel der Box an oder aus.
Ton (sound)
Syntax: sound on/off
Beschreibung: Schaltet den Ton über der Lautsprecher im Deckel der Box an
oder aus.
Fuÿschock (footshock)
Syntax: footshock on/off
Beschreibung: Schaltet das Fuÿschockgitter an oder aus.
6 Tipps
• Man kann Ereignisse als Eingangsgröÿen, E�ekte als Ausgangsgröÿen auf-
fassen.
• Setze als erstes die Grundidee einer einzelnen Iteration um. Rücksprünge,
Abbruchbedingen etc. können später hinzugefügt werden.
• Als Folgen auf Ereignisse (meist als F bezeichnet) kann ein E�ekt oder
eine Steueranweisung angeben werden, auch eine weitere upon-Sequenz ist
möglich: aus upon E0 do F0 wird durch Ersetzen von F0 durch upon E do
F die Anweisung upon E0 do upon E do F .
• Schreibe mehrere gleichzeitig auszuführende Folgen als Liste: upon E do
(F1, F2, . . . ).
• Schreibe oder-verküpfte Ereignisse als Liste von wenn-dann-Paaren nach
einem einzelnen upon: upon (E1 do F1, E2 do F2, . . . ).
• Gib die Laufzeit eines Experiments als Zähler auf höchster Ebene mit
abort als Folge an: (upon timer 600.0 do abort, . . . ).
• De�niere den Grundzustand zu Beginn eines Zykluses explizit.
114 USER MANUAL, IN GERMAN
Element Beschreibung Beispiel
Ereignisquellentimer Zeit Ereignis nach Zeit
Sekundentimer 5.0
random min max Ereignis nach einer Zeitzwischen min und maxSekunden
random 5.0 10.0
lcd Ausrichtung Position Ereignis bei Überquereneiner Linie an PositionPosition in AusrichtungAusrichtung ("|" oder"-")
lcd "|" 20
standup Ereignis beim Aufrichten standup
con�dencebelow min Ereignis beimUnterschreiten desKon�denzwertes min fürdie ermittelte Positiondes Tieres
con�dencebelow 0.9
E�ektefootshock on/o� Schaltet den Fuÿshocker
an oder ausfootshock on
light on/o� Schaltet das Licht anoder aus
light on
sound on/o� Schaltet denLautsprecher an oder aus
sound on
Steueranweisungenupon Ereignis do Folge Führt bei Ereignis die
Anweisungen der Folgeaus
upon timer 10.0 do abort
goto Marke Springt zurück an diedurch Marke de�nierteStelle
goto "START"
abort Beendet die Ausführungder Steuerdatei
Table 1: Sprachelemente
7. LÖSUNGEN ZU ÜBUNGEN 115
7 Lösungen zu Übungen
Übung 1
Wir beginnen mit einem leeren Grundgerüst:
upon E do F
Um nach einer zufälligen Zeitspanne zwischen 10 und 20 Sekunden ein Ereignis
auszulösen, wählen wir als Ereignisquelle randomtimer 10.0 20.0, und ersetzen E
entsprechend:
upon random 10 .0 20 .0 do F
Das Anschalten des Lautsprechers können wir durch sound on beschreiben:
upon random 10 .0 20 .0 do sound on
Übung 2
Zu Beginn des Experiments werde es Licht:
l i g h t on
Die Anweisung, um nach 30 Sekunden das Licht ausgehen zu lassen, ist:
upon 30 .0 do l i g h t o f f
Die beiden Befehle verknüpfen wir, indem wir sie als Liste schreiben:
( l i g h t on , upon 30 .0 do l i g h t o f f )
Es wird nun gleich zu Beginn einerseits das Licht angeschaltet, als auch ein
timer gestartet, der nach 30 Sekunden das Licht wieder ausschaltet.
Übung 3
Zuerst setzen wir das Ausschalten des Lichtes bei Linien-Überquerung um:
upon l c d "−" 23 do l i g h t o f f
Die Anforderung, frühestens nach 5 Minuten auf die Überquerung zu reagieren,
können wir auch ausdrücken als �Nach 5 Minuten, beginne auf Linienüberque-
rungen zu achten�:
upon t imer 300 .0 do
upon l c d "−" 23 do l i g h t o f f
Nun müssen wir nur noch zu Beginn das Licht anschalten, damit wir es wieder
ausschalten können:
( l i g h t on ,upon t imer 300 .0 do
upon l c d "−" 23 do l i g h t o f f
)
116 USER MANUAL, IN GERMAN
Übung 4
Als erstes ergänzen wir die Lösung aus Übung 3 um eine Marke zu Beginn der
Anweisungen:
" Star t " :( l i g h t on ,upon t imer 300 .0 do
upon l c d "−" 23 do l i g h t o f f
)
Um nach 10 Minuten erneut zu starten, müssen wir die Sequenz upon timer
600.0 goto "Start" an passender Stelle einfügen. Da der 10-Minuten-Zähler
mit dem Ausschalten des Lichtes und somit mit der zweiten Linienüberquerung
starten soll, erweitern wir den Folgen-Teil dieser Überquerung zu einer Liste von
Aktionen (Ausschalten des Lichtes und Starten des Neustart-Zählers):
" Star t " :( l i g h t on ,upon t imer 300 .0 do
upon l c d "−" 23 do
( l i g h t o f f ,upon t imer 600 .0 goto " Star t "
))
Übung 5
Das Anschalten des Lichtes nach 20 Sekunden erreichen wir durch
upon 20 .0 do l i g h t on
Die bedingten Anweisungen formulieren wir etwas um, so dass sie sich intui-
tiver umsetzen lassen: �Entweder soll beim Aufrichten das Licht ausgeschaltet
werden, oder nach 60 Sekunden der Ton angeschaltet werden�. Diese entweder-
oder-Sequenz schreiben wir als upon-Anweisung mit zwei Ereignis-Folge-Paaren:
upon ( standup do l i g h t o f f ,t imer 60 .0 do sound on
)
Diese upon-Anweisung soll erst aktiv werden wenn das Licht angeht, daher fügen
wir sie mit dem Licht-an-Befehl in eine Folgenliste zusammen:
upon 20 .0 do
( l i g h t on ,upon ( standup do l i g h t o f f ,
t imer 60 .0 do sound on
))