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

Team Vision for Subsystem Level Build & Test Phase

This phase is dedicated to evaluating and prototyping with early purchases with a focus on the subsystems. The subsystems targeted were the motors, power supply, and I/O systems, currently made up of the light-touch buttons, tempo slider, and tempo display. Additionally, time will be spent preparing for system integration, particularly the PCB for the beat programming board, control box arrangement, drum mounting mechanism. 

This vision was fulfilled, as the team tested components of the build as they came in and planned for assembly and integration after each test. There were difficulties in testing the motors, which lead to some important lessons regarding the relays and motor driver circuit that will be further tested and implemented in the next phase. Good progress was made on the PCB layout and control box arrangement, with the PCB ready for simulation and eventual testing of the beat programming board. 

Test Results Summary

The updated test plan for this phase can be found here:  Test Plan: MSD2

The test plan relates engineering requirements to tests, where the basic subsystem tests provide a foundation for higher-level integrated tests and more thorough fulfillment of requirements. The completed tests are summarized below:

Beat Generation Output Testing:

The Arduino was programmed to read the tempo slider's input and toggle an LED as a visual output. This further confirmed the process of reading the tempo slider, and showed that the microcontroller can output signals with proper timing. Timing was verified using a separate metronome application and observing the LED toggle each beat. The limits of the tempo range were tested (40 and 200 bpm), as well as common tempos between those ranges. 

Tested tempos:

  • 40 bpm
  • 60 bpm
  • 100 bpm
  • 150 bpm
  • 180 bpm
  • 200 bpm


Video: Tempo Timing Demo

Button Input Testing:

The light-touch buttons are to be the primary control system for the drum striking mechanisms. Before integrating with the motors, the method for interfacing with the buttons must be prepared first and the buttons themselves tested. All three buttons were plugged into a 3.5mm port, which were wired to the Arduino. Each 3.5mm jack has one pin connected to ground and one connected to an Arduino pin. There is a third pin that can be used to read that something is plugged into the jack, but there is no discernible need for such confirmation at this time. The button pins on the Arduino are set to pull-up mode so they read high by default, and then read low when the button is pressed. This means that no additional power is required to use these buttons. This reading strategy will also support any passive switch connected to the 3.5mm port. 

All three buttons operated successfully, and some useful insights were gained in testing. 

  • Buttons require a debounce delay to prevent accidental triggers. Testing shows 100ms delay was too short, 200ms should be sufficient. 
    • Debounce must be implemented in non-blocking delay checks in order to allow for simultaneous operation and to not impede other functionality
  • Caps on buttons screw on, but are relatively loose and easy to unscrew. This makes it easy to swap or clean caps, but adds some potential for students to unscrew cap through use or fidgeting.
    • Added as a potential risk.

Demonstration shows individual LEDs being toggled by each button.

Video: Button Test

Motor Testing

The motors and motor driver circuit subsystems were tested using one relay, as initially designed. The first relay used proved to be malfunctioning in some capacity, though it's undetermined if that was due to delivery or testing. The relay was swapped out and the new chip was verified, but a single relay was unable to drive the motor in both directions. New plans have been made to switch to arrange the relays in h-bridge configurations to drive the motors using 4 relays. Once more relays are acquired, we will be able to confirm their operation at max bpm, stress test the motors, and integrate them with the microcontroller. 

Power Supply Testing

Basic operation of the power supply was verified, testing the cord connection wiring and output with no load. The power supply can successfully output the voltage ranges needed for the motors and control circuitry. During integration, further stress testing will be performed. 

  • One consideration raised during testing was heat generation. The placement of the power supply in the control box will leave some room for ventilation, but the reality of a closed box and several motors running at our max tempo raises the risk of excessive heat generation. Stress testing with our sub-components will be performed in integration testing, and heat has been added as a risk to track. 

Development Updates

In addition to basic subsystem-level testing, work was spent preparing for the integration phase. This work included planning for strike mechanism mounting designs, PCB schematic and layout work, control box component placement, and software design considerations. These components will be expanded upon and included in prototyping and testing in the integration phase. 

PCB Schematic and Layout

The beat programming board is made up of 25 Cherry-MX keyboard switches with LEDs, a seven-segment display, and a tempo slider. To reduce the I/O needed to run the beat programming switches, a polled circuit was designed to read individual columns. This circuit will be implemented on a PCB to keep the design compact and neat, which also provides space for integrating other electronics into the PCB. 

Beat Programming Switches Schematic:

This schematic details the implementation of the toggle functionality of the switches as well as the poll-by-column strategy so that the circuit state can be read using only 4 input pins and 3 output pins. The PCB components involved in this design were placed on a layout design to act as a starting point for control box dimensions and to see where additional components can be added.

Spacing between switches is 2 cm horizontally and 1 cm vertically, making the layout relatively accessible. Current plans are to integrate the microcontroller into the PCB using header pins on the bottom of the board, reducing loose wiring. The Arduino footprint, slider connection, seven-segment display, and other external microcontroller pin connections will be added during integration. 

Control Box Layout

The beat programming board will serve as the main control box for all control and power components, keeping the overall system more compact and protected. To accomplish this, we are planning a tiered layout inside the control box. The bottom will contain the power supply and external connection, with a gap above it for ventilation. Next, power and motor circuitry will be mounted. At the top of the box, the PCB with the Arduino integrated underneath will be secured, with the beat programming board extending out the top and the external button connectors and motor wiring given proper cutouts on the sides. Current estimates see a minimum box size of 20x35 cm and a thickness of 7 cm, which is subject to change per power supply ventilation testing and power circuitry layout requirements. 

Software Considerations

Throughout basic testing using the microcontroller, observations were made that will inform the final software design. 

  • Non-blocking polling: Due to timing requirements and the need for button inputs and motor outputs to be read or written simultaneously, functions responsible for polling or writing to devices must not place a hard lock on CPU time. This means other functions must be able to run while another is undergoing a delay period. 
    • Cannot use hard delay instructions, instead check the current count of the internal clock to see if enough time has passed
    • Use a basic scheduler loop where each operation (checking for button input, reading beat programming board switches, writing motor outputs) is checked in a single loop, and individual operations simply will not execute until their timer has run out. This keeps near-simultaneous functionality and allows for a hard time limit to be set at the bottom of the loop. 
  • Software timing constraints on motors: If testing reveals difficulties for motors or certain instruments running at their max speed, software blocks can be implemented to prevent motors from overextending themselves without changing the allowable input range. For example, if the bass drum cannot operate at 200 bpm, the software can regulate its strike time independently while still allowing the snare or hi-hat to operate at the desired tempo.
    • Need for this functionality to be confirmed with motor integration

Risk and Problem Tracking

As testing and prototyping begins, project risks will be addressed and updated. The integration phase will see the likelihood of risks decrease as testing reveals solutions or eliminates potential problems. 

Risk Management Live Document: Risk Management

New risks:

  • Loose screw caps on buttons
  • Power supply heat generation

As testing continues, some risks may manifest as problems that require special attention to resolve. These problems will be tracked in a new Problem Tracking document, which provide a way to monitor a problem, discuss potential solutions, and monitor the results of implementing those solutions. 

Problem Tracking Live Document: Problem Tracking

New problems:

  • Budget Frozen (RESOLVED)
  • Motor Testing Difficulties (problem resolved, testing ongoing)

Functional Demo Materials

Presentation for Review - Subsystem Level Build and Test Review.pdf

Peer Reviews

At the end of each phase, the team completes peer reviews, during which they discuss and evaluate each member's performance.  The team works together to rate the contribution of each individual for this phase, assign a score from one to five, and make notes of things they did well, as well as how they can improve for the next phase.

Plans for next phase

At the end of the next phase, the team should have the control/beat programming board and drum strikers completely built. Core systems will be integrated and ready for a functional demo. A plan will be made to complete design and prepare for delivery. We will have to closely track our risks to ensure we stay on schedule and continue testing throughout.

Each team member has filled out three-week plan documents and attached them below. These documents allow us to reflect on what we have done in the last phase and plan for the next phase. 

  • No labels