Original and live documents for all of the following sections can be found in the Problem Definition Documents directory. Also for a breakdown of the work containing items such as the team schedule, expectations from the team, and preliminary risk management these items can be seen at the Planning & Execution page.
Team Vision for Problem Definition PhaseAt the end of this phase, we want to have a solid, finalized version of our problem statement, customer requirements, and engineering requirements. We also want to provide ourselves with a clear, well defined path moving forward into the next phase which is the System Design Phase.
Project SummaryA bicycle power meter is a device used by professional and amateur cyclists in order to show the cyclist their power output on the bicycle. The RIT Cycling Team approached this MSD team to provide a power meter for their ImagineRIT bicycle blender exhibit. Their desire is to have this device take the input force from the cyclist and display their power output and calories burned. The current devices on the market which provide these features are not quite instantaneous. There is a lag associated with the time between the rider exerting force on the bike and when the rider receives feedback from the system.
The goal of this project is to develop a functioning power meter for the bicycle blender exhibit. In order to achieve this task the MSD team aims to improve upon the communication speed between the power meter sensors and the display in existing devices. This will assist in achieving a more instantaneous system and closer to real-time display.
The following is a link to a one page summary for this project. This one page summary then led to brainstorming ideas for the various ways in which this device could be used.
Use CasesThe use scenarios that were thought up by the MSD team are shown in the following photos:
The original document for the use cases of the bicycle power meter as well as the revisions that were made to the use scenarios can be found within the Use Scenarios sub-directory.
These use scenarios then allowed for the MSD team to be able to provide some project goals and key deliverables that would be needed to satisfy the use of the bicycle power meter in each of these various situations.
Project Goals and Key DeliverablesThe key deliverables and the expected outcomes of this project are shown below:
- Develop a finished, working product
- The finished product will meet all customer requirements
- The finished product will be user friendly for both the primary customer (RIT Cycling Team) and end users (ImagineRIT visitors and professional/amateur cyclists)
- Successful presentation/exhibition at ImagineRIT
- To create an easily perceived link between the power exerted when cycling and the health benefits (i.e. calories burned)
- To improve upon current power meter technology
(available on the market)
- Increase communications speed between the meter itself and the cycling computer
- Develop a more portable/easily removable and installable product
After a set of key deliverables were created it was time to take these goals to our customer, the RIT Cycling Team, and ask them a few questions to gain a better understanding of what they desired in our device which would be used in their ImagineRIT exhibit. The goal of these questions was to discover what features we would want to include in this device that would satisfy our customers needs.
Customer Interview Questions
- What data does the rider need to see?
- What data should be displayed?
- How accurate do you want the data to be?
- Is there a preferred location on the bicycle for the device to be placed?
- What are some of the constraints that you see with this device?
- What types of improvements can be made from existing power meters?
The outcome and takeaways from the customer interview can be found here. This interview with our customer then laid out a solid foundation for us to define the customer requirements for this project.
Customer Requirements (Needs)
The purpose of the customer requirements is to take the outcomes from the customer interview and to put these needs into a list of priority items. All of the high priority customer requirements will be incorporated into the device and the low priority items will be incorporated based on practicality, budget, and available time to add these to the design.
The details of the customer interview that led to the customer requirements, the preliminary customer requirements, as well as the live document for the customer requirements can be found in the Problem Definition Documents sub-directory.
Engineering Requirements (Metrics & Specifications)After completing the Customer Requirements, these were then used to form the Engineering Requirements. The Engineering Requirements are quantitative and have values that are measurable and testable that will be used to assist in the design of the deliverable product to our customer.
The live document for the Engineering Requirements can be found using the Problem Definition Documents sub-directory. Creating the Engineering Requirements for this projects also encouraged the MSD team to be conscious of the possible constraints that could be involved with this particular project.
ConstraintsThe constraints for this project are as follows:
- Budget ($1000)
- Complete by Imagine RIT
- Must use metal crank arm (not carbon)
- Wireless communication between daq and display
- Must be compatible with bike blender
- Cannot interfere with user pedaling
- Battery powered
- Elastic Modulus of crank given
- Poisson’s ratio of crank given
- Shear Modulus of crank given
- Has a display
- Has external display capability
- Has a reset button
- Has error messages
- Meets IP43 standard
House of QualityAfter laying out both the customer and engineering requirements it was necessary to match up each of the engineering requirements to a particular customer requirement. The reason for doing this is to ensure that all of the customer requirements will be met and incorporated into the device. Another reason for performing this is to ensure that we are not adding any engineering requirements into this device that serve no purpose in satisfying our customer.
The live document as well as the previous revisions for the House of Quality can be found within the Problem Definition Documents sub-directory of the Problem Definition Documents.
RisksThe following are potential risks that our MSD team could face during this project:
- The power meter is unable to communicate with the display
- The power source is unable to last for 10 hours
- Moisture and dust could damage the device
- Lack of app development knowledge
- Lack of funding to produce quality materials
- Do not complete the working product on time
- Over-exertion of rider on the bicycle
- Bicycle falling off of the stand
- Pinchpoints from moving parts on the bicycle
- Electro-Magnetic Interference with the device signals
Design Review MaterialsAfter the Gate Review for the problem definition phase our MSD team had some key points and feedback to take away from the review. The following are the main topics and feedback that was provided to our MSD team from the review panel:
- We were advised to keep pursuing other strain gauge
- There was the concern that we were making final decisions too soon
- The panel wanted us to explore all other options for our design, and not thinking strictly of stain gauges as a way to measure force
- The panel wanted us to look into a torque sensor as another way to measure force other than strain gauges
- There was the worry that we were already to the end of the next phase, being the design phase
- We were also urged to notice some of the differences between constraints vs. customer requirements
- We have scheduling and budget as constraints when we may want to include these as requirements
- We should try to make all of our engineering requirements test-able and measurable
- Try to think of ways around "user-friendly" to make it more test-able
- Properties of the bike parts or the metal would be constraints, not engineering requirements
These notes from the gate review led our team to go back to our problem definition items such as the customer requirements, engineering requirements and constraints to review them and update them with correct elements in each category. This led our team to develop a list of key action items as well as plans for moving into the next phase of the project.
- Action Items
The document for the notes from the gate review can be found within the Problem Definition Documents page.
Plans for next phaseThe MSD team also came up with a defined path moving forward for the next phase of this project. This path moving forward will help this team as we complete the system design as the next phase. Our path moving forward is as follows:
- Calculate expected strain range
- Based on 0-2000W and aluminum crankset
- Research strain gauge specs and prices
- Focusing on gauges that work well with aluminum, and measure accurately in our expected strain range
- Research RIT iPhone app writing rights
- Research possibility of in series connector for
non-drive side strain gauges
- Focusing on minimizing the interference in the signal transmitted through the connector. An amplifier placed between the gauges and the connector may solve this.
- Research accelerometer/gyroscope specs and prices
- This will be used to sense the angular velocity of the crank instantaneously
- Research microcontroller specs and prices
- Research battery for sufficient life and power
- Must be fully functional for 10+ hrs
- Gather bike crankset parts
- Draw preliminary design in CAD
The original document can be found here.