High-Level Design

advertisement
Adrian Buckley
Evan Defibaugh
John Duhamel
Alex Kaiser
Darnell Parker
Craig Riggins
T
Q
~Q
Project Objectives
-
Relay real time Nintendo 64 session data
between multiple hosts for network play
Provide an interface for a Microsoft Kinect
frontend in place of tradition controller
Utilize non-obtrusive electronics
Minimize cost and maximize functionality
Power consumption is a secondary concern
System Architecture
Player 1
Controller Signal
Player 2
Controller Signal
Client 1
Server
Player 1
Controller Signal
Client 2
Player 2
Controller Signal
Nintendo 64
N64 RCA
Signal
Client 1
N64 RCA
Signal
Player 1
Television
N64 RCA
Signal
Server
N64 RCA
Signal
Client 2
N64 RCA
Signal
Player 2
Television
Client Architecture
Microsoft
Kinect
Kinect
USB Signal
Regular N64
Controllers
N64
Controller Signal
ARM Cortex
MCU
Digital
Controller Signal
Analog RCA
Signal
Television
Digital
RCA Signal
Ethernet IO
MCU takes input from 4 N64 controllers
 Microsoft Kinect can track 2 people

Server Architecture
Nintendo 64
Analog
RCA Signal
N64 Controller
Signal
ARM Cortex
MCU
Digital
RCA Signal
Digital
Controller Signal
Ethernet IO
Can communicate with 1-4 clients
 Moves controller signal from client to N64
and RCA signal from N64 to client

Unified Hardware
Nintendo 64
RCA
Signal
N64 Controllers /
Microsoft Kinect
Controller Signal
Controller
Signal
ARM Cortex
MCU
Controller
Signal
RCA Signal
Television
RCA
Signal
Ethernet IO

1 hardware architecture will be able to
operate as either the client or the server
Advanced System Architecture
Player 2
Controller Signal
Client 1 /
Server
Player 1
Controller Signal
Client 2
Player 2
Controller Signal
Nintendo 64
N64 RCA
Signal
Client 1 /
Server
N64 RCA
Signal
Player 1
Television
N64 RCA
Signal
Client 2
N64 RCA
Signal
Player 2
Television
Kinect Integrated Peripheral
Kinect
XBOX Kinect
Processor
Processor
Linux Microcontroller
Linux
Microcontroller
Kinect Sensor

I/O
 2 Cameras (RGB and IR Depth)
 IR Output
 4 Array Microphone
 USB Port
Possible Implementations
ROS: BeagleBone
2010: PC
VS C# 2010: Netduino
VS C#
Implementing Kinect
via ROS on Beaglebone
ROS (Robot Operating System) is an open
source project focusing on interfacing
microprocessors with robots (in our case the
Kinect and a peripheral Linux microcontroller)
Kinect Processor
Control Node
Implementing Kinect
via VS C# 2010 on Netduino
The Netduino operates on Microsoft Visual
Studios C# 2010 via Net. Micro workforce
Minor Hiccups in Progression
Using the Netduino
Using the Robot OS
• Netduino requires
 ROS tutorial has
Net. Micro
incorrect/missing
framework, where
info
Kinect requires Net.
 Open source, thus
Framework
compatibility issues
from node to node • Trouble converting
from standard to
 Unintuitive to
micro
navigate
There is no problems implementing Kinect via PC
Last Resort and Additional info
As a last resort the Kinect can be routed
through a Windows PC for processing then
sent to microcontroller.
More ROS info
More Net. Micro workforce
http://www.ros.org/wiki/kinect
(Install ROS)
http://www.ros.org/wiki/ROS/Tutorials
(ROS Tutorial)
http://beagleboard.org/bone
(Beaglebone Description)
http://www.ros.org/browse/list.php
(ROS software)
http://docs.com/BTN4
(Installing OpenNI)
http://www.netduino.com/netduino/schematic.pdf
(Netduino Schematics)
http://informatix.miloush.net/Microframework/Arti
cles/WpfEmulators.aspx
(.net micro install)
http://informatix.miloush.net/microframework/Arti
cles/Reflector.aspx
(.net micro reflector)
http://netduino.com/netduino/specs.htm
(Netduino Specs)
Gesture and Speech Algorithms
Joint Data is returned in X, Y, Z, and W
(confidence) data
 Evaluate position of joints relative to another
and trigger button pressed event
 For audio grammar files must be written
 Compare text output of audio and set trigger
for the controller or the sensor as being used
 Output control trigger and button triggers

Kinect Processor Interface
The Processor will output triggers in the form
of buttons and sensor/controller triggers for
both players one and two
 The triggers will be relayed to the Linux
microcontroller that will convert button trigger
to N64 controller output format and use the
control trigger to decide if forwarding the N64
controller data or sensor converted data

N64 Controller Tutorial
How the N64 Controller Sends Its Data


The N64 controller only has three pins: Ground, data, and
VCC. It takes a +3.6V supply.
The N64 uses a protocol in which bits are sent serially to and
from the controller as 4µs-wide pulses. ‘Low’ is 3 µs low and
1 µs high, and ‘High' is 1 µs low and 3 µs high.
N64 Data Polling
The N64 continually polls the controller using an 8-bit
command (0x01), and the controller reports the state of its
buttons and analog joystick with a 32-bit response: 16 bits for
the buttons, signed 8 bits for horizontal joystick position, and
signed 8 for vertical. Each bit packet ends with a stop bit (1).
Button Configuration
The buttons are mapped to their respective bits as follows:
Bit
0
1
2
3
4
5
6
7
Button
A
B
Z
Start
D-Up
D-Down
D-Left
D-Right
Bit
8
9
10
11
12
13
14
15
Null
Null
L
R
C-Up
C-Down
C-Left
C-Right
Button
Sample Joystick Positions and respective bits:
Left Extreme
1
0
0
0
0
0
0
1
Left Off Center
1
1
1
1
1
1
1
1
Right Off Center
0
0
0
0
0
0
0
1
Right Extreme
0
1
1
1
1
1
1
1
Up Off Center
0
0
0
0
0
0
0
1
Down Off Center
1
1
1
1
1
1
1
1
Joystick Off-Center Left & Down
The Translator Box

The Kinect will take player movement/sound data and
send over button and trigger data to the “translator box,”
which then converts that data into the 64-bit struct
format shown below.
Button Data
Joystick Data
Which Player?
More Buttons?
Time Delay
16 bits
16 bits
1 bit (0 or 1)
1 bit
Int (30-bit)


There will be a physical master switch on the translator
box, to switch between Kinect control and N64 controller
control. When this switch is set to “Kinect,” the
translator will await trigger and button data from the
Kinect to process.
If the switch is set to “N64,” the translator will need to
keep track of one or two controllers, simultaneously
converting their button presses into the shown format,
but with the “More Buttons” bit and time delay
consistently set to zero.
Server to Translator to N64


Another Translator Box is needed to translate the
Server’s data into N64 controller data for the N64.
This translator will read in the controller data, and send
the correct button sequence via serial ports to the N64,
correctly timed. If the N64 polls the “controller,” but the
translator has not received button data from the server,
the translator will automatically respond with a 32-bit ‘0’
analog stream and continue doing so until new button
data appears.
Audio/Visual Signal


The video output of the Nintendo 64 carries
visual information via an analog signal, plus
two synchronizing signals for aligning the
video signal on a television.
The audio output, also analog, is split into
two signals for stereo speakers in a
television.
Audio/Visual Waveforms
Video
Audio
Audio/Visual Sampling


The audio and visual output of the Nintendo
64 must be digitized and formatted for input
into the server for transport over the internet.
Once the audio/visual information is sent
over the internet it must be converted back
into an analog signal to be displayed on a
player's television.
A Series of Tubes – Hardware

Initial design and testing will be done on an
Arduino with an Ethernet shield.
 Ardiuno is easy to program to send and receive
data packets.

After getting a fully functional system with the
Premade hardware we will move on to a
custom PCB with a Linux OS.
Our Internet Objectives

We need the data received from the server
to be real time
 If there is missing data we just move to the next
data packet.
 We know that the receiver is ready to receive
packets.
TCP/UDP

TCP/IP uses an established connection
between sender and receiver.
 This requires an acknowledge signal from the
receiver which takes time.

UDP instead sends packets in a continuous
stream and doesn’t care if packets are
missing on the receiver side.
 Instead of waiting for acknowledgement UDP just
tags the packet with the correct receiver IP
address and sends it on its way.
UDP in depth

UDP sends data with a header, and within
the header a 2byte portion telling the
receiver how long the data section will be.
 This 2byte section allows for a maximum of 64Kb
section of data which is more than enough for
sending the n64 signal and frames of an RCA
signal.
 The other parts of the header are receiver IP and
port number.
Putting it all Together
Using UDP because we need a real time
connection and don’t mind dropped packets.
 Using a static IP for our server so that we
have something to aim at for our UDP
packets.
 Using Arduino and Ethernet shield to
prototype and onto custome PCB once all
kinks are worked out.

Project Schedule
Longest Design
Period
37 Days for Integration
11 Days for Testing
Technical Reference Manual
Division of Labor
Task
Adrian
Program Mgmt &
Documentation
P
Kinect Programming
S
N64 Translation
Evan
John
Alex
Darnell
S
P
S
Ethernet Interface
P
S
S
Audio/Video Signal
Conversion
S
P
S
N64 Gameplay Action
P
P
P
P = Primary
S
S
P
Controller Programming
Craig
S
P
P
P
S = Secondary
P
P
Advanced Parts List
Hardware
Television
XBOX Kinect
Nintendo 64
Nintendo 64 Controller
Nintendo 64 Controller
Nintendo 64 Controller Cable Extension
Nintendo 64 ROMS
Netduino
Beagle Bone
Modem
Parts for Printed Circuit Board
XBOX Kinect / Nintendo 64 Shield
RCA Cable
Case
PCB Development / Revisions
Cost Quantity Extended Cost Possible Substitutions
Provided
Provided
Provided
Provided
$19
$10
Provided
$60
$90
Provided
$50
$14
Provided
$10
$500
2
2
2
3
4
2
7
2
3
1
1
2
1
1
TBD
Provided
Provided
Provided
Provided
$76
$20
Provided
$120
$270
Provided
$50
$28
Provided
$10
$500
Beagle Board
Coax Cable
TOTAL ESTIMATED PROJECT COST = $1,074
*NOTE* – ALL EXPENSES PAID TRIP TO LAS VEGAS FOR “ELECTRONICS
SEMINAR” NOT INCLUDED
Goals
Primary:
• Control Nintendo 64 game exclusively via an XBOX Kinect
Secondary:
• Have one N64 controller communicate with one N64
console over the internet
• Control the N64 game using either the Kinect or the N64
controller remotely
Tertiary:
• Play a complete N64 game with 2 players at one location
using the Kinect, and the other 2 players at a different
location using N64 controllers
• Allow functionality with a variety of different controllers
Milestone 1 Objectives
Kinect Translation
• Kinect translator sends simple gesture data to
the Linux µController, in correct format
Nintendo 64
• Send properly timed Nintendo 64 analog signal
from the µController to the N64 console
Network Configuration
• Send data packets across the network to and
from each user using the µController
Audio/Video
• Convert analog input into a digital code
Milestone 2 Objectives
Kinect
 Determine ideal Kinect gestures for
satisfactory user interface
 Transmit verbal commands through Kinect
Network Configuration
 Send and receive N64 and audio/video
signals across server
Audio/Video
 Output signal from server to television
Risks and Contingency Plan
Risks
 Syncing the N64 timing sequence with the Netduino
microcontroller’s internal timer
 Busy internet path/lost data packets
 Delay between Kinect / N64 input and television
output
 Data corruption or potential injury resulting from
falling or player collisions while playing with a
motion sensitive controller
Solutions
 Use only N64 controllers (no Kinect) for game
control
 Leave out server / direct connection from
microprocessor to N64
 User plays video game at own risk!!
Questions???
Download