Mech - User contributions [en]

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-05T17:20:38Z

Philip Dames: /* Experiment */

= Setting up the Junus Amplifier =

[[Image:power_supply_diagram.png|thumb|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.
 

Next, use the USB to RS-232 cable to connect the amp to your PC. If this doesn't work you will need to find and install the driver for the HL-340 USB to serial converter (there is a copy of the driver in the folder Philip's Files\usb-serial-driver.zip on the desktop of the PC used for the QNX manipulation project). You will also need to download and install [http://www.copleycontrols.com/Motion/Downloads/index.html CME2] (Copley Motion Explorer); note that Copley's documentation for the amplifier and software can also be downloaded from the same page.

 
[[Image:copley_basic_setup.png|thumb|Basic Setup Menu|right]]
Open the program and add the COM port used by the USB to serial cable to the list (the list can be changed later in the Tools -> Communication Wizard menu). Next go to Amplifier -> Basic Setup. Here you select from the different operational modes and input types.
 

== Operating Modes ==
* Current - This is the most commonly used mode. Here, the amplifier will create an output current proportional to some input signal to drive the attached actuator. In this mode there is only one control loop running within the amplifier making it the preferred choice (the more control that can be done outside the amp, the less of a black box it is).
* Velocity - This mode takes the current control mode and adds another feedback loop around the current control loop so that the velocity of the motor is proportional to the input signal. For the Junus amps, the motor speed is estimated from the back emf of the motor during use, making it less reliable than the current control mode.

== Command Sources ==
 
[[Image:junus_amp_pin_diagram.png|thumb|Junus Amp Input Pin Diagram|right]]
The pin diagram for the Junus amp is found to the right.
* Analog Command - In this mode, an analog input is connected to pins 2 and 9, with the analog reference voltage going to pin 9 and the signal going to pin 2. The voltage range for the input is +/- 10V with the output being proportional to the voltage, i.e. 0V is 0A (or 0rpm) output, +10V is maximum positive current output, and -10V is maximum negative current output.
* PWM Command - In this mode the output is related to the duty cycle of the PWM signal in one of two ways. To switch between these modes, click on the PWM command button in the block diagram.
** 50% mode - This mode uses a single input pin (pin 3). Here a 50% duty cycle is the zero point (0A or 0rpm) with 0% being fully negative and 100% being fully positive.
** 100% mode - In addition to the PWM input pin there is an extra input pin (pin 4) to control the sign (or direction) of the output. Here, a 0% duty cycle is the zero point, 100% duty cycle with the direction pin LO is fully negative and 100% duty cycle with the direction pin HI is fully positive.
 

Now click on the Motor button in the block diagram. Here you can input all the necessary parameters about your motor from the data sheet, or that you experimentally found. Now you are ready to look at the control loop. There is a PI controller with tunable parameters used to control the output current. While you are welcome to play around with the parameters on your own, I would suggest that you click on the I Loop button and select Auto Tune, at least to get a starting point for the parameters. It will give you several options based on different levels of aggressiveness of the controller.

Click on Input/Output. Here you can set up the different input and output pins. I recommend using IN1 as Amp Enable-HI (or LO) Enables With Clear Faults (pin 13). This ensures that the motor can only spin when you give it a command to turn on. Choose HI if your digital outputs default to LO, or vice versa, as it can vary depending on the presence of pull-up resistors, etc. You now have your amp configured and you are ready to start controlling your motor.

There are also a couple of other utilities built into the CME2 software. The first is the Control Panel (second button from the left in the top menu). This allows you to software enable/disable the amplifier as well as monitor various inputs/outputs of the motor during use. The other is the Scope (third button from the left in the top menu). This lets you apply various functions to drive the motor and monitor inputs/outputs over time. This is useful for making sure your control parameters are tuned the way you like them.

= Using the Motor =

If you are using analog command mode, a simple test to make sure your setup is working correctly is to connect the enable pin to +5V (or GND, depending on how it was configured) and use a potentiometer to control the input voltage and make sure the motor spins as you would expect it to. As a reminder, 0V is 0 output, negative voltage will move it in one direction and positive voltage in the other.

If you are using PWM command mode, a more involved test would be to do the activity found [[ME 333 Lab 4 | here]]. For our system, the plant would be the entire amp/motor package and feedback loop in the diagram at the top is designed to control the position of the motor.

= Motor Modeling =

For our purposes, we have chosen to model the motor using the following equation, where <math>\tau</math> is the output torque, <math>k_m</math> is the motor constant, <math>i</math> is the command current, <math>\mu_d</math> is the dynamic friction coefficient, <math>mu_s</math> is the static friction, <math>\omega</math> is the speed of the motor, and the <math>sgn</math> function returns the sign of its argument.

<math> \tau = k_m i - \mu_d \omega - \mu_s sgn(\omega) \,</math>

This can be easily solved to find the necessary command current (and thus the analog or PWM input) needed to follow a reference trajectory, which would be the feedforward model of our system.

== Setup ==

To determine the values of the parameters in the above equation, you should run a series of tests at various input levels to make sure the parameters are constant at various speeds and accelerations of the motor. To set up the experiment you will need a mount for the motor (a table-mount vice works well), an object of known inertia (ex. momentum wheel), and you will need to hook up the encoder on the motor to a device that can read it in (ex. decoding chip connected to a PIC).

== Experiment ==

 
[[Image:motor_model_wiring.png|200px|Wiring diagram for the motor modeling setup|right]]
For each run of the experiment, the motor is driven by three periods of a square wave current at a specified amplitude. Multiple periods are used to allow transient behavior to die down and for filtering purposes, described in the following section. During each run the position from the encoder is recorded and post-processing is used to find the velocity and acceleration associated with the trajectory.

Code used to drive the motor during the experiment can be downloaded [[Media:motor_model_PIC_code.zip|here]]. This code is meant to be run on the [Introduction to the PIC32|PIC32 board]. The basic wiring diagram is to the right and the datasheet for the LS7083 decoder can be found here [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html] and includes all the wiring diagrams necessary.

To actually run the experiment, use the MATLAB code [[Media:motor_model_analysis_code.zip|here]]. The function dataCollection takes in the amplitude of your square wave current and outputs this to the amp. It then collects the trajectory data and saves it to a .mat file (see file for details on directory and file name format). Note that the COM port, Imax (maximum current set on the amp), and other variables must be changed in both the MATLAB code and the amp or PIC.
 

== Filtering ==

 
[[Image:filtering_example.png|200px|An example of filtering data|right]]
To find the velocity and acceleration of the motor during the experiment, the raw data from the encoder must be smoothed otherwise there are large spikes in the calculated derivatives due to signal noise, etc. To smooth the data, a moving average is used (this is why we collected extra periods of data, so we can still apply the moving average to the end points). The idea of a moving average is the filtered value at a specific time is the average of the unfiltered value and the nearest N values in each direction. Choosing a low N leads to less smoothing but retains more of the original data. I found that an N of 5 was good for my data set, but this will be different for each application depending on the amount of noise, etc. The number of points to use in the filter is the second (and optional) argument to the MATLAB file fitParameters. In this function, the raw data is first smoothed using the moving average, then finite differences are used to calculate the velocity. This is then smoothed using the same moving average and finite differences are used again to find the acceleration.
 

== Fitting Parameters ==

 
[[Image:model_example.png|200px|An example of motor model data|right]]
Now that you have the acceleration, you can easily find the torque because you know the inertia of the object being rotated. Going back to the model, you now have the torque and velocity so you can solve for the three unknowns. You can also choose to model the motor as having a different set of parameters for positive and negative torques, something I found to work better than a single set of parameters.

In the figure to the right, an example of a motor model is shown, with trials run at 50 mA intervals from 150 to 400 mA. The filtered data is plotted as the dots and the ideal model based on the calculated parameters are the solid lines, this type of plot can be generated from the function batchProcess. In this plot, the effect of filtering is evident in the rounded edges near the transition points (crossing zero velocity and zero acceleration lines). You can also see the motor is reaching its maximum speed at 200 mA.

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-05T17:20:13Z

Philip Dames: /* Experiment */

= Setting up the Junus Amplifier =

[[Image:power_supply_diagram.png|thumb|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.
 

Next, use the USB to RS-232 cable to connect the amp to your PC. If this doesn't work you will need to find and install the driver for the HL-340 USB to serial converter (there is a copy of the driver in the folder Philip's Files\usb-serial-driver.zip on the desktop of the PC used for the QNX manipulation project). You will also need to download and install [http://www.copleycontrols.com/Motion/Downloads/index.html CME2] (Copley Motion Explorer); note that Copley's documentation for the amplifier and software can also be downloaded from the same page.

 
[[Image:copley_basic_setup.png|thumb|Basic Setup Menu|right]]
Open the program and add the COM port used by the USB to serial cable to the list (the list can be changed later in the Tools -> Communication Wizard menu). Next go to Amplifier -> Basic Setup. Here you select from the different operational modes and input types.
 

== Operating Modes ==
* Current - This is the most commonly used mode. Here, the amplifier will create an output current proportional to some input signal to drive the attached actuator. In this mode there is only one control loop running within the amplifier making it the preferred choice (the more control that can be done outside the amp, the less of a black box it is).
* Velocity - This mode takes the current control mode and adds another feedback loop around the current control loop so that the velocity of the motor is proportional to the input signal. For the Junus amps, the motor speed is estimated from the back emf of the motor during use, making it less reliable than the current control mode.

== Command Sources ==
 
[[Image:junus_amp_pin_diagram.png|thumb|Junus Amp Input Pin Diagram|right]]
The pin diagram for the Junus amp is found to the right.
* Analog Command - In this mode, an analog input is connected to pins 2 and 9, with the analog reference voltage going to pin 9 and the signal going to pin 2. The voltage range for the input is +/- 10V with the output being proportional to the voltage, i.e. 0V is 0A (or 0rpm) output, +10V is maximum positive current output, and -10V is maximum negative current output.
* PWM Command - In this mode the output is related to the duty cycle of the PWM signal in one of two ways. To switch between these modes, click on the PWM command button in the block diagram.
** 50% mode - This mode uses a single input pin (pin 3). Here a 50% duty cycle is the zero point (0A or 0rpm) with 0% being fully negative and 100% being fully positive.
** 100% mode - In addition to the PWM input pin there is an extra input pin (pin 4) to control the sign (or direction) of the output. Here, a 0% duty cycle is the zero point, 100% duty cycle with the direction pin LO is fully negative and 100% duty cycle with the direction pin HI is fully positive.
 

Now click on the Motor button in the block diagram. Here you can input all the necessary parameters about your motor from the data sheet, or that you experimentally found. Now you are ready to look at the control loop. There is a PI controller with tunable parameters used to control the output current. While you are welcome to play around with the parameters on your own, I would suggest that you click on the I Loop button and select Auto Tune, at least to get a starting point for the parameters. It will give you several options based on different levels of aggressiveness of the controller.

Click on Input/Output. Here you can set up the different input and output pins. I recommend using IN1 as Amp Enable-HI (or LO) Enables With Clear Faults (pin 13). This ensures that the motor can only spin when you give it a command to turn on. Choose HI if your digital outputs default to LO, or vice versa, as it can vary depending on the presence of pull-up resistors, etc. You now have your amp configured and you are ready to start controlling your motor.

There are also a couple of other utilities built into the CME2 software. The first is the Control Panel (second button from the left in the top menu). This allows you to software enable/disable the amplifier as well as monitor various inputs/outputs of the motor during use. The other is the Scope (third button from the left in the top menu). This lets you apply various functions to drive the motor and monitor inputs/outputs over time. This is useful for making sure your control parameters are tuned the way you like them.

= Using the Motor =

If you are using analog command mode, a simple test to make sure your setup is working correctly is to connect the enable pin to +5V (or GND, depending on how it was configured) and use a potentiometer to control the input voltage and make sure the motor spins as you would expect it to. As a reminder, 0V is 0 output, negative voltage will move it in one direction and positive voltage in the other.

If you are using PWM command mode, a more involved test would be to do the activity found [[ME 333 Lab 4 | here]]. For our system, the plant would be the entire amp/motor package and feedback loop in the diagram at the top is designed to control the position of the motor.

= Motor Modeling =

For our purposes, we have chosen to model the motor using the following equation, where <math>\tau</math> is the output torque, <math>k_m</math> is the motor constant, <math>i</math> is the command current, <math>\mu_d</math> is the dynamic friction coefficient, <math>mu_s</math> is the static friction, <math>\omega</math> is the speed of the motor, and the <math>sgn</math> function returns the sign of its argument.

<math> \tau = k_m i - \mu_d \omega - \mu_s sgn(\omega) \,</math>

This can be easily solved to find the necessary command current (and thus the analog or PWM input) needed to follow a reference trajectory, which would be the feedforward model of our system.

== Setup ==

To determine the values of the parameters in the above equation, you should run a series of tests at various input levels to make sure the parameters are constant at various speeds and accelerations of the motor. To set up the experiment you will need a mount for the motor (a table-mount vice works well), an object of known inertia (ex. momentum wheel), and you will need to hook up the encoder on the motor to a device that can read it in (ex. decoding chip connected to a PIC).

== Experiment ==

 
[[Image:motor_model_wiring.png|200px|Wiring diagram for the motor modeling setup|right]]
For each run of the experiment, the motor is driven by three periods of a square wave current at a specified amplitude. Multiple periods are used to allow transient behavior to die down and for filtering purposes, described in the following section. During each run the position from the encoder is recorded and post-processing is used to find the velocity and acceleration associated with the trajectory.

Code used to drive the motor during the experiment can be downloaded [[Media:motor_model_PIC_code.zip|here]]. This code is meant to be run on the [Introduction to the PIC32|PIC32 board]. The basic wiring diagram is to the right and the datasheet for the LS7083 decoder can be found [http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html|here] and includes all the wiring diagrams necessary.

To actually run the experiment, use the MATLAB code [[Media:motor_model_analysis_code.zip|here]]. The function dataCollection takes in the amplitude of your square wave current and outputs this to the amp. It then collects the trajectory data and saves it to a .mat file (see file for details on directory and file name format). Note that the COM port, Imax (maximum current set on the amp), and other variables must be changed in both the MATLAB code and the amp or PIC.
 

== Filtering ==

 
[[Image:filtering_example.png|200px|An example of filtering data|right]]
To find the velocity and acceleration of the motor during the experiment, the raw data from the encoder must be smoothed otherwise there are large spikes in the calculated derivatives due to signal noise, etc. To smooth the data, a moving average is used (this is why we collected extra periods of data, so we can still apply the moving average to the end points). The idea of a moving average is the filtered value at a specific time is the average of the unfiltered value and the nearest N values in each direction. Choosing a low N leads to less smoothing but retains more of the original data. I found that an N of 5 was good for my data set, but this will be different for each application depending on the amount of noise, etc. The number of points to use in the filter is the second (and optional) argument to the MATLAB file fitParameters. In this function, the raw data is first smoothed using the moving average, then finite differences are used to calculate the velocity. This is then smoothed using the same moving average and finite differences are used again to find the acceleration.
 

== Fitting Parameters ==

 
[[Image:model_example.png|200px|An example of motor model data|right]]
Now that you have the acceleration, you can easily find the torque because you know the inertia of the object being rotated. Going back to the model, you now have the torque and velocity so you can solve for the three unknowns. You can also choose to model the motor as having a different set of parameters for positive and negative torques, something I found to work better than a single set of parameters.

In the figure to the right, an example of a motor model is shown, with trials run at 50 mA intervals from 150 to 400 mA. The filtered data is plotted as the dots and the ideal model based on the calculated parameters are the solid lines, this type of plot can be generated from the function batchProcess. In this plot, the effect of filtering is evident in the rounded edges near the transition points (crossing zero velocity and zero acceleration lines). You can also see the motor is reaching its maximum speed at 200 mA.

File:Model example.png

2010-09-05T17:19:45Z

Philip Dames:

File:Filtering example.png

2010-09-05T17:19:32Z

Philip Dames:

File:Motor model wiring.png

2010-09-05T17:19:06Z

Philip Dames:

File:Motor model analysis code.zip

2010-09-05T17:18:56Z

Philip Dames:

File:Motor model PIC code.zip

2010-09-05T17:18:44Z

Philip Dames:

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-05T17:18:28Z

Philip Dames: /* Motor Modeling */

= Setting up the Junus Amplifier =

[[Image:power_supply_diagram.png|thumb|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.
 

Next, use the USB to RS-232 cable to connect the amp to your PC. If this doesn't work you will need to find and install the driver for the HL-340 USB to serial converter (there is a copy of the driver in the folder Philip's Files\usb-serial-driver.zip on the desktop of the PC used for the QNX manipulation project). You will also need to download and install [http://www.copleycontrols.com/Motion/Downloads/index.html CME2] (Copley Motion Explorer); note that Copley's documentation for the amplifier and software can also be downloaded from the same page.

 
[[Image:copley_basic_setup.png|thumb|Basic Setup Menu|right]]
Open the program and add the COM port used by the USB to serial cable to the list (the list can be changed later in the Tools -> Communication Wizard menu). Next go to Amplifier -> Basic Setup. Here you select from the different operational modes and input types.
 

== Operating Modes ==
* Current - This is the most commonly used mode. Here, the amplifier will create an output current proportional to some input signal to drive the attached actuator. In this mode there is only one control loop running within the amplifier making it the preferred choice (the more control that can be done outside the amp, the less of a black box it is).
* Velocity - This mode takes the current control mode and adds another feedback loop around the current control loop so that the velocity of the motor is proportional to the input signal. For the Junus amps, the motor speed is estimated from the back emf of the motor during use, making it less reliable than the current control mode.

== Command Sources ==
 
[[Image:junus_amp_pin_diagram.png|thumb|Junus Amp Input Pin Diagram|right]]
The pin diagram for the Junus amp is found to the right.
* Analog Command - In this mode, an analog input is connected to pins 2 and 9, with the analog reference voltage going to pin 9 and the signal going to pin 2. The voltage range for the input is +/- 10V with the output being proportional to the voltage, i.e. 0V is 0A (or 0rpm) output, +10V is maximum positive current output, and -10V is maximum negative current output.
* PWM Command - In this mode the output is related to the duty cycle of the PWM signal in one of two ways. To switch between these modes, click on the PWM command button in the block diagram.
** 50% mode - This mode uses a single input pin (pin 3). Here a 50% duty cycle is the zero point (0A or 0rpm) with 0% being fully negative and 100% being fully positive.
** 100% mode - In addition to the PWM input pin there is an extra input pin (pin 4) to control the sign (or direction) of the output. Here, a 0% duty cycle is the zero point, 100% duty cycle with the direction pin LO is fully negative and 100% duty cycle with the direction pin HI is fully positive.
 

Now click on the Motor button in the block diagram. Here you can input all the necessary parameters about your motor from the data sheet, or that you experimentally found. Now you are ready to look at the control loop. There is a PI controller with tunable parameters used to control the output current. While you are welcome to play around with the parameters on your own, I would suggest that you click on the I Loop button and select Auto Tune, at least to get a starting point for the parameters. It will give you several options based on different levels of aggressiveness of the controller.

Click on Input/Output. Here you can set up the different input and output pins. I recommend using IN1 as Amp Enable-HI (or LO) Enables With Clear Faults (pin 13). This ensures that the motor can only spin when you give it a command to turn on. Choose HI if your digital outputs default to LO, or vice versa, as it can vary depending on the presence of pull-up resistors, etc. You now have your amp configured and you are ready to start controlling your motor.

There are also a couple of other utilities built into the CME2 software. The first is the Control Panel (second button from the left in the top menu). This allows you to software enable/disable the amplifier as well as monitor various inputs/outputs of the motor during use. The other is the Scope (third button from the left in the top menu). This lets you apply various functions to drive the motor and monitor inputs/outputs over time. This is useful for making sure your control parameters are tuned the way you like them.

= Using the Motor =

If you are using analog command mode, a simple test to make sure your setup is working correctly is to connect the enable pin to +5V (or GND, depending on how it was configured) and use a potentiometer to control the input voltage and make sure the motor spins as you would expect it to. As a reminder, 0V is 0 output, negative voltage will move it in one direction and positive voltage in the other.

If you are using PWM command mode, a more involved test would be to do the activity found [[ME 333 Lab 4 | here]]. For our system, the plant would be the entire amp/motor package and feedback loop in the diagram at the top is designed to control the position of the motor.

= Motor Modeling =

For our purposes, we have chosen to model the motor using the following equation, where <math>\tau</math> is the output torque, <math>k_m</math> is the motor constant, <math>i</math> is the command current, <math>\mu_d</math> is the dynamic friction coefficient, <math>mu_s</math> is the static friction, <math>\omega</math> is the speed of the motor, and the <math>sgn</math> function returns the sign of its argument.

<math> \tau = k_m i - \mu_d \omega - \mu_s sgn(\omega) \,</math>

This can be easily solved to find the necessary command current (and thus the analog or PWM input) needed to follow a reference trajectory, which would be the feedforward model of our system.

== Setup ==

To determine the values of the parameters in the above equation, you should run a series of tests at various input levels to make sure the parameters are constant at various speeds and accelerations of the motor. To set up the experiment you will need a mount for the motor (a table-mount vice works well), an object of known inertia (ex. momentum wheel), and you will need to hook up the encoder on the motor to a device that can read it in (ex. decoding chip connected to a PIC).

== Experiment ==

 
[[Image:motor_model_wiring.png|200px|Wiring diagram for the motor modeling setup|right]]
For each run of the experiment, the motor is driven by three periods of a square wave current at a specified amplitude. Multiple periods are used to allow transient behavior to die down and for filtering purposes, described in the following section. During each run the position from the encoder is recorded and post-processing is used to find the velocity and acceleration associated with the trajectory.

Code used to drive the motor during the experiment can be downloaded [[Media:motor_model_PIC_code.zip|here]]. This code is meant to be run on the [Introduction to the PIC32|PIC32 board]. The basic wiring diagram is to the right and the datasheet for the LS7083 decoder can be found [[http://pdf1.alldatasheet.com/datasheet-pdf/view/71312/LSI/LS7083.html|here]] and includes all the wiring diagrams necessary.

To actually run the experiment, use the MATLAB code [[Media:motor_model_analysis_code.zip|here]]. The function dataCollection takes in the amplitude of your square wave current and outputs this to the amp. It then collects the trajectory data and saves it to a .mat file (see file for details on directory and file name format). Note that the COM port, Imax (maximum current set on the amp), and other variables must be changed in both the MATLAB code and the amp or PIC.
 

== Filtering ==

 
[[Image:filtering_example.png|200px|An example of filtering data|right]]
To find the velocity and acceleration of the motor during the experiment, the raw data from the encoder must be smoothed otherwise there are large spikes in the calculated derivatives due to signal noise, etc. To smooth the data, a moving average is used (this is why we collected extra periods of data, so we can still apply the moving average to the end points). The idea of a moving average is the filtered value at a specific time is the average of the unfiltered value and the nearest N values in each direction. Choosing a low N leads to less smoothing but retains more of the original data. I found that an N of 5 was good for my data set, but this will be different for each application depending on the amount of noise, etc. The number of points to use in the filter is the second (and optional) argument to the MATLAB file fitParameters. In this function, the raw data is first smoothed using the moving average, then finite differences are used to calculate the velocity. This is then smoothed using the same moving average and finite differences are used again to find the acceleration.
 

== Fitting Parameters ==

 
[[Image:model_example.png|200px|An example of motor model data|right]]
Now that you have the acceleration, you can easily find the torque because you know the inertia of the object being rotated. Going back to the model, you now have the torque and velocity so you can solve for the three unknowns. You can also choose to model the motor as having a different set of parameters for positive and negative torques, something I found to work better than a single set of parameters.

In the figure to the right, an example of a motor model is shown, with trials run at 50 mA intervals from 150 to 400 mA. The filtered data is plotted as the dots and the ideal model based on the calculated parameters are the solid lines, this type of plot can be generated from the function batchProcess. In this plot, the effect of filtering is evident in the rounded edges near the transition points (crossing zero velocity and zero acceleration lines). You can also see the motor is reaching its maximum speed at 200 mA.

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-04T18:43:19Z

Philip Dames:

File:Junus amp pin diagram.png

2010-09-04T17:42:41Z

Philip Dames:

File:Copley basic setup.png

2010-09-04T17:42:32Z

Philip Dames:

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-04T17:42:19Z

Philip Dames:

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-04T16:58:11Z

Philip Dames:

= Setting up the Junus Amplifier =

[[Image:power_supply_diagram.png|thumb|150px|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.

File:Power supply diagram.png

2010-09-04T16:57:38Z

Philip Dames: uploaded a new version of "Image:Power supply diagram.png"

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-04T16:57:29Z

Philip Dames:

= Setting up the Junus Amplifier =

[[Image:power_supply_diagram.JPG|thumb|150px|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.

Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps

2010-09-04T16:56:36Z

Philip Dames: New page: * Setting up the Junus Amplifier right The first thing you need to run the amplifier is to find a DC power source that ...

* Setting up the Junus Amplifier

[[Image:power_supply_diagram.JPG|thumb|150px|Power Supply Diagram|right]]
The first thing you need to run the amplifier is to find a DC power source that outputs 20-90V with a maximum current greater than what you expect your motor(s) to draw. This should be connected to the amplifier according to the following diagram, where the capacitors and diodes are rated for the voltages/currents you are expecting to see.

File:Power supply diagram.png

2010-09-04T16:56:09Z

Philip Dames:

Projects and miscellaneous

2010-09-04T16:49:08Z

Philip Dames:

*[[ME 333 final projects]]
*[[Real-Time Linux for TrackCam]]
*[[NI-DAQ Cards on Linux]]
*[[PPOD Experiments with a Textured Plate]]
*[[VPOD 3DOF Vibratory Device]]
*[[Design and Control of a Pantograph Robot]]
*[[PIC Motor Control with EEPROM and Interactive Menu Example]]
*[[Swarm Robot Project Overview]]
*[[Robot Helicopter Project]]
*[[E-Puck Color Sensing Project]]
*[[Guitar Tuning Project]]
*[[Mohr's Circle]]
*[[E-puck Mobile Robot]]
*[[Bearings]]
*[[Using the Basic Stamp Microcontroller]]
*[[Basic Stamp]]
*[[Solderboard]]
*[[Battery disaster]]
*[[LIMS Air Hockey Table]]
*[[Rotational Stiffness]]
*[[PIC USB]]
*[[MATLAB Motor Controller]]
*[[Flexure Characterization and Design]]
*[[Bouncing Polygon Simulator]]
*[[Control with TrackCam Vision Feedback and MATLAB]]
*[[High Speed Vision System and Object Tracking]]
*[[MonkeyBot Simulation Project]]
*[[PPOD-mini Project]]
*[[PPOD User Guide]]
*[[PIC32MX: High-speed Wireless Communication]]
*[[Setup, Use, and Modeling of Harmonic Drive Motors with Junus Amps]]
*[[test]]

Projects and miscellaneous

2010-09-04T16:45:40Z

Philip Dames:

Haptic Gaming System

2010-03-19T08:06:13Z

Philip Dames:

[[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] (and the other projects) in action on YouTube.
 

==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. [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).

=== 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 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.

 
{| 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. 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.

 
{| 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 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 Fsck 50000 // Frequency
#define BRG_VAL ((SYS_FREQ/2/Fsck)-2) // Baud rate generator value

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)
{
// 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. 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()
{
// 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 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
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 (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)
{
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 [[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 ====

 

[[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.
* 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 ==

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-19T07:48:28Z

Philip Dames: /* Game Programming */

[[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] (and the other projects) in action on YouTube.
 

==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 [[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 ====

 

[[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.
* 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 ==

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-19T07:47:37Z

Philip Dames: /* Debugging Tips */

[[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] (and the other projects) in action on YouTube.
 

==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.
* 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 ==

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-19T03:15:56Z

Philip Dames: /* 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] (and the other projects) in action on YouTube.
 

==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.

ME 333 final projects

2010-03-19T03:14:56Z

Philip Dames: /* 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:Kpmw_Ferrofluid.jpg|thumb|150px|Ferrofluid Art|right]]

The goal of this project was to create an interesting display using Ferrofluid, which forms interesting shapes in the presence of a magnetic field. The display consists of a hexagonal array of 19 solenoids attached to magnets. Depending on the motion of the solenoids, the fluid will either be smooth or show 'spikes'.

 

=== [[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 while collecting jewels. The second involves feeling a virtual shape displayed on the screen. This can be made more challenging by turning the display off and attempting to identify the shape. See our video demonstration on [http://www.youtube.com/watch?v=7j37NCYWHF8 YouTube].

 

== 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-19T01:36:53Z

Philip Dames: /* Decoder Board */

[[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 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:36:21Z

Philip Dames: /* Decoder Board */

[[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 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.

 
{| 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:30:52Z

Philip Dames: /* Software */

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

==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-18T17:23:57Z

Philip Dames:

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

==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.

=== 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-18T17:02:00Z

Philip Dames: /* Next Steps */

Haptic Gaming System

2010-03-18T17:01:44Z

Philip Dames: /* Overview */

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

==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.

=== 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]].

 

== 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.

The most fun aspect to this project is that using the basic system we have developed, (while there is room for improvement) a wide variety of interactive demonstrations and games can be developed. The foundations for communication, the mechanical platform, and all of the necessary circuitry are in place so all that is needed is a creative mind and some programming knowledge.

Haptic Gaming System

2010-03-18T16:57:33Z

Philip Dames:

Haptic Gaming System

2010-03-18T16:48:36Z

Philip Dames: /* Next Steps */

==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]].

 

== 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.

The most fun aspect to this project is that using the basic system we have developed, (while there is room for improvement) a wide variety of interactive demonstrations and games can be developed. The foundations for communication, the mechanical platform, and all of the necessary circuitry are in place so all that is needed is a creative mind and some programming knowledge.

File:Circut1Team22meg.jpg

2010-03-18T16:37:44Z

Philip Dames: uploaded a new version of "Image:Circut1Team22meg.jpg"

File:Circut2Team22meg.jpg

2010-03-18T16:36:19Z

Philip Dames: uploaded a new version of "Image:Circut2Team22meg.jpg"

File:Circut2Team22meg.jpg

2010-03-18T16:35:32Z

Philip Dames: uploaded a new version of "Image:Circut2Team22meg.jpg"

File:Circut1Team22meg.jpg

2010-03-18T16:33:39Z

Philip Dames: uploaded a new version of "Image:Circut1Team22meg.jpg"

Haptic Gaming System

2010-03-18T16:32:12Z

Philip Dames: /* Further Reading */

Haptic Gaming System

2010-03-18T05:55:26Z

Philip Dames: /* 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==

 
{| 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:54:49Z

Philip Dames: /* 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==

 
{| 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]]
|}
 

=== 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]]
|}
 

=== 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]]
|}
 

== 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==

File:HapticsBlockDiagram.png

2010-03-18T05:52:47Z

Philip Dames:

Haptic Gaming System

2010-03-18T05:51:54Z

Philip Dames: /* 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==

 
{| border="0"
|[[image:Overall.png|thumb|400px|center]]
|[[image:CircuitsTeam22.jpg|thumb|400px|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]]
|}
 

=== 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]]
|}
 

=== 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]]
|}
 

== 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:51:19Z

Philip Dames: /* 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 ===

 
[[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]]
|}
 

=== 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]]
|}
 

=== 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]]
|}
 

== 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:47:27Z

Philip Dames: /* 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 ===

 
[[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]]
|}
 

=== 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]]
|}
 

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

its circuit

 
{| border="0"
|[[image:MotorControlCircutTeam22.png|x200px|right]]
|[[image:PictureofMotorControlCircutTeam22.jpg|x200px|right]]
|}
This circuit uses current feedback to maintain a constant output current to get a constant stall torque from the motor.
And there is the link of the PCB
http://www.mech.northwestern.edu/courses/433/Writeups/MotorAmp/motoramp.htm

 

== 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:02:18Z

Philip Dames: /* Mechanical 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 ===

[[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-18T05:01:46Z

Philip Dames: /* Mechanical 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]]
|[[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 ===

[[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-18T04:27:23Z

Philip Dames: /* 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|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.
[[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 pantograph 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]]

=== 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-18T04:26:49Z

Philip Dames: /* 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|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.
[[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 pantograph 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]]

=== 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-18T04:25:34Z

Philip Dames: /* Overview */

==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|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.
[[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 pantograph 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]]

=== 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==

File:HapticInterfaceSourceCode.zip

2010-03-18T04:10:37Z

Philip Dames:

File:PICWiringTeam22.jpg

2010-03-18T03:13:29Z

Philip Dames: uploaded a new version of "Image:PICWiringTeam22.jpg"