P17363: Player Piano

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

During this phase, our team planned to figure out the top to bottom functional view of the system. Along the way we broke the system up into sub systems which have more defined tasks. Once the system has been broken up into sufficiently specific sub systems we want to analyse the feasibility of various approaches. This will help determine which approach best meets our needs.

Functional Decomposition

public/Systems Level Design Documents/Function Decomposition diagram V2.png

This chart shows a chronological view of the piano's operation, as well as a functional breakdown for each step. the resources are shared between different operations (ie, the main controller is used to both load the music and control the UI), so many steps connect to the same functional parts. A fully interactive version of this chart is available at this link.


public/Systems Level Design Documents/Benchmarking.png

Morphological Chart

public/Systems Level Design Documents/Morph Chart Rev 2.png

Selection Criteria

Concept Development

PianoDisk as Datum
public/Systems Level Design Documents/BenchPugh.png
Servo Actuators as Datum
public/Systems Level Design Documents/BenchPugh1.png
Actuation Evaluation
public/Systems Level Design Documents/ActuatorPugh.PNG
Linkage Evaluation
public/Systems Level Design Documents/PughChartCable.PNG

Conclusion: Solenoids will be used for actuators

Systems Architecture

System Concepts

Feasibility: Prototyping, Analysis, Simulation

Method of Actuation

Parameters to Test:

Solenoid Use Feasibility

Since solenoids will be the chosen method of actuation for this project, further insight into solenoid physics is required. The Force behind the strike of a solenoid can be given by the equation below:


F = Force in Newtons
N = Number of turns around Solenoid
I = Current in Amps
A = Area of the Solenoid
G = gap distance between solenoid and plunger

Since the only variable that can be changed is the current, we will be using Pulse Width Modulated signals from our chosen microcontroller in order to create the effect of a hard or soft key press. Several model solenoids will be purchased in order to determine best power to sound ratio. I.e. will a 24v solenoid be more reliable and easier to manipulate then a 5v solenoid

Pulse width modulation can be accomplished by rapidly turning on and off the mictorcontroller output in order to mimic a specific DC voltage or even a varying AC voltage. The below image illustrates basic PWM concepts.

IO Requirements

The I/O requirements for each modular design is determined based on the 12 keys that will need to be driven and monitored by the module's respective uController.


12 PWM Output pins are required to drive 12 driver circuits to provide analog control to all actuators.


12 Digital input pins are required to know when the user strikes each key. These can be matrixed if necessary to reduce the number of pins required. A 3x4 matrix can be used, which will reduce the number of pins to 7.


A high speed communication protocol is required to ensure smooth operation and no sputtering in play while "talking" with the main control board. As a result the acceptable existing protocols are listed below. UART with Baud rate greater than 38400 RS-422 RS-485 I2C CAN MOD Buss

Decision Making

Conclusion The MSP432P401R is what the group has decided to go with. We have come to this decision via the Pugh chart analysis. The MSP432 fits our needs the best, and through the coursework at RIT all the Electrical Engineers already have experience with TI's developing invironment.

Selecting a Microprocessor via Benchmarking

1. Raspberry Pi Model 3B

2. BeagleBone Black Rev C


Each of the processors listed above boast their own advantages and drawbacks. Upon careful consideration of the engineering requirements and project budget, the Raspberry Pi seems to be the most fitting option. The Beaglebone Black has no place in this decision; it's surplus of IO pins is simply not needed in this situation. The overpowered ODROID would really beef up the system, but that kind of processing power is unnecessary for the interpretation of a single MIDI file. Furthermore, having the Pi's on-board WiFi and Bluetooth at the team's disposal will open the doors for many development and user interface options.

public/Systems Level Design Documents/pughchart.png public/Systems Level Design Documents/pughchart3.png

Analyzing a MIDI File

Since MIDI files adhere to a standard format, there are numerous open-source parsing solutions. One option would be running a Node JS application on the Raspberry Pi (or equivalent microprocessor) to do the high-level processing. The node package manager (npm) already has several MIDI libraries available for download, the most promising of which seems to be Midi Parser.


public/Systems Level Design Documents/Budget Feasibility.PNG

This file is lays out what our most pressing design options are from a financial perspective. As an example of the use of this file, if one wanted to assess using Sparkfun solenoids, a MSP432 on demo board, a raspberry pi and the existing power supply for 2 octaves, one would use the cost/Octave for each of those options times 2(for 2 octaves) if the cost increases to do 88 keys, resulting in a cost of $179.86. The per octave per 88 keys distinction is used to highlight situations when there is no change for number of keys, i.e. only one main controller is needed for 1 key or 88, but you need an actuator for each key automated. With our budget it became clear that automating all 88 keys would use most if not all of our budget. Automating just 2 octaves is a much more financially sound plan, if we need to make hardware changes after already purchasing parts we will still have the financial flexibility to make those changes. Designing a modular actuation system that can be replicated for all 88 keys would enable the team to ensure the device has as many features as it can. In short, automating 2 octaves of the piano is the most financially feasible option.

Time Constraints and Extra Functions

We are following our project plan to the completion of our deliverables. However, we understand that there will be some time constraints that will limit our implementation of the extra functions of the piano. Some of these include:

We also acknowledge the issues of completing the design before the career fair in the spring. With that in mind, we have decided to focus on proper functionality in two octaves of the piano meaning 24 keys. With a scaled down version of the piano, we can put in as much functionality as possible.

Designs and Flowcharts

Risk Assessment


Design Review Materials

Include links to:

Plans for next phase

As a team, where do you want to be at your next review? What questions will you answer during the next phase?

Michael Riola:

Danny Buonocore:

Tim Doores:

Matthew Mack:

Scott Porter:

Tyler LeGacy:

Samraaj Singh:

Systems Design Review Presentation

Presentation Link

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation