Haptic Gaming System - Revision history

Philip Dames at 08:06, 19 March 2010

2010-03-19T08:06:13Z

← Older revision		Revision as of 03:06, 19 March 2010
Line 22:		Line 22:

	=== Existing System ===		=== 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).		Haptikos began as a modification of the pantograph used by John Glassmire for finger position tracking for his M.S. [http://lims.mech.northwestern.edu/papers/glassmire06/GlassmireMaster.pdf 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).


Line 73:		Line 73:
	=== DAC/Level Shifter Board ===		=== 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.		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 two [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 instead of speed control). Note the actual board consists of two identical channels, one for each motor, while the schematic shows only one.

	<br clear=all>		<br clear=all>
Line 85:		Line 85:
	=== Motor Control Board ===		=== 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.		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. Michael 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.

	<br clear=all>		<br clear=all>
Line 150:		Line 150:
	=== RS-232 Communication with PC ===		=== 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		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 instead of downloading the code from above. 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 DESIRED_BAUDRATE 19200 // The desired BaudRate RS-232
	#define Fsck 50000		#define Fsck 50000 // Frequency
	#define BRG_VAL ((SYS_FREQ/2/Fsck)-2)		#define BRG_VAL ((SYS_FREQ/2/Fsck)-2) // Baud rate generator value

	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]].		This first function initializes the UART1 port on the PIC. For an more detailed 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)		void initUART1(int pbClk)
Line 192:		Line 192:
	}		}

	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.		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. Because this is higher priority, it may be necessary to increase the period of the interrupt if the PIC is receiving longer packets of information from the PC. This function also initializes the I2C communication ports (further explanation of this below).

	void initInterruptComm()		void initInterruptComm()
Line 209:		Line 209:
	}		}

	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.		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		// UART 1 interrupt handler
Line 233:		Line 233:
	}		}

	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.		We also create an interrupt controller for Timer1 to send position information back at the pre-defined rate of 10ms. The function uses putsUART1 which sends a string of data to the PC, which then parses the string into the individual components. The end line character "\n" is useful so the PC knows that it has received the entire data string, though any character could be used.

	// interrput code for the timer 1		// interrput code for the timer 1
Line 252:		Line 252:
	=== I2C Communication with DACs ===		=== 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.		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 (ACK-ed). This address is defined by the chips used as well as the configuration pins set when wiring the chips. 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 the voltage level to output. The I2C 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)		void MAX518(int force)
Line 304:		Line 304:
	=== Game Programming ===		=== Game Programming ===

	The games are programmed and run in [[Processing]], a Java-based programming language. 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.		The games are programmed and run in [[Processing]], a Java-based programming language that makes the creation of graphics very easy. 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 ====		====Link's Adventure ====

Philip Dames: /* Game Programming */

2010-03-19T07:48:28Z

Game Programming

← Older revision		Revision as of 02:48, 19 March 2010
Line 304:		Line 304:
	=== Game Programming ===		=== 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.		The games are programmed and run in [[Processing]], a Java-based programming language. 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 ====		====Link's Adventure ====

Philip Dames: /* Debugging Tips */

2010-03-19T07:47:37Z

Debugging Tips

← Older revision		Revision as of 02:47, 19 March 2010
Line 333:		Line 333:
	* 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.		* 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.		* 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.
			* Common ground - When connecting several circuit boards together, make sure they have a common ground. If this is not done, the ground from one board can float relative to the other boards and cause problems when sending signals between boards.

			* Current limitations - When using DC/DC converters, exceeding the maximum current may cause the converter voltage output to decrease.
			* [http://en.wikipedia.org/wiki/Impedance_matching Impedance matching] - As with all modular circuitry, make sure that the output impedance of one circuit is matched to the input of the connected circuit.

	== Next Steps ==		== Next Steps ==

Philip Dames: /* Overview */

2010-03-19T03:15:56Z

Overview

← Older revision		Revision as of 22:15, 18 March 2010
Line 5:		Line 5:
	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.		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] (and the other projects) in action on YouTube.

⚫	Watch [http://www.youtube.com/watch?v=7j37NCYWHF8 Haptikos] in action
	<br clear=all>		<br clear=all>

MeganWelker: /* Overview */

2010-03-19T03:12:59Z

Overview

← Older revision		Revision as of 22:12, 18 March 2010
Line 5:		Line 5:
	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.		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
	<br clear=all>		<br clear=all>

MeganWelker: /* Box */

2010-03-19T01:39:28Z

Box

← Older revision		Revision as of 20:39, 18 March 2010
Line 40:		Line 40:
	=== Box ===		=== 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.		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==		==Electrical Design==

Philip Dames: /* Decoder Board */

2010-03-19T01:36:53Z

Decoder Board

← Older revision		Revision as of 20:36, 18 March 2010
Line 96:		Line 96:
	=== Decoder Board ===		=== 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.		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.

	<br clear=all>		<br clear=all>

Philip Dames: /* Decoder Board */

2010-03-19T01:36:21Z

Decoder Board

← Older revision		Revision as of 20:36, 18 March 2010
Line 96:		Line 96:
	=== Decoder Board ===		=== 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.		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.

	<br clear=all>		<br clear=all>

MeganWelker at 01:34, 19 March 2010

2010-03-19T01:34:06Z

← Older revision		Revision as of 20:34, 18 March 2010
Line 1:		Line 1:
	[[Image:Haptikos.jpg\|thumb\|right\|~~600px~~]]		[[Image:Haptikos.jpg\|thumb\|right\|400px]]

	==Overview==		==Overview==

MeganWelker at 01:33, 19 March 2010

2010-03-19T01:33:50Z

← Older revision		Revision as of 20:33, 18 March 2010
Line 1:		Line 1:
	[[Image:Haptikos.jpg\|thumb\|right\|~~550px~~]]		[[Image:Haptikos.jpg\|thumb\|right\|600px]]

	==Overview==		==Overview==