Higher-level user application programme access hardware functionality through a device driver. Device drivers are software programmes that simplify programming by acting as a translator between hardware and the application that uses them.
Almost all the PGM hardwares are shipped with a Windows driver. Considering that most robotic development tools are based on Linux, this was the selected Operating System for IWARD (in order to simplify development between different project- partners, Ubuntu Linux was the preferred choice). Device drivers are hardware dependent and operating-system-specific. Therefore, separate device drivers for all PGM hardware are developed. At the development stage, all drivers were designed for Linux 2.6 kernel on X86 platform. Later they were cross-compiled for the gumstix XScale processor.
6.2.1 RFID Driver
Wavetrend provides only a Windows based device driver and executable sample demo application software for the L-RX201 RFID reader. They do not provide any source code to their clients. A Linux device driver is developed for interfacing the L-RX201 RFID reader unit with the PGM application programme. Figure 6-1 presents the architecture for the RFID device driver that is developed for IWARD project. This driver can be accessed also by any other application programme if required.
137
The L-RX201 reader comprises of a RF Module (RF Receiver and Demodulator) and a network communications module that includes a Micro-controller. The proprietary RFID protocol stack is already implemented by Wavetrend on onboard firmware of this Micro-controller. The Micro-controller communicates directly with the RF Receiver module and connects to the outside world via serial interfaces. Data can be sent independently to and from the 2 x RS485 ports of the L-RX201 reader and is simultaneously represented on the RS232 port. The RFID driver, interfaced with the serial port driver will access this data from the RS232 port of the host (PC, Gumstix etc.) through the serial driver interface of the kernel. The user application programme does not have to know the underlying protocols and addressing techniques, reader settings for configuration, specific packet format for sending commands and receiving responses, and how to decipher the Tag data from the incoming packets. Rather, it needs to invoke a routine in the driver and the driver will issue commands to the device. Once the device sends data back to the driver, the driver will invoke routines in the original calling programme. This also complies with the modular IWARD software architecture requirement as set by the consortium. Thus, writing a higher-level application code will become easier for the programmer. Furthermore, this modular architecture will also protect the system from crash if any programme is coded erroneously [280].
Figure 6-1: Architecture for the RFID device driver in Linux.
The RFID device driver is written in C using POSIX (Portable Standard for UNIX) terminal (serial) control functions. Serial I/O under UNIX is implemented as part of the terminal I/O capabilities of UNIX [280]. There is no separate serial-I/O API in UNIX. Routines that need to control certain terminal I/O characteristics do so by using the ‘termios’ structure as defined in the header <termios.h>. The POSIX "termios" structures are at the centre of serial-port I/O control. This RFID driver is actually a
RFID Reader Kernel space User space Serial Driver RFID Driver Application
138
wrapper around the ‘termios’ structure. The RFID device driver controls the designated serial port through the serial command interface parameters for the L-RX201 (given in Table 6-1).
Table 6-1: Serial command interface for L-RX201. Transmission speed Parity Start bit Stop bit Data bits 115200bits/second None 1 1 8
The application programme invokes the RFID driver using the provided interface. The driver opens the serial port, configures it for communication and passes the associated write command to the serial interface. The serial driver then writes these commands using system calls to the serial interface. The driver then issues a read command and if any data is presented at the serial port, the serial interface passes the response data back to the driver. The driver then deciphers the response data and returns the abstract data to the calling programme. Wavetrend has specific format of the ‘Write’ command and the response data. Due to the confidentiality agreement with Wavetrend Technologies Ltd. these are not disclosed here.
6.2.2 Cricket Driver
The Cricket driver is developed similarly, using a serial port. The cricket’s onboard embedded software is based on TinyOS 1.1.6 and pre installed by the manufacturer. The host device (to which the listener is attached) must run a software to process the data obtained [244].The cricket driver processes the information obtained over the serial interface and passes it to the user application programme. The cricket device driver is written in C using POSIX terminal control functions. The Cricket listener provides data in ASCII format to the cricket device driver running on the attached host over an RS232 interface. The serial command interface parameters for cricket are given in Table 6-2.
Table 6-2: Serial command interface for Cricket. Transmission speed Data format Flow control Stop bits 115200bits/second 8 bits, no parity Xon/Xoff(“software”) 1
The application programme invokes the cricket driver using the provided interface. The driver opens the serial port, configures it for communication. If the listener and beacons
139
are both turned on, every time the listener hears from the beacon it provides output data in ASCII format (as shown in Figure 6-2) to the serial port interface. The serial driver reads the data using standard UNIX system calls read(2) and passes it to the cricket driver.
Figure 6-2: Cricket output Data format
From the many fields of the output, the “DB” field gives the distance to the beacon. The default units are centimetres. The driver deciphers the distance results and passes it to the application programme.
6.2.3 Camera Driver
The Philips ToUcam PRO II USB camera only has driver for Windows OS. In Linux, one can use the OpenCV library for grabbing images from the USB connected Philips cameras. OpenCV has an interface for Video4Linux2 (v4l2) API which is included by default in the 2.6 kernel series. Unfortunately, v4l2 API was intended for TV grabber cards and not for webcams. It does not support all the features that Philips webcams have. For example, the settings for frame rate, shutter speed and automatic gain control can not be changed. Allowing a webcam to automatically adjust those features may work well for video conferences but these lighting variations are undesired effects in any image processing operation such as tracking or colour segmentation etc. Such kind of image processing operations requires the above features to be fixed. Fortunately, Pwc Wrapper [281] provides API and can be interfaced with OpenCV in order to gain full features of Philips webcams. A Linux device driver for Philips ToUcam PRO II camera was developed by combining the OpenCV library with Pwc Wrapper functions.