SlashBot
Developed and Constructed by
Bill Cunningham
-Lead Mechanical
Ryan Foster
-Circuitry, Device Driver
Michael Plucinski
-Device Driver, Software, Mechanical
Mark Price
-Lead Circuitry, Mechanical
Introduction
SlashBot is a guitar playing robot. It is delicately orchestrated and physically coordinated by an mpc-555 microcontroller. The physical apparatus required to construct Slashbot can all be purchased from your local machine shop andconstructed with much patience and planning.
Abstract
In order to build a guitar playing robot, we had to engineer a physical apparatus that was capable of holding unique frets on a guitar, as well as picking an individual string simultaneously. We decided to use mpc-555 microcontroller to trigger solenoids that would be the main physical driving components. Each individual solenoid would have to be custom fit to the electric guitar we had available to use, an Ibanez GAX30. We would also need a way of converting a midi file (used as input) into string/fret coordinate positions. We decided to split up our project into 4 groups, Mechanics, Circuitry, a Device Driver, and the Conversion Software.
Hardware Design - Plucking Strings
The physical method for pushing down the frets and for strumming strings is based on solenoid triggering. A transistor based circuit is setup to regulate the firing of a solenoid based on the a control signal from the microcontroller. In this manner we can control which frets and which strings to pluck instantaneously.
Fret Solenoids
The solenoids that were responsible for driving the frets had to be buffered and regulated by a transistor circuit coming from the microcontroller. We used two inverting CMOS logic gates to buffer the microcontroller signal into a power MOSFET junction (regular buffers were in short supply). The power MOSFET ran a source-drain voltage of 20V to trigger the solenoid, while the gate was connected to the CMOS buffers with pull-up resistors provided.
Plucking Solenoids
Solenoids were used in a similar fashion to "pluck" individual strings. A solenoid was positioned at each string to pull a pick across a string to create a pluck. When the solenoid was reset however it would again strum across the string and produce a unwanted vibration. In order to avoid this unwanted phenomenon, 555 timers were used to trigger another solenoid which would elevate the picking mechanism to avoid striking the string again. Careful calibration was required to setup the hardware timing involved in configuring the elevating circuitry.
Device Driver
The device driver was responsible for firing particular pins correspondent with musical notes and time events. The pins were mapped to three locations. In the case of output pins dealing with strumming, a short burst of 1 bit being on was all that was needed, and was then shut off. In the case of pins dealing with solenoids, these were kept on until the next time event where new notes would need to be played.
Software
The software we wrote took a midi file as input, parsed out the tracks inside the file, chose 1 (via user input) and then built a LOL structure. The first list was of time_event structures, each of which contained a list of note_node structures. The software was responsible for assuring the notes being played were on valid string/fret coordinate positions. The software also ran simple statistics determining how many notes and events were lost due to range issues, and offered the ability to shift notes by octaves. The part that dealt with the midi file was written in Perl. The output from that file was a simple text file of "at time X play note Y for length Z" lines. This was read in by the code running on the microcontroller (written in C) via the serial port. The LOL was a simple 2 D dynamic array. The first dimension included "time events structures" which had information on at what time this event should occur at, a linked list of notes that should be played, and which time event was next. The second dimension was a linked list of note events, which were just fret/string coordinate positions. Once this list was loaded it was sorted, and parsed through to make sure all strings and fret positions were within range. Any octave shifting was also done here, during the range check. The first time event was handled, and then a time was set to wait until the next time event (which was calculated by subtracted the next time event's time with the current time event's time).
Result
Our initial design was not fully implemented. At the last minute we had to change from using stepper motors to using 2 solenoids per each string for plucking. That forced us to cover from 6 frets to 4. We also never hooked up the plucking curcuits to the microcontroller. For some reason they wouldn't work. If given another day or two we would have had that working as well. As of right now, we don't have enough power hooked up to play more than a 2 frets at a time, our initial design had us playing 6 at once, enabling full chords to be played. Our code doesn't handle turning notes 'off'. We just let them ring out, ignoring the 'length' attribute we send over. This could easily be coded in by restructuring the first list of time events to have a way of signaling notes to be off. If we had the stepper motors we probably would have had this done.
Conclusions
It was possible to do implement what we wanted, and we came really close. If we put another 10 man hours into it plucking would have worked, another 2 or 3 man hours and the software would have supported multiple notes being played at once. If we had to redo the project, I don't know what else we would have changed. Maybe trying it with an aquostic guitar? Even then, we would have different issues (plucking would have had to have worked, and force of pressing down the frets would have been an issue).
References
Refer to our initial proposal for any parts we used.
Thank you Slash - you are an amazing guitarist.