RIT will permanently shut down the RIT Wiki (Confluence wiki) on February 2, 2024. Review the Wiki Shut Down Overview for information on alternative tools, exporting content from the wiki, and other FAQs.
Team Vision for Detailed Design Phase
The Detailed Design Phase is conducted to further develop our design and prepare for building our final product. We had planned for much of this phase to be spent prototyping and determining if our designs were feasible and effective. Unfortunately this plan was unable to be followed as the pandemic forced classes online and we lost access to on-campus resources. To ensure we were making progress and keeping up to date with our plans and documentation, we held biweekly team meetings over Zoom, a virtual meeting tool. Our goal in this revised work situation was to continue to flesh out designs and important concepts for the project, such as the power system, and ultimately make sure we are ready to prototype and build quickly when MSD II begins.
We have further developed our test plan, schematics, and flowcharts from the earlier design phases to better prepare ourselves for MSD II when we will be able to begin building our product. We placed orders for several of the more "high risk" components and have been able to do minor tests on the individual components to gauge some aspects of feasibility of the design. In addition, we have updated the bill of materials to be more complete as we have narrowed the design and determined what will be needed.
Prototyping, Engineering Analysis, Simulation
Due to the remote working situation, large-scale prototyping couldn't be completed. However, some components were able to be purchased and sent to engineers for limited prototyping and testing.
Videos of these prototyping and testing results are shown in the Photos and Videos page of the wiki: P20068 Photos and Videos
Door Lock Actuators:
Some analysis was done with the linear actuators we are planning to use as part of our project. Testing the strength and current draw of the motors with a DC power supply shows that the linear actuators will pull a lot more current than what the maximum said to be on Amazon, aka it could pull 3A+ while only sitting at around 5-6V, which is half of the voltage the motor is supposed to take. Therefore, if a resistor with a value of the resistance across the motor were to be hooked up with it, we would be able to current limit the motor at roughly 2.5A, which is roughly a 5 Ohm resistor. The strength of the actuator is quite strong, and the power it consume the slower it goes, so it will still work even at lower voltages but just slower. Unfortunately, using a frequency generator wasn't powerful enough to help the motors actuate, so we weren't able to see if it could switch at 333ms fast which is our goal to get.
Tempo Slider and Seven-Segment Display:
Slide potentiometer and seven-segment display were acquired and tested using a personal Arduino Uno. This allowed the Arduino code to be analyzed and the components tested so that their operation was better understood. This also allowed us to confirm the wiring and pin requirements needed to operate these devices. The full tempo range was demonstrated, verifying this component's software state diagram described in the Flow Charts section below and showing that adjusting the tempo will be smooth and easy, contributing to some preliminary test requirements.
Drawings, Schematics, Flow Charts, Simulations
This section walks through drawings and schematics for all subsystems associated with the design.
Beat Programming Board
The beat programming board will be designed off Chrome Music Labs with additional functionality. The primary addition is the tempo slider, which allows for the tempo to be adjusted from 40bpm to 200bpm. The tempo will be displayed on a green seven-segment display. The software interface connecting the slide potentiometer to the seven-segment display currently allows for a smooth mapping from the slider's 0-1024 range to the desired 40-200 tempo range, but the increment can be customized if fine control isn't needed. The switches are Cherry MX Speed Silver switches, which have a low activation force and actuation point, making them ideal for allowing students to interact with the programming board. A CAD mock-up of the casing has been created and will be used to ensure all of the components will fit and have proper spacing before prototyping.
Tempo Slider:
- 0-1024 Analog range
- 3 pins - power, ground, and analog out (two slots are available to determine which side of the slider is 0 and which is 1024)
- 5V input voltage
- 5.4kΩ resistance
- 21mm wide x 85mm long
Seven-Segment Display:
- Green (brightness is adjustable in software)
- 20mA max current (max brightness)
- 330Ω resistors on digit power pins
- 19mm x 50mm x 14mm
Slider and Seven-Segment Display Wiring Diagram with Arduino Mega 2560:
- Microcontroller connections can be reduced by omitting the far-left digit, the decimal points, and the center colon connections, as they are not needed for our display range and their removal does not impact operation of the device.
*Note: Slider model used in this circuito.io diagram differs from our selection only in pin locations - our model uses a pin interface on one end of the device
Beat Programming Switches:
- Cherry MX Speed Silver
- 0.45N Activation Force
- 1.2mm Actuation Point
- Custom 3D-Printed Keycaps
- Built-in LED Slot with each switch
- Top row = green LED
- Middle row = blue LED
- Bottom row = red LED
Switch Toggle Functionality Schematic:
- To preserve ease of actuation, toggle functionality will be added through hardware
- T-flip flops will allow the switch to toggle its output when pressed, rather than only give an output while being actively pressed
- The LED will work on the toggled signal, and so will remain on after the switch is pressed and released, and only turn off when the switch is pressed again
- This circuit will be used on all 24 beat switches
Switch I/O Reduction Schematic:
- To more reasonably manage microcontroller pins, the switches will be polled by column, so only three pins are required to be read at a time
- This reduces I/O from 24+ pins to 3 inputs and 3-4 outputs
User Controller
The user controller is what will be in the hands of students, allowing them to play the drums in real-time or select which instruments are active in beat-programming mode. For familiarity and ease-of-use, adaptive buttons will be provided as the primary input source for this controller. These buttons are 2.5in wide and will connect to the control board through a mono 3.5mm adapter. This adapter is intended to be universal, so any 3.5mm adaptive switch product can work with our design. The buttons themselves will be secured to a mounting board with Velcro, but can be detachable to be manipulated individually to suit any student's grip or range of motion. The cable connecting the button to the control box is 6ft long.
Buttons:
- AbleNet Jelly Bean Twist
- Red, Green, Blue, and Clear colored caps
- 6ft cord length
- 2.5in diameter
- 2.5oz activation force
- 0.025in actuation point
Switch Interface:
- 3.5mm mono connector
- Standard for adaptive switches
- Adapter on the control board makes this interface universal - any 3.5mm mono connecting switch should be supported
Wiring Schematic:
Motor Mount Concepts
Requirements state that the robotic drum assist must be easy to set up and take down, and we don't believe permanently modifying instruments is practical from a cost and engineering standpoint. Several options have been identified for securely mounting the drum assist components (striking mechanism) to the drums, with different designs and products expected to be used for each instrument.
The drum striking mechanism for snare can be mounted to the rim of the drums using a percussion claw as shown. The mechanism can be attached to the claw by a metal rod that is clamped in to the back of the claw and would be clamped to the internals of the striker.
A similar arrangement can be made for the bass drum, or a motor mechanism can be fashioned separate from the bass drum that is more similar with the traditional layout. The image below is an example of a striker that would be placed next to the bass drum. Our design will have the option for interchangeable drumsticks.
The team has considered several designs for the hi-hat striker attachments and have decided upon a design concept that attaches to the pole of the hi-hat to avoid the potential of the striking mechanism being knocked over and ensure that there is ground space used in the final assembly. The mount is similar to the snare attachment in that the striking mechanism will also be attached to the mount via a pole.
Power Supply/Interconnect
Changes made to the interconnect design shows how the buttons will be wired up with the MC. We will need a step down voltage regulator to provide the voltage signals to go through to the MC and then, with the programming, allow the user to manually play the drums. Resistors have been also added to limit the current going into our components along with a capacitor that may need to stay or leave depending on a reliable relay we choose to power the motors. The PSU has been upgraded from a 150W, 12.5A 12V source to a 200W, 17A 12V source so it would have even more room to power other future components. The DC Step down converter will more than likely be an IC chip that will provide a smooth +5V to the buttons for the signals to activate on the MC.
Software
The software subsystem resides on the microcontroller and manages communication between subsystems. All user input must be handled by the software before motors are activated.
- Main software loop should complete within ~50ms to feel sufficiently real-time
Tempo Display:
To display the tempo, the microcontroller first reads the analog input on the pin connected to the slide potentiometer. It then needs to map the 0-1024 range of the slider to the tempo's 40-200 range, using the built-in map function for Arduino applications. This convenient mapping strategy allows any range to be displayed, and it is very simple to reprogram the microcontroller to support a different output range. The seven-segment display is controlled by seven segment pins and 3 digit pins which control which diodes in each digit should be lit up.
User Input State Diagram:
The software will work sequentially, though the processing of the snare, bass drum, and hi-hat are shown in parallel for simplicity. The time to complete a processing loop will be sufficiently fast so that each instrument is processed nearly in parallel. After initialization, the software will wait for the buttons to be pressed by the user, at which time the microcontroller will send an activation signal to the motor driver. The motors can't activate and strike instantaneously, and there will be some time needed for the drumstick to reset to its resting position after hitting the drum. A cooldown will be implemented in software so that the motors aren't activated too soon after the previous strike. This processing will happen in a continual loop until the system is turned off or the beat programming mode is activated.
Beat Programming Mode State Diagram:
- The Repeat 8x loop can be modified to 6x for a 3/4 time signature
- Processing loop for each beat must complete within 150ms to meet maximum tempo
As described earlier, the beat selections will be polled to reduce I/O needed on the microcontroller. The software will iterate through the eight columns of the beat programming switches, sending select signals to the multiplexers and reading the beats into an internal representation of the beats. The main loop will be executed by measure, or by the 8 half-beats making up each measure. At the end of each measure, the beat selections will be polled again to refresh and catch any updates. Each half-beat processing block will check the user input for each instrument and only send an activation signal to the motors when the users indicate that instrument should be active. A master timer will be used to keep track of the timer so that there are no discrepancies between tempos and timing while instruments are added or removed and beats change. After inputs are processed, the loop will not continue until the next half-beat is available.
Bill of Material (BOM)
The Bill of Material helps us project out the total cost of the project, and ensures that we consider our sources and alternatives for components. The Detailed Design phase was intended for us to keep track of high-risk items and understand the flexibility of the design as we prototype and begin building. To help with this, four items were purchased and sent to members for remote prototyping.
- Tempo Slider
- Seven Segment Display
- Arduino Mega 2560 Microcontroller
- Door Lock Actuators
These purchases were reflected in the BOM and associated shipping costs were factored in to the total cost at this time. We are currently at half of the total allocated budget for the project, which is a good place to be given the financial uncertainties of the current academic situation. This gives us plenty of room to account for shipping costs, and additional items we identify once prototyping is complete and the final build begins. These additional items will likely be small structural materials to be used in housing components, but this design phase was primarily focused on the internal subsystem design.
Link to Live BOM Document: Bill of Materials.xlsx
Test Plans
After getting a better idea of the tasks we could work on from home, and after acquiring some necessary system components, three tests from the original test plan which had been taken out for Phase 3 were added back in. These proved to be things that we are able to consider and/or work on remotely. These tests are highlighted in green. Out of the remaining tests listed, those highlighted in yellow are tests that will be at the forefront of our planning as we move into the stages of early prototyping.
Link to Live and Completed Test Plan Document: P20068_Test_Plan_V2.docx
Design and Flowcharts
High-Level Design Flowchart
There were some slight changes to the high-level design flowchart during the Detailed Design phase due to feedback with the customer. These changes mainly pertain to the beat programming board, where the volume/force slider input was removed due to updated requirements and testing with a drumset. Some additional inputs and outputs were specified, with the beat select buttons also driving LEDs, a Start button, and a seven segment display added to the beat programming controller. At this time, this high-level description of the robotic drum assist is accurate and likely won't see significant structural changes.
System Architecture
The systems architecture flowchart for this design remains largely unchanged. This diagram was a primary tool used for identifying which components to focus on in early design, and is a more simplified representation of what was explored in the high-level flowchart.
Risk Assessment
Throughout this Detailed Design phase, risk was a major consideration in design decisions. Unfortunately, due to the Covid-19 situation, we were unable to do the prototyping necessary to mitigate much of the risk likelihoods. At this time, the risk likelihoods are unchanged, but the owners of each risk will keep their risks in mind as we prepare for building and prototyping next semester.
Link to Live Document: Risk Management.xlsx
Design Review Materials
The Detailed Design Phase Review for P20068 - Robotic Drum Assist takes place on Thursday, April 23rd, 2020 at 2pm. This review aims to inform our customer of current progress, revisit design decisions made over the course of MSD I, provide an overview of the current design, establish plans for MSD II, and answer any questions from the customer.
Pre-read materials were provided, containing a Detailed Design phase overview and a list of relevant charts and tables that are referenced in the presentation.
Link to pre-read document: Detailed Design Review Pre-Read.pdf
Presentation Slides: Detailed Design Review.pdf
Plans for next phase
Due to the Covid-19 situation, there aren't many large-scale prototyping efforts possible to complete in the time before the end of the semester. However, simulations and small prototyping or testing opportunities may arise as we validate the schematics and designs and prepare for MSD II. One research point is to better understand the 3.5mm interface for the user controller so that other inputs can be supported as needed.
The next phase will be Subsystem Level Prep, the start of MSD II. In this phase we aim to regroup, double-check the design, and begin rapid prototyping and purchasing to make up for deficiencies in the Detailed Design phase. We will proceed quickly with building and testing so that any significant issues or changes to the BOM can be caught early. With more thorough testing and understanding of the design on a larger scale, we can proceed to build and settle on enclosures for components.
Given the uncertainty of the situation, there is a possibility that we will again be working remotely for at least the beginning of MSD II, and so we took some time to think about how that would affect our schedule. The goal of this project remains the same: we want to deliver as much of a working prototype for the students to use as possible. This may involve preparing a thorough design that can be continued by future groups, but the ideal scenario is that we can deliver an early, functional design ourselves. Prototyping and building will be difficult if the team is apart again, so extra focus will be on simulations and modeling to effectively realize our design without needing to physically build it. Risk will be evaluated and mitigated through these simulations and any limited prototyping/building we are able to accomplish, and the documentation will be extremely important, as it is now.
The team has prepared individual plans, describing what actions they can take to ensure that we meet expectations and are fully prepared for MSD II and the next phase of the project.
