System Level Design

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

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 here: Benchmarking.xlsx 

Concept Development

Interface:

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. 

Joystick

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?

Considerations:

• 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

Conclusion:

• 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

Tools:

• 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)?

Tools:

• 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

Conclusion:

• 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)

Tools:

• 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?

Requirements:

• 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)

Tools:

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

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.