3.5 Implementation
Fabrication and Assembly
The following are some of the fabrication choices that we made:
We decided to make all of the linkage and cam parts out of wood, all being consistent with each other. This choice was primarily made so that all of the linkage pieces could be visible through the backings of the clear acrylic. We considered using orange acrylic for these parts so that the tolerance of the laser cutting could be more consistent for all parts being laser but, however the orange acrylic was not available in the 1/4 in thickness that we needed and the 1/8 thickness would not have fit the edges of the bearings nicely and therefore thought it to be a better move to use wood.
Though we could have 3D printed our parts, most specifically the cam which we had done during the prototyping phase, we ultimately chose against it. We therefore designed all of our pieces to primarily use laser cutting over 3D printing due to the time constraint of 3D printing.
First attempt for final assembly
The first attempt at a final assembly revealed that the links were too thin and brittle around some of the bearing points. This led to the breakage of some of the links. We made adjustments to thicken these brittle points and recut the affected links.
We observed that the xylophone key contact with the arm link was lacking and chose to reorient the location of the key to the orange line in Figure 1, this location being chosen based on the motion of the mechanism, to improve the contact between the key and the arm.
We found that upon assembling that spacing was inconsistent and the mechanism as a whole was not the most stable. We turned to laser cut wooden spacers and 3D printed shaft collars as a way to line up and secure the linkage arm. We continued using spacers and shaft collars into our final iteration and seen below.
To further increase stability of the vertical base plates, we increased the height of the black 3D printed feet along the sides.
We found that the contact between the arm and the xylophone key was more muted than we would have liked, so we chose to add washers to the end of the long, playing arm (marked with blue in Figure 1) to increase resonance and improve the sound of the contact with the key.
Electronics
Our electronic components consisted of:
10 RPM DC Motor
L298N Motor Driver - controls both the speed and direction of rotation of a DC electric motor
Joystick
UNO R3 Arduino
6F22 9v battery
The 10 RPM motor was attacked via a shaft collar to the D shaft where all of the cams were attached. This meant that the motor was tasked with the rotations of all 3 cam mechanisms. We originally used a 100 RPM motor which worked well when we had up to 2 of the layers of the cam-follower and 4-bar mechanisms assembled onto the baseplate. This was showing promising results by allowing quick and forceful taps of the arm to the key (with the rubber bands helping to keep tension). However when we added the final layer, we found that this motor did not have enough torque to continue rotating all of the cams. We therefore had to sacrifice some performance of the tapping motion by using a stronger, but lower RPM motor, resulting in slower motions, less force when making contact with the key, and thus a more muted sound.
The motor driver controls the speed and direction of rotation of the DC motor. We used the UNO R3 Arduino to give information to the motor driver and the joystick to automate the system. Finally, we used the joystick as a “play button” to start the automation of the mechanism and the 6F22 9v battery to power the system.
Software Development
We wrote an Arduino program that received input from a joystick controller.
We designed our cams to the the dictators of how the mechanism would move based on the change on radius. By dividing the cam into equally spaced out parts, the timing was essentially already built into the design. This made the software development portion very simple, only needing to program a simple method to write to the motor the speed we wanted to move at and in what direction we wanted to go.
Setup
We gave names enA, in1, in2 to the three Arduino pins that hook up to our motor driver and buttonPin for the pin that connects our start/stop button (the joystick)
In setup(), we made sure to mark the motor-pin drivers as outputs, picked a default rotation direction for the motor (clockwise), and enabled buttonPin to read high (1) when idle, and low (0) when pressed to record input correctly.
Program Loop
We made a loop function to continuously read the value of the joystick input (buttonPin) to decide if the song function should be played. If the joystick had been pressed, the buttonPin value would be 0 and thus cause the run_song() method to be run. If it remained idle, the buttonPin value would be 1 and thus keep the motors off.
Song Function
We wrote a helper function, run_song(), that spins the motor at full power for the duration of the song. We timed one full rotation of the song and recorded it as 13.2 seconds. We initialized a global variable SONG_LENGTH to hold this value and was used to run the motor for the length of the song. This function ran once the button pin read LOW, meaning the joystick was pressed once.
Because we were using the 10 RPM motor, we needed to run it at its max speed to get the most force to strike the key when the drop in radius came around. We also needed to make sure that the motor was rotating clockwise, as rotating counterclockwise would result in the follower getting stick at the points where the radius was minimized, potentially damaging our mechanism.