P16214: Bicycle Power Meter
/public/

Systems Design

Table of Contents

The problem definition phase helped to lay out our path moving into the systems design phase. The problem definition phase resulted in our MSD team having criteria and requirements for which our design has to meet. This page shows the progression that our team faced when deciding on a full system design for our bicycle power meter.

Team Vision for System-Level Design Phase

Our MSD team vision for the System-Level Design Phase is to produce a finalized system concept that will meet our key customer requirements. We were able to talk as a group to process through various design concepts that were good and some that were not so good. The basis for determining if a design was good was dependent on if it met the basic customer requirements as well as a preliminary feasibility analysis to see if the design would be possible to create within the time frame. Our selected systems design concept will aide our subsystem design phase to make finalized subsystem design concepts in the next phase of this project.

Functional Decomposition

To begin the systems design concept generation it was necessary to break down the purpose of this product into its various functions and sub-functions that it will need to perform in order to complete the desired task at hand (to record the riders output power and to display the riders power and calories burned). Each function and sub-function will be design so that it will met the key customer and engineering requirements. Our team was able to break the function of the power meter into four main functions which are that the device has to measure mechanical power, transmit data, process data, and then display data. These four functions were then broken down into smaller sub-functions as to how each of these four functions would be completed. The rest of the functional decomposition including the functions and sub-functions of the power meter can be seen below:

Functional Decomposition for the Bicycle Power Meter

Functional Decomposition for the Bicycle Power Meter

The results of this functional decomposition allowed our MSD team to start to generate ideas for possible design concepts that could perform all of the functions and sub-functions that we had come up with.

Original Documents

The original document for our functional decomposition as well as our preliminary draft of the functional decomposition can be found in the Functional Decomposition sub-folder of the Systems Level Design Documents folder.

Benchmarking

The purpose for benchmarking is to look at other existing products to see their performance and then to see how our device could improve upon these. The reasoning behind benchmarking is also to find out if there are any concept options or solutions that have already been created which we could incorporate into our design and also improve upon it. We specifically looked at certain functions and features that we want to incorporate into our design and looked at other existing products to see how they performed in these particular categories. The following image shows the existing products and categories/functions that we will be using to benchmark the performance of our device.
Benchmarking

Benchmarking

Original Documents

The original and live documents for the benchmarking spreadsheet can be found here.

Concept Development

After our MSD team had created the functional decomposition we then started to generate ideas for a concept that would perform these functional and sub-functional tasks. This involved taking a look at each sub-function and thinking of ways as to how we could accomplish this task. For example, with one of our sub-functions being to mount sensors to the bicycle we thought many different locations where we could mount a sensor to the bicycle in which it would be able to perform its objective. The rest of our concept generation ideas can be seen in the image below:

Concept Generation for the Bicycle Power Meter

Concept Generation for the Bicycle Power Meter

Morphological Chart and Concept Selection

After brainstorming a large list of possible concept ideas, this would be used to set up our morphological table which would be used to help our MSD team design a list of concepts. These concepts would then be compared to each other to see which concept would provide the best solution to our problem for our customer. The morphological table was formed by making one axis a list of the functions and sub-functions that our device needs to perform that were thought of in the functional decomposition. The other axis of the morphological table contains the ideas that were generated for each function or sub-function. Our MSD team morphological table looked as shown below:

Morphological Table

Morphological Table

Using this morphological table that we generated then allowed us to create full system concepts. Using the snake method to choose a feature for each function or sub-function then provided us to generate four system concepts. These concepts incorporated the various concepts that we generated and will each perform the set of functions and sub-functions that we had determined that the device needs to accomplish. The image below shows the four system concepts that were generated by our MSD team.

Concepts that were Generated from the Morphological Table

Concepts that were Generated from the Morphological Table

These four system concepts that were generated were then compared to each other to see which concept would be the best option to perform all of the functions as well as to see which concept would be the most feasible to accomplish.

Original Documents

The original document for our morphological table can be found in the Systems Level Design Documents.

Concept Selection

After using the morphological table to generate system design concepts we then compared these designs against each other to see which design would be more practical to create and would also satisfy all of the key customer and engineering requirements. This comparison against the various concepts was taken a look at using Pugh analysis. Pugh analysis is performed by looking at a list of selection criteria taken from a group of items ranging from the customer requirements to constraints that we are faced with during this project. The selection criteria that was used for this Pugh analysis are as follows:
Pugh Analysis

Pugh Analysis

After our MSD team came up with a list of selection criteria that we felt were the most important for a successful completion of this project, we placed these into our Pugh analysis. Each concept is compared to the other concepts to see how they gauge in performance against each other in regards to the selection criteria. The concepts are then compared by using non-numeric values such as 'pluses' and 'minuses' to gauge their performance. The image above to the right of the selection criteria shows our Pugh analysis to compare our system design concepts to see which design is the best fit for our customer.

Original Documents

The original documents as well as the live documents for both the selection criteria and the Pugh Analysis table can be found within the Pugh Analysis sub-folder of the Systems Level Design Documents folder.

Systems Architecture

The systems architecture shows our design flow from how the device receives the input data all the way to how the device will output the processed data. The systems architecture shows each of the main functions as thought of from our functional decomposition. The systems architecture also starts to define the subsystems and how these systems will interface with each other. The subsystems will be further designed in the next phases of this project. The following image shows the systems architecture for our bicycle power meter.

Systems Architecture

Systems Architecture

Feasibility: Prototyping, Analysis, Simulation

Once the concept had been chosen for the systems design it was necessary to perform some feasibility analysis to ensure that this design would be possible to make within the time frame as well as to see if the selected design will be able to meet the customer and engineering requirements. This led the MSD team to ask a set of questions and then be able to answer them using analysis. The list of questions that our MSD team desired to look further into are as follow:
  1. Question: How much power will the bicycle power meter consume?
    • Assumptions:
      • Need the device to last for minimum of 10 hours for ImagineRIT
    • Analysis:
      • Will be based on what team chooses to measure force/ power (i.e. Strain gauge vs load cell)
    • Solution:
      • Will be narrowed down once concept is finalized
  2. Question: Can the device be removed from the bicycle?
    • Assumptions:
      • The device is attached to a part that can be removed from the bicycle or swapped between bikes
      • The communication range of the device is large enough to span one end of the bicycle to the other, where the display will be
    • Solution:
      • This would be solved by researching and performing analysis on various sensors to see how big and small of sizes these sensors can be packaged. The next step would be to perform analysis on various parts of the bicycle to see which parts can be easily removed from the bike and to determine the various types of sensors and sizes of sensors that can be placed on that particular part.
  3. Question: What temperature ranges will the device need to operate and be stored in?
    • Assumptions:
      • Running for no longer than 10 hours at a time
      • Bike Blender will be used and stored in Rochester, NY
      • Bike Blender used in May
    • Analysis:
      • Avg. high temp. in Rochester in May: 68F
      • Avg. low temp. in Rochester in May: 46F
      • Record high temp. in Rochester in May: 94F
      • Record low temp. in Rochester in May: 26F
      • Record high temp. in Rochester ever: 102F
      • Record low temp. in Rochester ever: -22F
    • Solution:
      • Our device must be able to operate within -22F - 102F at the very minimum; we should allow some room for error/new records.
  4. Question: How much lag time will the system have?
    • Assumptions:
      • Using multiple off-the-shelf sensors/devices
      • Using a microcontroller
      • Using wireless communication
    • Solution:
      • Without knowing the final system design and all of its subsystems, it is impossible to determine an estimated lag time for the system. Once the design is finalized and we begin to create prototypes for the subsystems, the lag times can be measured and added together to get an overall system lag time.
  5. Question: How much strain will be placed on the top of the crank arm?
     Drawing for Crank Arm Strain Calculations

    Drawing for Crank Arm Strain Calculations

    • Assumptions:
      • Force of 624N applied at end of crank arm
      • Crank arm length (172.5mm)
      • Crank arm thickness (20mm)
      • Assume cantilever beam
      • Elastic modulus of aluminum 69Gpa
    • Solution:

M=.1725 * 624 = 107.64 N­M

I= (bh^3)/12 = (.020 * .040^3)/12 = 1.07*10^­7

strain= MC/EI

= (107.64 * .020) / (69*10^9 * 1.07*10^­7) = .00029m

Original Documents

The original feasibility analysis document can be found in the Systems Level Design Documents folder.

Designs and Flowcharts

Refer to the Systems Architecture above.

Design Review Materials

The presentation that was used for the Systems Design Phase gate review can be found at our at the following link:

https://docs.google.com/presentation/d/1y7h3ZBUeZFQ1tM7cPPbX6Sq6eGMui-LXlqgeS4Slhi4/edit?ts=56043f24

Notes from Review

After our MSD team completed the gate review we were left with some notes from the review panel. The take-aways from this review are as follows:

Plans for next phase

As our MSD team moves into the next phase, the Subsystems Design phase, we want to start thinking about the concepts that we will use in our subsystems. In order to accomplish this we will need to research various methods to perform our sub-functions of the functional decomposition. The following is a list of tasks, including research, that we will achieve in the next phase of the design to generate concepts for our subsystems.

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Subsystem Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation