Team Members: Eric Klawitter, Arnold Taganas, Michael Yu

Summary

The purpose make a mouse that could function without using an optical tracker or mechanical tracker, which can only operate in certain conditions. This was accomplished using an accelerometer and gives a solution that functions similarly to a WiiMote. Two mbeds (one for the handheld transmitter, one for the desktop-connected receiver) are used to implement a wireless solution.

Mouse/Transmitter:

Receiver:

Video Demo

Motion Tracking

The project uses a (BNO055 IMU). The solution uses the yaw and roll of the IMU to control the horizontal and vertical position of the cursor, respectively. The user can turn and point the mouse in order to move the cursor.

Using the mouse's orientation instead of its position leads to several benefits. First, the motion was much more ergonomic and easy to control. Second, tilting and rotating the mouse requires less space than moving it laterally. Finally, the motion is much more intuitive for users as it behaves very similar to pointing. This makes it very useful for events like presentations.

The controls are relative, i.e. motion commands are sent based on a change in the mouse's position rather than tracking its current position. The mouse seems to function best when the range of motion just covers the entire resolution of the screen; however, there are options to change the sensitivity of the mouse for a user's preference. In the case where the range of motion does not cover the entire screen, a button can be depressed to move the mouse WITHOUT moving the cursor, allowing the user to reset their hand position, much like lifting a regular mouse off the mousepad.

Touchpad

The project uses a (MPR121 Touchpad). The Touchpad obtains 12 buttons that correlate to different commands. Commands for each button is shown on the figure below.

Touchpad

Two bytes are used for the buttons on the touchpad. The two bytes contain a bit array where each bit is assigned a command. Each time a button is pressed, an interrupt on a falling edge will be used to call the function to send a command.

Wireless Communication

A free space mouse is half useless when tethered by a cable to a computer, so the mouse had to operate wirelessly. This was done by using an RF transmitter and receiver to handle communication. One mbed with the IMU sends data to the receiver that then sends the data to the computer.

The overall range of the pair is quite good. We have not been able to move far enough away to break the data link while still being able to see the screen/cursor (30+ feet).

Transmitter

(Looking towards the silver circle, left to right)

The transmitter sends eight bytes of data per transmission. Two bytes are the mouse's yaw. Two bytes are the mouse's roll. Two bytes is a bit vector representing the buttons' states. The final two bytes are used as a checksum.

Receiver

RF Messaging Protocol

Each message from the transmitter to receiver consists of 8 total bytes. The X, Y, and button values are each encoded into 16 bit short values. Each value is encoded in little endian format, with the X and Y as signed 16 bit integers. The button code is also sixteen bits, although only 12 are used. The touchpad on the transmitter has 12 individual buttons, and each of the first twelve bits represents a button, with 1 indicating a press. These 6 data bytes are book-ended by a start character and checksum. The start character is always 0x55. The checksum is the 8 bit sum of every byte (including the start character) without inversion and ignoring overflow. This is calculated on the sender side and validated by the receiver prior to processing the data.

USB Mini-B

The receiver takes the data from the transmitter and decodes it. The yaw and pitch are scaled to pixels. The button state is decoded to determine which buttons were depressed. It uses the USBDevice Library to setup the appropriate drivers to be used with a windows PC. In order to add functionality, the USBMouseKeyboard class was used to provide features like back, forward, page up, page down, etc.

Code

Wireless Transmitter

Wireless Receiver and PC Interface

Issues

The original attempt was to track the 2D position of the mouse for cursor control; however, because the IMU can only measure acceleration, velocity and position had to be numerically integrated. Unless the IMU is both extremely fast and accurate, this can lead to large errors, especially as time progresses and the errors accumulate.

It was planned to use two bluetooth modules to communicate between the two mbeds; however, we could not find a way to have our bluetooth modules communicate with one another instead of the app, so we switched to RF.

When we switched to RF, we were able to transmit data, but the receiver encountered large amounts of noise and signal distortion, causing poor data transfer. A checksum was implemented in order to allow corrupted data to be detected and ignored.

One final issue encountered was that the transmitter maxes out at 4800 baud. This corresponds to only 75Hz (modern mice typically are 1000Hz). When accounting for corrupted transmissions that must be thrown out, the mouse might have been 60Hz, giving a jerky motion. It is still easily usable, but can be a visually distracting. A solution would be to use a solution that allows higher data throughput.

Future Work

The most important issue to solve would be using a communication protocol to allow higher bandwidth to allow smooth cursor motion.

The current solution fits well in the hand and almost feels like a remote, but it would also be a nice addition to set all of these on a custom board to shrink the size. Then it could be packaged into a better form factor.

Finally, further functionality can be added. It's been mentioned that this would do well for presentations. Other features, like a laser pointer and microphone could prove useful to the users of this device.