| Supported hardware
| Development history
| Future possibilities
| About the authors
See also Whisker in pictures
The philosophy behind Whisker was to create a powerful, cheap system that has a strong basic design. A server program controls the hardware itself, and communicates with clients, which typically embody behavioural tasks. I see the particular strengths of Whisker as these:
- It uses cheap, standard hardware. In August 1999, a system capable of controlling 72 digital I/O lines cost approximately £1350 (including computer) using hardware from Amplicon and a home-built PC. The precise cost depends on the mix of input/output lines, but in practice a fully-wired system to control 6-8 fully-kitted operant chambers is less than £2000.
- Whisker uses a client-server model. This means that clients (behavioural tasks) run completely independently of each other, with the server ensuring that they do not access the same I/O resources at the same time. For example, if you write a program to run a particular schedule, you can write it for a single operant chamber and run eight copies if you have eight chambers. You can write a new program and test it using one chamber while your other chambers run undisturbed.
- The use of TCP/IP as the underlying communications protocol brings one other advantage: clients can run on a different computer from the server (the server being the computer with the chambers connected to it). While this may not be wise on a real network with real behavioural tasks (because speed would depend on the vagaries of the network), it does mean that you can find out how far your subjects have got from your office computer, in a different building from the lab.
- The client-server communications system is simple, and was specifically designed to make behavioural programming simple, reliable and safe; for example, it incorporates safety timers to ensure that infusion pumps are not left on accidentally. It also provides facilities that make yoking trivially easy.
- Clients can be written in any programming language that supports TCP/IP (e.g. C, C++, Visual Basic, Perl...). This enables powerful, compiled languages to be used. In principle, a simplified "front-end" client could be written to enable simplified and/or graphical task programming; however, I personally feel this severely restricts the power of behavioural control programs and have not implemented this yet.
- On present-day hardware, the system is fast enough to make it realistic to use the computer for other tasks (wordprocessing, data analysis, etc.) while running behavioural tasks. Obviously, this requires a reasonably fast computer and a trustworthy operating system; Whisker has not yet been tested on 'legacy' hardware (slowest machine used so far: AMD K6-2/450 MHz, 128 Mb RAM, Windows NT 4.0, <£500). The system time resolution is ~1 ms.
- A development kit, including client libraries, is provided to make writing tasks easy.
The essence of Whisker: a client-server model.
At the core of Whisker is the server. This is a program that runs on your control computer, to which your operant chambers are connected.
Behavioural tasks run as separate programs, called clients. (A client does not necessarily have to be a behavioural task, but most are.) Typically, the clients are run on the same computer as the server.
The clients communicate with the server via a networking protocol called TCP/IP. A client will 'connect' to the server, in exactly the same way that a web browser connects to a web server, and can then control all the devices attached to the server by passing simple text messages to and from the server. For example, the client may tell the server to extend a lever into the operant chamber, and to report back whenever that lever is pressed.
The Whisker server is implemented as a single multithreaded program, written in C++ (using MFC and the MCL threading library).
Behavioural tasks are implemented as separate programs. See Behavioural Tasks for details.
- PC-compatible computers running Windows NT 4 or Windows 2000.
- Multiple monitor support requires Windows 2000.
- Video cards are supported through Windows.
- Sound cards are supported through Windows.
- Network cards are supported through Windows.
- Digital I/O cards from
- ICS, or other generic 82C55 controller chip
- Touchscreens for which a UPDD driver is available.
- For full details of hardware compatibility, see Ordering / Hardware suppliers.
- Whisker was designed and written by Rudolf Cardinal for use by the IV group (headed by Prof. Barry Everitt) within the Behavioural and Cognitive Neuroscience Group of the Department of Experimental Psychology within the University of Cambridge. The project began as a tentative attempt to obtain new operant control equipment 'on the cheap' from a general-purpose electronics supplier, for use with rats. While hardware was readily obtained to manage digital input/ouput devices of any kind, no suitable control software was available. Rudolf saw this as an opportunity to create a system that was intrinsically powerful and robust by implementing a client-server design and allowing clients (behavioural tasks) to be written in a general-purpose programming language, filling a gap in the operant control market. He thinks of it as the system he would have liked to have had for his own research.
- Design began in August 1999; the system was adapted to the lab's equipment and went live in February 2000.
- The eventual system cost a fraction of the leading competitor system and proved far more powerful. It was adopted throughout the lab for which it was developed.
- In order to extend Whisker's capabilities, it was extended to support multiple visual displays, audio output, touchscreens, and keyboard input. This made Whisker a general-purpose control system useful for testing humans, other primates, birds, and rodents, using a wide range of device types.
- In addition, Whisker was made significantly easier to program for, with the creation of development toolkits for Visual Basic and C++. The lead programmer for this development is Mike Aitken.
- Whisker is now widely used throughout the world, and has been instrumental in many significant scientific publications.
- Support analogue devices. This would include analogue inputs (for electrophysiology and neurochemistry) and outputs (to control lamp brightness, for example). The system would need to handle up to at least 100 kHz uninterrupted acquisition for electrophysiology.
- Support video capture (camera) devices. For example, the existing client-client communication system would allow easy extension of present clients to handle automated measurement of freezing behaviour in the rat, if a single video capture/analysis client were written; if properly validated, this would represent an enormous time saving for researchers.
About the authors
Whisker was created by people who have expertise in behavioural research as well as extensive experience of computer programming.
- Rudolf N. Cardinal designed and wrote the original Whisker system in 1999-2000 and holds the primary responsibility for the server side of its current implementation. He holds PhD and research MD degrees in psychology and behavioural neuroscience from the University of Cambridge, and worked as a Lecturer in Neuroscience at the MRC Cambridge Centre for Behavioural and Clinical Neuroscience and Department of Experimental Psychology, University of Cambridge. He is a member of the Royal College of Physicians, and a psychiatrist in Cambridge, UK.
- Michael R.F. Aitken contributed to the development of the multimedia extensions to Whisker and holds the primary responsibility for the development toolkit and library. Mike holds a PhD in psychology from the University of Cambridge. He is a University Lecturer in the Department of Experimental Psychology, University of Cambridge, a member of the University of Cambridge Behavioural and Clinical Neuroscience Institute, and a Fellow of Selwyn College, Cambridge.