Preliminary Detailed Design

Team Vision for Preliminary Detailed Design Phase

The Preliminary Detailed Design phase will allow us to expand on concepts developed during the System-Level Design phase, establish an early Bill of Material, and prepare for prototyping. We plan to go into more detail in schematics and flowcharts for important components, and identify suitable materials and products to include in the Bill of Material, and evaluate selected concepts through early prototyping.

The initial goal was to focus on high-risk requirements and components so that prototyping can determine what concepts are feasible and identify changes that need to be made to the design early. Due to unforeseen circumstances, access to on-campus resources were suspended for the remainder of this phase, so completing the expected prototyping was no longer practical. The emphasis was shifted to creating schematics, flowcharts, and drawings to better describe our design, which will allow us to quickly move into larger-scale prototyping once the project returns to campus. 

The actual results of this phase mirrored the revised goal, which deprioritized prototyping in favor of further independent component design work and research. The bill of material was created and populated with early materials and devices, which provided an early estimate of the funding required to complete the project. Flowcharts and block diagrams from the System-Level Design phase were expanded with more detail and schematics to describe component connections. Focus was placed especially on important components that would benefit from customer feedback, such as the user input control layout and motor mounting mechanism. The power supply, motor specifications, primary microcontroller specifications, and beat programming board I/O reduction were also covered in this design phase. 

Prototyping, Engineering Analysis, Simulation

This phase is primarily focused on expanding the block diagrams, flowcharts, and descriptions of the concepts developed in the System-Level Design phase in order to better identify how the different components will function and communicate. This was achieved by continuing the prototyping and engineering analysis work started in the previous phase, as well as preparing for simulations where physical prototyping is impractical. Due to campus access limitations that arose during this phase, large-scale prototyping of concepts was not able to be completed, so the emphasis for this placed on analysis and research. The component selections that result from this analysis and limited prototyping will be evaluated through the test plan and large-scale prototyping once campus access is restored, but will be sufficiently vetted against requirements in the meantime through research, customer and advisor feedback, and simulation as the detailed design track continues. 

Feasibility: Prototyping, Analysis, Simulation

Beat Programming Board Switches

In order for the switches (buttons) on the beat programming board to be easily arranged and usable by the majority of users, they would need to be relatively small and have a very low force requirement for activation. Keyboard switches fit the size description and could be arranged into 3 rows of 8 switches, corresponding to the 4-beat (with off-beats) measure that will be available for programming, without requiring a large board size. There are a wide variety of switches available, with some emphasizing a light-touch requirement. A feasibility analysis was performed on these switch options, focusing on the Cherry MX switches used in consumer keyboards, due to their availability and familiarity. Table 1 below shows several properties that were compiled and analyzed for popular Cherry MX switches. 

Table 1: Cherry MX Keyboard Switch Characteristics

In the data collected in Table 1, the actuation force and actuation point were most relevant. These properties determine how much force is needed to press the switch and how far the switch has to be pressed in order for it to register as a press. To make the beat programming board more accessible, a low force and small actuation point were desirable. With these criteria in mind, the Speed Silver type was selected, as it has the lowest actuation force of 0.45N and the smallest actuation point by far at 1.2mm. 

Toggle Functionality

The beat programming board will allow a group of beats to be selected and played automatically on each instrument. To accomplish this, the switches must act as a toggle, where a user doesn't have to hold down the switch for the beat selection to be saved and active. As it is important for the switches to be extremely light and easy to press, the larger actuation point and mechanical design of physical toggle switches would be detrimental. Our design will employ T flip-flop hardware on each switch to add toggle functionality. The LEDs accompanying each switch will light using the toggled signal so that users can clearly see what beats are selected. This hardware can be implemented on a PCB or an FPGA. 

A schematic representation of the toggle circuitry is shown in the Drawings and Schematics section of this page.

User Input Buttons

There are several options for allowing students to control the individual instruments of the drum set in real-time. In the System-Level Design phase, it was decided that standard adaptive buttons would be the most familiar, easiest, and most accessible method of control. Now, the specifics of those buttons need to be identified. The AbleNet wired switch catalog was the primary source of information due to the documentation provided, which included the important activation force and actuation point specifications. An additional compact switch set was also included for comparison due to its favorable price point. The notable characteristics from the selected switches are shown in Table 2. 

Table 2: User Input Switch Options

The most important characteristics for accessibility is activation force and the actuation point, which determines how much force needs to be applied and how long it needs to be applied for in order to activate the switch. For maximum accessibility, these values need to be small, meaning that they will be easy to trigger. An additional consideration is the size of the switch. Larger switches are easier to interact with, but could make arranging them on a controller more cumbersome. The price is another important factor, as accessibility products are often expensive. 

With these button size specifications, some layout concepts were proposed for the user controller. These are simple mock-ups to get an idea of how the buttons can be arranged, and what effect that has on the size of the controller. Due to project requirements, there is a size limit where achieving accessibility and meeting the customer's teacher cart aren't feasible, and that limit was explored here. 

Horizontal Layout:

If the buttons are arranged horizontally, all buttons may be equally easy to access. However, using larger buttons could make this controller very wide, which may be uncomfortable for students and could impact the total device size on the cart. 

The larger buttons are 5 inches in diameter, which would make this controller 17 inches wide with half-inch gaps between buttons.  

The smaller reasonable button size is 2.5 inches in diameter, which could be placed on a controller approximately 10 inches wide. 

Staggered Layout:

A staggered layout, where some buttons are offset on the board, would reduce the width but increase the height of the board. This may be more comfortable in total size, but the buttons farther away from the close side of the board would be more difficult to reach for some students. 

Using larger buttons, the total width could be reduced to just over 1 foot. The height would then increase up to 8-10 inches. 

Smaller buttons would reduce the controller to a width of 6-7 inches and a height of 4-5 inches. This is a reasonable hand-held size, but that may not be enough for some clients. 

Disconnected Layout:

An alternative approach is to disconnect the buttons and let them be handled independently of each other, which would open up a variety of options for students to do what is most comfortable for themselves. A main control box would still be required to handle the inputs and communicate with other devices in the system, but the buttons themselves could be arranged in a custom manner. For ease of transport, the buttons could be attached together in a horizontal manner so they are not free when not in use. 

This would mean each button pad is simply the size of that button. Interlocked size would be the same in the horizontal case with an added control box. 

We will be making a decision on button size and arrangement based on customer feedback at our design review.

Motor/Drumstick Assembly Mounts

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 Requirements

Making sure all components receive the required power is an important consideration. Quantitative analysis was performed on the core components in order to identify the power requirements of the system, which were used to select a power supply and determine how systems would be connected. Notes and assumptions used in driver and power supply selection are listed below. Simulations will be prepared in 

Motor Driver:

• 2.5A per door lock actuator motor

• With 3 motors, we would need 7.5A.

• Will want large headroom to prevent overheating of motor driver

• At least 5 Amps per motor, 15 amp driver

Selection:

• Want driver to be active and normally stocked for quick replacement if the part breaks

• Found one driver rated at 12A for 2 motors (6Amps per motor) and one driver rated for 12A for one motor

• Each driver is rated for an “infinite” run time at its rated power output which in theory leads to zero down time

Microcontroller Selection

The motor signal processing and beat programming system requires a microcontroller. The primary considerations in selecting a microcontroller are the I/O pins it needs to support and the required peripherals. As separate motor drivers were researched to handle powering the motors, the current output of the microcontroller wasn't a major requirement. 

The beat programming system will require a timing peripheral in order to accurately maintain tempo. There will also be a need for an analog to digital converter, and potentially a PWM peripheral based on current motor controller designs. 

I/O Reduction

The biggest selection factor in our design is the number of I/O pins that must be supported. The beat programming board is made up of 24 switches, a slide potentiometer for tempo adjustment, and at least one additional switch to start beat programming mode. Each switch will contain a corresponding LED, meaning there are 4 pins per switch. 96 pins for just the beat switches is an unreasonable amount of I/O, but luckily much of it can be reduced through a variety of methods.

Matrix Configuration: Computer keyboards use a matrix configuration of switches so that pins are only needed on the extreme ends of each row and column of switches. However, this would still require 22 pins, which is a significant amount for one function on a microcontroller. 

Switch Breakout Board Matrix Configuration - from Sparkfun Tutorial

LEDs: The LEDs can be tied to the switch signal to reduce their reliance on the microcontroller. As we are planning to use simple single-color LEDs, there is no microcontroller logic necessary for determining when to light the LEDs. Removing the LEDs from the microcontroller reduces the matrixed I/O to 11. 

Polling by Column: An alternative approach would be to check the beat selections one column at a time, so that the microcontroller only needs to provide pins for the 3 switches on each column. This would use a hardware and software combination to control which column is checked, where the software specifies which column to poll, and the hardware is arranged to multiplex the switches on a row so that the microcontroller receives only the inputs for the column it desires. 

The polling method was selected as it offloaded the I/O from the microcontroller, requiring four output pins and three input pins. The outputs correspond to an enable signal and three select signals, which indicate which of the eight switches to read from, derived from 2^3=8. One input signal to the microcontroller will be provided for each individual instrument, as power and ground rails can be handled in hardware as well. The hardware component can be implemented on a PCB or an FPGA for future customizability. A schematic of this I/O reduction is provided in the next section. 

Microcontroller

The approximate I/O from each component is listed below. 

• Beat Programming Board
  • 4 out
  • 5 in
• Motors
  • 3 out
• User Input
  • 3 in

For familiarity and versatility, the Arduino brand of microcontrollers was chosen. Arduino boards have been used in automated drum projects in the past, and have a wide range of documentation and support available. The programming language is a specialized version of C++, and is familiar to the programming engineers who will be handling software development on the project.

It is important to have a wide pin overhead for the microcontroller to support additional features, improvements, and unexpected requirements. With this in mind, the Arduino Mega 2560 was selected. It is an 8-bit board with 54 digital pins and 16 analog inputs, providing more than enough overhead for future development. 

This board contains timers, a PWM mode, and runs at 16MHz, which will be sufficient for maintaining a steady tempo in beat programming mode. This board also fits standard Arduino shields, so additional functionality can be added later if more peripherals are required. 

Drawings, Schematics, Flow Charts, Simulations

This section contains several schematics, drawings, and expanded flowcharts created in this preliminary design phase. 

I/O Reduction Circuit

This method allows for progressive scanning of programmer board inputs without needing to check all 24 pins. Multiplexing like this turns 24 input pins into 3 input and 3 output pins, with one enable pin. This design is compatible with a custom PCB implementation, or could be programmed onto an FPGA. 

Toggled Switch Circuit

This circuit allows the LEDs to be controlled directly from the switch mechanism without the need for software control, reducing the number of I/O pins needed. It also produces a toggled signal based on the switch input, so that the switch only needs to be pressed once to be active, and again to be disabled. The switch input is sent into the clock input of the T flip-flop to eliminate reliance on an external clock signal. Every time the switch is pressed, the clock signal rises, and the output Q is inverted from its previous value. At all other times, Q remains the same. 

This circuit will be repeated for all toggled switch on the beat programming board, totaling 24 beat selection switches and a start switch, with potential for more switches as the feature set is expanded. 

Beat Programming Board

The switches that will be used for each of the square buttons in the diagram are 15.6 x 15.6 mm. The play button will be a customized key cap for a switch. The prerecorded beats buttons are tentative at this point. As we choose a micro-controller and establish how many pins we have available for use, then we will be able to figure out how many buttons we can have to store prerecorded beats. The entire programming board will be between 30-40 cm wide to ensure adequate spacing between buttons, and approximately 13 cm tall to accommodate the slide potentiometer for tempo adjustment.

The tempo slider can allow for fine adjustment of the tempo, which is expected to range from ~60 to 200 beats per minute. A notched implementation could be used to allow the tempo to be incremented at a steady step.

Interconnect Design of Main Components

The interconnect design above shows how the components will be powered and connected from the outlet AC source all the way to the motors hitting the drums. A PSU coming from the AC source will need to rectify that voltage to a +/-12 V source for the motors/relays, along with an IC chip that can step down the +12V source to a +3.3V/+5V power line for the micro controller. The micro controller will then use the signals coming from the IO pins to power the motors and play the drums.  

User Input Software Diagram

As indicated in the high-level design flowchart in the Design and Flowcharts section below and in the Systems-Level Design phase, there will be some input processing handled in the software to handle the User Input mode of operation. A microcontroller will be placed between the user input buttons and the motors driving the striking mechanism, so some software will need to pass control signals along. This operation was captured in the following software state diagram, which describes the expected states the program will pass through over the course of normal program execution. 

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 Software Diagram

The beat programming system will be heavily based in software, using the microcontroller's timer peripheral to send control signals in 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 is a document that lists all the components and materials required to complete the project and the financial information for each item. This ensures that the project budget can support all of the desired parts. This early indication of the financial status of the project is extremely helpful in future planning and risk management, as a tight budget means risks avoidance is much more important. Some components may need to be reevaluated if the financial burden in acquiring and maintaining them is too great. The Bill of Material also provides a way to organize the items required to prototype, test, and build the final design. The draft Bill of Material is shown below. 

Bill of Material live document can be found here: Bill of Materials.xlsx

Test Plans

Due to the COVID-19 outbreak, our team was unfortunately unable to start prototyping and testing physical components as early as we had originally hoped to do.  However, there are still several tests from our original list that we can keep in mind while working from home to help us proceed.  The modified test plan we will be using during this time is as follows:

Design and Flowcharts

Systems 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. 

High-Level Design Flowchart

There were some slight changes to the high-level design flowchart after the System-Level Design review 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 and a Start button 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. The individual components will see more detailed diagrams and schematics added as detailed design progresses, such as those displayed in the Drawings, Schematics, Flow Charts, Simulations section above. 

Risk Assessment

The COVID-19 outbreak has shifted our development plans around, which impacts the risk management of our project. There were some modifications made to the risk assessment document to reflect the changes in the situation and realize some new risks that have arisen due to the new working situation. 

1. Risk item #3 was modified after feedback during the previous phase review. The likelihood of damage due to too strong of a drum strike was decreased from 6 to 3, as we have eliminated the requirement for adjusting the volume/strike force. After live testing on a drumset in the previous phase, we determined that the strike force we need is going to be extremely low compared to the full power of our motors. With only one low-power strike setting, the likelihood of a problem will be reduced. 
2. New risk item #11 addresses the fact that large-scale prototyping will be unattainable during this phase. Without this early prototyping, there could be an impact on the quality of the final product, as the team will have less time to deal with design issues. To alleviate this problem, we will focus on preparing a solid design during MSD1 so that prototyping can be fast once we return to campus. Simulations, research, and limited small-scale prototyping will be employed to fill in the gap and identify potential issues before we are able to prototype.
3. New risk item #12 is a resource risk that arose due to the global impact of COVID-19. As businesses scale back and shipping time increases, there is a possibility that certain materials are more difficult to acquire. This would result in increased difficulty prototyping and completing a final product, and could add considerable extra design time if alternatives need to be found. We will focus on suppliers with good history, buy early to minimize delays on work due to shipping, and try to identify alternatives to components where possible. 

The updated risk assessment document is available here: Risk Management.xlsx

Design Review Materials

The Preliminary Detailed Design Phase Review for P20068 - Robotic Drum Assist takes place on Thursday, April 2nd, 2020 at 2pm. This review aims to inform our customer of current progress, gather feedback on new concepts, display more detailed models and diagrams, and serve as an official meeting time for discussing current requirements, proposing a draft Bill of Material, and answering any questions. 

Pre-read materials were provided, containing a Preliminary Detailed Design phase overview and a list of relevant charts and tables that are referenced in the presentation. 

Link to pre-read document: Preliminary Detailed Design Review Pre-Read.pdf

Presentation Slides: Preliminary Detailed Design Review.pdf

Plans for next phase

The next phase is Detailed Design, a continuation of the current Preliminary Detailed Design phase. We expect to have received some valuable feedback from the customer after the current design review, which will provide a final direction for several integral components, including the user input controller. This will allow us to expand circuit schematics to detail the user input controller and connect it to the rest of the system. The several drawings will be converted to CAD renders, with well-defined dimensions in order to help evaluate the total device area against size requirements. Block diagrams, flowcharts, and schematics will continue to be refined and expanded on at lower levels, as the majority of components should be identified and selected at the end of the next phase. Attention will be given to software state diagrams and design documents, and limited prototyping can be performed on individual functions using related hardware. As large-scale prototyping is not expected for the remainder of MSD I, the Detailed Design phase should provide a fully fleshed out design in the end, with a complete Bill of Material, so that prototyping and implementation can begin immediately at the start of MSD II. 

Team members prepared individual plans that describe their goals and thoughts on the next phase.