Digital Motion Tracking System

Digital Motion Tracking System

Final Project Report

Andrew Dunmore

(356118)

Anthony Eshpeter

(252477)

Abstract

The completed project is a digital motion tracking system. It is capable of tracking the position of up to 31 sensors. It is queried for data through a parallel-port connection to some sort of device (most likely a PC). The querying device is capable of asking the system to:

Initialize. The system will initialize, and pass back the number of attached sensors.

Obtain Sensor Information. The querying device asks for information on a specific sensor attached to the system. The system will then return the position information of that sensor. If the system is unable to retrieve the information, it will return an error code.

The sensor position information is passed back as a 3-dimensional Cartesian vector (x,y,z) relative to the origin of the established grid. The positional information is returned back in millimeters, has accuracy to the nearest millimeter (x10^-3m) and has a range of 0 to 8191 mm.

Unfortunately, the system is not a complete success, and has two shortcomings:

The returned position information is not compliant with the specified resolution of millimeters, and does not return the position information correctly.

The initial system was supposed to calculate velocity, but now does not include that functionality.

This report will examine the successes and failures currently associated with the project.

Table of Contents

Abstract *

Table of Contents *

Overview *

Design Details *

Emitter *

Detector *

Hardware *

Controller *

Positional ALU *

Data Transfer (UART) *

Experimental Results *

System Data Transferring *

Information Queries *

Analysis of Results *

Design Verification *

References *

Digital Motion Tracking System Controller IC Data Sheet *

Design Documentation *

Overview

The ship is passive in its steady states, and does not do anything until the user asks it to do something. The user can supply two requests to the system. The first request is an initialization request. Sending the value 32 to the system does this. After the initialization code is sent, the user must expect a value back in the range of 0-31. This indicates how many sensors are attached. Once this value is received, the user may request information from the system from any of the sensors by passing the system a value between 0 and the number of attached sensors. If the passed value is invalid or the sensor times out, the system will return an error code (128) back to the user. If the received value is NOT 128, then it is part of the positional information and the user must expect 4 more bytes to come.

Design Details

Emitter

The emitter controls the pulsing of the speakers. When it is doing nothing, it asserts its ready_to_emit line so the main controller knows that it can send a pulse anytime. When the main_controller asserts one of the emitter’s sp_go lines, the emitter produces one clean pulse of duration 12.5 microseconds (a frequency of 40KHz). It then waits until the line has been low for 12.5 microseconds after the pulse before it reasserts it ready_to_emit line.

Detector

Hardware

The speaker is attached to the left side of the circuit show. From here it is passed through an audio amplifier. The audio amplifier was chosen because it produced the best frequency-vs-gain characteristics at 40Khz. This output is then pass through a comparator who detects whether the signal is above or below the DC steady state output of the amplifier. If it is below, it outputs a ‘1’, and if it is above, it outputs a ‘0’. To change to positive logic, the comparator output is passed through an inverter, which also produces the guaranteed TTL logic levels we need to interface to the FPGA.

Controller

The detector must time the duration of the pulse in flight. The detector is told to start timing at the exact same time that the emitter is told to emit a pulse. This counter is incremented once every3 microseconds ( 0.001 m / 330 m/s = 3 microseconds ). This means the counter holds the distance the sensor is from the emitter in millimeters. The counter is a 13 bit counter. If it reaches 8191 (1111111111111 binary) it sends a timeout to the main controller. If the detection circuitry does detect a pulse, the controller immediately stops the counter, waits for the pulse to go low, and then tells the main controller that valid data is waiting.

Positional ALU

Its purpose is to perform position calculations of the system. In order to calculate the x, y, and z coordinates, the following equations were produced:

The ALU will perform these operations and return its findings to the main controller where they will be processed to the computer via the UART. The inputs of the ALU will be the distances from the emitters to the receivers (R_o, R_z, R_y, R_z). Therefore these values must be squared in order to use them for further computations. The internal hardware of the ALU includes a squarer function at the input as to square each value as they enter the ALU. The squared values are then stored in registers, where they await further computation. The ALU will be set up in the following manner with data inputs coming from the detector, control inputs from the main controller and data outputs to the main controller.

Data Transfer (UART)

Data transferring is done through a standard parallel port. It allows the transferring of data in both directions at the same time. If the Trans_Req line to the main controller is high, the main controller knows data has been received. It then loads in that data and asserts the Trans_Ack line. If the main controller wants to send data, it puts the data on the DataOut lines and then asserts the Send_Req line. The UART will lower the CTS line during transferring (at which time the main controller must lower the Send_Req line) and re-assert it when transferring has been completed.

Experimental Results

The testing of the system involved two stages: system data transferring and information queries.

System Data Transferring

A program was written in C (see appendix) that was capable of the transmit/receive protocol used for the UART. The UART was loaded into the Altera board and wired to the 7-segment displays and dip switches. The 7-segment display showed any data that was transferred TO the board, and the dip switches were set for transferring data FROM the board. The results are tabulated below.

UART Receiving UART Transmitting

Data Sent	Data Received	Data Sent	Data Received
0	0	0	0
1	1	1	1
5	5	5	5
10	10	10	10
32	32	32	32
64	64	64	64
70	70	70	70
127	127	127	127
128	128	128	128

From the above data we were able to conclude that the system data transferring worked with 100% reliability.

Information Queries

Once data transferring was functional, the entire system was placed together and ran. First off, initialization was tested. Two sensors were given random addresses and attached to the system. The system was then told to initialize, and then it was asked for information on the sensors. Below are the results.

Sensor 1 Address	Sensor 2 Address	Initialization returned	Sensor 0 information query.	Sensor 1 information query.	Sensor 2 information query.	Sensor 3 information query.
1	2	2	Error	ok	ok	Error
3	5	2	Error	ok	ok	Error
30	3	2	Error	ok	ok	Error
15	8	2	Error	ok	ok	Error
0	6	1	Error	ok	Error	Error
0	0	0	Error	Error	Error	Error
1	0	1	Error	ok	Error	Error

This shows that the emitter circuitry/detector circuitry/main controller seem to be performing properly. The system is handling timeouts properly, the detector is detecting signal pulses, and the main controller is behaving properly.

The final test results were to place the sensor in the grid and make sure the returned positions were accurate. The sensors were queried for data 5 times in each position to check for stability of the results. Note: Sensors were mounted to a mount and were completely still during testing.

X Position Y Position Z Position

Actual Distance	Returned Result	Actual Distance	Returned Result	Actual Distance	Returned Result
50 mm	512	50 mm	512	50 mm	512
	512		512		512
	512		512		512
	512		512		512
	512		512		512
60 mm	512	60 mm	512	60 mm	512
	512		512		512
	512		512		512
	512		512		512
	512		512		512
70 mm	512	70 mm	512	70 mm	512
	512		512		512
	512		512		512
	512		512		512
	512		512		512
80 mm	512	80 mm	512	80 mm	512
	512		512		512
	512		512		512
	512		512		512
	512		512		512
170 mm	513	170 mm	513	170 mm	513
	513		513		513
	513		513		513
	513		513		513
	513		513		513
250 mm	514	250 mm	514	250 mm	514
	514		514		514
	514		514		514
	514		514		514
	514		514		514
300 mm	514	300 mm	514	300 mm	514
	514		514		514
	514		514		514
	514		514		514
	514		514		514
310 mm	514	310 mm	514	310 mm	514
	514		514		514
	514		514		514
	514		514		514
	514		514		514
320 mm	515	320 mm	515	320 mm	515
	515		515		515
	515		515		515
	515		515		515
	515		515		515

All four emitters produced the exact same results. This is attributed to the fact that all tests were done away from any walls that could possibly cause a discrepancy in data. This also shows that the emitter circuitry is producing the exact same wave pulses for each speaker and that the sensor is picking up on them equally.

Unfortunately, experimental data and actual data do not agree.

Resolution

Average Experimental Resolution = ( (170-0) + (250-170) + (320 – 250) ) / 3 = 107 mm

% error = (experimental –actual)/ actual x 100 = (107 –1)/1 = 106000%

Positional Error

approximately infinity. Easily seen in chart on preceding page.

Sensor Stability

% Deviation = 0% (by inspection of data on chart).

Analysis of Results

The results were surprising. Since the initialization routine works, we know the distance counters are timing out properly. We also know that the detector is telling the main controller data has been received because it returns back information. Unfortunately, the information is incorrect. This leads the distance counters to be the possible suspect of failure. With an average resolution of 107mm, the system seems to incrementing the counters at every 324 microseconds instead of the 3 microseconds it should be going. But this does not acknowledge the fact that the counter results should then start at 0 instead of 512. This leads one to believe the pos-alu is the other culprit. Unfortunately, previous simulation has shown that these two systems should work properly separately and together. There are currently two possible solutions to the problem.

Assume a faulty Positional ALU. Port the Raw data from the detector to the computer and allow the computer to perform the calculations. This would also allow for more room on the chip and velocity functionality could be placed in instead.

Modify detector for better reliability. The current detector design is very sensitive and will trip faulty readings if any noise interferes with it. It is possible that noise may be causing the positional ALU to shut down prematurely, and the remaining detection cycles then start up in the middle of the receiving pulse and produce erroneous results. In order to correct this, the system could be designed so that multiple pulses are detected before a decision is made on whether a valid signal was been received. This would increase reliability (if that is the problem), but would unfortunately increase latency and decrease accuracy.

Design Verification

(simulation)

References

Current references include many informative web sites:

Design overviews

http://www.cs.sfu.ca/people/ResearchStaff/amulder/personal/vmi/HMTT.pub.html

http://reality.sgi.com/employees/jam_sb/mocap/

Serial Interfacing Specifics

http://www.online.ro/chipdir/uart.htm

http://www.hut.fi/Misc/Electronics/hwprojects.html

http://www.senet.com.au/~cpeacock/

and a text:

Ashenden, Peter J. The Designer’s Guide to VHDL. San Francisco, California: Morgan Kaufmann Publisher’s Inc., 1996

Digital Motion Tracking System Controller IC Data Sheet

Pin	Name	Input/Output	Description
91	clk	input	The system clock. Must run at 25.175 MHz.
45-50	mic_address	output	The address lines that enable one of the 31 possible sensors.
63	sp1_out	output	Attached to the ultrasonic emitter at R_o. This produces the proper signal pulses.
64	sp2_out	output	Attached to the ultrasonic emitter at R_x. This produces the proper signal pulses.
65	sp3_out	output	Attached to the ultrasonic emitter at R_y. This produces the proper signal pulses.
66	sp4_out	output	Attached to the ultrasonic emitter at R_z. This produces the proper signal pulses.
182-188, 190	data_in_comp	input	Data lines coming from the computer.
195, 196	data_out_comp	output	Data lines going to the computer.
193	ack_comp	input	Data transmission control line. The computer asserts this line to acknowledge it has received the data properly.
199	CTS_comp	output	Data transmission control line. The system asserts this line when it is ready to receive data.
181	send_req_comp	input	Data Transmission control line. Computer asserts this line to tell the system it wants to send data.
198	trans_req_comp	output	Data transmission control line. System asserts this line when it wants to send data to the computer.
55	rec	input	Line from external detector hardware.

Maximum Speed

clock period = 93.9 ns

frequency = 10.64 MHz

Logic Blocks

Emitter	184/1152	16%
Detector	85/1152	7%
Positional ALU	528/1152	46%
UART	95/1152	8%
Main Controller	139/1152	12%
DMTS (digital motion tracking system)	1031/1152	89%

Design Documentation

(VHDL, schematics if applicable, module and interface descriptions)