home


Tuesday, June 27

Here's a picture of me and the MIDI berimbau, swiped from Bennett. It's kind of blurry, and doesn't show much detail, but it's all I got...

Sunday, June 25

Well, everything's done, except updating my journal, of course. So, I managed to come up with a mostly working MIDI berimbau for last Thursday's class. The design of the thing was pretty much as described below (1/2" diameter PVC tube , nylon string, yogurt container). The PVC tube worked quite well - it's flexible, not too stiff, but seems to be durable enough to deal with being flexed for a time (I would untie the string when I wasn't working on the berimbau, though, just to make sure I wasn't unnecessarily stressing the tube). When the whole thing was strung up, it had a decent feel - the string was taut enough to create a good simulation of a real berimbau. The balance of the instrument isn't quite right (it's a bit top-heavy when fully assembled), but it's not too bad overall.

The next problem I had to solve is that of the "rock." In a real berimbau, the player holds the instrument with the pinky and ring finger of his left hand. Between the thumb and index and middle fingers of his right hand, he holds a rock. The rock can be pressed against the string, producing a higher pitch when struck (like fretting a note on a guitar). After coming up with a design for the bow and resonator gourd, I had to figure out what to do about the "rock." I decided on a "literalist" approach to solving the rock problem: have the player hold some kind of thing with a switch that will close when pressed against the string of the berimbau. To that end, I harvested a momentary switch from an electronic game I found in the junk pile in the workshop. I then drilled a hole in the bottom of a pill bottle (from the pharmacy), stuffed it with foam, and put my switch on top. I made a cardboard disk that would just fit inside the bottle, and taped it to the top with enough play so that it would (in theory) close the switch. Alas, the switch I had chosen was too small, so one had to press on exactly the right spot on the disk in order to close the switch. I spoke with Tom, and he provided me with a couple of alternative switches. One switch was another momentary switch that has a springy metal strip on top - when this strip is depressed, the switch closes. The metal strip was larger than the pad on the other switch I was using, so it seemed like it would work. I managed to liberate a similar switch on a circuit board in the junk pile. It's really satisfying to be able to re-use components that would normally be considered trash. Anyway, this switch did the trick. The whole "rock" contraption was really makeshift, but it worked. Its main drawback was that it was even more awkward than the original berimbau (more on that later), mostly due to the size of the pill bottle (it was a bit too large).

I experimented with various configurations for the the piezo film sensor (used to detect the movement of the string). I tried to rig up a spring system that would keep it firmly against the string, though ulitmately didn't work all that well. I drilled a couple of holes in the tube so I could feed the leads from the piezo through the tube and out the bottom. The wire was stiff enough so that I could adjust the piezo film so that it rested against the string when the berimbau was assembled. I had inserted a photocell in the yogurt container, and finished my "rock" switch, so I was ready to see if I could get any data out this mess. I wrote a short Arduino program to display the sensor data on the serial monitor. Mercifully, I was still getting decent data from all three sensors. Tom also helped me to get the "data logger" program (written in Processing) to work properly so I could see what the output from the piezo sensor looked like. The data logger code is here . It's a nice bit of code, though Processing can be slooooowww... In any case, the data logger demonstrated quite clearly that the piezo was pretty noisy, but the actual hits on the string were pronounced. It seemed as though I wasn't getting a lot of values in between the noise floor and a hit (in other words, the hits were all near the maximum value from the sensor). At Tom's suggestion, I tried adjusting the gain on the op amp circuit (by changing some of the resistor values), but in the end, I stuck with the original design. The final MIDI berimbau had a real tangle of wires that connected the sensors to the Arduino (and other circuitry). I was planning on wiring everything to a serial port, and using a serial cable to connect the MIDI berimbau to the Arduino, but didn't have time (surprise).

The next step was to write some more code to map my sensor data to vaguely appropriate MIDI data. Since time was running a bit short, I decided to just do a somewhat mindless data-mapping. I should note here that, from everything I've read about building musical controllers, the data mapping step is really important. Obviously, that would be something to work on later. But, for now, I decided to map the data from the piezo to MIDI velocity. This mapping makes sense, since one would expect that how hard one hits the string of the MIDI berimbau would determine the level of the sound coming out of the synthesizer. My piezo wasn't going to give me a lot of sensitivity to dynamic range, but it would have to do for now. I also tried to smooth the data coming from the piezo by taking an average of successive values. I decided to map the values of the photocell in the "gourd" (yogurt container) to MIDI note (not that one would ever want to try to play a melody using this setup). Because in the real berimbau, the rock is used to change the pitch of the berimbau, I decided to use my "rock" to displace the MIDI note by an octave up or down, depending on the range of the MIDI note as determined by the value of the "gourd" (photocell) sensor. After some trial and error, and some help from Roy as well, I got my code in working order. The final version is here. The code, naturally, is not perfect. One problem I noticed was that I got some stuck notes if I hit the string in rapid succession (i.e., not all MIDI notes were turned off). I wasn't able to figure out why that was happening, though it seems to be a common problem when dealing with MIDI (at least I've seen it while programming Max patches). I also wired a switch to my Arduino and added code that would send an "all MIDI notes off" message to the synth, just in case things got out of hand, but that didn't work (improper message format? sending to the wrong MIDI channel?). Another bug I just noticed is that I should reset the "sum" and "count" variables in the loop() method if the value from the string sensor is beneath the threshold.

My in-class demo went okay, the MIDI berimbau did its thing. I connected it to a synthesizer module borrowed from the ITP equipment room. To gloss over the stuck MIDI note problem, I used a sound on the synth that didn't have an infinite sustain (I used the "koto" sound). Tricky! Tom and members of the class had some good suggestions. One was to use a bolt to provide an adjustable support for the piezo sensor - i.e., so that it could be adjusted to the correct position ( instead of the useless spring contraption I had rigged up). He also mentioned that I could have used single-wire, multi-conductor cable (e.g. ethernet cable, some of which was of course available in the junk pile) to connect the MIDI berimbau to the Arduino in a less chaotic fashion. We also talked about improving the design of the berimbau itself. For example, instead of trying to recreate the "rock", perhaps mount a switch that serves the same purpose on the berimbau tube. It seemed as though the overall design of the MIDI berimbau was decent.

If I were to continue work on the MIDI berimbau, I would definitely need to solve some of the problems with the physical interface. For example: figure out a way to get better data from the string (maybe the piezo is not the best solution); if I stick with piezo, come up with a better way to adjust its position; figure out a better solution to the "rock" switch (maybe embed the switch in the berimbau tube); come up with a better wiring system so the connection from the berimbau to the Arduino is more manageable. I would also consider improvements to the design of the MIDI berimbau itself, though I would want to keep it fairly close to the orignal instrument. I'd also need to fix the bugs in the Arduino code, of course. If I were really going to perform with the MIDI berimbau , I'd definitely work on creating a sound that makes sense for the interface (I could see using Csound for that part of it, maybe with Max to handle the MIDI data). Along with the sound design, I'd also need to come up with a good mapping of sensor data to MIDI data, which is, as noted above, is an important part of any musical controller design. I could see myself proceeding further with the MIDI berimbau - it has enough potential (and is different enough from other controllers that I've seen) to keep me interested in developing it further.

Note: sorry for the lack of pics, I don't have a digital camera. But I'll try to get something up there if I can.

Sunday, June 18

Hmm. I guess I haven't updated this in a while. Anyway, I'm working on the berimbau MIDI controller. The berimbau itself will be made out of a section of narrow (1/2" diameter, I think) PVC tube, the gourd will be made out of a large plastic yogurt container (one quart size), and the string will be some kind of string, probably nylon (it'll have to be pretty strong so that it can hold the tension produced by the bent PVC tube). A metal string would be better, since that's what the real berimbau has, but that's probably much more difficult to deal with than nylon string. I'll attach the yogurt container-gourd to the berimbau with a couple of cable ties.

As for sensors, the plan is to use a piezo resistor to measure the movement of the string, a photresistor to measure the distance of the gourd from the player's body, and a switch to measure whether the user has pressed the "rock" against the string (with the left hand). I still have to figure out how I'm going to build the "rock". Kevin provided me with a bunch of piezo film resistors (thanks, Kevin!). The output of all the sensors will go into the Arduino, which will, I hope, map the sensor data to MIDI data which will be sent out a standard MIDI jack to a synth of some kind.

Tom suggested using an op amp circuit with the piezo so that the voltage levels are in a better range of values. There's a circuit in the PComp book, but I used the one on the sensor wiki. I built this circuit with an LM324 IC instead of an LM358 (the LM324 is just like the LM358 except that it has four op amps on it instead of two). I managed to solder the piezo resistor to a couple of leads without destroying it. Nice. I seemed to be getting reasonable data from the piezo, though I may have to add a pot so that I can adjust the gain on the op amp circuit.

Thursday evening, June 8

So, the dryer detector actually worked when I demo'ed it in class. Amazing. There were a number of good suggestions made by Tom and the class. I think Kevin's suggestion makes the most sense - instead of having a bunch of switches to select which apartment gets a signal when the dryer is done, just have dryer status indicators in each apartment. Say, an LED in each apartment that lights up when the dryer is running (no matter who started it). One possible improvement to that design would be to indicate how long the dryer has been running, although that requires more than just an LED as an interface. People also had a number of suggestions about how to send the information from the basement to the apartments. Someone suggested running a cable (ethernet?) to the basement from the apartments. Tom, I think, mentioned a system that can send signals through power lines (X10?). There might be some wireless way to do this as well, though that has a number of problems (e.g. range limitations of the systems, radio interference from the zillions of wireless devices that people have). I guess I will try to implement these changes for the final project, though I would like to try the berimbau controller as well (especially since we're going to cover MIDI next week in class). Anyway, I'm reasonably pleased with the results of the dryer detector so far, though the project is much less ambitious than everybody else's projects (I'm not a slacker, really!).

Thursday afternoon, June 8

I went to Radio Shack, and picked up a "piezo transducer" for about $2. It's a piezo sensor in a plastic housing (probably designed for use as a speaker). I wasn't sure exactly how to wire the piezo into my circuit, though I figured that it would probably be similar to the circuit that we've used for other sensors (e.g. the flex sensors). Specifically, the red lead of the piezo should be connected to the appropriate analog in pin of the Arduino board, the black lead should be connected to ground. In addiiton, a high value resistor would need to be placed between the analog in and ground, so that the input is properly grounded. Roy let me know about a piezo sensor tutorial on the Arduino website, here. And indeed, this tutorial confirmed what I was thinking about wiring the circuit. The tutorial definitely provided some useful information, such as suggesting a resistor value.

So, I hooked up the piezo to my Arduino using the circuit described in the piezo tutorial. For debugging, I sent the values from the piezo sensor to the serial monitor so I could get an idea of what kinds of values I was getting from the thing. I put the sensor on the table and pounded the table with my fists to simulate the vibrations of a dryer. The values I was getting from the piezo were pretty low (mostly ranging from 0 to 4 or so), not really a useful range. So, I liberated the piezo sensor itself from its plastic housing. As expected, I got a much larger range of values from the piezo sensor alone (up to about 250 or so when I was pounding table).

I added some code to handle the input from the piezo. Basically, I look for values from the piezo above a threshold value to determine whether the dryer is on or not. The way the system works is as follows: the user turns on the "system enable" switch after they have started the dryer. They then use two switches to select which apartment will receive the "dryer is done" signal. There's a red LED to indicate whether the system is enabled, and two green LED's to indicate which apartment will receive the "dryer is done" signal. For the moment, this signal just lights two yellow LED's (one for each apartment, of course). The signal gets sent if the dryer is "off" (i.e. the piezo sensor reads values below the threshold) for 15 seconds. To reset the system, turn the "system enable" switch off. Obviously, the big hurdle now is to figure out how to get the signal from the basement to the apartments. Anyway, the whole thing seems to be working reasonably well, as far as it goes. The final code is here.

Wednesday, June 7

I made some progress on my dryer-detector device. I got the basic controls setup - one "system enable" switch, and two switches to indicate which of the two apartments to send the "dryer is finished" message to. For now, I'm using a momentary switch to simulate the sensor that will detect whether the dryer is running or not. For that particular sensor, I think I'm going to use a piezo sensor, thanks to a suggestion by another ITP student (I believe her name is Avani). She pointed me to a project she worked on that used piezo sensors in ping pong paddles, which helped me get an idea of how to use the thing.

Tuesday, June 6

I did some more work on the serial communications lab. I tried to get the "mouse" code working, to no avail. I used Processing, pretty much the same code that's in the lab. My version is here. I would get data back for a short time (the Arduino would send about three "packets" of data, then nothing). Not sure what's wrong... I'll have to look into that later this week, after I make progress on the mid-term project.

Speaking of mid-term projects, I decided to do the "dryer is finished" detector. Tom suggested, for the mid-term project, getting all the pieces working except the connection from the basement to my apartment. So, I need to detect when the dryer is finished (something to detect the rumbling of the dryer, or its temperature), and the interface on both ends. So, that's what I'm gonna do...

Monday, June 5

I have to get cracking with everything (this flu has really lingered on, and now I'm really really behind). This afternoon I'd like to work on the servo-motor and serial communication labs. I still have to finish up the love-o-meter, though there are various parts I need before I can do that (e.g. pressure sensors). I wish I had been in class last Tuesday to see other people's love testers, based on the work people did for the combination lock, I'll bet there were some cool love-testers.

(later that same day...)

I did indeed manage to get some stuff done, lab-wise. I got the servo-motor working. The code for that is here. I tried using the formula Tom provided in the lab for mapping the range of sensor values to the desired output values to the control the servo motor. Tom's formula is:

pulseWidth = ((sensorValue - minSensorValue) * pulseRange / sensorRange) + minPulse

When I used this formula, the values I got for pulseWidth did not vary much. As Tom mentions, the problem is that Arduino doesn't have floating point numbers, just integers. A formula like this has a bunch of integer divides, in which values are often truncated. So, as Tom suggests in the lab, I just came up with a rough formula that involved no division (actually, I needed two formulas - one for the pot as an input device, one for the flex sensor as an input device).

I also began working on the serial communcation lab, and did the first few parts of the lab. I hooked up the cicruit, using a pot, flex sensor, and momentary switch as my input sensors. I then wrote a couple of short Arduino programs (based on the first couple of code samples provided in the lab) to make sure I was sending and receiving data properly. I then wrote the Arduino program to read the data from all three sensors and send the values back through the serial port. That code is here. I used Hyperterminal to check that values coming from the Arduino, and everything looked good.

Saturday, June 3

I had another idea for a possible mid-term or final project. The problem: I live on the third floor of a house, the washer and dryer are in the basement. Is there a way to send a signal up to my apartment when the dryer finishes? I guess it's not an interactive device, but sort of an interesting problem nonetheless.

Thursday, June 1

Well, I lost four or five days due to a flu, so I'm feeling way behind... (this class moves fast). I have to finish up the love-o-meter, play around with the servo motor, and get cracking on my mid-term project. I do have an idea for that, at least. I'd like to make an electronic music controller based on a berimbau. I figure I can use a photoelectric sensor to detect the distance of the gourd part of the berimbau to the player's stomach. The wire of the berimbau can have voltage on it, and the "stone" could be something conductive wired so that when it's pressed against the wire, it completes a circuit. I'm not sure how to measure the force with which the user hits the string. I also need to find some materials for the berimbau itself (I don't feel like destroying my berimbau for this project).

Saturday, May 27

I thought about the love-o-meter, and came up with an idea for a device that "measures" someone's kissing skills. The design I have in mind is a styrofoam head with a set of fake lips. There would be an FSR behind the lips, and the length of the kiss and the pressure exerted would be used to calculate the "score." There would be an optimal time and force to achieve the highest score. Okay, it's ridiculous, unsanitary, etc., but what can you do?

The problem with the design is locating the necessary parts. I'll have to mail order an FSR, unless someone has one I can use. I bought a flex sensor variable resistor, but I'm not sure it's going to do the job. I managed to solder a couple of wires to the leads of the flex sensor without destroying it, and then plugged it into the circuit I used for the pot. I tried different (fixed) resistor values to see if I could change the sensitivity. The range did change, but it seemed, that the values were shifted, but the sensitivity was about the same. With one of the resistors, the values went from about 500 - 580 or so (I think this was with a 10Kohm resistor? can't remember); with another resistor (220 ohm) the range was something like 0 to 13. Gilles suggests using the pot instead of a fixed resistor to fine tune the values (which I think you mentioned in class). I still have to figure out this a bit...

Friday, May 26

I played around with the potentiometer a bit. I built the circuit described in the lab, and wrote a short Arduino program to retrieve the pot values. All seemed to work as expected, though I had to modify the code provided in the lab a bit.

Monday, May 22

I finished programming my combination lock and wiring the breadboard. The combination lock has one momentary switch. There are three possible values that could be entered to the lock via the switch, based on the length of time one holds down the switch. The values are "short" "medium" and "long." In addition, if one holds the switch down for longer than the maximum "long" duration (about 5 seconds), the system is reset. To open the lock, one has to enter the correct sequence of values. The combination is hard-coded, and is currently set to "medium", "short", "long." The code is here. The circuit contains LED's to indicate which value the user has entered, and LED's to indicate whether the user has entered the correct combination or not.

One problem with the design is that the user doesn't really know how many values have been entered. For example, assume a user enters the values "medium", "short", "medium". First, the "medium" LED is lit. Second, the "short" LED is lit. However, when the user enters the last "medium", the "medium" LED is already lit, so the user doesn't really know if they properly entered a value (or what value they actually entered). An improved design would offer the user better feedback.

Sunday, May 21

I spent a few hours working on lab 2, programming the Arduino to make a "combination lock." Mostly experimenting with the code. I discovered the pulseIn() method, which allows one to measure the duration between changes in the voltage state on a pin. The documentation is here. Note that the duration is in microseconds, not milliseconds. One question: how frequently is the loop() method called?

I found an answer to the question of the proper soldering iron temperature: about 600 - 700 degrees (F). I found the answer in a pdf that has a bunch of soldering hints. I found the link on the tutorials page on the PComp website. The soldering tutorial is here (pdf).

Saturday, May 20

I spent quite a few hours at home trying to get my computer (a 17" Powerbook running OS 10.3.9) set up for programming the Arduino. All in vain... I got to the point where my Mac would sort of recognize the Arduino. When I plugged it in, the directory would show up in the /dev/ directory (something like tty.Serial-USB1), and the Arduino IDE would list the USB port on the "serial ports" list. But when I tried to upload a program to the Arduino, I would get a system message telling me that I had unplugged my USB device during data transfer, some data may have been lost, blah blah blah. And then my Mac wouldn't recognize the Arduino for a while (if I waited an hour or so, I could repeat the above frustrating procedure). You'd think that computers would behave in a more deterministic manner.

Thursday, May 18

The main challenge of lab 1 was re-learning how to solder. Okay, I know that you're supposed to heat up the components being soldered and let the solder melt onto it, instead of melting the solder directly on the components. This proved to be fairly easy when soldering the header pins to wires (for the DC power jack), since the header pins are small (and there's not much metal to heat up). It was a little more difficult soldering the wires to the power jack itself. Somehow, I managed to make one decent solder joint on the jack, though the other isn't so good... The other issue regarding soldering is: what power setting to use on the soldering irons? Too cool, and the components don't melt; too high, and the solder seems to burn off, and the components melt. Another tip, from Rose, is to use the narrow gauge solder, it's more manageable than wider gauge.

All this stuff takes a lot longer than expected...


home