RatTracker - A Functional-Reactive Approach to Flexible Control of Behavioural Conditioning...

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

http://download.oertel.ch/university/diploma_thesis.pdf

http://www.opensource.apple.com/cdl/

http://www.gnu.org/copyleft/gpl.html

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


(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


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


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


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


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

http://www.can-cia.org/can/

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

http://www.can-cia.org/

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.


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


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.


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.


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.


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.


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.

http://www.nomaware.com/monads/


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


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.

http://www.haskell.org/ghc/


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/.

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.


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


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/.

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.


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

http://darcs.oertel.ch/repos/thesis/

http://darcs.oertel.ch/repos/thesis/

http://darcs.oertel.ch/?r=thesis

http://darcs.net/

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


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


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.


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 )


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).


• 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�):


• 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.


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


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:


• 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 ]


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.


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

}


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 ( )

}


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,


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.


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/


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.


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


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/.

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]


light on]




sound off,light off,footshock off]


light on]





light on]





light 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.

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.


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.


10 20 30 40Run

0

20

40

60

80

100

120

140

160A

ccum

ulat

ed E

scap

es


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


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.

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�.


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.


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


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:


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


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 "

))

)


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.


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.


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


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


)


Ü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


)

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

))

RatTracker - A Functional-Reactive Approach to Flexible Control of Behavioural Conditioning...

Documents

Transcript of RatTracker - A Functional-Reactive Approach to Flexible Control of Behavioural Conditioning...