3. Device Overview

In Player, we use the notion of a device in much the same way as most UNIX systems. That is, a device is an abstract entity that provides a standard interface to some service. Devices behave similarly to files in that they must be opened with the correct access mode before use, and closed afterward. Once open, a device can be read from, written to, and configured (note the similarity to UNIX's read(), write(), and ioctl()), although not every device supports all three operations. A conceptual overview of these device operations is given in Section 3.1.

As in UNIX, devices in Player do not have a one-to-one mapping to physical hardware components, and with good reason. For example, it so happens that when retrieving odometry data from the ActivMedia Pioneer 2-DX robot, one also receives sonar range data. A client program that only wants to log the robot's current position should not also receive unwanted sonar range data; in fact, the client should be completely unaware of the coupling that exists inside the robot, because it is irrelevant. In order to present an intuitive interface to the client, Player controls one physical piece of hardware, the P2OS microcontroller, but implements two different devices: position and sonar. These two devices can be opened, closed, and controlled independently, relieving the client of the burden of remembering details about the internals of the robot. In addition to making such logical divisions, the device abstraction allows us to implement more sophisticated devices that do not simply return sensor data but rather filter or process it in some way.

Besides controlling different kinds of devices, Player can control multiple instances of a given kind of device. For example, if you have 2 SICK laser range-finders attached to your robot, then you can access both of them through the use of indices (see Chapter 4 for how to tell Player about the devices and Section 5.4 for protocol-level details of indexing). In fact, all device access is made by index; it just happens that most of the time, the index is 0 because there is only one of each device.

NOTE: Player implements no device locking. That is, many clients can have concurrent access to a given device, and they can concurrently command it. Player makes no attempt to arbitrate among the clients, and the command that is actually sent to the device will be determined by the rate at which the clients are sending commands, as well as some subtle timing issues. We purposefully chose not to implement any device locking, as it results in a more flexible system in which interesting ideas such as large-scale collaborative control can be explored (e.g., [3]).