Human Interface Devices

navigation bar

Table of Contents > QUARC > User's Guide > Using Devices

The demand for interactive systems is continually increasing. QUARC is designed to meet that demand by interfacing with some of the latest human interface devices. For example, the Nintendo Wii Remote, or "Wiimote", was originally intended for games but is finding increasing application in other areas. QUARC allows real-time code designed in Simulink to interface with the Nintendo Wiimote directly, making its 3-DOF accelerometers, four infrared position sensors and 11 buttons accessible to real-time applications. Support for more human interface devices is already being planned for future releases of QUARC.

The human interface devices described in this section typically have a comparable version that runs on the host system and interfaces with the real-time code on the target, from the host. In fact, there are generally more "host" devices available. Refer to the Devices on the Host PC page for information about using human interface devices on the host to control real-time code on the target.

The host devices require the use of external mode in Simulink. The human interface devices listed in this section do not require external mode and interface with the device directly from the real-time code. Thus, these human interface device blocks are suitable for production code in which Simulink will not be used. The human interface device blocks currently available are enumerated below. Click on an item in the list to go to the corresponding reference page.

Wiimote

While each human interface device has different capabilities, the human interface device blocks supplied by QUARC function in a similar fashion. The Nintendo Wiimote will be used as an example.

The Nintendo Wiimote is depicted on the left. It combines pointing and motion-sensing capabilities, as well as a speaker, rumble feature and expansion board for additional input devices. QUARC currently supports its pointing and motion-sensing capabilities only.

Using the Nintendo Wiimote is as simple as placing the Wiimote block in your Simulink diagram. The Wiimote block is found under the QUARC Targets/Devices/Nintendo/Controllers library. It has a number of outputs. The state of the wiimote buttons is available at the buttons output as an 11-element vector Boolean values, corresponding to each of the 11 buttons of the wiimote. An element is true if the button is pressed, and false otherwise. To access the state of an individual button, use the Selector block in the Simulink/Signal Routing library. To access the state of every button as a separate signal, use the Demux block in the same library.

The Wiimote block also outputs a 3-vector containing the X, Y and Z axis accelerations, measured in g's, at its xyz_accel output. Again, the Selector or Demux blocks may be used to extract individual accelerations. The Z-axis acceleration will read a positive acceleration due to gravity when the wiimote is held motionless. While it is tempting to double integrate the accelerometer measurements in order to get position, it is important to note that this technique will experience significant drift because any offset in the accelerometer reading, however small, will be integrated. A better method of deriving position would be to use an estimator that combines the accelerometers and IR position sensing to determine absolute position.

The Wiimote is capable of using optical infrared sensing to detect the position of four infrared LEDs (usually mounted on a sensor bar that comes with the Nintendo Wii). Each position is an (x,y) coordinate pair representing the coordinates within a 1024 x 768 grid. The four IR position measurements are available at the IR_x and IR_y outputs, which are 4-vectors with one element for each position sensed. Again, the Selector or Demux blocks may be used to extract individual positions.

Unfortunately, the Wiimote is not always able to detect the positions of all the infrared LEDs because they must be in the line of sight of the device. Hence, the coordinates are not always valid. The IR_valid output is a 4-vector of Boolean values indicating which (x,y) coordinates are valid for the current sampling instant. This output may be used to drive the enable input of a set of Enabled Subsystem blocks to process the sensed positions only when they are valid.

navigation bar