UltraMouse 3D
UltraMouse 3D
UltraMouse 3D
Ultramouse 3D is a spatial human interface device that lets the user interact with computer
programs in three dimensions.
Introduction
Ultramouse 3D times the delay of high-frequency sound waves from the unit held by the user to
each of three receivers and passes this information along a serial cable to the computer. The
accompanying open-source API provides easy functions that let any Win32/C++ application start
reading 3d data in less than 5 minutes.
This is our unique final project for ECE 4760 at Cornell University.
Karl Gluck
MCU software implementation, C++ API and 3d demo code
David DeTomaso
Hardware design, refinement and analysis
Design
Conclusions
Everything from schematics and a bill of materials to the C++ API and a DirectX demo project.
Jump to a Section
High-Level Design
Design Considerations
Analog Design
MCU Software
PC Software (API)
Software Downloads
Results
Ethical Considerations
Legal Considerations
High-Level Design
Sound travels through air at approximately 345 m/s. From this, the time it takes for sound to
travel between a transmitter and receiver can be described as:
From this, a reasonably fast counter could keep track of a time delay between transmission and
reception and back calculate a distance.
If the time of transmission and the time of reception on each of three receivers is known, R1, R2,
and R3 can be calculated. Then, with known values of w and h, the 3d coordinates of the
transmitter can be calculated by solving a system of equations of the form:
The only patent we could find is US Patent # 4862152 which details a similar system of
ultrasonic 3d positioning and was filed in 1985. However, beause the patent does not seem to be
extended and because our design differs in the specific way pulses are detected and position data
is filtered, we do not think that our project is in violation of this patent.
Design Considerations
Placement of the ultrasonic sound receivers will affect the accuracy of the measurements. In
order for sufficient resolution, the distances between receives should be on the same scale as the
distance between the transmitter and the receivers. Receivers very far apart are not practical for
the user and receivers close together will have very small time offsets. For the application space
we intended, it made sense to mount the three receivers on three corners of a computer monitor.
In order for the MCU to accurately resolve the three distances, a fast counter is needed.
However, because the MCU’s onboard Timers cannot be interrupted with three separate external
inputs we must emulate a timer by calling an interrupt at a fixed rate. Increasing the rate of this
interrupt will allow the system to resolve distances more accurately but also limit the amount of
code that can be executed within the interrupt. We chose to run this interrupt at a rate of 160 kHz
so that accuracies as fine as 2mm could be resolved and the interrupt could use up to 100
processor cycles to handle the receiver signals.
Analog Design
Receiver Circuit
The main purpose of the receiver circuit is to amplify the small 40 kHz signal coming from the
ultrasonic receiver so that a digital input port on the MCU will read a logic high when a signal is
being transmitted and a logic low at all other times. Additionally, the delay through the circuit
should be minimal to allow for accurate positioned based on the sounds propagation delay in air.
To accomplish this, we have cascaded three operational amplifiers configured for an overall gain
of around 80 dB. For each amplifier, we required the following specifications:
We found the following specifications well satisfied by the Japan Radio Co. NJU7031D
operational amplifier. The resulting circuit worked well within the required specifications and
was able to amplify input signals to small to be discerned on the oscilloscope to levels detectable
by the digital input pin.
Transmitter Circuit
Our transmitter circuit is modeled after the fan driver circuit found in lab 5. To drive the
ultrasonic transmitter an alternating voltage at 40 kHz must supplied across the transmitters two
leads. To accomplish this, we used a digital output pin the MCU to drive the gate of a power
transistor. By placing the transmitter, in parallel with a resistor, between the transistors drain and
the supply voltage, a 40 kHz signal supplied by the MCU can drive a 40 kHz signal across the
transmitter ranging from supply to ground. To transmit as strong a signal as possible, we use the
voltage coming directly out of the AC/DC transformer which tends to range from 9 – 13 volts.
The main method of the MCU program is used to initialize required values and to take over once
all three receivers are triggered. After variables are initialized, an infinite while loop
continuously checks to see whether three receiver triggers have been detected or if the timeout
value has been reached. If either of these is the case, TCCR0B is set to 0 to disable the 160 kHz
interrupt so that transmission can be handled efficiently. If three triggers have been detected, the
loop waits as ISR USART0_UDRE is called to send time delays to the PC. In either case, delay
and counter variables are re-initialized and the 160 kHz interrupt is enabled and set to transmit
for its first millisecond.
UM3DAPI_Create
UM3DAPI_Update
Called every loop of the main program to read data from the device and calculate its
coordinates
UM3DAPI_Destroy
The functionality of these methods is clearly explained in the source file, but a few design points
are worth mentioning.
First, the incoming data from the receiver is very noisy--for every hundred good samples, there
are a few huge spikes in the delays. Standard linear filters we attempted (low-pass, mean,
moving average, exponential weighting) were unable to remove these effectively without
creating such large delays in the data that the interface felt sluggish. Instead, the implementation
uses a median filter on the incoming data points. This effectively eliminates all large jumps in
the data; however, it leaves smaller ones. In the figure below, data was taken for the user
drawing a square (more data here). The blue stars are the source data, and the red line is the
median-filtered data.
The second important point is how we removed the smaller jitters in the data. By smoothing the
triangulated spatial coordinate from the output of the median filter into the "current" position by
an exponential weight, the smaller jumps are hardly noticeable. Unfortunately, this means that
the filter's ideal exponential constant has to be tuned to the rate at which UM3DAPI_Update is
called.
Finally, the Z-axis is different than one would expect. Although the math derived to calculate a
true z-coordinate works fine in theory and MATLAB simulation with ideal data, in practice it is
unusable. Instead, the UM3D API simply takes the sum of square distances to each receiver and
calls that the "Z" coordinate. As a result, "Z" is more sensitive on the top and left side of the
screen (where there are two transmitters close together); however, the slight distortion isn't
nearly as bad as using the extreme distortion experienced with a true mathematical solution. A
second effect is that Z is positive coming out of the screen, making this a left-handed coordinate
system.
We also found that the serial interface on the computer is very slow. The MCU has to delay 30
milliseconds (enough time for 480,000 instructions!) every loop to avoid filling up the PC's
serial-port buffer. The symptom of transmitting too quickly is that motion becomes delayed by
several seconds as the buffer is slowly emptied by the receiving program.
One final "gotcha" was that if you start up the MCU before starting the client program, there is a
chance that the program will start picking up bytes in the middle of a transmission. The incoming
data will look like junk (delays should be less than 400 most of the time, but junk will often be
tens of thousands), or it may seem like receivers are placed in the wrong order.
Results
Our device samples position data at a rate of 50 Hz allowing for quick updating of the receivers
position in a real-time feel. The range of operation is about a meter. This is because we are using
a transmitter to act as one of our receivers in order to save cost and its lowered sensitivity to the
ultrasound signal limits our range.
To test the accuracy of each receiver, we recorded while holding the transmitter still for 12
seconds.
Receiver Mean Distance Maximum Variation Standard Deviation
#1: Bottom Left 54.3 cm 7.1 cm 1.5 cm
#2: Top Left 45.8 cm 2.6 cm 0.5 cm
#3: Top Right 45.8 cm 3.4 cm 0.6 cm
Because our design emits audio frequencies at 40 kHz, it will interfere with other designs that
operate on the same frequency. The transmitter is extremely easy to use: all that is needed is to
hold the device within range of the receivers and point it in their general direction.
Conclusions
Our device can function well in the way that we intended it to – as a 3-dimensional input device
to a computer. However, jitter in the time delays recorded by the MCU were higher than we
initially expected. Additionally, the range of approximately 1 meter was less than we expected.
If further development were considered to allow for the use multiple simultaneous inputs then we
propose the following design changes:
Flip the circuit around so that the held units contain receivers and the mounted units
contain transmitters.
Transmitters will pulse one at a time at a fixed rate
Receivers will calculate how the rate they observe deviates from the known fixed rate
Increase the number of transmitters from three to four so that precise synchrony between
transmitters and receivers is not needed
Position information sent back to the input unit using the wireless Bluetooth protocol
In this way, a large number of 3d position units could be simultaneously used without interfering
with each other. This could be useful if the device were incorporated into a gaming system to
allow for multiplayer capability.
Ethical Considerations
In the spirit of training ourselves to practice as ethical engineers, we have followed this code of
ethics throughout the design, assembly, testing, and reporting of our project. As per our
responsibility, we have taken precautions to ensure the safety of anyone using our device by
preventing accidental electrical contact. Since our principle interests in the design of this device
were to further our knowledge of design using microcontrollers and to complete the ECE 4760
course, no conflicts of interest exist. All of our claims on the devices performance were made
based on real, un-altered data collected while testing our device.
We believe our device is an appropriate application of technology using ultra-sound and in its
design we have improved our own and possibly a few friends understanding of what can created
using electrical devices. Because our project fits within the skill-set of ECE 4760 and because
both of us satisfy the requirements to enroll in this class, we felt qualified to undertake this
project. All work, unless otherwise credited, is our own. Issues such as bribery, fair-treatment,
and malicious action were not encountered throughout our completion of this project.
Legal Considerations
The safety of our users is both a legal and ethical consideration and so precautions have been
taken to ensure no skin-to-wire contact when using the device. The only significant transmitted
energy from this device is the 40 kHz sound wave emanating from the ultrasonic transmitter.
Because this is not an electromagnetic wave and 40 kHz is outside the range of human hearing,
its intensity is not regulated by the FCC. However, this noise will be detectable by some
household pets including mice, cats, and certain species of dog. Before commercial deployment
of such a device, research will have to be undertaken to rule out the possibility of induced
hearing damage in these household pets when near the transmitter of our device.
The only material we used not created by us is the Tiger_3d demo which is distributed for free
use by Microsoft. It would probably not be possible to patent our project in its current state
because 3d ultrasonic positioning has been patented before however a more specific
implementation (such as the suggested changes to include multiple receivers) would be
significantly different from previous ideas and might be able to receive a patent.