Software goals

From Bcontrol

Jump to: navigation, search

We describe here a system designed for behavioral experiments.

The goals of the system are to

  1. Interact rapidly with the experimental subjects. In other words, the system should respond to the events fast (sub-millisecond level), so as to get reliable time traces of behavior when combining it with electrophysiology.
  2. Provide a convenient user-interface to study this behavior.
  3. Regulate the experiments on a daily basis by recording the experimental data and settings used by multiple experimenters on multiple subjects.

The experimental subjects used for explanation purposes in this documentation are rats.


[edit] Interact rapidly with rats

(Goal 1: Real Time Linux State Machine)

The rats reside in a behavior box. The following things can happen in this box.

  1. The rat gets exposed to certain type of stimulus e.g. sound, light, water, and odor.
  2. The rat pokes into one of the three pokes, commonly called 'Center', 'Left' and 'Right' pokes.

This is the rat's way of communicating with us about what it feels about the stimulus it received from us. Humans or other animals might communicate differently. We can call this a stimulus-and-response concept; and our job is to study the behavior of the rats with the help of this stimulus-and-response concept.

A state diagram is one of the most convenient ways, to visually summarize how we want to control a rat's behavior with the help of stimulus-and-response concept. We need a system that frequently (meaning in real-time) sends the stimulus to the rats and records the response of the rats to a particular stimulus or a set of stimuli. To facilitate this kind of behavioral experimentation, we associate stimulus/stimuli with a state and say that the rat is in a particular state when it is exposed to a particular set of stimuli or a single stimulus; hence we use state diagrams. Based on the rat's response to the stimulus (or stimuli) when it resides in a state, we may choose to transfer the rat to another state (which may be to subject the rat to a different stimulus or stimuli) or keep it in the same state.

[edit] Brain Feed #1: Simple State Diagram comprising states, output actions and events

  • A state diagram is composed of states, their output actions, and the events that are responsible for transitions between states.
  • The adjacent figure shows a state diagram with three states. Each state is associated with an output action (blue text and a graphic below/beside each state in the adjacent figure) which can be to subject the rat to a single stimulus like light (State_2) or sound (State_3) or multiple stimuli (both light and sound together are outputs of State_4); the events are labeled across the arrows.
  • In the adjacent figure, Lin (meaning rat pokes into the left poke) causes a transition from ‘blank state’ to ‘light state’ where the Left Light is turned ON.
  • Also, note that some states might not have any output actions (like State_1 in the adjacent figure). This too is a type of stimulus to the rat. It is like subjecting the rat to absolute silence and darkness. We can call it a blank state or empty state.
  • The events shown in the adjacent figure are generated by rat pokes and designated with the following names: Cin, Lin, Rin – rat puts its nose into center, left, and right pokes respectively; Cout, Lout, Rout – rat pulls nose out of center, left, and right pokes respectively (e.g. Lin causes transition from State_1 to State_2).
  • We call them hard events because they are coming from the subjects (in this case, the rats) and not internally from the software.

The system we designed to run the state diagrams is real-time software which runs on a Linux machine. The job of this software is to send out the different types of stimuli and report the responses of the rats to the real world in real-time based on finite state diagrams designed by us. We call it finite because the number of states is always finite. The machine which runs this software is called Real-Time Linux State Machine (RTLSM) or Finite State Machine (FSM).

[edit] Convenient user-interface to study the rat's behavior

(Goal 2: Governing Machine)

Up to this point, we learnt that the RTLSM runs state diagrams. But, who will design those diagrams for the RTLSM? We have custom-software which runs on a separate machine (which we call the Governing Machine) to design state diagrams and dispatch them to the RTLSM. On the Governing Machine, we call the act of designing a single state diagram, a Trial. One might want to run several trials in a particular sequence, for an experiment; which means designing several state diagrams, such that one runs after the other. Sometimes, when a set of trials are completed, the experimenter might choose to mark it as a particular Stage of experiment being completed. For convenience, experimenters design all the trials that are required for an experiment, at once; and they call it a Protocol. When the experiment starts, this Protocol is simply launched. So, we have learnt three new words that are commonly used on the Governing Machine platform: Trial, Stage and Protocol. The adjacent figure shows a pictorial representation of how we design several state diagrams (or Trials) and wrap them in a Protocol.

Now that we have a Protocol design, the next step is to dispatch it to the RTLSM. For this purpose, we have three modules running inside the Governing Machine’s custom-software: Dispatcher, State Machine Assembler/Dissembler, and Transporter.

  1. Dispatcher is a software module which acts as an interface between the Protocol and the RTLSM. It issues instructions to launch and close a Protocol, and to handle the handshaking between the Governing Machine and RTLSM.
  2. The job of the State Machine Assembler/Dissembler software module is to act as an interpreter (or translator) between the Governing Machine and the RTLSM. It converts the instructions issued by Dispatcher into an internal language that can be understood only by the RTLSM and vice-versa.
  3. The Transporter is a module that checks if the communication path between the Governing Machine and the RTLSM is clear; then sends all the interpreted instructions to the RTLSM and receives any information requested by Dispatcher from the RTLSM. It acts as a communication liaison between the Governing Machine and RTLSM, and hence also called a liaison app.

Since multiple experimenters may run multiple experiments on multiple rats, even before the Dispatcher can launch a Protocol, it needs to know some basic information like the names of the experimenter, the rat and the Protocol. This is facilitated by another GUI module on the Governing Machine called Runrats. This module helps us select the Protocol, experimenter and rat and then passes this information to the Dispatcher. There are two ways for Runrats to get this information. One way is for us to feed this information manually to Runrats via its GUI window. The other way is for Runrats to fetch (or retrieve) all this information from a database server via a liaison software module (or app) called Zut. We call it a liaison app because it helps communicate between the Governing Machine and the Server Machine (about which we will talk next in Goal 3)

[edit] Regulate experiments on a daily basis

(Goal 3: Server Machine)

  1. Experimenters build different protocols and run it on different rats at different times of the day. So, we need a scheduler which will decide the experiment to be run based on the following parameters: experimenter, protocol & rat name.
  2. To automate this whole scheduling process, we built a simple scheduler webpage which collects the above stated parameters and stores them in a database server.
  3. When requested for information, the database server (which resides on a separate machine called Server Machine) serves these parameters to the Runrats module on Governing Machine, via Zut, which will help Runrats pick the scheduled Protocol for that date & time; and Runrats finally sets that Protocol for the Dispatcher to launch.

[edit] Software Architecture

Now that we have an idea of what are the goals, let us look at the Software Architecture of this Behavioral Software Suite and learn how it realizes these three primary goals.

As we can see in the adjacent figure, the entire block diagram is separated into three parts corresponding to the three goals which are realized by three physically separate machines: 1.) State Machine; 2.) Governing Machine; 3.) Server Machine.

The goals are separated using purple lines. We can call them goal separator lines. You will notice that there are two small boxes intercepting purple lines (the goal separators). Although these are Governing Machine’s software modules they intercept the goal separator lines because they act as liaison apps between the Governing Machine and, Server Machine & State Machine.

To better understand the adjacent block diagram, we will see step-by-step what happens starting from the top; when an experimenter, on a typical day, sets the schedule to run a particular protocol on a rat; to the bottom where the rat’s behavior in the behavior box is studied:

  • Experimenter opens scheduler webpage and sets the schedule to run a rat (named R0113) using protocol called (say) Light Chasing under his/her name.
  • The schedule is transferred to the web server which in turn transfers it to the database server with the names of the experimenter, protocol and rat.
  • Technician arrives at the Governing Machine, starts the GUI app Runrats.
  • Runrats now communicates with the Database Server via back-end app Zut to retrieve the rat name, experimenter name and the protocol name.
  • Zut retrieves the information, requested by Runrats, from Database Server and passes it to Runrats.
  • Runrats is ready with the protocol to be run and calls the Dispatcher.
  • The Dispatcher reads the Protocol and sends the first state diagram to the State Machine Assembler (SMA) which translates (or interprets) the state diagram into an internal language understandable by the RTLSM and delivers it to the RTLSM using the liaison app Transporter.
  • The RTLSM receives the state diagram, and starts running it. As a consequence of running a state diagram, hard events will be generated and state transitions occur.
  • The Dispatcher continuously bugs the RTLSM for information like the latest events and state transitions that occurred. At this point, the system takes a reverse path. All this information is transmitted to the Transporter by the RTLSM. This whole process is called handshaking.
  • The information held by Transporter is again interpreted into a language (that the Dispatcher can understand) by the State Machine Dissembler (SMD) and subsequently sent to the Dispatcher.
  • Dispatcher analyzes the information it received from the RTLSM and checks if the state diagram it just sent has been completed or not.
  • If Dispatcher learns that the RTLSM has completed running the current trial, it buckles up and starts bugging the Protocol to build the next state diagram.
  • Protocol analyzes the performance results of the current trial and prepares the next trial; in other words builds the next state diagram and delivers it to the Dispatcher.
  • Also, once the Protocol knew that a certain number of trials have been completed, it marks it as a stage completion.
  • Once the entire Protocol finishes running, the results are saved and sent to the database server.
Personal tools