Basically, we made a music box, using a wooden body of glued and nailed parts cut out with the laser cutter, a motorized music-scrolling mechanism, and an array of photo cells connected to an RDSCricket running a program that played a certain note whenever a photo cell "saw" a black spot on the scroll of music.
A more complicated explanation: My team wrote a PicoBlocks program that played a certain "melody" (one of eight notes in the D-major scale, sustained for a set time) when the corresponding photo cell had a reading above a certain threshold. (In arbitrary units, the threshold was about 400 for each photo cell, with a "dark" (above a black-marker dot) reading of about 550 and "light" (above white paper) reading of about 50.) We wrote a simplified version of sheet music by marking a long scroll of paper with black marker dots aligned with the sensor we wanted to play (i.e., a dot on line 1 would play a D, a dot on line 2 would play E, etc). The photo cells measured the transmission of light through paper--a hand-wired electronic array supplied an LED shining directly beneath each photo cell, so a large amount of light transmitted (light paper) would cause low photo cell readings, and a small amount of light (dark spot on the paper) would cause high readings and thus trigger the appropriate note. Each end of the scroll was taped to a Lego axle (made of three small Lego axles joined together, with four small Lego wheels spaced out with Lego bushings). One of the axles was attached directly to a PicoBlocks motor, while the other was left to freely spin in two slots on the main wooden body of the music box. The body was drawn in the CAD program SolidWorks and cut out of wood with the WE-Lab's laser cutter; its main features are holes for the scroll axles, a light sensor box to limit variable external light on the sensors, a drawer to easily remove the RDSCricket motherboard, and cute music note decorations.
A partially assembled music box, showing how things fit together:
Below left: Another view of the partially-assembled music box; the photo cell array and LED are not yet fixed in the light sensor box, and the wires are still messy, but this shows the aesthetically-pleasing outline of Wooden Iteration II. I added a few more music notes to the new back piece for decoration. In this iteration, we were still trying to light the photo cells with an LED from above; after further quantitative tests, we eventually changed this to light the sensors from underneath the scroll of paper. Below right: Top view of the PicoLED and photo cells affixed in the light sensor box, wires more organized; the RDSCricket sits in the drawer at the base of the main box.
Key Components (Works-Like Iteration I):
The working model of the scrolling mechanism. We initially tried to tape together pieces of regular-sized paper, but soon realized that the tape joint caused an irregular jerk of motor motion, so we used some extra-long paper from the library. We were excited for our success!
We then tested the photo cell mechanism; we discovered that the photo cells were sensitive to ambient light
We used PicoBlocks (familiar from the SciBorg Feedback and Control unit) to program our light sensor and motor scrolling mechanism. The PicoBlocks text language was a new area for exploration, as we needed to control eight different sensors to connect each photo cells to a note. After we learned how to find the appropriate syntax, the team quickly became comfortable writing a simple music-reading program:
The calibrated sensors play notes when exposed to dark paper and are silent on light paper (unless an ambient shadow makes its way through the haphazard works-like light box--this will easily be fixed in the final wooden version).
The sensors play over a note!
Works-Like Iteration II:
For our works-like model, we used Legos to build a housing for the photo cell array, lit this with a Pico LED, and ran music off of a long scroll of paper. This was the final scroll design, but the light sensor housing and overall shape of the music box soon became much more organized. The program isn't working perfectly yet, but its melody is correlated with the notes drawn on the page (in hindsight, these notes were spaced much too close together for the sensors to read properly).
Looks-Like Iteration 0:
After sketching numerous potential designs, we chose a simple box to contain the main components (RDSCricket and scrolls) and a light sensor box to shade the photo cells from ambient light (illumination would be provided by the Pico LED). We then eagerly jumped into SolidWorks--thanks to our earlier windlass and bottle-opening projects, Hannah, Jamie, and I all felt comfortable working with the program. We spent a few hours making the parts and toying with this design of a separate light sensor box that would sit on top of the main box body. After all this thinking, we realized a much simpler, more elegant design that fused the main box and light sensor box together, which we printed with the laser cutter. There were a number of parts we would have to join together; thankfully, many weeks earlier we had analyzed the advantages and disadvantages of piano wire, heat staking, bushings, and notches for Delrin. Our previous assignment with SolidWorks (the windlass project) suggested that heat staking was messy, and piano wire difficult and painful; bushings were inappropriate for joining right angles of planar pieces. We decided to build out of wood, for a more aesthetically pleasing appearance, and to use notches, wood glue, and tiny nails to assemble the pieces (which worked very well to form a sturdy and beautiful music box).
Looks-Like Iteration I:
Above: The SolidWorks version of the first looks-like iteration. Below: The wooden version.
We also widened the hole in the photo cell box side, to allow for easier insertion and removal of the photo cells and wires, and slightly raised the height of the drawer to more easily pull out the RDSCricket.
Wooden body parts (Wood Iteration II):
All were drawn in SolidWorks, printed out with the laser cutter; most parts had pegs and notches for sturdiness and ease of assembly, but all were additionally glued and/or nailed together for a stout frame.
A pile of parts!
We made sure everything in Wooden Iteration II fit together nicely before gluing; here a hand from each teammate holds together the project. Thanks to our stunning SolidWorks Assembly prowess (and experience from the Pegs and Notches SolidWorks assignment), everything was perfectly sized!
A diagram of the wooden parts (not shown: LED board)
- 2 side pieces
- Notches to fit in to middle and back piece
- 1 front piece
- Music notes cut out
- Extended top for light sensor housing
- 1 back piece
- Music notes cut out
- Formed a small section for the speaker, motor, and wires to be contained within the box
- 1 middle piece
- Extended top for light sensor housing
- Open to use less materials and for ease of wiring
- 1 drawer
- 1 front piece
- 1 bottom piece
- 2 tracks
- Motherboard sits on top, drawer pulled out for ease of "on" switch access and to facilitate battery-changing
- 1 base board (box bottom)
- Notches for sides and middle to fit on
- Holes for drawer tracks
- 1 light sensor top
- Isolates the sensors from variable external light
- 2 light sensor sides
- Isolate the sensors from variable external light
- 1 speaker box
- 3 solid sides
- 1 side with hole for wire
- 1 back piece
- 1 front piece with many holes
- 1 LED board
- 8 holes for LEDs
- Wiring underneath
Above: Circuit diagrams for the LED wiring. Professor Banzaert helped me look up the specifics for the forward voltage of the LEDs (the minimum voltage they needed to turn on), and we used Ohm's Law to determine that we could wire up to two in series, and four sets of two would be in parallel (top left). I needed a 270-ohm resistor in the circuit to limit the current to prevent the LEDs from quickly burning out. After my circuit diagram got the OK from Professor Banzaert (top right), I worked out how to wire the LEDs in a line (bottom)--red are the LED prongs, purple is the + wire, and green is the - wire (I didn't draw in the resistor here, but I put it on the purple wire so it would be in series with all the LEDs).
Above left: I successfully soldered the first two LEDs together! Middle: I carefully spaced out holes in the cardboard to perfectly match the Lego-mounted photo cells, and put an LED in each one. Right: All the LEDs soldered in series and parallel, with electrical tape for firm connections. Below: I successfully wired together eight LEDs! They run beautifully with the battery setup found in the RDSCricket.
Above left: Top view of the final wooden LED board; we used the laser cutter to cut perfect holes for the LEDs. The wooden piece was carefully measured to fit snugly beneath the light sensor box, so it could be easily removed but was stable. The thin wooden piece at the top of the board helps the board stay a fixed distance from the photo cells (we found that tiny variations in the distance between the paper and photo cells could cause large changes in the reading values). It also assists in feeding the music scroll paper straight to maintain the proper alignment of notes with the appropriate sensors. Above right: the underside of the wooden LED board, with wires taped neatly together; the 270-ohm resistor is visible on the white wire. I was careful to make a mechanical connection around each area of solder to maximize the stability of the connections, which made the LED array quite sturdy!
A descriptive list of the LED board parts and their functions:
It's hard to see in the photo, but the notes were 1.5 cm long, with 4.5 cm between the start of one note and the start of the next.
Above left: Graphing a light sensor's reading from the first test (simply taping two LEDs to the edge of the stabilizing board beneath the music) showed no readings, so this design did not provide enough light. Center: A cardboard prototype LED board stabilizing piece with holes for an LED lined up under each sensor. Right: Two LEDs in place for sensors 1 and 2. A few trials and some graphing showed that, with an LED under every sensor, the photo cells could consistently and accurately read the music scrolls.
- 8 white LEDs
- 4 parallel groups of 2 in series
- 270-ohm resistor
- In series with all LEDs
- Liberal quantities of solder
- Electrical connections between resistor, wires, and LEDs
- Electrical tape
- Mechanical connections to reinforce solder, and for safety insulation
- Insulated wire
- 5 strands of thin wire wrapped together
- 22-gauge insulation surrounding
- Pre-wired plugs to fit in breadboard or port on RDSCricket
Hannah proudly displays a "Twinkle" scroll.
- "Ode to Joy" and "Twinkle, Twinkle, Little Star"
- Notes 1.5 cm long, 4.5 cm from start of one to start of next
- Notes drawn with black marker on long pieces of paper
- 2 axles
- One large, two tiny Lego axles joined with Lego pieces
- 4 small Lego wheels (2 cm diameter)
- 8 Lego bushings
- Fit inside holes in the main body box
- Adjustable power
- Attached to one axle
- Controlled by PicoBlocks program via RDSCricket
- Controlled by PicoBlocks program via RDSCricket
- Contained in wooden speaker box, attached with hook-and-loop tape to the main box for maneuverability
- 8 Lego-mounted photo cells
- Plugged in to 8 sensor ports in RDSCricket
- Readings interpreted by PicoBlocks program via RDSCricket
- Contained in light sensor box (top portion of main box body)
Music of the Light
A job well done!
Impressions on the design process:
The tricky bits: Troubleshooting for multiple weeks
We had a few interesting malfunctions (read: many), most notably the inconsistent motor motion and random screeching that occurred intermittently during our recorded trials 3-23 (see logs below). We changed the batteries twice, but to no avail. Finally we discovered that these strange errors were caused by one of the RDSCricket's battery packs becoming disconnected from the motherboard. After we soldered this back together, our cricket ceased screeching randomly, although we realized its sensor readings were still highly variable.
Consulting with Professor Berg suggested that, once the batteries were working, some of this variability may have occurred because the Pico LED we were using did not run a constant light--we confirmed with an oscilloscope that this light actually oscillates at 160 Hz. We switched out the Pico LED for two hand-wired LEDs, which produced constant light and worked much better. However, we still had difficulty calibrating each sensor consistently.
Professor Berg, who had years of experience working with our type of photo cells, further suggested that we use them to measure the transmission of light through the page, rather than the reflectance of light (i.e., we should shine light underneath the music paper instead of down onto the paper from above the photo cells). We were initially reluctant to change our light placement, which we thought would require major rewiring, and we were skeptical of the supposed improvements to photo cell accuracy. But eventually we recalled Feynman's sage words ("if [your model] disagrees with experiment it is wrong", from The Character of the Physical Law), and Professor Banzaert helped me test a cardboard prototype after class. I learned how to collect and graph data in PicoBlocks to compare the effectiveness of various design changes:
Above left: Graphing a light sensor's reading from the first test (simply taping two LEDs to the edge of the stabilizing board beneath the music) showed no readings, so this design did not provide enough light. Center: A cardboard prototype LED board stabilizing piece with holes for an LED lined up under each sensor. Right: Two LEDs in place for sensors 1 and 2. A few trials and some graphing showed that, with an LED under every sensor, the photo cells could consistently and accurately read the music scrolls.
Top: a typical light sensor reading after scrolling through the music once, with LEDs shining down onto the page from above the photo cells. The difference between light and dark values is at most 250. This was a record of half of a scroll-through on the "Ode to Joy" scroll, so one would expect four clear peaks, the first two farther apart and the last two close together. However, the sensor showed a peak whenever a neighbor note appeared (one line above or below), often of equal or greater magnitude than the corresponding line. This is likely what caused the sensors played wrong notes so frequently, even when we increased their calibration thresholds. We later learned that the photo cells are not very directional (unlike an eye, a photo cell primarily senses only the presence or absence of light within a certain radius of its sensor), which explains the high sensor readings for neighboring notes.
Above: A typical light sensor reading paper with an LED directly below, with ambient light. The peaks are clearly defined (differences of over 400 for most), and occur only where black spots were present on the page.
Below: A typical light sensor reading white paper or a black note (peaks) lit from below, in the closed light box to limit ambient light. Lighting from below seems to greatly increase the accuracy of the sensor--it shows three significant peaks, spaced as expected from the music. Although the difference between light and dark values for this sensor seems much less than for the top-down lighting scenario, the huge improvement in accuracy and reproducible readings (calibration is no longer necessary before every run!) made the bottom-up lighting design vastly superior to top-down lighting.
After one last calibration (which had by now become much faster, after we figured out how to display the raw readings for sensors 1-8 with PicoBlocks), we ran the music program:
Success!
We cleaned up the program and added in an automatic rewind, using the PicoMotor's count.
Left: The final string of automatic rewind. Right: Text language PicoBlocks for the custom block "runmusic", the light-sensing code. The calibration values for each photo sensor were similar but distinct, based on individual variations; after one calibration everything worked beautifully.
Below: 100 documented runs and subsequent corrective action.
The awesome bits: Hands-on learning and eventual success
I greatly enjoyed soldering together the LED array. It was inspiring to discover an instance where my high school physics knowledge was directly applicable--I was pleased to utilize skills I didn't realize I had. Suddenly all my casual tinkering building tiny circuits with alligator-clip wires in my elementary school years had progressed to a new level!
After going into this class with hardly any programming knowledge (besides a tiny bit of VPython from Physics 107), I was excited to discover that I could write a wonderfully-functional program in PicoBlocks text for the music box! I greatly enjoyed the Feedback and Control unit, where I was often frustrated but learned so much about programming. PicoBlocks worked well for the scope of Music of the Light, although a more sophisticated music box (for example, one that automatically calibrated light and dark readings) might benefit from a programming language with more options for storing data.
Another high point: trials 85-100. 14 of these runs were absolutely perfect; there was one minor error once, which was quickly corrected. "Twinkle, Twinkle, Little Star" has never brought me so much joy!
Impression of the final design:
After a few weeks of frustrating troubleshooting, my group was ecstatic to finish a beautifully-working Music of the Light. Despite the annoyance associated with endless testing, I'm glad we spent so much time troubleshooting, as this led to a fantastic final product. The scrolling mechanism consistently worked well, especially with the automatic rewind program; although adding a gear train to change the angular velocity:torque ratio (as we learned in the Lego cars project) would have been a better idea than simply adjusting the motor's power through PicoBlocks, this adjustment proved unnecessary in the final design, and the box looked sleeker without added gears. After building the LED board, the light sensing program ran with consistent accuracy, with too many perfect runs to count (though the photo cells, speaker, and motor depleted the RDSCricket batteries after playing constantly for 1.5 hours at the exhibition). The LED board was actually very pretty; the electronics on its back side were neatly taped and well-hidden, as were the RDSCricket motherboard and all the photo cell wires. The speaker box smoothly meshed electronics with the wooden body of the main box and helped to hide the motor without confining it in a box that would amplify its noise. Music note cutouts on the front and back panels of the main box added a whimsical element that nicely reflected the music box's intended use. Overall, Music of the Light was impressively functional and aesthetically pleasing.
Further research:
With more time, we would like to experiment with different note lengths--the music box currently plays only quarter notes, and we would like to expand this to half, whole, and eighth notes as well. Our general ideas for this would be different colors for different note lengths (to have two different thresholds per sensor and thus play two different durations of one note based on the sensor's reading), or to add an additional sensor that would detect the presence or absence of another symbol on the page that could be used to differentiate between note lengths (which would require creative wiring, as there are only 8 sensor ports available on the RDSCricket). We could alternatively go to player-piano or "Guitar Hero"-style notation of note length correlated directly to the size of the note on the page (which would be less aesthetically-pleasing and use more paper, but would allow for more variation in note lengths), and then have each note play continuously as long as the sensor sensed black on the page.
We would also like to experiment with expanding the musical range of this box--it currently plays one octave (a D-major scale), but replacing the eighth line (currently the high D) with a command to play the subsequent note up an octave (like an 8va in standard music notation) upon seeing a black mark could add another octave to the range.
Accidentals (naturals, sharps, and flats outside of the original key) would be a further interesting addition. This would likely need more sensors, but perhaps a small dot before a note could tell the program to play the subsequent pitch up or down by half a step.
Given another iteration of the project, we would also try to add in some gearing instead of simply setting down the PicoMotor's power, for a more effective way to decrease motor speed. Time constraints and material use concerns prevented us from gearing the motor initially, but given a chance to restart, gearing considerations would definitely go into the first design stage.
Below: Pictures of the finished music box looking beautiful!
Ode to Joy (Project Finished!)
After many weeks of highs and lows,
The music box now happily goes!
Beethoven was stuck in our heads;
Now "Twinkle, Twinkle" plays in stead,
And every note means sweet success
After a steep slope of progress.
I'm pleased with the project of my group--
We truly were a marvelous troupe!
.png)
