Mech - User contributions [en]

ME 333 final projects

2010-03-19T03:13:25Z

MeganWelker: /* Haptic Gaming System */

See the '''[[ME 333 end of course schedule]]'''.

Final projects for ME 333 in years 2000-2007 can be found
'''[http://lims.mech.northwestern.edu/~design/mechatronics/ here]'''.

__TOC__

== ME 333 Final Projects 2010 ==

=== [[Sample Project Title]] ===

[[Image:Persistence of Vison Display|thumb|150px|Project photo caption.|right]]

You can copy and paste this wiki code to start your wiki page (but don't erase this code). Then replace this text with your own. A few sentences describing what your project does, with a link to a youtube video. Look at other final project wiki pages for ideas, but see [[ME 333 end of course schedule]] for more information on what should be included on your wiki page.

 

=== [[Furuta Pendulum]] ===

[[Image:Picture 1.png|thumb|150px|Furuta Pendulum|right]]

The Furuta pendulum, so named because it was first developed by Katsuhisa Furuta, is a rotational inverted pendulum. In other words, the horizontal arm, which rotates in the horizontal plane, drives the movement of the vertical arm, which is free to rotate in the vertical plane. Out objective was to build a Furuta pendulum that would hold the vertical arm up, as you can see from the [http://www.youtube.com/watch?v=7DtFLKgNUk4 demonstration video].

 

=== [[Music from the Heart -- Music Suit]] ===

[[Image:Music from the heart overview.jpg|thumb|150px|The "music suit" on James, with heart rate detector on his finger.|right]]

This project attempted to create a natural form of musical expression by connecting sensors to the body. Six tilt switches were attached to the wrist, ankles, and shoulders, each controlling a single pitch from the [http://en.wikipedia.org/wiki/Pentatonic_scale pentatonic scale]. The heart beat was obtained using [http://en.wikipedia.org/wiki/Photoplethysmograph photoplethysmography] on the user's finger, and this signal was used to strike a drum in sync with the heart beat.

For a video demonstration, click [http://www.youtube.com/watch?v=YyipByy7m6I here].

 

=== [[Conservation of Angular Momentum Locomotion Robot (Fluffbot)]] ===

[[Image:Isometric view of Fluffbot guts.jpg|thumb|150px|The Fluffbot without Fluff.|right]]

Cute fluffy robot that uses conservation of angular momentum to move forward and backward. The robot's momentum wheel accelerates in the floor-plane. The robot's net angular momentum must remain zero-- a steering wheel guides the Fluffbot to accelerate in the opposite direction. This moves the robot forward in a curved path. The momentum wheel and steering wheel then change direction of acceleration. This repeated process moves the Fluffbot forward in a sinusoidal path.

 

=== [[Differential Drive Mobile Robot]] ===

[[Image:Mobile_Robot_-_Parametric_-_Small.jpg|thumb|150px|Mobile Robot|right]]

The goal of this project was to create a small differential drive mobile robot that would act as a low cost replacement for the popular E-Puck Robot. The robot uses hybrid stepper motors to allow it to track its position through odometry, has a laser cut acrylic chassis for easy replication and replacement, and a 1500 mAh, 13.2V battery pack for long run time. The robot also uses the NU32 board for its control logic and a XBee chip for communication.

 

=== [[Ferrofluid Art Display]] ===

[[Image:Persistence of Vison Display|thumb|150px|Place holder text for caption .|right]]

A little blurb about our Ferrofluid Art Display will go here. Just a few sentences talking about blah blah lkasjdfal hfalsdjh.

 

=== [[Can Launching Fridge]] ===

[[Image:27_Fridge.jpg|thumb|150px|Project photo caption.|right]]

The goal of the can launching fridge was to create a fridge that would, when initiated by either a remote control or a wired push button, automatically load, aim, and fire a can to multiple predetermined locations. The fridge uses a combination of stepper motors, a DC motor, and solenoids to create the ultimate mix of convenience, fun, and refreshment.

 

=== [[High Speed Motor Control]] ===

[[Image:2dofArmSetUp.jpg|thumb|150px|Project photo caption.|right]]
The project suggested was to design a system for high speed motor control using the PIC 32. To demonstrate the motor control, a two degree of freedom (2-DOF) parallelogram robot arm was designed to follow paths specified in a MATLAB gui.

 

=== [[Variable Frequency Electrosense]] ===

[[Image:TR_JP_PP-sensor.jpg|thumb|150px|Variable Frequency Electrosense|right]]

Our objective was to build upon existing research being done at Northwestern utilizing Electrosense technology by testing if information can be derived from varying the emitter frequency. We sought to send sinusoidal waves at discrete frequencies between 100 Hz and 10 kHz and to read in the sensed wave using a PIC 32’s ADC. We then sent the gathered information to a PC for plotting and analysis. By mounting the sensor on a one dimensional linear actuator we are able to gather additional data about objects and perform object detection and identification algorithms. While our initial results have revealed exciting trends, farther research is necessary before any significant conclusions can be made. A [http://www.youtube.com/watch?v=PJY097L2m1M video] of the project is available on YouTube.

 

=== [[Remote Controlled Wiitar]] ===

[[Image:Wiitar.jpg|thumb|150px|Guitar Controlled by a wiimote: The Wiitar!|right]]
This project uses an array of solenoids to depress stings on the neck of a guitar. A motor over the strings of the guitar turns an arm which strums the instrument, playing the chord depressed by the solenoids. The system is controlled by a Wii Remote.

 

=== [[6-DOF PPOD]] ===

[[Image:Jd-cr-Assembly.jpg|thumb|150px|Project photo caption.|right]]
The PPOD-mini is a miniaturized version of the Programmable Part-feeding Oscillatory Device ([http://lims.mech.northwestern.edu/projects/frictioninducedforcefields/index.htm PPOD]) found in the Laboratory for Intelligent Mechanical Systems (LIMS).

 

=== [[Butterfly Rolling Manipulation]] ===
[[Image:Butterflyteampic.jpg|right|upright=1.3|thumb|Butterfly Project at Mechatronics Fair]]
The Butterfly emulates contact juggling by the stabilization of dynamic rolling. The apparatus rolls a cylinder by rotating the "hand" using a specific trajectory and is able to move the cylinder from one side to the other without losing contact. A video of the Butterfly captured in high speed can be found [http://www.youtube.com/watch?v=dtYv3qNz_LI here].

 

=== [[Haptic Gaming System]] ===

[[Image:Haptikos.jpg|thumb|150px|Haptic Robot.|right]]

An interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor by moving the red joystick. Two games were created to test the feedback system. The first is a side-scroller in which you avoid hitting moving blocks. The second involves feeling out the virtual shape with nothing other than a blue position dot and a blank screen.

Watch [http://www.youtube.com/watch?v=7j37NCYWHF8 Haptikos] in action

 

== ME 333 Final Projects 2009 ==

=== [[Mozart's Right Hand]] ===
[[Image:mrh_box.JPG|thumb|150px|Mozart's Right Hand|right]]
Mozart's Right Hand is a musical instrument capable of playing two full octaves of the [http://en.wikipedia.org/wiki/Diatonic_scale Diatonic Scale.] The user wears a glove on his right hand and uses motions of the hand and fingers to create different notes that are played with a speaker. The pitch of the note is controlled by the orientation of the user's hand as he rotates it ether from the wrist, the elbow, or the shoulder. The LCD on the front of the box tells the user the pitch that corresponds to his or her current hand orientation. When the user touches together his thumb and index finger, the speaker plays the tone. A [http://www.youtube.com/watch?v=vec-W4QeHQU video] of Mozart's Right Hand in action is available on YouTube.

'''Chosen the OUTSTANDING PROJECT by the students of ME 333.'''

 

=== [[Persistence-of-Vision Display]] ===
[[Image:Persistence of Vison Display|right|thumb|150px]]
This is a fully customizable display implemented using the concept of Persistence of Vision. User-specified images (and even moving images) were displayed by rotating a column of LEDs at speeds faster than 300rpm. Each individual LED was modeled as a row of pixels. Conversely, the rotational position of the panel of LEDs represented the pixel columns of the display; the time interval and rotational speed determined the width of the pixel columns.

 

=== [[Rock Paper Scissors Machine]] ===
[[Image:rps whole thing.JPG|thumb|150px|Rock Paper Scissors Machine|right]]
A machine that will play a fully functioning, intuitive game of [http://en.wikipedia.org/wiki/Rock-paper-scissors Rock/Paper/Scissors] (abbreviated as RPS) with a user. The machine is represented by a human-like hand, capable of seperate and independant wrist, arm, finger and thumb motion. The players' hand goes into a glove equipped with flex sensors, which wirelessly transmits data to the machine based on what the player chose. The machine then reads this data, randomly chooses a throw of its own, and displays what the machine threw, what the human threw, total win/loss/tie info, and winner/loser both on an [http://en.wikipedia.org/wiki/Lcd LCD] screen and in the form of a thumbs up/down/side motion. Video of the machine in action can be found [http://www.youtube.com/watch?v=xbLNBSTTrcE here.]
 

=== [[Three-speaker Chladni Patterns]] ===
[[Image:chladni_660hz|right|thumb|150px]]
This project uses three speakers to generate shapes on a circular aluminum plate depending on which frequency the speakers are playing at. Once the speakers hit a resonant frequency of the plate, salt migrates to the nodes (zero amplitude) regions of the plate to form distinct patterns.
 

=== [[Basketball]] ===
[[Image:Mechatronics2009Bball|right|thumb|150px]]
This project consists of a throwing arm propelled by a Pittman motor is mounted on a turntable and throws the ball into the "hoop." The hoop is wrapped in reflective tape and an IR emitter, receiver pair is used to sense where the IR is reflected most (the hoop with highly reflective tape). An ultrasonic sensor then pings the hoop for the distance of the hoop. With this information, the arm is able to "make a basket." A video can be found [http://www.youtube.com/watch?v=Y466dzP-qiY here].
 

=== [[Robot Drummer]] ===
[[Image:Robot_Drummer.jpg|thumb|400pix|right|Robot Drummer]]
The Robot Drummer is a device that demonstrates high-speed motor control by being able to drum when given commands. Through an RS232 cable, Matlab sends commands to a "master" PIC. The master then sends the commands to two "slave" PICs through I2C communication. The slaves take the commands and implement PID control of the motors.
 

=== [[Automated Fish Refuge]] ===
[[Image:Entire Fish Refuge|right|thumb|200px]]
The automated fish refuge allows for the controlled movement of a fish refuge with the goal of recording specific behavior. The mechanical design is completely adjustable and allows adjustable degrees of oscillating movement and orientation of the refuge. The program is primarily in MATLAB for ease of use and the velocity profile can be a sine, square, triangle, or any function that the user inputs. [http://www.youtube.com/watch?v=wGOKujMhN88 Check out the video!]

 

=== [[Marionette]] ===
[[Image: MarionettePicForIntro.JPG|right|thumb]] The Marionette Project focused on using RC Servos to make a puppet that would do a dance with the press of a button. There were 5 different dances programmed for the marionette, showcasing different styles of movement. The movement had 2 degrees of freedom thanks to using 5 bar linkages and 2 RC servos for each arm. Two more RC Servos were used on the back of the marionette to create the appearance of leg movement. The movements included a Hula dance, Jumping Jacks, and even some moves right out of Saturday Night Fever.

 

=== [[Monkeybot]] ===
[[Image:monkeybot_pic|thumb|right|200px|Monkeybot]]
The monkeybot is a swinging robot capable of moving side to side and climbing. It consists of a two link, double pendulum system with an electro-magnet on each end. At the pivot is a DC motor, which provides an input torque and allows the swinging system to gain energy and climb. Check out the video of the monkeybot climbing [http://www.youtube.com/watch?v=TA2VcH_GDJ0 here] and a later brachiation video [http://www.youtube.com/watch?v=0hfwJEVQyeQ&feature=related here].
 

=== [[PPOD-mini: 6-DOF Shaker]] ===
[[Image:PPOD_mini.JPG|thumb|200x200 px|right|PPOD-mini 6-DOF Shaker]]
The PPOD-mini is a miniaturized version of the Programmable Part-feeding Oscillatory Device ([http://lims.mech.northwestern.edu/projects/frictioninducedforcefields/index.htm PPOD]) found in the Laboratory for Intelligent Mechanical Systems (LIMS) at Northwestern. The PPOD-mini utilizes six speakers that act like actuators. The speakers are connected to a acrylic plate via flexures of tygon and iron. In its current implementation, the phase of the speakers can be controlled independently, giving the device six degrees of freedom. The movement of objects placed on the acrylic plate can be controlled by changing the phases of the speakers.

 

=== [[Automated Xylophone]] ===
[[Image:AutomatedXylophonePicture1.jpg|thumb|200x200 px|right|Automated Xylophone]]
The Automated Xylophone controls several solenoids which hit various pitches on an actual xylophone based on the note selected. The device has two main modes: using the keypad, a user can choose to either play notes in real time or store songs to be played back later. A video of the Automated Xylophone playing in real time mode can be found [http://www.youtube.com/watch?v=_ubpAEyq9kg here].

 

=== [[Vision-based Cannon]] ===
[[Image:SM_Gun_Camera_PIC_Setup.JPG|thumb|200x200 px|right|Vision-based Cannon]]
This project uses a webcam and Matlab to analyze an image and direct a modified USB Missile Launcher to fire at targets found in the image.

 

== ME 333 Final Projects 2008 ==

=== [[IR Tracker]] ===

[[Image:IR_Tracker_Main.jpg|right|thumb|200px]]

The IR Tracker (aka "Spot") is a device that follows a moving infrared light. It continuously detects the position of an infrared emitter in two axes, and then tracks the emitter with a laser. [[Media:MT_MS_AZ_TrackerVideo.mp4|See Spot Run.]]

'''Chosen the OUTSTANDING PROJECT by the students of ME 333.'''

 

=== [[Robot Snake]] ===
[[Image:HLSSnakeMain.jpg|right|thumb|200px]]

This remote control robotic snake uses servo motors with a traveling sine wave motion profile to mimic serpentine motion. The robotic snake is capable of moving forward, left, right and in reverse.

[http://www.youtube.com/watch?v=r_GOOFLnI6w Video of the robot snake]

Featured on [http://blog.makezine.com/archive/2009/03/well_documented_robotic_snake.html Makezine.com].
 

=== [[Programmable Stiffness Joint]] ===

[[Image:SteelToePic2.jpg|thumb|200px|The 'Steel Toe' programmable stiffness joint|right]]

The Programmable Stiffness Joint varies rotational stiffness as desired by the user. It is the first step in modeling the mechanical impedance of the human ankle joint (both stiffness and damping) for the purpose of determining the respective breakdown of the two properties over the gait cycle.

 

=== [[Magnetic based sample purification]] ===

 

=== [[Continuously Variable Transmission]] ===

[[image:CVT_system.JPG|thumb|200px]]

This prototype is a proof of concept model of a variable ratio transmission to be implemented in the 2008-2009 Formula SAE competition vehicle. The gear ratio is determined by the distances between the pulley halves which are controllable electronically.

 

=== [[Granular Flow Rotating Sphere]] ===
[[Image:Team-21-main-picture.JPG|right|thumb|200px]]
This device will be used to study the granular flow of particles within a rotating sphere. The sphere is filled with grains of varying size and then rotated about two different axes according to a series of position and angular velocity inputs.

 

=== [[Vibratory Clock]] ===

[[Image:Vibratory_Clock.jpg|right|thumb|Vibratory Clock|200px]]

The Vibratory Clock allows a small object to act as an hour "hand" on a horizontal circular platform that is actuated from underneath by three speakers. The object slides around the circular platform, impelled by friction forces due to the vibration. [http://www.youtube.com/watch?v=KhgTNCfdwZw Check it out!]

 

=== [[WiiMouse]] ===

[[Image:HPIM1027.jpg|right|thumb|200px]]

The WiiMouse is a handheld remote that can be used to move a cursor on a windows-based PC, via accelerometer input captured through device movement.

 

=== [[Intelligent Oscillation Controller]] ===

[[image:ME333_learning_oscillator.jpg|thumb|200px]]

This device "learns" a forcing function that is applied to a spring and mass system to match an arbitrary, periodic acceleration profile.

 

=== [[Baseball]] ===

[[Image:Baseball_Playfield.jpg|Sweet Baseball Game|right|thumb|200px]]

An interactive baseball game inspired by pinball, featuring pitching, batting, light up bases and a scoreboard to keep track of the game.

 

=== [[Ball Balancing Challenge]] ===

[[Image:Ballbalancechallenge.JPG|right|thumb|200px]]

An interactive game involving ball balancing on a touchscreen with touchscreen feedback and joystick action.

Haptic Gaming System

2010-03-19T03:12:59Z

MeganWelker: /* Overview */

[[Image:Haptikos.jpg|thumb|right|400px]]

==Overview==

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen. However, using our platform, all it takes is a creative mind and some programming knowledge to develop a wide variety of other games/demonstrations.

Watch [http://www.youtube.com/watch?v=7j37NCYWHF8 Haptikos] in action
 

==The Team==

 
[[Image:Team22haptics.jpg|thumb|right|400px]]

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering BS/MS)
*Megan Welker(Mechanical Engineering BS/BM)

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|400px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible. The backboard of the pantograph is screwed into the bottom. The motors were held in place by a set of holes in the top plate and a second bracket suspended between the top and bottom. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page for the TR-36, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC and read in on the timer pins.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== RS-232 Communication with PC ===

We found that reliable communication between the different components of our system was one of the more challenging aspects of the project. Because of this, we decided to post our code here as a quick reference. The desired baud rates for serial (DESIRED_BAUDRATE) and I2C (BRG_VAL) communication were defined at the beginning of the code to be

#define DESIRED_BAUDRATE 19200 // The desired BaudRate RS-232
#define Fsck 50000
#define BRG_VAL ((SYS_FREQ/2/Fsck)-2)

This first function initializes the UART1 port on the PIC. For an explanation of the configuration variables, and other UART functions, see chapter 16 of the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]].

void initUART1(int pbClk)
{
// define setup Configuration 1 for OpenUARTx
// Module Enable
// Work in IDLE mode
// Communication through usual pins
// Disable wake-up
// Loop back disabled
// Input to Capture module from ICx pin
// no parity 8 bit
// 1 stop bit
// IRDA encoder and decoder disabled
// CTS and RTS pins are disabled
// UxRX idle state is '1'
// 16x baud clock - normal speed
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN

// define setup Configuration 2 for OpenUARTx
// IrDA encoded UxTX idle state is '0'
// Enable UxRX pin
// Enable UxTX pin
// Interrupt on transfer of every character to TSR
// Interrupt on every char received
// Disable 9-bit address detect
// Rx Buffer Over run status bit clear
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR

// Open UART2 with config1 and config2
OpenUART1( config1, config2, SYS_FREQ/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.

// Configure UART2 RX Interrupt with priority 2
ConfigIntUART1(UART_INT_PR2 | UART_RX_INT_EN);
}

The next initialization function configures Timer1 which is used to generate an interrupt every 10 ms that sends location data to the PC. The timer is configured to add one count every 64 clock cycles of the PIC with a priority of 7 (the highest value) as the feedback to the computer is important for rendering the game correctly.

void initInterruptComm()
{
// Initialize timer 1 to generate interrupt to send data to PC
// init Timer1 mode and period (PR1) // produces 10ms period
OpenTimer1( T1_ON | T1_PS_1_64 | T1_SOURCE_INT, 12499);

mT1SetIntPriority(7); // set Timer1 Interrupt Priority
mT1ClearIntFlag(); // clear interrupt flag
mT1IntEnable(1); // enable timer1 interrupts

// Initialize I2C lines to communicate data to DACs
OpenI2C1( I2C_EN, BRG_VAL );
OpenI2C2( I2C_EN, BRG_VAL );
}

Then we create an interrupt handler for UART1 which is triggered when the PIC detects that there is data in the serial buffer. This is set to a priority level of 2 because it is less important than sending location information to the PC. The function ReadUART1 retrieves a single character from the serial buffer, use getsUART1() for strings.

// UART 1 interrupt handler
// it is set at priority level 2
void __ISR(_UART1_VECTOR, ipl2) IntUart1Handler(void)
{
unsigned char force;

// Is this an RX interrupt?
if(mU1RXGetIntFlag()) {
// Clear the RX interrupt Flag
mU1RXClearIntFlag();

force = ReadUART1(); // get data from PC
mLED_0_Toggle(); // toggle LED for feedback
MAX518(force); // send signal to motors
}

// We don't care about TX interrupt
if ( mU1TXGetIntFlag() ) {
mU1TXClearIntFlag();
}
}

We also create an interrupt controller for Timer1 to send location information back at a pre-defined rate. The function uses putsUART1 which sends a string of data.

// interrput code for the timer 1
void __ISR( _TIMER_1_VECTOR, ipl7) T1Interrupt( void)
{
// send data to PC every 10 ms (based on Timer1)
char RS232_Out_Buffer[32];
sprintf(RS232_Out_Buffer,"%d %d %d %d\n",X, Y, phi1, phi2);
putsUART1(RS232_Out_Buffer);

mLED_3_Toggle(); // toggle LED for feedback

// clear interrupt flag and exit
mT1ClearIntFlag();
} // T1 Interrupt

=== I2C Communication with DACs ===

The two I2C ports were initialized above in the initInterruptComm() function. The I2C communication also uses functions from the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]], found in chapter 15. The general structure of the function is to send a series of commands to the DAC and wait for this to complete after each command. First, the Start command is sent, then Idle waits until the I2C line is no longer busy. Then the address of the chip on the I2C line is sent out and the PIC waits until the chip has acknowledged (ACKed). This addressed is defined by the chips used as well as the configuration pins set when wiring the device up. It then sends the command byte to tell the DAC to get ready to output data and finally it sends the data byte telling the DAC how much voltage to output. The line is then closed to avoid sending extraneous data and the process is repeated for the second DAC. This information will change depending on the device being interfaced with (particularly if the PIC has to switch from master to slave mode) but the basic principles outlined here can be used for most applications.

void MAX518(int force)
{
unsigned char addr = 0b01011000; // address of DAC on I2C line
unsigned char cmd = 0x00; //command line
int force1 = 127+(7-(force >> 4))*8; // upper nibble to motor 1
int force2 = 127+(7-(force & 15))*8; // lower nibble to motor 2

// Send to DAC 1 //////////////////////
StartI2C1(); //Send the Start Bit (begin of data send)
IdleI2C1(); //Wait to complete

MasterWriteI2C1 (addr); //address
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1 (cmd); //command line
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1(force1); //output
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

StopI2C1(); //end of data send
IdleI2C1(); //Wait to complete

// Send to DAC 2 //////////////////////
StartI2C2(); //Send the Start Bit (begin of data send)
IdleI2C2(); //Wait to complete

MasterWriteI2C2 (addr); //address
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2 (cmd); //command line
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2(force2); //output
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

StopI2C2(); //end of data send
IdleI2C2(); //Wait to complete
}

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

== Debugging Tips ==

While working on the project, as with all mechatronics projects, we ran into many small problems. We will highlight some of the most common ones so that you don't make the same mistakes that we did and can spend more time improving, rather than fixing, your project.

* ALWAYS CHECK YOUR WIRING - When using a breadboard wires often get knocked loose, break off, etc. The thing we spent the most time on was trying to debug circuits where a wire had simply come out of the breadboard or that we had put back in the wrong place. Don't waste your time reading the I2C signals on an oscilloscope to make sure that the data is correct only to find out you accidentally wired the data line to the clock pin of your chip. And remember that the multimeter is your friend; when dealing with lots of ribbon cables it is invaluable for checking if pins are wired correctly.
* Use the oscilloscope - While the multimeter is good for checking some things, it missed quick voltage changes that a scope will let you see. We used this for 95% of our debugging, from checking power lines to reading the individual bits being sent over I2C or RS-232 lines.
* Check your soldering - Make sure the solder on any solder board, PCB's, or the PIC board is done correctly. This tends to wear out over time and can break loose/come into contact with other connections creating shorts. If your circuit is not working, check this as it only requires a short visual inspection but can save hours of headache from changing software and tracing wires all over your circuit boards.
* Remember how your circuit is supposed to work - After we built the power amp PCBs we were testing them to make sure they work. Since they are current control circuits, the motor + and motor - pins must have current flowing between them or the output voltage will float. We forgot to put a power resistor between these pins and spent a long time trying to figure out why the output was not changing before we finally realized it actually did work exactly as it was designed to.
* Use sockets when moving your circuit to solder board - If a chip burns out and you have soldered it directly to the board, it takes a long time to remove. Use sockets instead as this makes changing chips very easy. The same goes for data lines, use pin headers and ribbon cables instead of soldering your cables directly to the board. This also makes moving the circuit much simpler as it can be disassembled.

== Next Steps ==

There are several areas for improvement in our project, the primary one being to improve the haptic feedback by allowing forces to be generated in arbitrary directions and increasing the resolution of forces we can generate. The first half of this involves debugging the Jacobian calculations and ensuring that all data types in the calculations are compatible (i.e., multiply ints by ints instead of floats). For the second half of this, we need more reliable serial communication from the PC to the PIC. While we were successful sending a single byte of data, when trying to send a string of data (2 or 4 bytes) the PIC would often, though not not always, fail to receive the data. Fixing this, the full capabilities of the DAC could be used to have 256 levels of forcing instead of the 16 we used. This would be helpful when trying to simulate textures, compliant objects, stickiness (damping), etc, all of which should be possible with a device such as Haptikos. This could be a benefit to games, such as feeling more resistance when your character walks through a patch of mud instead of over grass.

There are also a couple of improvements for the mechanical design. The Pittman motors used had a "clickiness" to them so as the user moved the pantograph around they felt slightly bumps in the motion, even when the motors were unpowered. While this may actually be a benefit for some applications (i.e., simulating rough surfaces), in general we would recommend choosing motors with a smoother feel to them. Also, when mounting the capstan drive system, take care to properly align all parts. Not centering the arcs properly can lead to increased resistance and can limit the size of the workspace. We ran into this issue with the initial build but fixed it for the final design.

Haptic Gaming System

2010-03-19T01:39:28Z

MeganWelker: /* Box */

[[Image:Haptikos.jpg|thumb|right|400px]]

==Overview==

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen. However, using our platform, all it takes is a creative mind and some programming knowledge to develop a wide variety of other games/demonstrations.

 

==The Team==

 
[[Image:Team22haptics.jpg|thumb|right|400px]]

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering BS/MS)
*Megan Welker(Mechanical Engineering BS/BM)

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|400px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible. The backboard of the pantograph is screwed into the bottom. The motors were held in place by a set of holes in the top plate and a second bracket suspended between the top and bottom. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page for the TR-36, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC and read in on the timer pins.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== RS-232 Communication with PC ===

We found that reliable communication between the different components of our system was one of the more challenging aspects of the project. Because of this, we decided to post our code here as a quick reference. The desired baud rates for serial (DESIRED_BAUDRATE) and I2C (BRG_VAL) communication were defined at the beginning of the code to be

#define DESIRED_BAUDRATE 19200 // The desired BaudRate RS-232
#define Fsck 50000
#define BRG_VAL ((SYS_FREQ/2/Fsck)-2)

This first function initializes the UART1 port on the PIC. For an explanation of the configuration variables, and other UART functions, see chapter 16 of the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]].

void initUART1(int pbClk)
{
// define setup Configuration 1 for OpenUARTx
// Module Enable
// Work in IDLE mode
// Communication through usual pins
// Disable wake-up
// Loop back disabled
// Input to Capture module from ICx pin
// no parity 8 bit
// 1 stop bit
// IRDA encoder and decoder disabled
// CTS and RTS pins are disabled
// UxRX idle state is '1'
// 16x baud clock - normal speed
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN

// define setup Configuration 2 for OpenUARTx
// IrDA encoded UxTX idle state is '0'
// Enable UxRX pin
// Enable UxTX pin
// Interrupt on transfer of every character to TSR
// Interrupt on every char received
// Disable 9-bit address detect
// Rx Buffer Over run status bit clear
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR

// Open UART2 with config1 and config2
OpenUART1( config1, config2, SYS_FREQ/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.

// Configure UART2 RX Interrupt with priority 2
ConfigIntUART1(UART_INT_PR2 | UART_RX_INT_EN);
}

The next initialization function configures Timer1 which is used to generate an interrupt every 10 ms that sends location data to the PC. The timer is configured to add one count every 64 clock cycles of the PIC with a priority of 7 (the highest value) as the feedback to the computer is important for rendering the game correctly.

void initInterruptComm()
{
// Initialize timer 1 to generate interrupt to send data to PC
// init Timer1 mode and period (PR1) // produces 10ms period
OpenTimer1( T1_ON | T1_PS_1_64 | T1_SOURCE_INT, 12499);

mT1SetIntPriority(7); // set Timer1 Interrupt Priority
mT1ClearIntFlag(); // clear interrupt flag
mT1IntEnable(1); // enable timer1 interrupts

// Initialize I2C lines to communicate data to DACs
OpenI2C1( I2C_EN, BRG_VAL );
OpenI2C2( I2C_EN, BRG_VAL );
}

Then we create an interrupt handler for UART1 which is triggered when the PIC detects that there is data in the serial buffer. This is set to a priority level of 2 because it is less important than sending location information to the PC. The function ReadUART1 retrieves a single character from the serial buffer, use getsUART1() for strings.

// UART 1 interrupt handler
// it is set at priority level 2
void __ISR(_UART1_VECTOR, ipl2) IntUart1Handler(void)
{
unsigned char force;

// Is this an RX interrupt?
if(mU1RXGetIntFlag()) {
// Clear the RX interrupt Flag
mU1RXClearIntFlag();

force = ReadUART1(); // get data from PC
mLED_0_Toggle(); // toggle LED for feedback
MAX518(force); // send signal to motors
}

// We don't care about TX interrupt
if ( mU1TXGetIntFlag() ) {
mU1TXClearIntFlag();
}
}

We also create an interrupt controller for Timer1 to send location information back at a pre-defined rate. The function uses putsUART1 which sends a string of data.

// interrput code for the timer 1
void __ISR( _TIMER_1_VECTOR, ipl7) T1Interrupt( void)
{
// send data to PC every 10 ms (based on Timer1)
char RS232_Out_Buffer[32];
sprintf(RS232_Out_Buffer,"%d %d %d %d\n",X, Y, phi1, phi2);
putsUART1(RS232_Out_Buffer);

mLED_3_Toggle(); // toggle LED for feedback

// clear interrupt flag and exit
mT1ClearIntFlag();
} // T1 Interrupt

=== I2C Communication with DACs ===

The two I2C ports were initialized above in the initInterruptComm() function. The I2C communication also uses functions from the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]], found in chapter 15. The general structure of the function is to send a series of commands to the DAC and wait for this to complete after each command. First, the Start command is sent, then Idle waits until the I2C line is no longer busy. Then the address of the chip on the I2C line is sent out and the PIC waits until the chip has acknowledged (ACKed). This addressed is defined by the chips used as well as the configuration pins set when wiring the device up. It then sends the command byte to tell the DAC to get ready to output data and finally it sends the data byte telling the DAC how much voltage to output. The line is then closed to avoid sending extraneous data and the process is repeated for the second DAC. This information will change depending on the device being interfaced with (particularly if the PIC has to switch from master to slave mode) but the basic principles outlined here can be used for most applications.

void MAX518(int force)
{
unsigned char addr = 0b01011000; // address of DAC on I2C line
unsigned char cmd = 0x00; //command line
int force1 = 127+(7-(force >> 4))*8; // upper nibble to motor 1
int force2 = 127+(7-(force & 15))*8; // lower nibble to motor 2

// Send to DAC 1 //////////////////////
StartI2C1(); //Send the Start Bit (begin of data send)
IdleI2C1(); //Wait to complete

MasterWriteI2C1 (addr); //address
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1 (cmd); //command line
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1(force1); //output
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

StopI2C1(); //end of data send
IdleI2C1(); //Wait to complete

// Send to DAC 2 //////////////////////
StartI2C2(); //Send the Start Bit (begin of data send)
IdleI2C2(); //Wait to complete

MasterWriteI2C2 (addr); //address
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2 (cmd); //command line
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2(force2); //output
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

StopI2C2(); //end of data send
IdleI2C2(); //Wait to complete
}

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

== Debugging Tips ==

While working on the project, as with all mechatronics projects, we ran into many small problems. We will highlight some of the most common ones so that you don't make the same mistakes that we did and can spend more time improving, rather than fixing, your project.

* ALWAYS CHECK YOUR WIRING - When using a breadboard wires often get knocked loose, break off, etc. The thing we spent the most time on was trying to debug circuits where a wire had simply come out of the breadboard or that we had put back in the wrong place. Don't waste your time reading the I2C signals on an oscilloscope to make sure that the data is correct only to find out you accidentally wired the data line to the clock pin of your chip. And remember that the multimeter is your friend; when dealing with lots of ribbon cables it is invaluable for checking if pins are wired correctly.
* Use the oscilloscope - While the multimeter is good for checking some things, it missed quick voltage changes that a scope will let you see. We used this for 95% of our debugging, from checking power lines to reading the individual bits being sent over I2C or RS-232 lines.
* Check your soldering - Make sure the solder on any solder board, PCB's, or the PIC board is done correctly. This tends to wear out over time and can break loose/come into contact with other connections creating shorts. If your circuit is not working, check this as it only requires a short visual inspection but can save hours of headache from changing software and tracing wires all over your circuit boards.
* Remember how your circuit is supposed to work - After we built the power amp PCBs we were testing them to make sure they work. Since they are current control circuits, the motor + and motor - pins must have current flowing between them or the output voltage will float. We forgot to put a power resistor between these pins and spent a long time trying to figure out why the output was not changing before we finally realized it actually did work exactly as it was designed to.
* Use sockets when moving your circuit to solder board - If a chip burns out and you have soldered it directly to the board, it takes a long time to remove. Use sockets instead as this makes changing chips very easy. The same goes for data lines, use pin headers and ribbon cables instead of soldering your cables directly to the board. This also makes moving the circuit much simpler as it can be disassembled.

== Next Steps ==

There are several areas for improvement in our project, the primary one being to improve the haptic feedback by allowing forces to be generated in arbitrary directions and increasing the resolution of forces we can generate. The first half of this involves debugging the Jacobian calculations and ensuring that all data types in the calculations are compatible (i.e., multiply ints by ints instead of floats). For the second half of this, we need more reliable serial communication from the PC to the PIC. While we were successful sending a single byte of data, when trying to send a string of data (2 or 4 bytes) the PIC would often, though not not always, fail to receive the data. Fixing this, the full capabilities of the DAC could be used to have 256 levels of forcing instead of the 16 we used. This would be helpful when trying to simulate textures, compliant objects, stickiness (damping), etc, all of which should be possible with a device such as Haptikos. This could be a benefit to games, such as feeling more resistance when your character walks through a patch of mud instead of over grass.

There are also a couple of improvements for the mechanical design. The Pittman motors used had a "clickiness" to them so as the user moved the pantograph around they felt slightly bumps in the motion, even when the motors were unpowered. While this may actually be a benefit for some applications (i.e., simulating rough surfaces), in general we would recommend choosing motors with a smoother feel to them. Also, when mounting the capstan drive system, take care to properly align all parts. Not centering the arcs properly can lead to increased resistance and can limit the size of the workspace. We ran into this issue with the initial build but fixed it for the final design.

Haptic Gaming System

2010-03-19T01:34:06Z

MeganWelker:

[[Image:Haptikos.jpg|thumb|right|400px]]

==Overview==

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen. However, using our platform, all it takes is a creative mind and some programming knowledge to develop a wide variety of other games/demonstrations.

 

==The Team==

 
[[Image:Team22haptics.jpg|thumb|right|400px]]

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering BS/MS)
*Megan Welker(Mechanical Engineering BS/BM)

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|400px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== RS-232 Communication with PC ===

We found that reliable communication between the different components of our system was one of the more challenging aspects of the project. Because of this, we decided to post our code here as a quick reference. The desired baud rates for serial (DESIRED_BAUDRATE) and I2C (BRG_VAL) communication were defined at the beginning of the code to be

#define DESIRED_BAUDRATE 19200 // The desired BaudRate RS-232
#define Fsck 50000
#define BRG_VAL ((SYS_FREQ/2/Fsck)-2)

This first function initializes the UART1 port on the PIC. For an explanation of the configuration variables, and other UART functions, see chapter 16 of the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]].

void initUART1(int pbClk)
{
// define setup Configuration 1 for OpenUARTx
// Module Enable
// Work in IDLE mode
// Communication through usual pins
// Disable wake-up
// Loop back disabled
// Input to Capture module from ICx pin
// no parity 8 bit
// 1 stop bit
// IRDA encoder and decoder disabled
// CTS and RTS pins are disabled
// UxRX idle state is '1'
// 16x baud clock - normal speed
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN

// define setup Configuration 2 for OpenUARTx
// IrDA encoded UxTX idle state is '0'
// Enable UxRX pin
// Enable UxTX pin
// Interrupt on transfer of every character to TSR
// Interrupt on every char received
// Disable 9-bit address detect
// Rx Buffer Over run status bit clear
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR

// Open UART2 with config1 and config2
OpenUART1( config1, config2, SYS_FREQ/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.

// Configure UART2 RX Interrupt with priority 2
ConfigIntUART1(UART_INT_PR2 | UART_RX_INT_EN);
}

The next initialization function configures Timer1 which is used to generate an interrupt every 10 ms that sends location data to the PC. The timer is configured to add one count every 64 clock cycles of the PIC with a priority of 7 (the highest value) as the feedback to the computer is important for rendering the game correctly.

void initInterruptComm()
{
// Initialize timer 1 to generate interrupt to send data to PC
// init Timer1 mode and period (PR1) // produces 10ms period
OpenTimer1( T1_ON | T1_PS_1_64 | T1_SOURCE_INT, 12499);

mT1SetIntPriority(7); // set Timer1 Interrupt Priority
mT1ClearIntFlag(); // clear interrupt flag
mT1IntEnable(1); // enable timer1 interrupts

// Initialize I2C lines to communicate data to DACs
OpenI2C1( I2C_EN, BRG_VAL );
OpenI2C2( I2C_EN, BRG_VAL );
}

Then we create an interrupt handler for UART1 which is triggered when the PIC detects that there is data in the serial buffer. This is set to a priority level of 2 because it is less important than sending location information to the PC. The function ReadUART1 retrieves a single character from the serial buffer, use getsUART1() for strings.

// UART 1 interrupt handler
// it is set at priority level 2
void __ISR(_UART1_VECTOR, ipl2) IntUart1Handler(void)
{
unsigned char force;

// Is this an RX interrupt?
if(mU1RXGetIntFlag()) {
// Clear the RX interrupt Flag
mU1RXClearIntFlag();

force = ReadUART1(); // get data from PC
mLED_0_Toggle(); // toggle LED for feedback
MAX518(force); // send signal to motors
}

// We don't care about TX interrupt
if ( mU1TXGetIntFlag() ) {
mU1TXClearIntFlag();
}
}

We also create an interrupt controller for Timer1 to send location information back at a pre-defined rate. The function uses putsUART1 which sends a string of data.

// interrput code for the timer 1
void __ISR( _TIMER_1_VECTOR, ipl7) T1Interrupt( void)
{
// send data to PC every 10 ms (based on Timer1)
char RS232_Out_Buffer[32];
sprintf(RS232_Out_Buffer,"%d %d %d %d\n",X, Y, phi1, phi2);
putsUART1(RS232_Out_Buffer);

mLED_3_Toggle(); // toggle LED for feedback

// clear interrupt flag and exit
mT1ClearIntFlag();
} // T1 Interrupt

=== I2C Communication with DACs ===

The two I2C ports were initialized above in the initInterruptComm() function. The I2C communication also uses functions from the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]], found in chapter 15. The general structure of the function is to send a series of commands to the DAC and wait for this to complete after each command. First, the Start command is sent, then Idle waits until the I2C line is no longer busy. Then the address of the chip on the I2C line is sent out and the PIC waits until the chip has acknowledged (ACKed). This addressed is defined by the chips used as well as the configuration pins set when wiring the device up. It then sends the command byte to tell the DAC to get ready to output data and finally it sends the data byte telling the DAC how much voltage to output. The line is then closed to avoid sending extraneous data and the process is repeated for the second DAC. This information will change depending on the device being interfaced with (particularly if the PIC has to switch from master to slave mode) but the basic principles outlined here can be used for most applications.

void MAX518(int force)
{
unsigned char addr = 0b01011000; // address of DAC on I2C line
unsigned char cmd = 0x00; //command line
int force1 = 127+(7-(force >> 4))*8; // upper nibble to motor 1
int force2 = 127+(7-(force & 15))*8; // lower nibble to motor 2

// Send to DAC 1 //////////////////////
StartI2C1(); //Send the Start Bit (begin of data send)
IdleI2C1(); //Wait to complete

MasterWriteI2C1 (addr); //address
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1 (cmd); //command line
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1(force1); //output
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

StopI2C1(); //end of data send
IdleI2C1(); //Wait to complete

// Send to DAC 2 //////////////////////
StartI2C2(); //Send the Start Bit (begin of data send)
IdleI2C2(); //Wait to complete

MasterWriteI2C2 (addr); //address
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2 (cmd); //command line
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2(force2); //output
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

StopI2C2(); //end of data send
IdleI2C2(); //Wait to complete
}

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

== Debugging Tips ==

While working on the project, as with all mechatronics projects, we ran into many small problems. We will highlight some of the most common ones so that you don't make the same mistakes that we did and can spend more time improving, rather than fixing, your project.

* ALWAYS CHECK YOUR WIRING - When using a breadboard wires often get knocked loose, break off, etc. The thing we spent the most time on was trying to debug circuits where a wire had simply come out of the breadboard or that we had put back in the wrong place. Don't waste your time reading the I2C signals on an oscilloscope to make sure that the data is correct only to find out you accidentally wired the data line to the clock pin of your chip. And remember that the multimeter is your friend; when dealing with lots of ribbon cables it is invaluable for checking if pins are wired correctly.
* Use the oscilloscope - While the multimeter is good for checking some things, it missed quick voltage changes that a scope will let you see. We used this for 95% of our debugging, from checking power lines to reading the individual bits being sent over I2C or RS-232 lines.
* Check your soldering - Make sure the solder on any solder board, PCB's, or the PIC board is done correctly. This tends to wear out over time and can break loose/come into contact with other connections creating shorts. If your circuit is not working, check this as it only requires a short visual inspection but can save hours of headache from changing software and tracing wires all over your circuit boards.
* Remember how your circuit is supposed to work - After we built the power amp PCBs we were testing them to make sure they work. Since they are current control circuits, the motor + and motor - pins must have current flowing between them or the output voltage will float. We forgot to put a power resistor between these pins and spent a long time trying to figure out why the output was not changing before we finally realized it actually did work exactly as it was designed to.
* Use sockets when moving your circuit to solder board - If a chip burns out and you have soldered it directly to the board, it takes a long time to remove. Use sockets instead as this makes changing chips very easy. The same goes for data lines, use pin headers and ribbon cables instead of soldering your cables directly to the board. This also makes moving the circuit much simpler as it can be disassembled.

== Next Steps ==

There are several areas for improvement in our project, the primary one being to improve the haptic feedback by allowing forces to be generated in arbitrary directions and increasing the resolution of forces we can generate. The first half of this involves debugging the Jacobian calculations and ensuring that all data types in the calculations are compatible (i.e., multiply ints by ints instead of floats). For the second half of this, we need more reliable serial communication from the PC to the PIC. While we were successful sending a single byte of data, when trying to send a string of data (2 or 4 bytes) the PIC would often, though not not always, fail to receive the data. Fixing this, the full capabilities of the DAC could be used to have 256 levels of forcing instead of the 16 we used. This would be helpful when trying to simulate textures, compliant objects, stickiness (damping), etc, all of which should be possible with a device such as Haptikos. This could be a benefit to games, such as feeling more resistance when your character walks through a patch of mud instead of over grass.

There are also a couple of improvements for the mechanical design. The Pittman motors used had a "clickiness" to them so as the user moved the pantograph around they felt slightly bumps in the motion, even when the motors were unpowered. While this may actually be a benefit for some applications (i.e., simulating rough surfaces), in general we would recommend choosing motors with a smoother feel to them. Also, when mounting the capstan drive system, take care to properly align all parts. Not centering the arcs properly can lead to increased resistance and can limit the size of the workspace. We ran into this issue with the initial build but fixed it for the final design.

Haptic Gaming System

2010-03-19T01:33:50Z

MeganWelker:

[[Image:Haptikos.jpg|thumb|right|600px]]

==Overview==

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen. However, using our platform, all it takes is a creative mind and some programming knowledge to develop a wide variety of other games/demonstrations.

 

==The Team==

 
[[Image:Team22haptics.jpg|thumb|right|400px]]

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering BS/MS)
*Megan Welker(Mechanical Engineering BS/BM)

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|400px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== RS-232 Communication with PC ===

We found that reliable communication between the different components of our system was one of the more challenging aspects of the project. Because of this, we decided to post our code here as a quick reference. The desired baud rates for serial (DESIRED_BAUDRATE) and I2C (BRG_VAL) communication were defined at the beginning of the code to be

#define DESIRED_BAUDRATE 19200 // The desired BaudRate RS-232
#define Fsck 50000
#define BRG_VAL ((SYS_FREQ/2/Fsck)-2)

This first function initializes the UART1 port on the PIC. For an explanation of the configuration variables, and other UART functions, see chapter 16 of the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]].

void initUART1(int pbClk)
{
// define setup Configuration 1 for OpenUARTx
// Module Enable
// Work in IDLE mode
// Communication through usual pins
// Disable wake-up
// Loop back disabled
// Input to Capture module from ICx pin
// no parity 8 bit
// 1 stop bit
// IRDA encoder and decoder disabled
// CTS and RTS pins are disabled
// UxRX idle state is '1'
// 16x baud clock - normal speed
#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS | UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN

// define setup Configuration 2 for OpenUARTx
// IrDA encoded UxTX idle state is '0'
// Enable UxRX pin
// Enable UxTX pin
// Interrupt on transfer of every character to TSR
// Interrupt on every char received
// Disable 9-bit address detect
// Rx Buffer Over run status bit clear
#define config2 UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR

// Open UART2 with config1 and config2
OpenUART1( config1, config2, SYS_FREQ/16/DESIRED_BAUDRATE-1); // calculate actual BAUD generate value.

// Configure UART2 RX Interrupt with priority 2
ConfigIntUART1(UART_INT_PR2 | UART_RX_INT_EN);
}

The next initialization function configures Timer1 which is used to generate an interrupt every 10 ms that sends location data to the PC. The timer is configured to add one count every 64 clock cycles of the PIC with a priority of 7 (the highest value) as the feedback to the computer is important for rendering the game correctly.

void initInterruptComm()
{
// Initialize timer 1 to generate interrupt to send data to PC
// init Timer1 mode and period (PR1) // produces 10ms period
OpenTimer1( T1_ON | T1_PS_1_64 | T1_SOURCE_INT, 12499);

mT1SetIntPriority(7); // set Timer1 Interrupt Priority
mT1ClearIntFlag(); // clear interrupt flag
mT1IntEnable(1); // enable timer1 interrupts

// Initialize I2C lines to communicate data to DACs
OpenI2C1( I2C_EN, BRG_VAL );
OpenI2C2( I2C_EN, BRG_VAL );
}

Then we create an interrupt handler for UART1 which is triggered when the PIC detects that there is data in the serial buffer. This is set to a priority level of 2 because it is less important than sending location information to the PC. The function ReadUART1 retrieves a single character from the serial buffer, use getsUART1() for strings.

// UART 1 interrupt handler
// it is set at priority level 2
void __ISR(_UART1_VECTOR, ipl2) IntUart1Handler(void)
{
unsigned char force;

// Is this an RX interrupt?
if(mU1RXGetIntFlag()) {
// Clear the RX interrupt Flag
mU1RXClearIntFlag();

force = ReadUART1(); // get data from PC
mLED_0_Toggle(); // toggle LED for feedback
MAX518(force); // send signal to motors
}

// We don't care about TX interrupt
if ( mU1TXGetIntFlag() ) {
mU1TXClearIntFlag();
}
}

We also create an interrupt controller for Timer1 to send location information back at a pre-defined rate. The function uses putsUART1 which sends a string of data.

// interrput code for the timer 1
void __ISR( _TIMER_1_VECTOR, ipl7) T1Interrupt( void)
{
// send data to PC every 10 ms (based on Timer1)
char RS232_Out_Buffer[32];
sprintf(RS232_Out_Buffer,"%d %d %d %d\n",X, Y, phi1, phi2);
putsUART1(RS232_Out_Buffer);

mLED_3_Toggle(); // toggle LED for feedback

// clear interrupt flag and exit
mT1ClearIntFlag();
} // T1 Interrupt

=== I2C Communication with DACs ===

The two I2C ports were initialized above in the initInterruptComm() function. The I2C communication also uses functions from the [[Introduction_to_the_PIC32#Further_Reading|Peripheral Library Guide]], found in chapter 15. The general structure of the function is to send a series of commands to the DAC and wait for this to complete after each command. First, the Start command is sent, then Idle waits until the I2C line is no longer busy. Then the address of the chip on the I2C line is sent out and the PIC waits until the chip has acknowledged (ACKed). This addressed is defined by the chips used as well as the configuration pins set when wiring the device up. It then sends the command byte to tell the DAC to get ready to output data and finally it sends the data byte telling the DAC how much voltage to output. The line is then closed to avoid sending extraneous data and the process is repeated for the second DAC. This information will change depending on the device being interfaced with (particularly if the PIC has to switch from master to slave mode) but the basic principles outlined here can be used for most applications.

void MAX518(int force)
{
unsigned char addr = 0b01011000; // address of DAC on I2C line
unsigned char cmd = 0x00; //command line
int force1 = 127+(7-(force >> 4))*8; // upper nibble to motor 1
int force2 = 127+(7-(force & 15))*8; // lower nibble to motor 2

// Send to DAC 1 //////////////////////
StartI2C1(); //Send the Start Bit (begin of data send)
IdleI2C1(); //Wait to complete

MasterWriteI2C1 (addr); //address
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1 (cmd); //command line
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

MasterWriteI2C1(force1); //output
IdleI2C1();
while( !I2C1STATbits.ACKSTAT==0 ) {}

StopI2C1(); //end of data send
IdleI2C1(); //Wait to complete

// Send to DAC 2 //////////////////////
StartI2C2(); //Send the Start Bit (begin of data send)
IdleI2C2(); //Wait to complete

MasterWriteI2C2 (addr); //address
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2 (cmd); //command line
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

MasterWriteI2C2(force2); //output
IdleI2C2();
while( !I2C2STATbits.ACKSTAT==0 ) {}

StopI2C2(); //end of data send
IdleI2C2(); //Wait to complete
}

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

== Debugging Tips ==

While working on the project, as with all mechatronics projects, we ran into many small problems. We will highlight some of the most common ones so that you don't make the same mistakes that we did and can spend more time improving, rather than fixing, your project.

* ALWAYS CHECK YOUR WIRING - When using a breadboard wires often get knocked loose, break off, etc. The thing we spent the most time on was trying to debug circuits where a wire had simply come out of the breadboard or that we had put back in the wrong place. Don't waste your time reading the I2C signals on an oscilloscope to make sure that the data is correct only to find out you accidentally wired the data line to the clock pin of your chip. And remember that the multimeter is your friend; when dealing with lots of ribbon cables it is invaluable for checking if pins are wired correctly.
* Use the oscilloscope - While the multimeter is good for checking some things, it missed quick voltage changes that a scope will let you see. We used this for 95% of our debugging, from checking power lines to reading the individual bits being sent over I2C or RS-232 lines.
* Check your soldering - Make sure the solder on any solder board, PCB's, or the PIC board is done correctly. This tends to wear out over time and can break loose/come into contact with other connections creating shorts. If your circuit is not working, check this as it only requires a short visual inspection but can save hours of headache from changing software and tracing wires all over your circuit boards.
* Remember how your circuit is supposed to work - After we built the power amp PCBs we were testing them to make sure they work. Since they are current control circuits, the motor + and motor - pins must have current flowing between them or the output voltage will float. We forgot to put a power resistor between these pins and spent a long time trying to figure out why the output was not changing before we finally realized it actually did work exactly as it was designed to.
* Use sockets when moving your circuit to solder board - If a chip burns out and you have soldered it directly to the board, it takes a long time to remove. Use sockets instead as this makes changing chips very easy. The same goes for data lines, use pin headers and ribbon cables instead of soldering your cables directly to the board. This also makes moving the circuit much simpler as it can be disassembled.

== Next Steps ==

There are several areas for improvement in our project, the primary one being to improve the haptic feedback by allowing forces to be generated in arbitrary directions and increasing the resolution of forces we can generate. The first half of this involves debugging the Jacobian calculations and ensuring that all data types in the calculations are compatible (i.e., multiply ints by ints instead of floats). For the second half of this, we need more reliable serial communication from the PC to the PIC. While we were successful sending a single byte of data, when trying to send a string of data (2 or 4 bytes) the PIC would often, though not not always, fail to receive the data. Fixing this, the full capabilities of the DAC could be used to have 256 levels of forcing instead of the 16 we used. This would be helpful when trying to simulate textures, compliant objects, stickiness (damping), etc, all of which should be possible with a device such as Haptikos. This could be a benefit to games, such as feeling more resistance when your character walks through a patch of mud instead of over grass.

There are also a couple of improvements for the mechanical design. The Pittman motors used had a "clickiness" to them so as the user moved the pantograph around they felt slightly bumps in the motion, even when the motors were unpowered. While this may actually be a benefit for some applications (i.e., simulating rough surfaces), in general we would recommend choosing motors with a smoother feel to them. Also, when mounting the capstan drive system, take care to properly align all parts. Not centering the arcs properly can lead to increased resistance and can limit the size of the workspace. We ran into this issue with the initial build but fixed it for the final design.

Haptic Gaming System

2010-03-18T14:29:16Z

MeganWelker: /* System Modifications */

==Overview==

[[Image:Haptikos.jpg|thumb|right|550px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|400px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|400px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T14:28:31Z

MeganWelker: /* Overview */

==Overview==

[[Image:Haptikos.jpg|thumb|right|550px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|400px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T14:28:19Z

MeganWelker: /* The Team */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|400px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

 
{| border="0"
|[[image:HapticsBlockDiagram.png|thumb|600px|center|Block diagram of circuit.]]
|[[image:CircuitsTeam22.jpg|thumb|300px|Circuitry.|center]]
|}
 

=== PIC Configuration ===

 
[[Image:PICWiringTeam22.jpg|x200px|right]]

We used the [[Introduction_to_the_PIC32|PIC32MX460F512L]] from Microchip on the NU32 board. The board was powered using a USB cable plugging into the socket on the left side of the board. The ribbon cable on the far right of the breadboard connects to the breakout board and has four I2C lines, four lines from the decoding circuit, +5V, and ground. The cable next to it is the RS-232 that connects the PIC to the PC.

 

=== Breakout Board ===

 
[[image:PictureofCircut2Team22.jpg|x200px|right]]

This board serves as a central hub for all of the other components to the circuit, allowing for only one ribbon cable to connect to the PIC's breadboard. Clockwise from the green power supply board, we have connections to the two power amplification circuits, the PIC breadboard, the decoding circuit, and the DAC/level shifting circuit. The power supply provides a separate +5V, -5V, and ground line to power the motors, protecting the PIC from the high amperage needed to drive the motors. In the center of the board is a [http://pdf1.alldatasheet.com/datasheet-pdf/view/303507/RSG/EC2A05.html Cincon EC2A05 DC/DC converter] that takes in the +/- 5V lines and outputs +/- 15V used for the level shifting circuit.

 

=== DAC/Level Shifter Board ===

This board takes the force data sent over I2C from the PIC (from the PC) and creates an analog voltage signal ranging from +/- 5V that feeds into the power amplification circuit. Here, we use a [http://www.alldatasheet.com/datasheet-pdf/pdf/73533/MAXIM/MAX518.html MAX518 DAC] chip that connects to a level shifting circuit using 2 [http://pdf1.alldatasheet.com/datasheet-pdf/view/70235/LINER/LT1001.html LT1001 op-amps], as shown in the circuit diagram. This is necessary to allow the motors to spin in both directions without the use of PWM (which we opted not to use because we want torque, and thus, current control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|right]]
|[[image:PictureofCircut1Team22.jpg|x200px|right]]
|}
 

=== Motor Control Board ===

This circuit uses current feedback in order to maintain a constant output current, allowing for direct torque control of the motors. This circuit was designed by Prof. Peshkin and detailed information can be found [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm here]. Two of these boards were used, one for each motor with the input coming from the DAC board and power from the central breakout board.

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
 

=== Decoder Board ===

The decoding circuit reads the signals from two optical encoders them into up and down counts (two each) that connect to the timer pins on the PIC. The encoders used are Canon TR-1 (equivalent to [http://www.usa.canon.com/industrial_encoders/lre_tr36.html TR-36]) which are 3600 counts per revolution using x1 decoding. The decoding circuit is that used in the Recommended Receiving Circuit link at the bottom of the page, where the channels first feed into a [http://pdf1.alldatasheet.com/datasheet-pdf/view/27890/TI/SN74HC14N.html SN74HC14N Schmitt trigger] which cleans up the signals going into the [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html LS7083 quadrature decoding] chips. These take the pulse trains and translate them into up and down counts which are then sent over to the PIC.

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|right]]
|[[image:2PictureofCircut1Team22.jpg|x200px|right]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:22:19Z

MeganWelker: /* Breakout Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]
|}
 

=== DAC/Level Shifter Board ===

The board in the picture consists of two identical channels while the schematic shows only one channel. The circuit first reads the data transmitted through I2C channel and generate 0-5 analog output. The following two op-amp circuits change the level from 0-5 to -5-+5 in order to drive motor both ways.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

The decoder reads the signals from two laser encoder mounted on the pantograph and converts them into two channels of up and down counts(four outputs in total).

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Power Amp Board ===
This circuit uses current feedback to maintain a constant output current to get a constant stall torque from the motor.
More about this board can be found at the [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm 433 project page]
 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:19:53Z

MeganWelker: /* Motor Control Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC/Level Shifter Board ===

The board in the picture consists of two identical channels while the schematic shows only one channel. The circuit first reads the data transmitted through I2C channel and generate 0-5 analog output. The following two op-amp circuits change the level from 0-5 to -5-+5 in order to drive motor both ways.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

The decoder reads the signals from two laser encoder mounted on the pantograph and converts them into two channels of up and down counts(four outputs in total).

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Power Amp Board ===
This circuit uses current feedback to maintain a constant output current to get a constant stall torque from the motor.
More about this board can be found at the [http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm 433 project page]
 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:18:18Z

MeganWelker: /* Decoder Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC/Level Shifter Board ===

The board in the picture consists of two identical channels while the schematic shows only one channel. The circuit first reads the data transmitted through I2C channel and generate 0-5 analog output. The following two op-amp circuits change the level from 0-5 to -5-+5 in order to drive motor both ways.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

The decoder reads the signals from two laser encoder mounted on the pantograph and converts them into two channels of up and down counts(four outputs in total).

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Motor Control Board ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:14:35Z

MeganWelker: /* DAC/Level Shifter Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC/Level Shifter Board ===

The board in the picture consists of two identical channels while the schematic shows only one channel. The circuit first reads the data transmitted through I2C channel and generate 0-5 analog output. The following two op-amp circuits change the level from 0-5 to -5-+5 in order to drive motor both ways.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Motor Control Board ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:13:31Z

MeganWelker: /* DAC Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC/Level Shifter Board ===
the name is better renamed to be DAC/level shifter board
And the board is the DAC/level shifter board, but the circuit is not. The right schematic should be “dac_level_me333.pdf” in the “circuits” folder inside the dropbox

Function: The board in the picture consists of two identical channels while the schematic shows only one channel. The circuit first reads the data transmitted through I2C channel and generate 0-5 analog output. The following two op-amp circuits change the level from 0-5 to -5-+5 in order to drive motor both ways.

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Motor Control Board ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:12:44Z

MeganWelker: /* Breakout Board */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===
This board serves as a hub to connect DAC/level shifter borad, decoder board and,power amp board, motor and PIC together. Also, it provides +15/-15 power supplyand +5/-5 large current power supply for power amp.

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Motor Control Board ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-18T05:12:21Z

MeganWelker: /* Electrical Design */

==Overview==

[[Image:Haptikos.jpg|thumb|right|500px]]

Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor on screen by moving the red joystick attached to the linkage system. Two games were created to highlight the capabilities of the feedback system. The first involves feeling a virtual shape displayed on the screen (the display can be toggled off if you want more of a challenge). This game is a simple demonstration of translating a virtual environment into something physical. The second is a side-scrolling level where the player collects jewels while avoiding boxes. This shows possible applications to an interactive gaming environment, where the user can directly feel what is happening to their character on screen.

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|left|600px]]

 

==Mechanical Design==

=== Existing System ===
Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. thesis work in friction-based tactile displays. This design allows the free point to move in a (roughly) semi-circular area in a plane. Two optical encoders are mounted at the shoulder joints to track the angle of the upper arm links (and thus the finger).

=== System Modifications ===

The existing system had the capability to accurately track finger position, but could not put apply any sort of haptic feedback. To add this capability, we chose to use a capstan drive system. In such a system, there is a thread spooled onto the motor shaft that winds in and out depending on how the motor is spinning. This thread is mounted to another element that is pulled back and forth as the thread spools out. Such drive systems can be found in other haptic devices (such as these [http://eduhaptics.org/index.php/HapticDevices/HapticPaddles haptic paddles]) and are chosen because they increase the torque of a motor as a gearhead does, but avoid problems such as backlash which is a major concern when the goal is to provide smoothly changing forces to a user. The motors chosen for out project were the [[Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder|Pittman 700935]] motors, which are relatively powerful motors without a gearhead.

The arc of the capstan drive was created by milling two 2.75" radius arcs out of Aluminum. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the motor, the thread was tightly wound around the spool (3/8" diameter brass cylinder, mounted with a set screw) three times and pulled taut in the groove. The spool was covered with a plastic layer to increase the coefficient of friction between the spool and the thread. The gear ratio created by our drive system is 44 : 3 (<math> = r_{arc}/r_{spool}</math>).

 
{| border="0"
|[[Image:EncodersTeam22.jpg|thumb|center|600px|Pantograph.]]
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

=== Box ===

To enclose the entire system, we made a 12" x 12" x 3" acrylic box using the laser cutter. The top plate is removable so that the circuitry is readily accessible and holes were cut to create a mount for the pantograph and motors. A second bracket was also cut to hold the pantograph and motors in place, which was mounted inside the box, and holes were cut in the bottom of the box to allow the pantograph to be screwed into the base plate. Holes were cut in the side and back of the box to allow wires to pass in and out of the box.

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

=== PIC Configuration ===
NU32 board carrying PIC32. The left ribbon cable socket is RS232 that connects PIC with PC. The socket on the right goes to all the other four circuit boards

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

=== Breakout Board ===

 
{| border="0"
|[[image:PictureofCircut2Team22.jpg|x200px|center]]

|}
 

=== DAC Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut1Team22meg.jpg|x200px|center]]
|[[image:PictureofCircut1Team22.jpg|x200px|center]]
|}
 

=== Decoder Board ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|x200px|center]]
|[[image:2PictureofCircut1Team22.jpg|x200px|center]]

|}
 

=== Motor Control Board ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|center]]
|}
 

== Mathematical Analysis of the Pantograph ==

There are two parts to this problem, the forward kinematics and the force generation, which are duals of each other.

=== Forward Kinematics ===

 
[[Image:pantographDimensions.png|right]]
The forward kinematics of a system (typically a robotic arm or something similar) is often used in robotics and gaming to calculate the position and orientation of a hand given the joint angles of an arm. The idea is to create a function such that <math>x=f(\theta)</math> where <math>x</math> is a vector giving the location of the finger and <math>\theta</math> is a vector of the joint angles (here the angles read by the encoders). For our system, the pantograph used was originally designed and build by John Glassmire (formerly of the Laboratory of Intelligent Mechanical Systems. Dimensions as well as full calculations of the forward kinematics may be found in Appendix D and Solidworks drawings of the parts found in Appendix E of the paper found at [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf]. Encoder 1 is found at angle 1, encoder 2 at angle 5, and the finger at angle 3, with arrows indicating the direction of positive motion, note that angle 5 is backwards to provide reflectional symmetry about the vertical axis.

=== Force Generation ===

Obviously, the wider the range of forces we can create, both in terms of magnitude and direction, the better sensation we are able to create with Haptikos. However, we also want to transition between forces in such a way that feels natural to the user. These are fundamental issue addressed by designers for any haptic device. There is a limit to the torques our motors can provide (current supply to each motor is limited to 500 mA), and thus on the strength of the forces we can give to the user and the resolution of these forces was also limited by communication issues (as discussed later).

We independently confirmed the forward kinematic calculations, and through a series of substitutions, put them all into a single function <math>x=f(\theta)</math>. Taking the derivative of this mapping, we have that <math>\dot{x} = \frac{df}{d\theta} \dot{\theta} = J(\theta) \dot{\theta}</math>, where <math>J(\theta)</math> is the Jacobian of the map. By the duality of velocity and force, we have that the torques required to produce a given force can be found using the relation <math>\tau = J(\theta)^T F</math>. For our map, the Jacobian is complicated and would take up nearly a page so it is omitted for brevity. However, we were unsuccessful using this approach to generate forces in arbitrary directions. This may be due to many causes, from data types conflicting to omitting a sign or term when typing out the equations.

Instead we used simple controls to achieve forcing in eight directions. A single byte of data was sent to the PIC containing the motor control information, with the first nibble to control motor 1 and the second to control motor 2. This allows for 16 levels of forcing, with 7 chosen to indicate zero force. Less than 7 provided a torque along the positive direction for each angle (as indicated in the figure) and greater than 7 along the negative direction. We found that activating both motors allowed us to create forces along the y and x axis (depending on if the motors were providing a torque in the same, or opposite, directions, respectively) while only activating a single motor provided forcing along the lines y = x and y = -x (motor 2 or motor 1, respectively). This range of 16 discrete force values was mapped over half of the possible force range because we found that having forces that were too strong caused for large jumps when the forces changed direction while smaller forces allowed for smoother-feeling transitions, at the cost of a more rigid feeling to surfaces.

==Software==

=== PIC Programing ===

All PIC programming was done in C using the MPLAB IDE by Microchip Technologies.
To install MPLAB, follow the instructions found [[Getting_Started_with_PIC32#Software|here]].
To create a new project in MPLAB, follow the instructions found [[HelloWorld PIC32#Create_a_New_Project|here]].
The source files for our project can be downloaded [[Media:hapticInterfaceSourceCode.zip|here]]
(remember to change the include directions if you are trying to use our MPLAB project files).

While the source code is commented, here is a list of the project-specific files and a brief summary of the contents of each.
* fingerTrack.c - This is the main file of the project, containing the main function as well as initialization and communication functions
** initEncoder - This initializes the 4 timers (T2CK - T5CK) used to count the up and down pulses from the [[Haptic_Gaming_System#Decoder|decoding circuit]]. Timers 2 and 3 are for the up and down counts of encoder 1, respectively. Timers 4 and 5 are used for up and down counts of encoder 2.
** getEncoderPositionX - This reads the current counts of encoder X and updates the angles, checking for rollover of the 16-bit counters.
** initUART1 - This initializes the UART1 bus of the PIC to be used for RS-232 communication with the PC.
** initInterruptComm - This initializes the Timer1 interrupt to run every 10ms and initializes both I2C buses on the PIC to talk to the DAC's. The interrupt timing could be synched to match the frame rate of the game, but we found this to be reliable and not interfere with the data transmission interrupt.
** MAX518 - This takes the data sent from the PC about how to force the system, parses the data, and sends out the appropriate signal to the DAC's over the I2C buses. Only 1 byte of data is sent between the PC and the PIC as this was found to be the most reliable, though it does limit the resolution of forces we are able to achieve (16 levels instead of 256). We did not find this to be a problem, but is one area of possible improvement.
** UART1 interrupt - When it detects that it has received data from the PC, the PIC will read the data, call the MAX518 function, and toggle LED0 for visual feedback. We had some issues with the interrupt not functioning correctly after the game was reset after a game over (this did not happen every time).
** Timer1 interrupt - This sends the current (x,y) position of the finger as well as the two angles of the encoders to the PC.
* calculations.c (and .h) - This library has the functions used to calculate the forward kinematics of the pantograph (i.e., to get finger position from the encoder readings).
** sine and cosine - These functions take in the current encoder angle (measured to the nearest tenth of a degree) as an integer and use a lookup table to calculate the sine. The output is an integer which must be divided by 10000 (the global variable SCALER). This was done to speed up calculations as it only involves integer math instead of floats, and can directly use encoder counts instead of converting these to radians.
** forwardKinematics - This calculates the current (x,y) location of the finger based on the current encoder readings.

=== Game Programming ===

The games are programmed and run in the Processing language (find out more information [[Processing|here]]). We chose to make two games that highlight different aspects of our project, though as you can imagine, our system could be used for many more.

====Link's Adventure ====

 

[[Image:LinksAdventureTeam22.jpg|right|x300px|alt=Screen shot of the game.]]
This game is a side-scrolling adventure game where the player must avoid the blocks and collect the jewels scrolling across the screen. As the player icon, we chose to use the character Link from the original Legend of Zelda game due to the simple graphics and game style. The three types of jewels each have a different effect on the game. Red replenish health lost from hitting the boxes, green increase the score, and blue slow blocks (whose speed gradually increases over time). When Link runs into a red block, Haptikos will shake the joystick as the box disappears to give the user a physical indication that their player was injured, much like the rumble feature found in many modern game console controllers. While the user has the option of going for a high score, we have found that it is generally more enjoyable to simply run into the blocks as this is the unique part of our device. Future iterations of this game would include some sort of haptic feedback when a jewel is collected to the player strikes the ground, possibly even simulating gravity by pushing the character towards the ground. Commented source code can be found [[Media:zeldaGame.zip|here]] and code allowing the game to be played with a computer mouse [[Media:zeldaGameMouse.zip|here]].

 

====Identification Game ====

 

[[Image:IdentiyGame.jpg|right|x300px|alt=Screen shot of the Identification game, in this case the user will feel a square.]]
In this game the player will feel a virtual shape (circle, star, triangle, square, or diamond) in the center of the screen. When the cursor (blue circle) hits the shape, the device will push the finger away from the shape, creating the sensation that you are feeling a wall. The player can also play blindly, using only the feedback from Haptikos to attempt to identify the invisible shape. To toggle this mode, press the 'i' key on the keyboard. Press 'r' to generate a new shape at random. Currently there are only 5 shapes, chosen because they are different enough so that the user can identify the shape (i.e., a heptagon and an octagon would be too similar to identify using the discrete forces available to us). Commented source code can be found [[Media:indentifyGame.zip|here]].

 

==Further Reading==

Haptic Gaming System

2010-03-17T23:47:09Z

MeganWelker:

==Overview==
Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor by moving the red joystick. Two games were created to test the feedback system.
The first, the player assumes the character of LINK (from Zelda) and jumps through a side-scrolling level collecting rupees and avoiding red boxes.
The second involves feeling out the virtual shape with nothing other than a blue position dot and a blank screen. The answer can be seen by pushing R.

[[Image:Haptikos.jpg|thumb|center|500px]]

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|center|600px]]

==Mechanical Design==

=== Existing System ===
Haptikos is a modification from a previous pentagraph configuration. This allows for the free point to be able to freely move in a fixed two-dimensional plane. There are two Canon TR-36 optical encoders with a 3600 count/rev in x1 mode mounted on top of the stationary pivot.(see below) They are used to track the angle of the larger bars and calculate the position of the free point.

[[Image:EncodersTeam22.jpg|thumb|center|600px]]

=== System Modifications ===

The existing system had the capability to accurately tell where the free point was in space, but could not put any force on that point.
[http://hades.mech.northwestern.edu/index.php/Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder A Pittman 700935 motor]was attached to each of the larger bars in the back of the pentagraph using a capstan configuration.

The capstan was created by milling two arcs out of Aluminum and then attaching one arc end to the furthest point from the backboard on each bar. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the Motor, the thread was merely wound around the shaft three times and replaced tight into the groove. (see below)

The gear ratio the arc applies to the motor is approximately 14.7 to 1. (Radius of arc/ Radius of Capstan Drive)

 
{| border="0"
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

===PIC Configuration===

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

===Whatever this is ===

what it does

its circuit

 
{| border="0"
|[[image:Circut1Team22meg.jpg|thumb|300px|center]]
|[[image:PictureofCircut1Team22.jpg|thumb|300px|center]]
|[[image:2PictureofCircut1Team22.jpg|thumb|300px|center]]
|}
 

=== Decoder ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|thumb|300px|center]]
|[[image:PictureofCircut2Team22.jpg|thumb|300px|center]]
|}
 

=== Motor Control ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.jpg|thumb|300px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|thumb|300px|center]]
|}
 

==Pre-Programming Anaylsis==

Philip would you like to put some of the mathematica code here, can we capture those graphs? I shall look into it...

==Software==

=== PIC Programing ===

To run the program you must download the HardwareProfile header files and the procdefs.ld file found here. [[HelloWorld PIC32]]

How we programmed it, Why we programmed it that way, how it talks to each other and gets the encoding information. How it talks to the motors to turn them on.

CODE

=== Game Programming ===

The games are programmed and run in processing. It can be downloaded here. [[Processing]]

====Link's Adventure ====

This demo allows the player to run through a simple avoid and collect game set-up. Link can collect either red rupees that will increase his health, green rupees to increase his score, or blue rupees to slow the increasing speed of the red blocks. When Link runs into a red block, Haptikos will quickly push the joystick in the direction that the box was traveling then stop as the box disappears. It is very effective in telling the player they have hit something, but not very effective at keeping the player from repeatedly running into the boxes because it is more fun.

[[Image:LinksAdventureTeam22.jpg|center]]

Below is the code from the Processing file

====Identity Game ====

This demo allows the player to try to identify the shape (circle, star, triangle, square, diamond) blindly using only the feedback from Haptikos and a blue dot that represents the cursor. When the blue dot approaches the edge of the box, Haptikos will push the cursor the opposite direction it was traveling.

The shape and the cursor
[[Image:IdentiyGame.jpg|center]]

Below is the processing code

==Further Reading==

Haptic Gaming System

2010-03-17T23:42:28Z

MeganWelker: /* Identity Game */

File:IdentiyGame.jpg

2010-03-17T23:41:52Z

MeganWelker:

Haptic Gaming System

2010-03-17T23:41:27Z

MeganWelker: /* Game Programming */

Haptic Gaming System

2010-03-17T23:37:42Z

MeganWelker: /* Link's Adventure */

File:LinksAdventureTeam22.jpg

2010-03-17T23:37:22Z

MeganWelker:

Haptic Gaming System

2010-03-17T23:35:57Z

MeganWelker: /* Link's Adventure */

Haptic Gaming System

2010-03-17T23:27:42Z

MeganWelker: /* Game Programming */

Haptic Gaming System

2010-03-17T23:24:16Z

MeganWelker: /* Game Programming */

Haptic Gaming System

2010-03-17T23:23:24Z

MeganWelker: /* PIC Programing */

Haptic Gaming System

2010-03-17T23:23:04Z

MeganWelker:

==Overview==
Haptikos is an interactive gaming system that allows the user to physically feel a virtual world. The player controls the cursor by moving the red joystick. Two games were created to test the feedback system.
The first, the player assumes the character of LINK (from Zelda) and jumps through a side-scrolling level collecting rupees and avoiding red boxes.
The second involves feeling out the virtual shape with nothing other than a blue position dot and a blank screen. The answer can be seen by pushing R.

[[Image:Haptikos.jpg|thumb|center|500px]]

==The Team==

*Yang Bai (Mechatronics Masters Student)
*Philip Dames (Mechanical Engineering MS/BS)
*Megan Welker(Mechanical Engineering BS/BM)

[[Image:Team22haptics.jpg|thumb|center|600px]]

==Mechanical Design==

=== Existing System ===
Haptikos is a modification from a previous pentagraph configuration. This allows for the free point to be able to freely move in a fixed two-dimensional plane. There are two Canon TR-36 optical encoders with a 3600 count/rev in x1 mode mounted on top of the stationary pivot.(see below) They are used to track the angle of the larger bars and calculate the position of the free point.

[[Image:EncodersTeam22.jpg|thumb|center|600px]]

=== System Modifications ===

The existing system had the capability to accurately tell where the free point was in space, but could not put any force on that point.
[http://hades.mech.northwestern.edu/index.php/Actuators_Available_in_the_Mechatronics_Lab#Pittman_700935_motor_with_500_line_encoder A Pittman 700935 motor]was attached to each of the larger bars in the back of the pentagraph using a capstan configuration.

The capstan was created by milling two arcs out of Aluminum and then attaching one arc end to the furthest point from the backboard on each bar. A piece of heavy duty thread was set into the groove of the outer side of the arc and secured by screws on either side. To connect the capstan to the Motor, the thread was merely wound around the shaft three times and replaced tight into the groove. (see below)

The gear ratio the arc applies to the motor is approximately 14.7 to 1. (Radius of arc/ Radius of Capstan Drive)

 
{| border="0"
|[[image:ArchTeam22.jpg|thumb|300px|Arc.|center]]
|[[image:MotorThreadTeam22.jpg|thumb|400px|Thread and Motor attachment.|center]]
|}
 

==Electrical Design==

The five boards created to run Haptikos

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|Circuitry.|center]]

|}
 

===PIC Configuration===

[[Image:PICWiringTeam22.jpg|thumb|400px|center]]

===Whatever this is ===

what it does

its circuit

 
{| border="0"
|[[image:Circut1Team22meg.jpg|thumb|300px|center]]
|[[image:PictureofCircut1Team22.jpg|thumb|300px|center]]
|[[image:2PictureofCircut1Team22.jpg|thumb|300px|center]]
|}
 

=== Decoder ===

what it does

its circuit

 
{| border="0"
|[[image:Circut2Team22meg.jpg|thumb|300px|center]]
|[[image:PictureofCircut2Team22.jpg|thumb|300px|center]]
|}
 

=== Motor Control ===
how it controls it

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.jpg|thumb|300px|center]]
|[[image:PictureofMotorControlCircutTeam22.jpg|thumb|300px|center]]
|}
 

==Pre-Programming Anaylsis==

Philip would you like to put some of the mathematica code here, can we capture those graphs? I shall look into it...

==Software==

=== PIC Programing ===

To run the program you must download the HardwareProfile header files and the procdefs.ld file found here. [[HelloWorld PIC32]]
How we programmed it, Why we programmed it that way, how it talks to each other and gets the encoding information. How it talks to the motors to turn them on.

CODE

=== Game Programming ===

The games are programmed and run in processing.

File:MotorControlCircutTeam22.jpg

2010-03-17T23:08:21Z

MeganWelker: uploaded a new version of "Image:MotorControlCircutTeam22.jpg"

File:Circut1Team22meg.jpg

2010-03-17T23:05:22Z

MeganWelker:

File:Circut2Team22meg.jpg

2010-03-17T23:03:53Z

MeganWelker:

File:MotorControlCircutTeam22.jpg

2010-03-17T23:02:28Z

MeganWelker:

Haptic Gaming System

2010-03-17T23:02:12Z

MeganWelker: /* thing 2 */

Haptic Gaming System

2010-03-17T22:55:58Z

MeganWelker: /* Electrical Design */

File:Overall.png

2010-03-17T22:55:28Z

MeganWelker:

Haptic Gaming System

2010-03-17T22:55:11Z

MeganWelker: /* Electrical Design */

Haptic Gaming System

2010-03-17T22:54:11Z

MeganWelker: /* Software */

File:PictureofMotorControlCircutTeam22.jpg

2010-03-17T22:46:04Z

MeganWelker:

File:PictureofCircut2Team22.jpg

2010-03-17T22:44:44Z

MeganWelker:

File:2PictureofCircut1Team22.jpg

2010-03-17T22:42:59Z

MeganWelker:

Haptic Gaming System

2010-03-17T22:41:49Z

MeganWelker: /* Electrical Design */

File:PictureofCircut1Team22.jpg

2010-03-17T22:41:05Z

MeganWelker:

Haptic Gaming System

2010-03-17T22:39:46Z

MeganWelker: /* Whatever this is */

File:PICWiringTeam22.jpg

2010-03-17T22:38:28Z

MeganWelker:

Haptic Gaming System

2010-03-17T22:38:02Z

MeganWelker: /* Electrical Design */

Haptic Gaming System

2010-03-17T22:30:25Z

MeganWelker: /* Electrical Design */

File:CircuitsTeam22.jpg

2010-03-17T22:29:48Z

MeganWelker:

Haptic Gaming System

2010-03-17T22:29:08Z

MeganWelker: /* Electrical Design */

Haptic Gaming System

2010-03-17T22:23:42Z

MeganWelker: /* System Modifications */

Haptic Gaming System

2010-03-17T22:23:23Z

MeganWelker: /* System Modifications */

Haptic Gaming System

2010-03-17T22:22:42Z

MeganWelker: /* System Modifications */

Haptic Gaming System

2010-03-17T22:21:40Z

MeganWelker: /* System Modifications */