Page tree
Skip to end of metadata
Go to start of metadata

Team Vision for System-Level Design Phase

During this phase, the team planned to take the requirements and foundations from the problem definition phase and begin early concept work. A variety of methods will be employed to translate customer and engineering requirements into high-level functions, break down those functions into low-level functions, prepare and evaluate concepts based on feasibility analysis, and continue benchmarking and risk assessment. These tasks will provide the team with a solid plan for moving into heavier design phases, and will even allow basic prototyping to begin. As these concepts are expanded on and prototyped, we will remain in contact with the customer and utilize other project resources to maintain a unified vision and take advantage of all available opportunities for learning and improving in regards to the project and the process. 

The actual outcome of this phase's activities closely followed the planned actions. Important concept and engineering analysis work was completed, which will allow the team to spend time prototyping and refining concepts in the detailed design phase. The tasks completed helped establish risk management actions and early plans, and allowed several valuable engineering process skills to be learned and employed. These skills included benchmarking, morphological charts, pugh charts, and high-level block diagram creation. 

Functional Decomposition

The simplest description of the drum assist device's function is to enable a drum set to be played robotically. This simple function will be the basis from which all the low-level functions needed for creating the drum assist and fulfilling the requirements established during the problem definition phase. A method called Functional Decomposition was applied to break down the simple, high-level function into smaller sub-functions. Through asking the question "How?" at each function and sub-function, additional sub-functions could be created to define what was needed for implementation. Looking up the tree of functions, the question "Why?" can be asked to verify relationships and show that each function has a purpose. 

This functional decomposition process created a tree of functions and relationships, which is shown in its entirety above. These resulting low-level functions would serve as the basis for concepts and early design work. 


Bench-marking is an exercise designed to identify strengths and requirements around existing solutions and concept options, so that the design process can avoid redundant work and have tangible data to test solutions against. For the drum assist, there aren't necessarily full prior implementations that exist, but the accessibility design space has created many useful products and initiatives throughout the past several years. Pieces of these previous efforts will be combined to identify some benchmarks to be used in comparison to our drum assist concepts and eventual prototypes. 

The working bench-marking document can be obtained hereBenchmarking.xlsx 

Concept Development


A common feature of devices built for accessibility is a wide range of supported control interfaces. This allows users of any mobility and ability level to control the device, and it is an important goal when creating an accessible device. While supporting any kind of control interface is the ideal goal, the time/budget constraints of this project require a minimum standard control set to be provided. Identifying one or two standard interfaces will allow us to ensure that the other aspects of the project receive the necessary engineering resources as well, and it will be simpler to work out how to support additional control systems with a primary system already established. With that in mind, the team saw multiple options for control interfaces. 

  • Light-Touch Buttons
  • Eye-Gaze
  • Tablet (iPad)
  • Joystick

Light-Touch Buttons: These buttons are used in many accessible communication and control devices, and are extremely responsive to even soft presses. This makes them useful for students with limited mobility in their hands, as they don't have to exert much effort to activate a button. Connecting them to a main controller and having them activate a drum striking mechanism wouldn't be too difficult, as the fundamental mechanics behind a button are well understood. A disadvantage could be the size and placement of buttons on a control board, which would require some extended design work to come up with an optimal solution. 

Light-Touch Buttons

Eye-Gaze: The eye-gaze control interface is a relatively new technology that allows users to interact with elements on a screen (tablet) using only their eyes. This would potentially be the most accessible control interface, as even those with a severe lack of motor control can use it. However, the commercial eye-gaze cameras and the computer systems/tablets to run them are very expensive and likely wouldn't be financially viable for this project. Due to the volatility of acquiring such a device, development access may be limited. There would also be a notable challenge in learning how to use the device, learn how to develop a custom interface, and communicate with the physical robotic drum assist through software. There are also challenges in creating a smooth initialization/sync process that is easily navigated by the end users. While the impact on accessibility would be significant, the cost and challenges lead us towards a simpler interface option. 

Open Orchestra - Clarion's Tobii Eye-Gaze Product

Tablet (iPad): Initially, the iPad seemed to be a strong candidate, as the devices could be supplied through an existing program at the school. The touchscreen interface would be suitable for students with limited mobility, and a lot of interface options could be customized through the control app we would create. However, app development on iOS would be relatively new for members of the team, and relying on the App Store could become a bottleneck in testing and delivering the device. Communication would also be a challenge, as we need to minimize latency and connectivity issues between the controller and the drum strike mechanism. Wireless communication may not be sufficient for the speeds and reliability we desire, and it's uncertain how supportive iOS is of interfacing with external hardware, such as a microcontroller. 

Apple iPad (Standard Model)

Joystick: Like the light-touch buttons, joysticks are commonly found in accessible and adaptive controllers. They can require a bit more dexterity to grasp the device, but are relatively simple to control and connect. One potential issue is in identifying which instrument/action each direction corresponds to, as we would have a maximum of four options but only three instruments are being planned at this stage. 


Drum Strike Mechanism Ideas:

The core purpose behind the robotic drum assist is live feedback from a snare drum, hi-hat, and bass drum. This provides students a better sense of participation, as the drums are actually played. To accomplish this, a system will be needed to rapidly strike the drum with a drumstick or mallet. The benchmarks collected for Arduino-controlled drums provide some tested concepts that we can incorporate and use as a starting point for further design work. 

Solenoid striker for snare:

String-winding design for bass:

Beat Programming Controller:

The ability to program a set of beats to play is a major requirement for the robotic drum assist, as some users may not be able to follow the beat in real-time, but could still see better participation by controlling the instruments playing a pre-set beat. The programming interface is somewhat dependent on the user controller interface selected. 

  • Externally Programmed File (MIDI format)
  • Custom Programming App
  • Physical Beat Programming Board

Externally Programmed: One option for providing pre-set beats is to use an established music format, such as MIDI, and have the instructor upload the file to the device with a computer or external memory. This would potentially restrict students from being able to participate in beat programming, and would require the use of an external system and application to program the beats. 

Custom Programming App: If the control interface was more software-based, such as on a tablet, then a custom programming application could be written. This would allow the interface to be simplified to work better with the drums, and the internal representation of the beats can be unique to the drum assist device. However, this follows the disadvantages of a tablet control system, where testing and modifications must go through an external app store, and communication with the hardware of the device may be difficult. 

Physical Beat Programming Board: Chrome Music Labs' Rhythm experiment is currently employed in class to set the beat, and its simple interface is easy for the students to interact with and understand. A physical version of this interface could share these benefits, and would also be a built-in part of the robotic drum assist. This would make it easy to connect and control. 

Beat Programming Board Concept

Feasibility: Prototyping, Analysis, Simulation

To confirm that the concepts selected and explored during this phase are able to deliver the required functionality, a feasibility analysis was performed. Several characteristics and important functions were used as the basis for notable questions that had to be answered in order to understand concepts and inform future design work. These questions raise awareness of important characteristics that must be adhered to, and will allow for more expansive design decisions to be made as detailed design and early prototyping begins. 

How much power will our system consume?


  • We will be using a powered mechanism to strike the drums along with a micro-controller
    • Micro-controllers have a variety of power requirements
    • Standard Arduinos can take 9V-12V with 2A on its main input
  • An AC - DC converter will be needed to power the components off school's power outlets


  • Power usage will be dependent on micro-controller activity and motors
  • This analysis will be completed after components are selected and full system specifications are finalized


  • Multimeter to measure power usage

How reliable would functionality of the motors be on a components running at lower efficiency (if we were to make the system battery powered)?


  • Stress-testing and performance analysis would determine reliability
  • Motor specifications will give an early indication to power requirements

Note: We are choosing to use plug-in power to avoid this risk

What is the maximum tolerable latency (input to drum strike)?

Benchmark and Collected Data (Arduino-Powered Robotic Drum and Responsiveness Studies):

  • Latency greater than 250ms feels sluggish
  • Latency of 100ms can still be slow depending on the application
    • A drum strike should feel relatively instant and should be very responsive in order to stay in tempo and match the beat


  • We should have less than a 100ms delay from input to output to meet standard set by Arduino-Powered Robotic Drum bench-mark and maintain responsiveness
  • Latency due to processing (micro-controller, circuitry) is expected to be very small (microsecond scale)
    • Therefore, the optimization should be aimed at the strike mechanism (motors)
      • Strike time depends on motor power/speed and the distance from the drum (angle of resting drumstick position)


  • This will be solved by analysis of product specifications and confirmed with prototype testing
  • Testing and benchmarks will provide an idea of the desired strike time

How large/heavy can our entire system be?


  • The system must fit on a teacher's cart (~1.5' x 3' x 1.5')
  • The system must be self supporting (sturdy on its own)
    • Servo motors range from 8g-20g weight
    • Must support different types of mallets/drumsticks, where mallets may be much heavier towards one end
  • The interface must be light enough to allow the students to lift it if needed (<5lbs)


  • This risk will be addressed through prototyping
  • User testing will aid in evaluation of prototypes

Morphological Chart and Concept Selection

A group of sub-functions and important design questions were identified using the functional decomposition tree and preliminary benchmarking and concept work. To organize the available options and aid in the selection of viable concepts, a morphological chart was created. In the left-hand column, sub-functions with outstanding questions and desires were listed. Horizontally from each of these function topics are potential solutions and implementations to be considered. The morphological chart allowed us to identify all the viable solutions for each fundamental component of the project, which were combined into general design concepts to be evaluated against each other. Some solution filtering was applied at this stage to focus our work on the most viable and most relevant solutions, using a colored priority system to label each solution by priority and eliminate nonviable options. 

Link to working document: Morphological Analysis Table.xlsx

Concept Selection

From the morphological chart, some the best solutions were combined into various design concepts so they could be evaluated. To identify which solutions should be pursued, Pugh charts were created evaluating solutions against a list of selection criteria. Weights would be applied to each solution by each selection criteria, with all being compared to a middle-ground solution labeled DATUM. The total score for each solution was tallied and used to select the solutions most worth pursuing. 

Selecting an interface to work with:

The team used 9 different criteria to evaluate which interface would be best for the final product (above). We then used the Morphological Analysis chart to analyze objectively what solutions would best fulfill sub-functions along with the chosen sensor (below). We chose to separate sensor selection from other functions because one of the most important parts of this project is keeping the end user in mind and making a product that is accessible to the greatest number of students. 

Comparing different designs: 

Design Key: 

After comparing several different designs that feature different solutions to sub-functions, we could see that designs 1-3 all performed similarly when compared to our criteria. This told us that we needed to choose the best parts of each design. Final design decisions will be made throughout the detailed design phase, where better analysis and prototyping can provide more definitive indications regarding the advantages and disadvantages of the leading concepts. 

Systems Architecture

This chart shows the movement of information and power through the system. The Power Supply subsystem provides electrical power to all components that need it. The Control subsystem takes information from the User Input subsystem and provides it to the Motor Subsystem, so that the drum strikes occur when and where intended.

Designs and Flowcharts

The high-level design flowchart gives an overview of the system design we envision, and defines the major components and connections that will be needed to bring the design to fruition. As the design work progresses with more detailed descriptions and component designs, this flowchart will be broken down into more detailed block diagrams and schematics. 

Risk Assessment

There are several risks inherent to this project, divided into technical, safety, resource, and social risks. 

  • Technical: Risks associated with technical design and implementation attributes of the project
  • Resource: Scheduling, financial, and personnel risks that impact deliverables
  • Safety: Risks that pose physical danger to the team, users, and materials
  • Social: Risks potentially involving harm based on social issues

These risks are analyzed to determine potential causes and related effects, and are then scored by likelihood and severity. This scoring system is combined into an overall importance score, which helps influence our efforts to mitigate, prevent, and respond to risks. A list of necessary response actions are given, and individual team members assume responsibility for certain risks in order to ensure that all risks are accounted for and given the attention they need as the design and implementation phases progress. 

This is the full working Risk Management Excel document: Risk Management.xlsx

First-Cut Test Plans

An early test plan was established based on current requirements and expectations. It aims to ensure that all engineering requirements are fully evaluated and provide the desired functionality. This plan will be updated in later phases as more project details are identified. 

Test #

Test Type

Test Name


Engineering Requirement

Required Equipment

Definition of Success

Test Owner



Space Compatibility Test

Test size and shape of robot with standard snare, hi-hat, and bass drum

Test compatibility with a standard wheelchair

Standard shape/size

Snare drum, hi-hat, bass drum, wheelchair, measurement tools (tape measure, caliper, etc.)

Robotic system fits on student’s wheelchair and is appropriately sized for a standard snare drum, hi-hat, and bass drum.




Power Test

System must be capable of being powered using AC Mains

Plug-in power supply

System power circuitry, AC Mains, multimeter

System and circuitry are powered on and function as desired when connected to AC Mains.




Ease of Construction Test

Design must have a low number of components to ensure simple setup/tear down and troubleshooting

Simple designs without too many components

System Components

System is able to be systematically set up and taken down with little to no trouble from the teacher/aides within a reasonably short period of time.





Endurance Test

Physical architecture must be sturdy and reliable enough to uphold integrity after repeated drum hits

Metal/wood structure to endure heavy swings

System Mechanical Build

System build remains in good condition with no significant wear or damage after all regular use cases.





Grip Test

Robot should be able to adjust to work with any drumsticks the customer would like to use

Requires an adjustable grip for different size ranges of drumsticks

Drumsticks, striking apparatus, potentially software

System is able to handle and function with any drumstick or mallet, regardless of size or material.




Beat-Creation Test

System should include a soundboard for programmable macros

Programmable beats

Soundboard, beat creation/programming software

Custom beats can be loaded into included soundboard, saved, and played back at any point.




Programmed-Play Test

System should include a soundboard to play pre-programmed macros

Pre-set beats

Soundboard, software

System soundboard will have custom beats and macros stored, which can be played back at any point.





Master Control Test

System should include a device for master control

Program settings for the teacher to change only on her behalf

‘Master’ soundboard, software

Master soundboard (used by teacher) has control of volume and tempo.  The system used by the student is appropriately affected by all changes made on the master soundboard.




Simplicity Test

System should be composed of minimal number of necessary components and structures

Limited number of subsystems

System build, circuitry, soundboards

Complete system does not contain any unnecessarily redundant components or subsystems.





Motor Test

Movement of the system shall be controlled with appropriate force, timing, and hold states dictated by electric motor

Electric motors for actuation

Electric motor, striking apparatus, three-piece drum set and/or drum heads and/or drum pads

Selected electric motor is able to control the robot to strike all three components of the drum set independently and as chosen by the user.  The motor delivers the appropriate amount of power to play the instruments with adequate sound quality, volume, and timing.




Fundamental Safety Test

Any small, sharp, or otherwise potentially dangerous components shall be adequate concealed or excluded

No sharp pieces or too small parts accessible

System build

The system does not have any exposed sharp pieces, or small pieces which could be removed and pose a choking hazard.





Ease of Transport Test

System able to be moved and transported with minimal effort

Lightweight designs

System build, scale for weight measurement(s)

System does not take significant effort to move due to weight.




User Interface Test 1A

System responds correctly and promptly to physically - selected user input 

Touch/physical control interface is responsive

System build, circuitry, software, drumsticks

System plays the drums accurately based on user input.



User Interface Test 1B

System responds correctly and promptly to user input accepted through eye-gaze technology

Responsive eye-gaze interface

System build, circuitry, software, drumsticks, eye-gaze technology (physical system and software)

System plays the drums accurately based on user input.


Design Review Materials

The System-Level Design Phase Review for P20068 - Robotic Drum Assist takes place on February 25th, 2020. This review aims to inform our customer of current progress, and serve as an official meeting time for discussing current requirements, proposing selected concepts, and answering any questions. 

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

Link to pre-read document: System-Level Design Review Pre-Read.pdf

Presentation Slides: System Level Design Review.pdf

Plans for next phase

  • The team will start to select the main components of the project, from motors to microcontrollers and power supplies. Once we figure out our components, we will find different companies that hold the available components needed for our project and add to our BOM. We will also create a plan for building, operating, and testing the entire system. These activities will contribute to the detailed design phase, where we will expand on the concepts explored in system-level design, and create more specifics and quantitative plans so that prototyping can begin. 

  • No labels