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

Intellectual Property Considerations

The Robotic Drum Assist is aimed at students with varying abilities, allowing and encouraging them to participate in music education. With this in mind, we would likely not be intending to patent or copyright aspects of the project (physical design, software interfaces), as we want it to be widely available and accessible to give students the experiences they deserve. 

Some parts of this project, may be covered by other intellectual property agreements. This will be elaborated on as we explore various options for the components making up the device. 

Team Setup

Our team is made up of two computer engineers, three electrical engineers, and one mechanical engineer. As noted in the member breakdown in the Project Overview page (here), we have discussed our team and individual strengths to come up with technical and non-technical roles according to our skills. The roles were assigned as follows:

Sofía QuiñonesElectrical Engineering

Testing and Verification Lead

Irfan PunekarComputer Engineering

Customer Relations and Aesthetics Lead

Yasha PavlovskiyElectrical EngineeringHead of Control Systems and InterfaceYXP2378@RIT.EDU
Hannah Van FleetMechanical Engineering

Mechanical Lead and Head of Purchasing

Josh AbramsComputer Engineering

Technical Lead and Documentation Manager

Mehmet KoksalElectrical Engineering

Lead Electrical Hardware Engineer


Team Values and Norms

The team has decided on several values to work and act by. 

  • Communication
  • Honesty
  • Having Fun
  • Accountability

These values aim to keep the team cohesive and productive. Team dynamics exercises were carried out to observe team traits and personality types, and the information gleaned from these exercises will be used to guide interactions with members and face potential challenges. 

As a team of engineers, maintaining a strict code of ethics remains extremely important. Ethical decisions will be discussed with the full team present, and all necessary outside resources (guides, MSD faculty) will be incorporated as needed. The team acknowledges that it also represents RIT and the Kate Gleason College of Engineering, and so it will conduct itself accordingly when carrying out interviews, speaking about the project, and traveling to the customer site. 

The team will work together to resolve personnel issues quickly and in an agreeable manner, and will consult higher conflict resolution resources (guide) when internal efforts are exhausted or a stalemate is reached. 

Project Plans & Schedules

The project was broken down into several tasks, and organized into a Gantt Chart to help identify project timing considerations. These tasks will guide our activities moving forward as we work to keep making progress and face challenges.

The full working document can be found here: Project Schedule Excel Document

Many of the tasks detailed in Phase 3 were given much more time to complete compared to the tasks detailed in the previous two phases due to the COVID-19 Pandemic.  Our team is finding new ways to meet via Internet in the midst of leaving campus and moving everything online.  This led us to be a bit more flexible with our deadlines.

Risk Assessment and Growth Curves

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

Other Team Resources

This project is supported by several organizations and groups, on and off campus. 

At RIT, eye-gaze research and equipment is accessible through experienced faculty and student organizations. 

  • BCI Research Team
  • Jeff Pelz (Eye-gaze system access contact)

Off campus, there are other interested parties and valuable resources.

  • Niagara/Orleans BOCES
  • Wayne/Finger Lakes BOCES
  • Preethi Vaidyanathan, Ph.D. (EyeGaze, Inc. Eye-gaze system expert contact)

Though we have decided as a team to focus on user interfaces which do not include Eye-gaze technology, these resources are still incredibly valuable and could be used in the future, should another group have the opportunity to expand on this project.

Meeting Minutes, Notes, & Actions

MSD I & II. Maintenance of records of team/guide meetings. This includes discussion, action items, decisions made, and work assigned.

  • 1/16/20 First Interview with Customer (Molly King)
  • 1/28/20 Phase 1 (Problem Definition) Review
  • 2/5/20 Site Visit and WKBW News Interview
  • 2/13/20 Follow-up Interview and Debriefing with Customer (Molly King)
  • 2/25/20 Phase 2 (System Level Design) Review
  • 3/24/20 Regroup Meeting to Plan for Virtual Semester - First Online Class Meeting
  • 4/2/20 Phase 3 (Preliminary Detailed Design) Review
  • 4/23/20 Phase 4 (Detailed Design) Review
  • 5/5/20 MSD I Gate Review
  • 8/20/20 MSD II First Meeting
  • 9/3/20 Phase 5 (Status Update/Build & Test Prep) Review
  • 9/28/20 Phase 6 (Subsystem Level Build & Test) Review
  • 10/26/20 Phase 7 (Integration Build & Test) Review
  • 11/20/20 Customer Handoff
  • 11/27/20 Phase 8 (Final Design and Conclusion) Review
  • 12/1/20 MSD II Gate Review

Peer Reviews

Individual team effort and progress will be evaluated through a peer review format. Team members will review each other, and these reviews will be shared with the guide so that critical problems can be addressed, and important feedback can be relayed to the necessary team members. These reviews will help keep team members accountable, and provide a way for any concerns to be voiced in a formal manner. 

Reviews will consist of acknowledging excellent behavior, progress, and interactions. It will also provide recommendations for improvements to make, aimed at helping to increase their effectiveness, efficiency, and cohesiveness within the team. These recommendations will be constructive, and team members are expected to make a reasonable effort in carrying out improvements throughout the next phase. 


  • Team will constantly monitor communication channels, both between team members and with guides, customers, and other project-related resources. 
    • Email will be primary communication method for communication with customer, guides, and other resources. 
    • Group chat on text-messaging apps (WhatsApp) will be primary method for inter-team communication.
  • Customer location and availability means that video conferencing will be used for interviews and review attendance. 
  • The team member appointed in the Customer Relations role will be responsible for handling communication with the customer and other contacts (faculty, other MSD groups). They will promptly relay all pertinent information to the team for discussion, as needed. 
  • Team members are expected to include (cc) all members and necessary contacts (guide, faculty) when conducting communication.
  • It is expected that pre-read materials will be provided to all known review attendees a minimum of one day prior to the review meeting. This includes providing relevant documents, presentation materials (slides), and links to notable entries in this Confluence Wiki.

Project Reviews

Review notes, preparation, and presentation materials are recorded in the page associated with that phase. These are located under the MSD I and MSD II sections of this wiki. 

  • No labels