At this present moment, the wiring for the ribbons and force sensors have only been handled. I was a bit hesitant on placing a decent amount of effort pertaining to the flat ribbon connections, as I am awaiting an order for FCI Clincher connectors. However, as time is passing, I decided to continue the process through the utilization of DIP sockets with soldered wiring connections to the Arduino Mega. I am hoping to either make a large dent in the programming this evening or have the application in a state where further programmin will be minimal.
As this coming week pertains to play testing, the focus of my work was geared towards the development of a prototype structure for holding the ribbon sensors. While wood will utilized for the final product, foam was chosen for this particular component of the work, as the ability to cut this particular type of material would allow for some experimentation for both structure and building plan.
Upon experimenting with various sizes pertaining to the width of each panel, I determined that 2 inches would provide a (personal) comfortable width. Thereafter, the cutting of each panel commenced.
After building the initial octagon structure, I noticed that placing the body against myself created some ergonomic, playing issues. The proximitiy did not allow one to comfortably glide one's hands up and down the object. In light of this situation, I decided to create a block across the backside of the panel. This shoulder-resting addition created further distance between the arms/hands and panels, allowing a more comfortable motion.
After handling this mentioned item, I doubled the length of the structure, as the sitting-style instrument required this addition
Prior to the play-testing, I attempted quickly setup the Arduino Mega in conjunction with a few ribbon sensors. Unfortunately, I was unsuccessful in the attempt; additional time would be required for this component. However, all ribbons, potentiometers, and switches were added for the event.
At this particular moment, I'm behind in schedule, as I cared to have the programming component will all sensors connected. Perhaps next week?
As I have maintained an interest in my previously mentioned idea within last week's blog, I continued to explore the creation of a musical instrument controller. As previously mentioned, it will focus on sound generation and manipulation via ribbon controllers. Furthermore, the device will be in the shape of a long, narrow, cylindrical octagon. It must be noted that the user will play the device sitting down, with one panel (back panel) resting on the individual's shoulder.
Regarding the build, three right-side panels will individually contain three long, ribbon sensors for sound generation, where sliding up/down the panel will control tone pitch. Three long, force-sensing resistors will be individually placed underneath each ribbon sensor, controlling the amplitude of the triggered tone.
The three left-side panels will individually contain two medium-length ribbon sensors, where they will globally control time-based, dynamic, and spectral effects of the generated sounds.
The front panel (opposite side of the user) will have four potentiometers and latching switches. Regarding the potentiometers, one pot will manipulate wavetable positioning for sound generation (speculative) and the three other pots with individually control the pitch range of the long, right-sided ribbon sensors (similar to stringed instrument tuning). The three latch switches will 'latch' the sound controlled by the three, right-sided ribbon sensors, where the user's hand can leave the ribbons and continue audio playback.
It must be noted that current concerns pertain to the fabrication of the device, as I need to investigate the construction of a tilting, base stand (possibly a yolk). Additionally, I'm under the impression that building this device in a modular fashion would be beneficial for removing and troubleshooting components.
The system design will be fairly straight forward, where the sensors, switches, and potentiometers will be connected to an Arduino Mega. Thereafter, the Mega will communicate (serial) with OS X. More specifically, Pure Data (within OSX) will recieve data values and handle the audio generation and manipulation. Lastly, Pure Data will output the generated audio and push to OS X's DAC, followed with the utilization of a loudspeaker setup.
BILL OF MATERIALS
ASSEMBLY - WORK IN PROGRESS
After wrestingling between two musical, final project ideas, I decided to settle on one that would be feasible within the given time period. For this work, I would like to create a lengthy, stand-up, octogan-shaped controller containing ribbon cables. Furthermore, these sensors would be connected to a device in one-of-two ways: an Arduino which is connected to OSX or a Raspberry Pi (utilizing the GPIO). Regarding sound generation and manipulation, I will be designing and utilizing a Pure Data patch.
Regarding the utilized ribbons, one side will be comprised of three long ribbons. Furthermore, these three strips will be individually stacked on top of long pressure sensors. This 3-ribbon setup will control the sound generation. On the left side of the controller, six ribbons (without pressure sensors) will be placed in a similar manner, but "half-the-size" to have a symmetrical property to the right side of the instrument. These six ribbons will be utilized for sound manipulation, where the manner of manipulation will be handled in a global manner.
It must be noted that three switches will be attached to the front side of the controller, where they will act as a means of "latching" their coordinating "sound-generating" ribbon. The thought behind this aspect pertains to the ability to sustain one-to-all sound generators.
While the sketch grants a rought idea on the concept, prototyping the device will give further details pertaing to the intrument's physical size and ribbon-to-controller ratio. Furthermore, I am speculating that the base of the controller would benefit with an "adjustable" characteristic, where the tilt could be handled. Furthermore, it must be noted that users would be sitting down on a chair to play the device.
For the midterm project, Joung-min Choi and I were partnered for the work. After discussing potential project ideas on three separate occasions (two before our "Pre-Midterm" class and one afterwards), we decided to pursue an enclosed, interactive housing structure, where a user could view the enclosed house windows through the utilization a "tubular" viewer. And upon directing the viewer on a particular window, the room would light-up, revealing an individual (cutout) within its residence.
It must be noted that the nature of this project stemmed from ideas pertaining to shadow-play. Further exploration within the collaborative process led to the final concept, where a user can participate in an act of voyeurism towards a house filled with mischisevious activities.
***Disclosure: As our collaboration contained a hefty amount of coordination, evaluation, and re-adjustments, the following information is a rough guide for the timeline of the work. This issue with my documentation is further addressed at the end of this blog posting.***
Our initial work began with the prototyping a room, where a cutout of an individual could be viewed behind tissue paper through the utilization of backlighting. Upon viewing this current setup, it was determined that the inverse of the cutout would produce a more interesting visual aesthetic; furthermore, the inverse would be further inline with the idea of shadow-play.
Upon determining this approach to lighting, we began planning the fabrication and Arduino programming process. The necessity for creating a detailed housing structure led to the determination of utilizing a laser cutter for the work. As I had not taken the Intro to Fabrication course, nor recieved the saftey session for the workshop, Joung-min took the lead on the design and construction of the housing. Within this particular process, I continuously took note of Young-min's design method for laser cutting, picking up techniques along the way. Perhaps the most interesting aspect of this design-work pertained to the utilization of a photograph containing the front-side of a building. This particular picture was layered within AutoCad, where the cut-lines were determined by the structural characteristics of the pictured building.
Upon completing the design of the front-side of the housing structure, we headed to a local supply shop to pick up material for cutting. After perusing through the store, Joung-min determined that a thin, fiberboard sheet could serve useable material for our project. We then had the shop cut our sheet in two, and then proceeded back to the ITP facilities
Within the laser cutting process of the building, I began testing the utilization of an accelerometer, as we speculated that the sensor readings could be applied to the activation of a specified room's LED. Upon utilizing and manipulating sample code provided within the Physical Computing website, I noticed that tilt could be easily identify positionings related to the housing structure's center-column rooms. However, I also noticed that finding any rooms with a left or right directionality (first and second column) required the rotation of the sensor. At that particular moment, I suggested (to Young-min) that designing a "tubular" viewer which forces the user to rotate the device when panning should be feasible within our timeline (I was wrong). It must be noted that I did attempt to utilize the IOT 33's gyrometer capabilities, but determined that appropriating the gyro's values into the work might prove to be too challenging within our timeline. This was a decision that I later regretted.
After the housing pieces were cut, Young-min began gluing the structure together. Thereafter, she began the prototyping phase for the enclosure (carboard).
During the previously mentioned processes, I began programming the LED lighting in conjunction with the accelerometer. Within this work, I relayed information regarding the approach to our programming, where creating functions to handle specific aspects of the work created a "cleaner" and more navigable script. Regarding this programming, one function handled the acquitision of accelerometer values, another function handled the "printing" of values for monitoring, and the last two handled the activation/deactivation of LED lighting based on accelermoeter coordinates.
Some time after this mentioned work, we headed to another local shop to pick up foam-core boards to create the rooms. After picking up this material, Joung-min began measuring and cutting the board. Meanwhile, I began cutting perfboards for housing LEDs for the rooms. The decision to utilize this type of board pertained to its ability to solder headers, where the wires and room LED could be easily mounted. Upon finishing the room and perf board construction, the wiring and mounting of the perf boards commenced.
It must be noted that prior to and during the previously mentioned processes, work pertaining to prototying the viewer and positioning came to the forefront. Upon finalizing these spec's, Joung-min began laser cutting, following with the gluing the enclosure.
After handling the previously mentioned items, focus pertained to the "tubular" viewer. Though we had lightly reviewed the fabrication of this component within the development of our work, finalizing a proper means of creating this component had not been solidified. Despite our efforts, we were unable to resolve the issues pertaining to our setup, where the rotation of the viewer would be required for triggering LEDs on the left and right sides (columns) of the building. As we were runnning short on time, we decided to tape the sensor to the end of the viewer.
It must be noted that at some point within our collaboration, it was determined that the cutouts had a stonger appearance in front of the tissue paper-covered rooms. Furthermore, we also determined that utilizing reflective tape would be assistive in the projection of light. Thus, it was added to the back of the enclosure.
The following pictures display our submitted project.
While the midterm project provided a multitude of "ups" and "downs," working with Young-min was an enjoyable experience. As I had never collaborated with an individual with an architectural background, the opportunity to grab techniques, approaches, and perspectives from this area of study was delightful.
With that said, the most valuable learning experiences within this work pertained to two significant problematic issues: underestimating fabrication components and maintianing documentation. Regarding the former, my understanding of programming to fabricating objects has a extremely large contrast pertaining to prior experiences. As my background pertains to computer science, I should have allocated time to understand and utilize the IOT 33's gyrometer in conjuction with its accelerometer. Unfortunately, I convinced myself that fabricating the viewer would be much easier. The final result proved that I was incorrect.
Regarding the latter issue, I was not documenting our work during the production process. Though pictures were taken along the way, recalling the detailed events throughout the work became difficult when writing this blog post. While this issue caused a large amount of frustration when piecing this writing together, it will ultimately serve as a posting in the list of "Never-do-this-again-at-ITP."
Week 6 pertained to the utilization of an Arduino in conjuction with P5.js. This handling of serial communication was rather foreign to me, as I was not aware that one was able to utilize a microcontroller in conjuction with a web browser. While my lack of experience in this area might have led to major difficulties within the lab project, the provided information within Week 6's material provided a great step-by-step tutorial for this manner of connection.
As I chose to not enroll in Introduction to Computational Media due to my prior academic experiences, I did not possess any P5 animations to utilize with the IOT 33. In light of this situation, I chose to create a different project. Specifically, the thought of utilizing "knobs" (Arduino with potentiometers) for "drawing" (P5.js) led to my interest of an "Etch A Sketch" project.
I initially drew upon last week's project as a reference point. Upon viewing the prior Arduino script, I began creating a new one for this work. In addition to the mentioned potentiometers, I decided to include a push-button to "erase" the screen. Thus, the utilization of a digital pin would be necessary. Regarding serial output, the captured values were formatted in a value-comma manner, terminating with a new-line. This choice was made in light of the lecture material.
It must be noted that I modified my "smoothing" function to properly handle analog values in accordance to the input argument. The prior week's work was only taking one analog value, adding this value twenty times to itself, and then dividing the sum by twenty. Essentially, this prior week's function did not do anything.
Regarding the IOT 33 circuit, a diagram was created in accordance to the project needs. Furthermore, the physical component was built in relation to the diagram.
After re-reviewing the P5 lecture material pertaing to serial communication, I began the creation of the browser's "Etch A Sketch." The initial portion of this journey was met with a significant hurdle. I failed to realize that the utilization of p5.serialcontrol was not compatible with OSX's Safari. I may have missed this component within class lecture or the provided website's material. Upon resolving this situation and establishing communication, I began handling the incoming Arduino data within the serialEvent function.
For each captured line, the string was split into a 3-element array in accordance with the commas. Thereafter, each array value was stored within their respective variable. Within the draw function, a circle object utilized the potentiometer variable values for X/Y positioning. It must be noted that these values were divided by 2 in accordance with the 512x512 canvas size. Regarding the final push-button value, a conditional statement handled the triggering of the a black background redraw if a HIGH value was seen. In this situation, the screen would be cleared.
The following video demonstrates the final work:
For Week 5's project, we were tasked to revisit a problematic project. In my particular case, the prior week's work contained issues pertaining to the reading of potentiometer values from the IOT 33's analog inputs. Specifically, I had difficulty in the management of potentiometer voltage fluctuations.
As opposed to utilizing the Arduino's tone function for sound generation, I decided to utilize Max MSP for this aspect. This decision did not only reflect upon Max's flexibility in oscillator generation and manipulation, but also pertained to the review of programming for this environment; many years have passed since my last experience.
In light of this programming pursuit, I chose to immediately dive into the Max environment. For sound generation and manipulation, I created a patch that has two major sound components: square wave generation and amplitude modulation. Regarding controls, the oscillator has frequency and level control. Additionally, the cosine wave, utilized for amplitude modulation, has frequency and depth options.
After building these mentioned components within the patch, I then tackled the handling of serial communication from the Arduino. My experience within this area is extremely limited. Thus, I utilized YouTube and Max's website for information. I must note that the YouTube channel "Programming for People" offered a step-by-step tutorial for this manner of communication.
Upon building the Max patch, I handled the re-programming of the Arduino script. As I decided to utilize a potentiometer for frequency handling, differing from the prior utilization of push buttons, my script needed to be modified. Furthermore, amplitude modulation control was to also be handled by potentiometers. In this particular scenario, programming needed to include the utilizaiton of four potentiometers. Upon modifiying this aspect of the script, I modified the averaging function, where an argument for the analog input's received voltage would be averaged/returned after recieving 20 samples. It must be noted that this particular function assisted with the fluctuating readings.
After building the Arduino script, I modified my original circuit to include the utilization of the mentioned four potentiometers.
Thereafter, testing commenced. I initially found difficulty with the communication between the Arduino and Max environment, as I was not recieving any data. This problem was speculatively resolved through the implementation of a 30-millisecond delay within the Arduino loop and the re-adjusting of the static serial port within the Max patch. Upon recieiving data within Max's environment, I began to further manipulate the range of values to be utilized for the frequency controls (tone and amplitude modulation components) in an attempt to create a more "playable" instrument.
During this latter process, I took notice of the potentiometer fluctations, as they had not been fully remedied. In light of this issue, I adjusted the patch to average incoming values in a similar manner to the Arduino script. This appeared to greatly assist with this problem. However, minor latency was now present with the controls from the Arduino to the Max patch. At this moment, I decided to "walk-away" from this new issue, as the mentioned latency was less problematic than the potentiometer fluctuations
After handling all-of-the-above, I was finally able to document my creation. It must be noted that I utilized Max's Presentation mode to create a cleaner GUI. The following video is a demonstration of my work:
Though a great leap was made in the handling of potentiometer reading's, the newly introduced latency is an issue. I'm under the impression that the averaging within Max is causing this problem. It must be noted that I attempted to utilize Arduino's Constraint function to assist with the potentiometer handling. However, I was unable to find a proper way to implement this function. Perhaps with further programming experience, I might be able to find a way to resolve the prior statement.
All-in-all, this new interation of Week 4's project saw greater results. I believe that my choice to utilize Max not only assisted with generation and handling of sound, but also served as a new starting point for further work within the Max environment. Furthermore, it provided a great re-introduction into the receiving and handling of serial communication from an Arduino.
For week 4, the comparison between pulse modulation and frequency modulation was covered within lecture. Furthermore, we were asked to apply these lecture concepts for our assignment. As our in-class demonstration involved the utilization of the tone function in conjuction with a mini loudspeaker, I chose to base my project within this same area.
My initial thoughts for my project pertained to a playable instrument. As my experience is limited with electronics, I chose to utilize push button switches, captured by the IOT 33's digital I/O, for triggering tone generation. Additionally, as I wanted to implement pitch shifting and "final output" control, I decided to implement potentiometers for these mentioned items. Regarding each tone generator's frequency, I utilized octaves for each sequential button, beginning with the first button's base of 440 Hz. Furthermore, as a potentiometer was being utilized for pitch-shifting, the recieving analog input's values required "math" for synonymous shifting from one button to the next:
The multiples pertaining to each button granted synonymous ranges, where base and max pitch shifting were "equal" from one button to the next.
Regarding the output control, a potentiometer was connected in between digital I/O 8 and the loudspeaker. It must be noted that during my testing, I decided to utilize an LED directly after the potentiometer to view the amplification and attenuation of the signal.
Within my Arduino script, the most noteable item pertained to a function for handling the unstable signal captured by the analog input. I surmised that summing multiple values (20), followed with finding the average, might stablelize the spastic quality of the shifting. I believe that it assisted with this issue.
Regarding my script:
The following pictures and video display my work:
Perhaps the biggest "take-away" from this project pertained to the utilization of a diagram sketch prior to building this project. Though components of the circuit were sketched out in a scattered manner, having these drawn pieces allotted for a speedier build. It must be noted that the uploaded diagram was created "after" the completion of the physical circuit, as the initial sketches were rather messy. Furthermore, this final diagram took a lengthy amount of time to create, as my experience with these types of drawings is rather limited.
I must also note that the quality of the projected sound left much to be desired. I am under the impression that noise was being introduced somewhere along the circuit chain. Though I attempted to resolve this issue through the cutting of fresh wire and the re-seating of components, I did not notice any improvement. Additionally, I'm curious if my circuit design is creating this problem. I will continue to investigate this issue within the next couple days
And lastly, the "playable" quality of this project is suffering. The utilization of push switches, including their placement on a breadboard, created difficult handling of sound triggering. Furthermore, the lack of housing for the potentiometers required careful adjustments for the pitch and output. Items, such as the mentioned ones, clearly indicate the necessity for user-friendly components and component placement.
Within lecture during week 3, our class recieved information pertaining to the utilization of a microcontrollers' digital and analog I/O. Within our labs, we followed tutorials to create circuits that utilized these arduino features. Initially, I was under the impression that I would handle these labs in a swift manner, as I appeared to have grasped the logic behind the provided material. However, the process proved otherwise.
PROCESS: LAB 1
When attempting the first lab regarding digital input and output, I followed the instructions provided within the Physical Computing web page. The process of reading the instructions and referencing the circuit diagram solidified my thoughts behind the functionality of the arduino within the circuit. After building the circuit, compiling the script, and uploading the program to the arduino, my creation did not function. Both LED's were not functional.
In light of this problem, I began troubleshooting through the pulling of all components and wires. After re-seating each component within circuit, I saw success. One light was operational in each state of the switch. The provided video displays the functionality of the first lab.
PROCESS: LAB 2
Upon the completion of the first circuit, I began the creation of Lab 2's project. Utilizing the same approach in Lab 1, I carefully followed the instructions and referenced the ciruit diagram when placing each component and wire within the breadboard. After completing the circuit, writing the script, compiling the instructions, and uploading the program, I ran into the the same issues within the first lab, where the circuit did not functioning. Thereafter, I removed the components and wiring, and re-seated all elements. Unfortunately, within the re-seating process, I broke the potentiometer's second pin (wiper). Fortunatley, I possesed another one within my electronics collection.
After handling the removal and re-seating, the circuit continued to not function. Thereafter, I checked the script, re-compiled it, and attempted to upload it to the IOT 33. Within the upload process, I recieved an error pertaining to the port connection for the IOT 33. This connection did not exist.
At this moment, I began searching internet for any information related to this problem. Initially, I was under the impression that this issue pertained to my current version of OSX (Mojave), as others had noted issues with Arduino connections when utilizing Mojave. Within these online readings, I found a troubleshooting guide for Arduino's. Upon perusing through the guide, I noticed that a light should momentarily blink on the Arduino during its connection to a computer. After inspecting the Arduino during the USB connection process to the computer, I did not see this "blink." After further research, I am currently under the impression that this "blink" pertains to the Arduino's ability to transfer/recieve data from the computer.
As I was unable to resolve this issue, I found an older non-Arduino brand board within my collection of electronics. I am fortunate to have kept Sparkfun's RedBoard, as it has similar capabilities of the IOT 33.
Upon connecting the board to the computer, the IDE identified the connection. Thereafter, I connected the RedBoard to the circuit, set the board type, set the port connection, compiled the script, and uploaded the program.
To my relief, the circuit worked. The video below displays its functionality.
LAB 1 & 2 REFLECTION
I am currently pondering upon my handling of electronic components within labs, as I've had issues pertaining the operation of circuits related to the seating of components. This did not only exist within the Physical Computing labs, but also existed within my Electronics for Inventors in-class lab. Furthermore, if my IOT 33 is faulty, I am placing complete blame upon myself. I am assuming that I shorted the unit somewhere within the troubleshooting process. I am planning to approach further projects with more care. It must be noted that I have placed an order for another IOT 33, which will arrive within 2 days.
OBSERVATION LAB: Burger King Ordering Kiosk
For the observation of this week's assignments, I chose to view the technological interactions of customers with Burger King's ordering kiosk.
As I've only heard of fast food ordering kiosks, my familiarity with these units was rather limited. My assumption pertaining to the utilization of this technology is reflective upon the human interaction between employee and customer, where the process could be slower and the ordering could be misinterpreted.
Upon viewing customers' interaction with the system for approximately 20 minutes, I noticed a few key elements. The design of the touchscreen interface utilizes over-sized buttons for a clear selection of menu choices. Furthermore, it must be noted that these type of buttons can be relatable to other touchscreen interfaces, such as Android or iOS devices. I am under the assumption that the design of this interface allows a fluid interaction between customer and system, as smart phones are common within today's environment. It must also be noted that large sliders (also found within other touchscreen systems) were utilized for itme customization. If any element took a lengthier amount of time, it related to this particular option. Though, the process of implementing ordering details to a specific item would logically be the most time-consuming element.
In addition to the mentioned observation, the utilization of large pictures on the buttons and next to the sliders appeared to create an easy, speedy interaction within the ordering process. The association of food item within a button created a "no-nonsense" system approach. Deviating from this food/button component was the menu button, allowing the customer to navigate to the main ordering area. While this button was occassionally utilized, I pondered upon the the labeling, as the text "back" could have been utilized. Though, I concluded the utilization of the text "menu" offers a more precise means of navigation. Overall, the utilization of the mentioned buttons created an easy ordering experience for the customers.
If I could note any difficulties within the interaction process, it pertained to the item list that reflected the ordered items. The placement of this list, located on the right-hand side of the touchscreen, displayed each requested item. The size of the textual information was significantly smaller than the mentioned menu on the left-hand side. When the customers were reviewing this list, I noticed a physical, bodily movement during this occurence, where the guest leaned towards this specified area. Perhaps Burger King's interactive choice related to both touchscreen real estate and constant visual feedback on the ordering process. While a separate page could have been devoted to their order within the item requesting process, perhaps this other manner of navigation would have created an additional step for the customer. Efficiency appears to be the key issue here.
Though my studies with interaction design have been limited, I found that the design of this kiosk was smart. Each element within the system had a clear purpose, creating a fluid experience for the customer. Furthermore, the popularity of touchscreen devices lends to a referenceable interaction.
As our class recieved further information regarding basic electronic components within a circuit, we were asked to individually create an application where the activation of an LED would be useful within a selected environment.
After pondering upon various ideas for this project, I decided to create a circuit to backlight my flask for incoming late-night projects. Though a prebuilt, fabricated switch could have covered the LED activation, I concluded that my conductive, steel flask could act as the connection within the circuit.
Regarding process, I initially sketched a circuit diagram prior to building the project. Thereafter, I began gathering and building the key components. As I desired to extend the distance between the breadboard and components, I wrapped foil paper (conductive) to the wire leads for the switch and also soldered wire to the LED.
The rest of the circuit construction was handled on the breadboard, where connections were created and the Arduino IOT 33 was utilized as the power supply (3.3 volts). Thereafter, the components were placed upon the table, where the LED and foil connections were positioned and taped on the table.
Testing began. Success! As an alternate text is unavailable for video, this documentation showcases the circuit completion through placement and removal of the flask.
When video documentation was attempted within a dark room, my phone's camera was unable to effectively shoot the action. However, a single picture was able to handle this visual documentation.
Regarding my self-critique, I concluded that housing would have been an effective means of relocating the circuit, as opposed to the utilization of tape to place the LED and switch. Furthermore, the size of the breadboard proved to be excessive for this project. Logically, a custom maded board would have been appropriate.
For our first class, we were given course information and expectations. Furthermore, lecture also pertained to basic circuits, where theory and components were described.
Within the end of lecture, we were asked to prototype a design for a dream project with an assortment of parts located near the equipment room. For my teams project, we decided to create an auto-feeding potato chip device. This device would keep fingers free of residue contained on the chips, creating a cleaner experience. Regarding construction, a belt would hold an articulating arm that pulls chips from a belt-held bag. The belt contained a switch for activation, and also contained a knob for feeding-rate.