Physical Computing Journal

Group Project 3 - Blackjack 2

2004-12-15T10:18:00.000-08:00

Lamar Hines and I have decided to continue working on the blackjack game project and have asked Rich Hauck to join us. We want to extend the functionality of the game and also make a few changes in the interface and messaging. In addition to changes we already had in mind, we decided to get some more user feedback to see what else we should work on. Here's what we found as well as some of my thoughts about these issues:

GAME PLAY SPEED ISSUE: Most users seemed to think that the game sequence was to slow, often users would see the text stating that it was dealing to player/dealer or hitting player/dealer and the user would be attempting to perform an action. As a result, we sped up the dealing portion of the game so that the initial card hand for both dealer and player are dealt in about 4 seconds. Users felt like this amount of time was much better than before, when it took about 8 seconds.

DESIRE FOR CLEAR USER FEEDBACK: Users seemed to want more visual details. People stated that they would prefer to know how many cards they had rather than just having the value amount of the cards. Furthermore, multiple users stated that they would prefer to see a graphic representation of the cards. So we changed the text from "Hitting Dealer ...., Hitting Player ....." to "Dealing to Dealer, Dealing to Player". Now the cards are dealt much more quickly and instead of displaying the total value of the cards of each, we display only the individual card values since adding the values of the cards together is an integral part of the game experience.

QPROX v. DIGITAL BUTTON INTERFACE: Some users felt that the qprox buttons were just as effective as actual buttons; however, others felt that they should be able to feel something to capture the natural impulsive nature of gambling. Also, all users agreed that consistency issues need to be addressed with the current button functionality. After some discussion, we decided that QProx buttons only make sense for those actions in the game which normally require hand motions, i.e., hit and stay. So all other buttons, including game reset, bidding, and doubling down would be standard digital buttons.

THE UNFAMILIAR PARTY: Users that were unfamiliar with game felt that some sort of instructions should be available. I felt like this is just an unavoidable problem in that there are simply people who don't know how to play blackjack. I feel like it isn't our responsibility/duty to tell them how to play. If they want to play, they can ask us or they can learn the basic rules elsewhere.

BIDDING: One users stated that they would prefer to have a range of digital buttons for bidding. Hitting buttons made a user think more of the consequences of their actions. We decided to use digital buttons for bidding, not only because users expressed such a preference, but also because, as stated above, it makes sense from an interaction design perspective not to use QProx sensors for such actions.

OVERALL: Most users agreed that a strong audio and/or visual guide would help to make the user interface more intuitive. Some audio or visual prompts might be helpful for inexperienced players. But, in my opinion, similar to the issue of players who don't know how to play blackjack, we should not implement functionality such as tips or advice or things like that. It might make the user experience richer, but the game is not intended to be an instructional tool. Separately, users stated that performance issues need to be addressed for consistency. The QProx sensors are a little cranky. Sometimes it seems they can be either too sensitive or not sensitive enough. I'm not sure if this is an inherent bug or if it is a problem with our implementation.

------------------------------------------------------------------------------------------------------

PROBLEMS/SOLUTIONS

- multiple LCD implementation

We spent a lot of time trying different ways to implement multiple LCDs two basic ways:

1) multiplexer - At James Robinson's recommendation, we initially bought a multiplexer down on Canal Street. Unfortunately, it came with no documentation and we were unable to find any documentation online or anywhere else. After many attempts to figure out how to use the multiplexer, we decided to try another approach, which was the original recommendation of Tom Igoe.

2) multiple PICs - We tried this for a while using a couple of different code architectures. Initially, all the logic code sat on one PIC and it was supposed to simply send out messages to be displayed to the other PIC to send to the LCD. However, sending out text messages is difficult since PIC Basic only supports one character strings. We tried for a while to create an array that would contain all the characters of any string we wanted to display, but couldn't get the array to print out correctly on the 2nd LCD. At this point, we had only a week left to finish the other functionality we wanted to implement like bidding and to get the box buttoned up and looking nice. So we decided to go with a single 2-line LCD.

- bidding

The code for bidding was fairly simple. We created a while loop that looks for a flag that is set only when a user presses one of the bid buttons. Initally though, there were values coming in from the bid buttons as a result of not using the correct resistor in conjunction with those buttons. We kept thinking it was a code problem, but once we were satisfied that it couldn't be the code, we tried different resistors on the buttons and eventually found a type that worked.

- double down/split

We really wanted to initially implement this functionality but simply ran out of time while focusing on what we considered the core things we wanted to accomplish--better messaging, faster gameplay, displaying card values, and bidding.

- automatically determine the value of the ace card

In the first version of the game, there were 4 "1" cards and 4 "11" cards to stand for Aces. Since that's obviously incorrect, we had to put only 4 "Ace" cards in the deck and figure out a way for the game to automatically determine if the player wants to use it as a "1" or an "11". We simply put in code that would check if an "11" would put the player or the dealer over 21. If so, the value is automatically switched to a "1". In our testing, this seems to work just fine.

------------------------------------------------------------------------------------------------------

FINAL USER TESTING FEEDBACK

Confusion over the value of X (X user for "10" but also for dealer hidden card. This was understandably confusing.)
LCD screen was hard to see - needed to be set at an angle
People pressed HIT and STAY - QProx was not extremely intuitive, but was recognizable
Overall, users really liked the interface
Bidding was fairly intuitive
Multiple pushes tried for bidding over single chip value
Button Sensitivity - needed a firm press
New players needed explanation of game, but found the experience easy

The final version was kind of fragile in that basic handling seemed to cause things not to work properly, like the QProx sensors. In a future version, we'd certainly like to tackle the issue of physical fragility. But overall, I think the game was a success and player feedback was generally very positive.

Here's the final code for the 2nd version of the blackjack game.

Group Project 2 - Blackjack 1

2004-11-10T20:15:00.000-08:00

This week, Lamar Hines and I are starting work on Group Project 2. We'd like to use QProx sensors in some kind of game device. We've decided to try to build an electronic blackjack game using a board, Qprox sensor chip, and 2 16x4 LCDs.

------------------------------------------------------------------------------------

Our initial observations:

What tool or device is the action taken on?
All the action takes place on or near a table. This can be seen as players making choices like hit, stay, bid, double down etc.

What is the goal of the activity?
The primary goal of the activity is for recreation and/or gambling stakes.

Observe a person or people engaged in the activity. What are the physical parameters of that activity?
The most significant physical parameters of this activity are the hand movements by the player(s) which indicate visually what they want to do in a given situation.

What does the person engaged in it do with their arms, their legs, their hands or feet, their head?
All movements are generally limited to the arms and hands. General actions include hand motions that indicate a choice as well as reaching and picking up or releasing cards/chips.

How do they change their posture? Where do they need to focus their attention?
General attention is on the game play area and the dealer. Posture doesn't seem to be an integral part of what they do.

Is there a secondary focus of attention (for example, if two limbs are used independently)? What physical elements of the activity make it engaging? What elements make it difficult, painful, or boring?
Players are very limited in physical movement because everything is so heavily focused and dependent upon staying stationary and using the hands.

Do the action multiple times (perhaps 100 times), or have someone else do it. Record the action, with a video camera, or sensors feeding a graphing program, or in some other way. What patterns appear when the action is repeated?
Reaching and taking with hands and arms is the most observed actions after observing the situation.

What are the physical characteristics of the medium that you have to take as given?
We plan to take different elements like the idea of hit me, stay, and play and incorporate physical actions that will be recognized by the QProx sensors.

------------------------------------------------------------------------------------

We have the basic code to send "Hello World" to an LCD, but are running into difficulty getting it to display the text. We've spent a lot of time getting the code and the wiring set up properly, but have not so far been able to isolate the problem. We are going to try to get some help from Michael Schneider and from Eric Fino, both of whom have worked with LCDs and/or QProx chips before. Eric Fino has some documentation from his last group project, and it has been helpful but doesn't indicate how exactly the LCD should be wired up to the PIC/board. Eric's project: http://stage.itp.nyu.edu/~ejf251/pcomp/elevatorwaitspace/ .

------------------------------------------------------------------------------------

After working with James Robinson and attending his drive-by on LCDs, we were able to get the LCD wired up correctly and get it working. Next, I will concentrate on translating the rules of blackjack into software.

------------------------------------------------------------------------------------

We have a basic blackjack game working which deals random cards to a dealer and a player. After dealing two cards to each, the player must decide to hit or stay. Upon staying, the dealer automatically either takes a card if the dealer's total is below the total of the player or stays if the dealer's total is already higher than the player's total. Right now, there is no other game functionality like bidding or doubling down.

------------------------------------------------------------------------------------

We did some play-testing and general user feedback was positive. Many people felt the game play was a little too slow and many also thought they were supposed to "press" the QProx buttons rather than just make a hand motion directly over them. So a little explaining was necessary to have users play the game the way we envisioned.

Here's the final code for Project 2 blackjack.

Lab Assigment: Talk to a MIDI device

2004-10-24T19:34:00.000-07:00

I'm just getting started on the Midi lab. I have to purchase a 5-pin DIN female connector (MIDI connector) and will start working on it again on Tuesday.

-----------------------------------------------------------------------------------------------

I got the supplies and found some code on Tom Igoe's site. In a nice turn of events, gettting this thing working was the easiest lab so far.

Here's the code for sending out to a MIDI device and modifying that signal with a variable resistor:

URL: http://stage.itp.tsoa.nyu.edu/~tigoe/pcomp/code/archives/midinotes.bas

DEFINE OSC 20
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 15 ' Set sampling time in uS
' set up serial UART registers:
define HSER_RCSTA 90h ' enable the receive register
define HSER_TXSTA 20h ' enable the transmit register
define HSER_BAUD 31250 ' set the baud rate
TRISA = %11111111 ' Set PORTA to all input
' Set up ADCON1
ADCON1 = %10000010
' declare an array of 12 word variables:
pitch var byte(12)
' declare other variables:
note var byte
ADCVar var word
' the 12 elements of the array called pitch are the 12 notes of a scale:
pitch(0) = 60 ' middle C
pitch(1) = 61 ' C#
pitch(2) = 62 ' D
pitch(3) = 63 ' D#
pitch(4) = 64 ' E
pitch(5) = 65 ' F
pitch(6) = 66 ' F#
pitch(7) = 67 ' G
pitch(8) = 68 ' G#
pitch(9) = 69 ' A
pitch(10) = 70 ' A#
pitch(11) = 71 ' B
main:
' My potentiometer gave a range from 0 to 1023:
ADCin 0, ADCVar
' convert to a range from 0 to 11:
Note = ADCVar / 100
' play note:
hserout [$90, pitch(note),$40]
pause 250
' noteoff:
hserout [$80, pitch(note), $00]
goto main

Lab Assignment: Serial output and Talking to Processing

2004-10-17T13:58:00.000-07:00

I had some initial trouble with this code as I'm not taking ICM this semester and so am not familiar with Processing. Fortunately, John Schimmel was around to help me out and answer questions.

------------------------------------------------------------------------------

code for Processing

float[] data = new float[2]; // create 2 space data array. 1) Potentiometer and 2) photocell
int index=0;
float xpos;
int bck;

void setup() {
size(255,255);
beginSerial(); //begin serial communication thing
serialWrite(65); //talk to PIC . like saying hello
}

void loop() {
background(bck);
fill(0,0,244);
ellipse(xpos, 100, 50,50); //movable circle
}

void serialEvent() { //automatic serial listener
data[index] = serial; // save messages to data array
index=index+1; // increment serial counter
if (index==2) { // both messages received
xpos = float(data[0]); // rename the first message to xpos
bck = int(data[1]); //save photocell value
serialWrite(65); // responsd back to PIC
index = 0; // reset serial counter to zero
}
}

-----------------------------------------------------------------------------------------

code for PIC

input portc.7
output portc.6
inputVar VAR byte
sensorValue VAR WORD ' Create variable to store result
photoValue VAR WORD
' POTENTIOMETER SETUP'
Define ADCIN parameters
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 50 ' Set sampling time in uS
TRISA = %11111111 ' Set PORTA to all input
ADCON1 = %10000010 ' Set PORTA analog and right justify result
PAUSE 500 ' Wait .5 second'

-------------------------------------------------------

main:

ADCIN 0, sensorValue 'potentiometer variable
ADCIN 1, photoValue 'photocell
sensorValue = sensorValue/4 'divide the value because it's too big'

----------------------

' THE LISTENING CODE - puts message into inputVar
serin2 portc.7, 16468, [inputVar] 'listening for potentiometer value
if inputVar=65 then ' if received message is 65, then respond to processing
gosub blink 'blink LED'
usage: serout2 dataPin, mode, [data]
serout2 portc.6, 16468, [sensorValue,photoValue] 'talk to processing
ENDif

goto main

---------------------------------------------------------------------------------------------

blink:

high portd.2
pause 250
low portd.2
pause 250
return

Group Project 1 - Chair massager

2004-10-10T13:59:00.000-07:00

The group project has gone well so far. We finally have the chair massager working the way we want. It's been a fun project. It took a while to figure out how the wiring worked inside the massager and then to figure out how to bypass the controller that came with it and set it up with a switch that turns on automatically when you sit down. Thanks to a couple of 2nd year students, we sorted it out. We still need to solder a couple things in permanently and then to hide all the wiring inside the massager, so that only the wire that plugs in to the power source is coming out of it.

The code for the PIC was very simple. It was a simple main method with a pause at the beginning, then a specified number of milliseconds (around 8 minutes) until it sent a signal to the relay switch which turned on the massager.

We set up the chair massager in the computer lab without telling anyone what is was or how it worked. We recorded about 4 people sitting in the massage chair. Each has a different response to it. 3 of the people were surprised when the chair started vibrating (of course) and decided to use a different chair. One person wasn't surprised at all since he saw the wiring and was expecting something to happen.

I don't think our idea of having the massage chair sitting in the computer lab as a surprise was a good idea. I think the chair massager should have been set up in the lounge area and should have had some explanation attached to it. Rather than having it in the computer lab, I think it would have been nice to have it on a chair in the lounge area. When people sat down, they would get a nice massage for maybe 15 min. The massager would automatically shut off then and be ready for the next person to get a massage. This would seem to be a much more logical and practical use for the chair massager--a tool for taking a break and relaxing in the lounge area.

Lab assignment: servo/analog out

2004-10-04T19:32:00.000-07:00

Lab 4 was interesting. It took a little time to get my head around it and I'm still figuring out the syntax of the language, but I got it done and it works properly. I've also helped a couple other people with their stuff and explaining things to others always helps me to learn it better.

Here's my code from Lab 4:

'****************************************************************
'* Name : lab_4_1.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2004 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 10/6/2004 *
'* Version : 1.0 *
'* Notes : *
'* : *
'****************************************************************
DEFINE OSC 4
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 50 ' Set sampling time in uS
sensorValue Var word ' Create variable to store result
start:
pulseWidth var byte ' set up constants with the minimum and maximum pulsewidths
minPulse CON 50
maxPulse CON 250
refreshPeriod CON 20 ' set up a constant with the time between pulses:
pulseWidth = minPulse ' set an initial pulsewidth:
pulseRange var word
pulseRange = maxPulse - minPulse
main:
Low PORTC.3 ' take the output pin low so we can pulse it high
adcin 0, sensorValue
PulsOut PORTC.3, pulseWidth ' pulse the pin
Pause refreshPeriod ' pause for as long as needed:
pulseWidth = minPulse + (pulseRange * (sensorValue/10)) / 100

GoTo main

-----------------------------------------------------------------------------------------------

'****************************************************************
'* Name : lab_4_2.BAS *
'* Author : DAVID YATES *
'* Notice : Copyright (c) 2004 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 9/26/2004 *
'* Version : 1.0 *
'* Notes : *
'* : *
'****************************************************************
start:
pulseWidth var byte
' set up constants with the minimum and maximum pulsewidths
minPulse CON 50
maxPulse CON 250
' set up a constant with the time between pulses:
refreshPeriod CON 20

' set an initial pulsewidth:
pulseWidth = minPulse
main:
'take the output pin low so we can pulse it high
Low PORTC.3
' pulse the pin
PulsOut PORTC.3, pulseWidth
' pause for as long as needed:
Pause refreshPeriod

' change the angle for the next time around:
IF pulseWidth > maxPulse Then
pulseWidth = minPulse
Else
pulseWidth = pulseWidth + 1
Endif

GoTo main

Lab Assignment: Variables and Analog Input Analog in; tracking changes with variables; practical jokes

2004-09-25T18:51:00.000-07:00

Lab: Variables and Analog Input

This lab was rather time-consuming and indeed I did not finish all of the steps. But I did finish most of them. Here's code for steps 1-3.

Code for Step 1:

'****************************************************************
'* Name : LAB_3_1.BAS *
'* Author : DAVID YATES *
'* Notice : Copyright (c) 2004 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 9/24/2004 *
'* Version : 1.0 *
'* Notes : *
'* : *'****************************************************************
' PicBasic Pro program to display result of' 10-bit A/D conversion through serial at 9600 baud'
' Connect analog input to channel-0 (RA0)
' Define ADCIN parameters
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 50 ' Set sampling time in uS
ADCvar VAR WORD ' Create variable to store result
TRISA = %11111111 ' Set PORTA to all input
ADCON1 = %10000010 ' Set PORTA analog and right justify result
Pause 500 ' Wait .5 second

main:

ADCIN 0, ADCvar ' Read channel 0 to adval

' print it to serial out, 'with linefeed and carriage return (10, 13)
serout2 PORTC.6, 16468, [DEC ADCvar, 13, 10]

GoTo main

-----------------------------------------------------------------------------------------------

Code for Step 2:

'****************************************************************
'* Name : LAB_3_2.BAS *
'* Author : DAVID YATES *
'* Notice : Copyright (c) 2004 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 9/24/2004 *
'* Version : 1.0 *
'* Notes : *
'* : *'****************************************************************
' PicBasic Pro program to display result of 10-bit A/D conversion through serial at 9600 baud'
' Connect analog input to channel-0 (RA0)
' Define ADCIN parameters
DEFINE ADC_BITS 10 ' Set number of bits in result
DEFINE ADC_CLOCK 3 ' Set clock source (3=rc)
DEFINE ADC_SAMPLEUS 50 ' Set sampling time in uS
ADCvar VAR WORD ' Create variable to store result
TRISA = %11111111 ' Set PORTA to all input
ADCON1 = %10000010 ' Set PORTA analog and right justify result
Pause 500 ' Wait .5 second

main:

ADCIN 0, ADCvar ' Read channel 0 to adval
' print it to serial out, ' with linefeed and carriage return (10, 13)
serout2 PORTC.6, 16468, [DEC ADCvar, 13, 10]

GoTo main

-----------------------------------------------------------------------------------------------

Code for Step 3:

'****************************************************************
'* Name : LAB_3_3.BAS *
'* Author : DAVID YATES *
'* Notice : Copyright (c) 2004 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 9/24/2004 *
'* Version : 1.0 *
'* Notes : *
'* : *'****************************************************************
switchVar var byte
input portb.4
output portb.7
pause 500

main:

switchVar = portb.4
portb.7 = switchVar

goto main

--------------------------------------------------------------------------------------------------

I did further work on the other steps in the Lab but did not save them out separately from the machine I was working on.

Lab Assignment: Digital input and output using the PIC microcontroller

2004-09-18T13:25:00.000-07:00

Lab: Digital Input and output using the microcontroller

I connected and LED and a 220k Ohm resistor to each of the pins at portd.0 to portd.7 on my PIC and used the following code:

-------------------------------------------------------------------------------------------------------------------

main:

high portd.0
pause 500
low portd.0

high portd.1
pause 500
low portd.1

high portd.2
pause 500
low portd.2

high portd.3
pause 500
low portd.3

high portd.4
pause 500
low portd.4

high portd.5
pause 500
low portd.5

high portd.6
pause 500
low portd.6

high portd.7
pause 500
low portd.7

high portd.8
pause 500
low portd.8

goto main

-------------------------------------------------------------------------------------------------------------------

Next we were supposed to use a switch to turn on/off another LED. This worked fairly easily and worked the first time I tried it. Here's the code:

-------------------------------------------------------------------------------------------------------------------

input portb.0
output portd.1

main:
if portb.0 = 1 then ' if the switch is closed on pin RB0
low portd.1 ' set pin RD1 low
else
high portd.1 ' set RD1 high
endif
goto main

-------------------------------------------------------------------------------------------------------------------

Lab assignment: Basic Electronics

2004-09-11T17:14:00.000-07:00

Lab 1

I finished almost all of Lab 1 today. I went shopping for all the supplies I needed and then was at the shop for a few hours. Fortunately, there were a couple of people there who were able to answer my questions when I had trouble. I'm still not sure I understand everything I did today. My stuff works, but I need to make sure I understand exactly why it works. I enjoyed it more than I expected I would. When I came home I watched "This Old House" and really enjoyed it. At the moment I feel like I want to learn how to make and fix all kinds of stuff. I hope this feeling continues.