3.1 Device access: data, command, configuration

Data

When a client reads from a device, the client receives the device's current data. For a Player device, the term data is used to refer to the salient state of the device. Of course, this definition is not objective, and for some devices, there may be more than one reasonable choice at to what constitutes the data. However we find that for most devices we can readily define the data as the information that is of interest to clients and that changes (relatively) frequently. For example, when interacting with a sonar device, which controls an array of sonar tranducers, the data is simply a list of range readings. For a laser device, which controls a scanning laser range-finder, the data includes not only the range readings from the laser but also some current settings of the laser, such as scanning aperture and angular resolution. We originally included only the range readings, but found that the auxillary configuration data is comparatively small and is in fact required in order to correctly interpret the range data. In the same way, the contents of a device's data will in general represent a trade-off between information content and communication overhead. Keep in mind that a device's data will usually be transmitted to the client at 10Hz (or faster).

Command

When a client writes to a device, the client sends a new command to the device. For a Player device, the term command is used to refer to the salient controllable state of the device. That is, a device's command will generally include those parameters of the device that are most often changed in the course of using the device. For example, when interacting with a position device, which controls a mobile robot, the command is a set of translational and angular velocities. Although many other aspects of the robot are user-configurable, most of the time one need only change the translational and angular velocities, as they determine the physical position of the robot, which is the main point of interest. For a speech device, which controls the a speech synthesizer, we chose to make the command the ASCII string that is to be synthesized; we believe that this choice presents a natural interface to the underlying synthesizer. Again, command specification will be different for each device, and keep in mind that a device's command will usually be transmitted to the server at 10Hz (or faster).

Configuration

All device interaction that does not qualify as data or command must be implemented as configuration. Whereas data and command are asynchronous, one-way, (pseudo-)continuous streams, the Player configuration mechanism provides a synchronous, two-way, request-reply interaction between client and device. When a client sends a configuration request to the server, the request is added to an incoming queue for the appropriate device. At its leisure, the device will service the request, generate an appropriate reply and add it to the device's outgoing queue. This reply will then be transmitted by the server to the waiting client. Thus another distinction of configuration, as compared with data or command, is that configuration requests and replies are not overwritten and so are guaranteed to be received by the device and the client, respectively^3.1.

In general, any kind of device interaction can be implemented as configuration, and a device can accept more than one kind of configuration request. Usually, configuration is used to assign or query some aspect of the device's state. For example, when interacting with a fiducial device, which finds special beacons in the environment, there are configuration requests that can be used to set parameters used in finding and identifying the beacons. Compared to data and command frequency, configurations are made relatively rarely; if for a particular device a particular configuration change is made very often, then the variables being configured should probably be part of the device's command.