Team Vision for System-Level Design PhaseDuring 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 Decompositionat this link.
- Sound quality
- Minimally intrusive
- Time of implementation
- Minimal actuation time
- Reliable Sourcing
Conclusion: Solenoids will be used for actuators
Feasibility: Prototyping, Analysis, Simulation
Method of Actuation
- Three types of solenoids as well as a homemade solenoid will be tested.
- Power during the strike of a key will be fluctuated to force a change in volume of the note
- Vacuum system to be pursued if solenoids unsuccessful
Parameters to Test:
- Speed of actuation
- How fast can a consecutive note be actuated
- Dynamics changes using dB meter
- Satisfaction of selection criteria
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 RequirementsThe 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
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
- Cost: $35
- Processor: 1.2 GHz 64-bit quad-core ARMv8
- RAM: 1 GB LPDDR2 at 900MHz
- On-board WiFi
- On-board Bluetooth
- 4 USB ports
- Cannot SSH over serial connection
- No on-board storage
- Slow RAM
2. BeagleBone Black Rev C
- Cost: $48
- Processor: 1 GHz 32-bit ARM Cortex A8
- RAM: 512 MB DDR3
- Over 70 GPIO pins
- 4 GB on-board eMMC storage
- DDR3 RAM
- Can SSH over serial connection
- Ethernet, but no on-board WiFi
- Only 1 USB port
- Cost: $74
- Processor: 2.0 GHz 64-bit octo-core Samsung Exynos 5422
- RAM: 2 GB LPDDR3 RAM
- Insane processor and RAM speeds
- 4 GB on-board eMMC storage
- 3 USB ports (2 of which are 3.0 at 5x speed)
- Can SSH over serial connection
- Supports UHSI micro SD protocol (2x faster than class 10)
- LED cooling fan and heat sink
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.
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.
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:
- Change tempo based on user input
- Read and follow dynamics from MIDI file
- Ability to pause and resume play of the piano
- Full functionality of 88 keys
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 #7 deleted as team was awarded work space needed.
- All other risks still prominent
Design Review MaterialsInclude links to:
- Presentation and/or handouts
- Notes from review
- Action Items
Plans for next phaseAs a team, where do you want to be at your next review? What questions will you answer during the next phase?
- Build CAD model
- Test force required for specified decibel level
- Design structure to hold solenoids
- Design structure for electric components and UI
- Benchmark different communication protocols between the microprocessor and individual microcontrollers - 1 hr
- Plan out and research different UI systems - 2 hrs
- Determine the feasibility of reading sheet music into program - 2 hrs
- Benchmark different input systems - 1 hr
- Calculate required force to hit keys and produce proper sound (1 hr)
- Work on 3D modeling of the design (2 hrs)
- Design ways to hold solenoids and improve rod/cable (2 hrs)
- Help with picking the proper solenoids to purchase (1 hr)
- Track purchases and finances (30 min)
- Wire up uController (MSP432) to control solenoid. - 2 hrs
- Benchmark existing power electronics solutions to solenoid control. - 4 hrs
- Design Feedback system for piano key presses. - 1 hr
- Research serial communication systems. - 4 hrs
- Test individual solenoid Types
- Evaluate Power requirements for system
- Feasibility of recycling current power supply
- Creating system architecture schematic
- Investigate software options for notes played feedback
- Investigate use of buttons inside the piano to provide feedback
- Work to integrate the main controllers to control the MSP432
- Ensure device power supply can actuate 10 keys at once.
- Benchmark solutions for reading MIDI files that are available via open source and compare to manual solutions.
- Determine manual techniques for parsing MIDI files, scrape existing projects to do a feasibility analysis
- Do a feasibility analysis regarding possibility of converting from PDF/images to MIDI structures
- Work with team to figure out output structure for the MIDI parser.