Final TUI Helper Points

As a final post, I wanted to collect all the problems and questions I ran across during the semester and address them for future class takers. Here, in no particular order, they are:

- The Handy Board, although a big headache, was very helpful for our project. Really try to take advantage of the online documentation -- available at http://www.handyboard.com/techdocs/hbmanual.pdf as well as the little information packet in the TUI lab

- On the same tangent as the Handy Board, I would advise _against_ using the internal power source of the device. We tried this at first, and since we didn't have a great understanding of resistors, we were draining it too fast. This then lead to the Handy Board not working for us. Try to put external batteries in an outside circuit and just have the Handy Board on a circuit to switch a relay on/off for your purposes.

- Magnetic Switches - as used on doors to a house - were great as an input device. They simply needed a COM and NO wiring to the digital input sensor and worked wonderfully.

- Use the resources of the department -- the other graduate students, professors, etc. They are there willing and able to answer your questions.

That's about it. If I reflect on more later, I will add it then. Remember to have fun! This was one of the most enjoyable classes I had. Remember to challenge yourself by stepping outside your comfort zone -- that's when you learn the most :)

Relays, Electromagnets, and Handyboard...oh my.

Music Combat is into the full swing of electronics now. Ask me what a relay is...a resistor...a bread board, I now know. Much of our time has been spent googling EE terms and flipping back the pages of our Physics books to remember Ohms Law, DC vs. AC, and more.

So, where is our project now, you might ask? We are still working with the Handyboard, trying to get the motor outputs to power our electromagnets (nails wrapped in thin gauge copper wire.) Unfortunately, we thought we had the program figured out. There were little libraries written to control the output of the motor current, to reverse the polarity of the outputs, etc. We wrote a short program to turn on each of the four outputs and then reverse the polarity of the four outputs (so as to 'pop' off our notes.) We got this working before class, weakly, but then when it came time for the proof-of-concept demonstration, the handyboard was not our friend. As it turned out, trying to power four electromagnets all from the poor little handyboard power was too much to ask of it. So the handyboard kept dying. Our solution? We needed to add relays into the mix, as well as external voltage/power (i.e. batteries) and rewire the darn thing.

So our current model. We hooked up a 9v battery and our electromagnet in a circuit with the purchased relay. (just a normal 9volt, DC relay you can purchase at any RadioShack or electronics shop.) We used the NO (normally open) and Com connections for this circuit. We then connected the coil to the handyboard inputs. Setup as shown.

After testing the connections worked well -- which they did! -- we soldered the pieces together with the solder iron and material in the TUI lab. This ensured that our connections would stay in place and not slip off as we moved things around.

So what next, you ask? Well, we have to make two more relay circuits to finish out the 4 motor outputs on the handyboard. Our next feat will be attempting to use some of the other input/output ports on the handyboard to input connections from our composer box with the use of reed switch relays. We'll see how that goes...

Handyboard

Coming into class today, we had experimented with creating electromagnets out of wire, batteries and 3" nails. Online, I found a parallel relay board with 8 separate connections for power DC switching we thought we could purchase and use with a computer. Then during class, it was pointed out that several modern day computers no longer have the serial port required for the relay, and that usb relay boards would run us about 180 dollars. Ouch. So back to the drawing board -- the nail, wire, battery thing was still O.K., but what kind of system could we use to interface between the current and a computer where we can code?

The answer: The Handyboard. Luckily, Orit, Mike Horn & Prof Jacob pointed us in the direction of this little gadget. After playing with it in class awhile, and then coming home to pour over the documentation we decided this was just the ticket we need for our proof of concept implementation. The Handyboard has 4 separate DC Motor input/output pairs. For our purposes, we can put in two ends of wire attached to our nail and a load (so the battery in the Handyboard doesn't go BOOM.) Using this little device, we can then switch between on/off, and power forward or backward (basically polarity switching ability.) Also included in the interactive C libraries that interact with the device are things to play tones at certain frequencies. For our purposes, if we were to program each of the possible note frequencies into the library, we could not only stick on the note to the staff (electromagnet/nail) but also play it's correct tone!

From here, we have downloaded the interactive C and need to begin working with the code. We also have to create four separate nail/electromagnets to use for the proof of concept. Hopefully, by next Monday's class, we will have 4 separate stickable spaces on our staff board that can have notes applied, pop off, and even sound the correct note. Awesome!

Further down the TUI path...

Electromagnets. Who would ever think a Computer Science major would be playing with electromagnets for course work? Only in the TUI World.

We are further along in our design work, now, far past the stage of playing around with Top Codes and clay. We had several changes of heart as to what our project would actually be. We began with a concept of a single pad where a user -- specifically a novice musician -- could play with beats, notes, rests, and meaures to better understand music. This idea was well received at first, and we were excited. However, with further investigation we realized this notion was a bit too GUI and not enough TUI. We didn't have enough real world, physical properties integrated with our design and the same basic concept could have been implemented on a computer screen. Back to the drawing board.

On to Music Combat. Our settled on, final design project is a battleship-inspired game. This idea was the best of all our initial concepts because of the lack of buttons and GUI known interfaces. Music Combat still attracts the same users -- unskilled music students, most likely children. Two users interact with the game much as with the game battleship. The noticable difference is the music component of one player taking the 'composer role' and one the 'musician role.' At first, we thought of integrating LED indicators and play buttons in order for the users of music combat to switch roles and indicate turn taking. Later, with critique of class and professors, we switched this notion to simply the composer token -- an RFID tagged guitar that may be placed in the user's music combat box to indicate their turn in the game to compose or attempt a tune. This got us even further away from the GUI notions so hard wired into us from years of computer use!

And now the implementation. We've seemed to settle on the use of electromagnets for this project as our one, solid technological component. This has been a fun diversion and interesting learning opportunity since none of the three of us have any prior knowledge on the subject. So began hours of goggling and reading up on the basics of building and using electromagnets. Our initial trials began with a run to Home Depot and a basic implementation of a nail, wrapped with some copper wire, attached to a battery. Unfortunately, the first nail used was not of the correct composition and was permanently magnetized by the battery current. Whoops. Lesson learned, onto the correct type of nail. After getting that basic idea working the major question becomes: how do we get the computer and electromagnets interacting? The answer, I believe, lies in a parallel port relay board. With the use of one of those, we can have the software on a computer hooked up to the board, which is in turn hooked up to the batteries and nails. This way, we can tell the computer with some code when to turn on/off or switch the polarity of our circuits and thus, when to have the notes/rests on our staff stay on or pop off.

That is an initial preview to our project. Stay tuned for part two of this entry where I will discuss further our challenges, more on how we reached our project, and what components we utilized to get to this point.

Assignment 2

Kelly, Meredith, and I decided to delve into the world of computer vision via Mike Horn's TopCode. It's no laser cutter - but we're working our way into the Tangible User Interface thing slowly. Our goals were to get a feel for the TopCode project and see for the first time how java code, on a screen, in the 'regular' computer world came out into the physical world to interact with everyday objects like our felt cutout notes.

There were a handful of things that went well. Kelly did an _exceptional_ job cutting out the feltpad notes - a quarter, half, and whole note. Each of the teammates brought a talent to the group -- Kelly's cutting ability, Meredith's access to the TUI lab, and my laptop computer complete with a Window's computing environment. Also going in our favor were having Orit and Mike Horn around to pester with questions and our use of the TUI lab's camera.

Some things that were challenging -- finding a printer in Halligan to get the TopCodes on paper. We had tried to print them at home, but couldn't find where in the code to create them. It was with Mike's help that we realized that we had to run the TopCodePrinter class from his code in order to create them. For future students reference:

java -cp topcodes.jar topcodes.TopCodePrinter

then CTRL + P to print

Once we had that worked out, it was easy to cut out the little circles and attach them to our felt notes. In the TUI lab, we made use of the digital camera and snapped some shots of our notes. As a word of caution when using TopCodes - make sure the codes are photographed clearly without reflection or blurring. Once we had the .jpg files to use, we again were stumped on how to feed them into the java code. It was with a tip from Mike again that we realized the DebugWindow was created for this purpose. With the following command:

java -cp topcodes.jar topcodes.DebugWindow

A window will pop up. From there, you can type CTRL + o to open one of your saved .jpg files. The selected jpg then appears in the window and in the cmd window the corresponding TopCode number is displayed. From here, we tweaked the code to specifically call out what notes the program was seeing - a quarter, half, or whole note.

Overall first impressions:

TopCodes could be a very useful piece of our TUI design, however the code will take some studying to learn all its functionality. Mike did a great job of writing it -- not so great a job of documentation (freely admitted on his part and suggested that anyone out there with some free time should be welcome to comment it.)