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

Team Vision for Integrated System Build & Test Phase

This phase is for prototyping and testing the project as a whole, and ensuring that the different subsystems work together as expected. In the previous Subsystem Level Build & Test Phase, the team targeted the motors, power supply, and and I/O systems in testing and build planning. Due to various challenges, the build process was slowed as certain problems were addressed. In this phase, the goal was to accelerate building of the subsystems and test them according to the standards of the team's test plan, as discussed in the next section. 

All goals of this test phase were not fulfilled. There has been definite progress in the integration of the motors with the power supply. The motor mounts are in development, but have yet to be tested fully. There have been delays in PCB design and fabrication resulting in the control board also not having been built or tested, but all of the other key components are ready for that subassembly. A late redesign of the beat programming functionality was discussed to overcome a major problem in fabrication. 

Test Results Summary

The updated Test Plan for this phase can be found here:  Test Plan: MSD2 Integration Build & Test

During this phase, we were able to make substantial progress through the tests listed in this document.  The following advances were made since our previous phase review:

  • Space Compatibility Test:  As we have progressed with integrating our subsystems and creating the enclosures for our interfaces, we have been able to better ensure that the shape and size of our user interfaces are compatible with a standard wheelchair and an appropriate size for the hi-hat, snare and bass drums.  This test is considered to still be in-progress, as we continue to construct our system.
  • Fundamental Safety Test:  The team has advanced greatly in the construction and integration of our user interfaces.  With this being the case, we have reached a point where we can make sure that there are no sharp or jagged pieces with the user interfaces.  This test is ongoing as construction continues.
  • Ease of Construction Test:  Work done with subsystem integration during this phase has verified our plans to only include system components which are absolutely necessary to avoid complicating the setup/teardown process.  This test is ongoing as we continue with construction.
  • Simplicity Test:  Similar to the Ease of Construction Test, our work for this phase has verified that our system includes the minimum number of components and structures necessary, for the sake of simplicity of the design.  This test is ongoing as we continue with construction.
  • Motor Stress Test:  Using our system hardware and a function generator, we have confirmed that the motors activate at the needed speeds and beyond.  This test is now marked as complete.
  • User Interface Test:  Software testing with our system hardware has confirmed that the system responds correctly and promptly to user input.  This test is now ongoing as we work on incorporating the drums with the rest of our system.

Motor Testing

The h-bridge motor driver circuit was built and tested at multiple stages of integration, starting with an independent test using a function generator. The function generator was used as the activation signal for the motors, changing the direction of the current so that the actuator extends and retracts in consistent intervals. This test proved successful, and was useful for stress testing and determining the maximum capabilities of the motors. 

The basic demonstration was at 2Hz, which corresponds to quarter notes at 120 bpm. 

Link to video: 2Hz Frequency Generator Test

With proper functionality demonstrated at 2Hz, the motors were tested at much higher frequencies to confirm they will work at our highest tempo and extended use. The maximum frequency a single motor could see action is 6.67Hz, which is half-beats at 200bpm. The motor was tested at 10Hz, corresponding to 600bpm quarter notes and far beyond our maximum use case. 

Link to video: 10Hz Frequency Generator Test

Observing the motors operating at 10Hz verified they meet our speed requirements, and also revealed tangible heat generation under such a load. To mitigate this heat and preserve the life of the motors, current-limiting resistors will be added on the inputs to the h-bridges, and activation signal inputs will be disabled between strikes to block current flow. 

After independently testing the motors, the frequency generator was replaced with our microcontroller. The Arduino can control the motor's operation through the h-bridge using two output pins. When one pin is high and the other low, current will flow and extend or retract the motor, as expected.

Link to video: Slow Speed Test with Arduino

There are several locations in the motor control process where timing can be manipulated. For a strike mechanism, it is important that the drumstick doesn't make contact with the drum for very long, so the delay between extending and retracting the motor is set to 50ms. This provides enough overhead for the maximum tempo of 200bpm to be reached with consistent motor behavior. To verify that the motor can be activated according to a set tempo, a demonstration was set up at 100bpm.

Link to video: 100bpm Test with Arduino

The successful 100bpm test showed that internal delays in the motor activation process can be managed. An upper-limit test was set up to run the motor at 200bpm, again confirming timing accuracy.

Link to video: 200bpm Test with Arduino

Finally, stress testing was performed with the Arduino to show how fast it can theoretically be activated. These tests showed a relationship between the extend-retract delay and the distance of the extension, which may be useful in controlling the force at which the drum is hit. 

Link to video: Stress Testing with Arduino

With hard-coded automatic playing verified, the two user input sources were set up to control the motor. First, the button was tested to demonstrate that end-users will be able to control the motor themselves. 

Link to video: Button Test with Arduino and Motor

This test combined the light-touch button and motor, which showed how easy it is to press the button and get a fast response. The button was previously tested and assigned a 100ms debounce delay to eliminate erroneous readings, which means the combined delay of the button and motor retraction is approaching the upper-limit of half-beats at 200bpm, which requires 150ms between strikes. Fortunately, the expected use cases don't show a need for supporting such a speed for button control. Still, quarter notes at 200bpm were tested as a reasonable maximum supported with the buttons. 

The other input device is the tempo slider, which sets the tempo for automatic playback. The next test demonstrated that the motors will respond to arbitrary or changing tempos, working through the full range of 40-200bpm quarter notes.  

Link to video: Tempo Slider Test - Full Range with Arduino and Motor

Button Platform

The platform for the buttons will be what the end-users physically hold or use to interact with the drum device. Per established design, the three buttons will be mounted on this platform non-permanently. Velcro will be used to allow buttons to be placed anywhere on the platform, or be removed and held freely to meet as many students' needs and comfort as possible. 

The platform is cut out of plastic sheet, which is slightly flexible but also sturdy and capable of withstanding drops and bends. The corners on the platforms will be rounded out to remove sharp points, and the surface will be sanded to reduce transparency. Two models have been cut, aimed at different use cases. 

  • 12x8 inch: Standard, small platform that can hold all three buttons. Three strips of Velcro will allow for positioning customization.

  • 24x12 inch: Intended for use on wheelchairs or between tables, for students who don't want something in their lap or need a larger platform to improve accessibility. Up to four strips can be allocated for a wider range of placements.

Durability of the platform was tested by dropping it flat and on its corner. 

Video of corner drop test: Corner Drop Test

Video of flat drop test: Flat Drop Test

Power Supply Testing

Alongside testing the motors, our power supply was tested to verify it provided the power needed to run the motors at our target speeds.  The Vin pin on the Arduino was also tested, confirming that a 9V input voltage successfully powers the microcontroller, allowing for independent operation. The AC power switch was tested, but didn't work as expected due to missing fuses internally. Fuses were ordered and this functionality will be verified before delivery. 

Striking Mechanisms

With the motors ready, proper planning and testing for the striking mechanisms began. Testing and development focused on the bass drum, which is the heaviest striker and so could see additional impact and momentum considerations. The purchased bass drum pedal has a standard mallet designed for removal already, so we are co-opting the existing platform. Rather than using the foot pedal to pull the mallet down, the motor's actuator will be placed at the bottom of the chain. Once this design is verified early in the final phase, it will be tested for stability and the plan applied to the other two mounts. 

1/4" x 2' x 4' birch plywood was purchased to serve as the casing around the striking mechanisms so that the motors can be properly secured, as indicated in the example fixture. 

Beat Programming Functionality and Alternative Plans

The beat programming board's PCB was completed and ready during this phase, but a major problem manifested in the ordering process. Assumptions about the complexity and cost of the board proved incorrect, and our target vendor would be charging $10 per square inch for our 70 square inch board, far surpassing our budget. With this in mind, alternative plans were created to meet the requirements and expected functionality of the beat programming board while remaining in budget and requiring minimal time/design shifts. 

Preset Beats and Toggle/Hold Functionality

To provide automatic playing of the drums, the existing user input buttons could be used to start preset beats (quarter notes on-beat, off-beat, half-beat, etc) or switch between them. This could be done by toggling the button for students with limited dexterity, or holding the button. There are sufficiently many open pins on the Arduino to use 3-4 switches to select beat configurations as well and toggle between auto-play and user input modes. 

Capacitive Touch Screen Application

The beat programming board's design was inspired by the Chrome Music Labs Rhythm application currently in use by the class. Following this theme, an Arduino-compatible touch screen could be fit to the top of the control box, allowing beats to be selected and played as intended. This is the most expensive and potentially time-consuming alternative, but would be the most elegant. Libraries are available for interfacing with the touchscreen, though using the touchscreen removes an element of physical feedback that is important for students. 

Arduino Bluetooth + Phone Application

Similar to the touch screen application, a phone app could be designed that could connect to the device through Bluetooth. This would likely be a cheaper option, but would likely remove interactivity from the students. It also could see reliability issues depending on phone and Arduino Bluetooth connectivity. 

Arduino WiFi Module + Local Web Server

This approach mimics the current use of Chrome Music Labs projected on the Smartboard for students to interact with. The Arduino would host a website that resembles the beat programming board design so that beats can be selected and played on the device. This offers more interactivity, but could also see reliability and convenience issues due to the need to either connect the device to school WiFi or connect the computer to the Arduino's WiFi, which would disable all other internet services. 

These concepts will be vetted and decided on at this phase's review, due to the timing of when the beat programming board problem was discovered. All concepts are expected to fulfill the established requirements, but the decision will be based more on budget and time, as the rest of the project also needs to be completed and tested for delivery. 

Risk and Problem Tracking

Throughout the project, risk has been tracked and managed to inform decisions and testing. With the integration testing performed in this phase, the likelihood of many risks were lowered due to better knowledge of how components work and interact. In the final phase it is expected that some risks will be fully eliminated, and any remaining risks will be factored into documentation and maintenance resources.

Link to live Risk Management document: Risk Management

When risks manifest into problems, or other problems arise during development, the Problem Tracking spreadsheet is used to monitor the response. There were two updates on the problem tracking sheet in this phase:

  • Beat Programming Board PCB Cost (critical) - Fabrication of the beat programming board proved to be far too expensive. To resolve this problem, alternate plans for auto-play functionality are being proposed and discussed. Full resolution is expected following the end-of-phase review. 
  • Power Supply Switch (ordinary) - Initial integration between the power supply and the AC switch showed that the switch was unexpectedly bypassed. Further investigation about how the switch worked indicated that the device didn't include its own fuses for properly connecting the switch. Fuses have been ordered and the switch will be re-wired to resolve the problem. 

Link to live Problem Tracking document: Problem Tracking

Functional Demo Materials

Presentation for Review - Integration Build and Test Review.pdf

Peer Reviews

At the end of each phase, the team meets as a group to discuss and assess individual member performance during this phase. Each member is rated on a scale of one to five for their contributions and effort put forth during the phase. Positive and constructive feedback is recorded and discussed to uphold team norms. 

Plans for next phase

At the end of next phase, the team will demonstrate and handoff the completed project to the customer. The drum striking mechanisms will be tested fully striking the drums at different tempos prior to handoff. Risk tracking and following personal deadlines will have to be followed closely to ensure the team will be able to finish the project in time. 

  • H-bridge implementation for remaining motors
  • Drum striking mechanism testing
  • Final code testing and production (near completion now)
  • Package circuitry into control box

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. The next and final phase will see the project completed and delivered to the customer. Details on delivery are to be discussed during this phase review, but plans are in place for the device to fulfill all requirements and desired functionality. 

  • No labels