Head-Mounted System Calibration
9.4 Summary and Further Reading
This chapter presented key points for installation of a modern, table-mounted eye tracker. As with earlier head-mounted systems, successful installation still depends on appropriate signal routing and synchronization. Modern systems have simplified these concerns, however, particularly if signal acquisition is based on a networked client/server model. Rather than relying on the interpretation of vendor-specific serial data, communication over TCP/IP facilitates faster development due to the reliance of accepted standards, e.g., socket programming. Although the data received may still be specific to a particular vendor’s format and protocol, their receipt from a socket stream is much simpler than byte assembly of a serial interface. An added benefit is the lifting of the proximity constraint placed by the length of a serial cable.
Video signal routing is still a (minor) concern, although this too has been simplified by the adoption of standardized displays, e.g., VGA. The installation of a three- headed system, described above, made simple by the use of a KVM switch, is a relatively complex one. Typical eye tracking “stations” need not be this elaborate and can for the most part resemble a typical computer workstation: computer and monitor along with eye tracking optics (possibly embedded).
Apart from hardware issues, the use of normalized screen coordinates (e.g., (x,y)∈ [0,1]) removes the problematic need for reference frame mapping, typically
(a) Classroom with 20 Gazepoint trackers. (b) Closeup of Gazepoint tracker mount.
Fig. 9.3 Eye tracker classroom installation with 20 eye trackers from Gazepoint
done in software, or at least the more daunting portion of coordinate registration that was needed previously. Given normalized point of regard coordinates, these are sim- ply scaled to a given display or window over which eye movements are collected.
Since the typical installation of one or two eye trackers in a lab, a recent trend is on developing larger eye tracking labs or classrooms, e.g., see installation at Clemson shown in Fig.9.3. Other similar classrooms have appeared at the SWPS University of Social Sciences and Humanities in Warsaw, Poland, the Slovak University of Technology in Bratislava, Slovakia, the University of the Free State in Bloemfontein, South Africa, and Lund University in Lund, Sweden. One of the main issues with such installations is synchronization among multiple eye trackers. Collecting data from multiple eye trackers simultaneously opens up new possibilities for interesting research and applications.
As with previous systems, the two primary sources where further information can be obtained on system installation and setup are the manufacturer’s manual and any user community groups that may have assembled. Users of eye trackers still report descriptions of their apparatus and any specific technical innovations required for system development, specifically to foster replication of their experiments by other researchers. Reports can still be found in journal articles such asVision Research, Behavior Research Methods, Instruments, and Computers (BRMIC), and conference proceedings. There are various conferences that deal with eye tracking, either directly or indirectly. For example, conferences that deal with computer graphics (e.g., SIG- GRAPH, EuroGraphics, or Graphics Interface), human–computer interaction (e.g., SIGCHI), or virtual reality (e.g., VRST), still carry papers that discuss the use of eye trackers. Two main conferences dealing directly with eye tracking run on an inter- leaved biennial basis: the European Conference on Eye Movements (ECEM), and the U.S.-based Eye Tracking Research & Applications (ETRA). Finally, the eye move- ment email listservseye-movementsandeyemov-lare excellent on-line “gathering places” of eye tracker researchers.
Chapter 10
Table-Mounted System Software Development
Virtually all the requirements for (interactive) eye tracking application development are similar today as they were a few years ago with older equipment (see Chap.7), save for the most important: mapping of the eye tracker coordinates. If gaze coordi- nates provided by the tracker are normalized (as they are provided by the Tobii eye tracker), then mapping of the coordinates to the display is trivially accomplished by multiplying (scaling) the normalized coordinates by the screen extents. If an appli- cation is running in a window smaller than the screen, then one must obtain the window’s position relative to the screen origin; this is usually readily available in most GUI toolkits. Given screen and window coordinates, mapping gaze coordinates to a given application’s reference frame follows similar logic as in Chap.7, namely based on linear interpolation.
Beyond coordinate reference frame alignment, the most important aspect of mod- ern eye tracker programming (at least with the Tobii tracker) is that the application controls eye tracker functionality; it does not merely respond to changes in operation mode (where the modes are idle, calibrating, running). Furthermore, it is important to note that the eye tracking Application Program Interface (API) client library may need to run in its own concurrent thread. In the specific case of the Linux Tobii API, all API calls must be contained within the same thread. This is particularly rele- vant to traditional event-driven (GUI) programming because the Linux Tobii client library (discussed in detail below) is itself event-driven. This means that there are two simultaneous infinite loops running outside the programmer’s control that must be synchronized in some way (in the Linux and Mac OS X environments this is accomplished with POSIX threads (Butenhof1997)). One loop is run by the GUI toolkit for which the programmer must implement functions (callbacks) to handle GUI events such as mouse motion, button presses, etc. The second loop is run by the Linux Tobii client thread for which the programmer must provide a callback function to handle its single event: consumption of gaze coordinates from the streaming buffer (this occurs when calibrating and running). The Linux Tobii API binary is available at http://andrewd.ces.clemson.edu/tobii/.
© Springer International Publishing AG 2017
A.T. Duchowski,Eye Tracking Methodology, DOI 10.1007/978-3-319-57883-5_10
105
The Linux Tobii client API was ported to Linux at Clemson University in an independent effort (not written by Tobii Technology). Porting of the client code was achieved via TCP/IP socket programming (referencing the very readable texts of Comer and Stevens (1993,2001)). The library was developed with Tobii’s permission and was last tested with Tobii’s TET Server v2.8.6 (ClearView Full Install Kit v2.5.1).
The code may not function with future TET Server versions but will be ported to work with future TET Server versions if Tobii sanctions the effort and provides sufficient cooperation.
The remainder of this chapter discusses the Linux Tobii client API. Although it is specific to the Tobii eye tracker, it is expected that most eye trackers will contain similar functionality, for example connection to the eye tracker (TCP/IP or serial port), calibration, and data streaming.