P17214: Smart Mountain Bike Suspension
/public/

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

During the System-Level Design Phase, our MSD team planned to use functional decomposition to break down the customer requirements elicited in the Problem Definition phase from our customer and user interviews to determine what the individual subsystems would need to be capable of. A variety of alternative solutions for each subsystem were explored with the effectiveness of each weighed against the customer and engineering requirements drafted in the first stage of the project.

With the top few alternatives in mind, preliminary feasibility analysis was performed to inform the final selection of subsystem alternatives and to refine our Engineering Requirements. The selected system-level design and functional decomposition will aid in the development of individual subsystem components in future design phases.

Functional Decomposition

Using the engineering requirements and our understanding of the problem space gathered in the previous phase, the required functions of the system were determined. The flowchart below depicts the functional decomposition of the different components of the Smart Bike suspension system.







Smart Bike Functional Decomposition

Smart Bike Functional Decomposition

A live version of the document can be found here.

Benchmarking

The table below demonstrates the capabilities and features of both current and upcoming products, which aim to provide similar resolutions to our problem. Using what information we could find about the products previously identified in our earlier benchmarking research, we looked at the critical subsystems of the products and created the idea board below.

A benchmarking of competitive products

A benchmarking of competitive products

The products in the table above gave the team an idea of how each of the other companies created a solution to the problem at hand.

The Magura system relies heavily on wireless communication, individual batteries, and a limited autonomous mode. Each suspension product houses the battery and computing power to adjust itself, with a handlebar mounted remote to adjust each component manually.

The Fox Live Valve relies on a solenoid in the damper itself to instantaneously adjust damping characteristics based on the terrain sensed in real-time by front and rear mounted accelerometers. It can be run off of integrated Di2 batteries already used in mounted electronic shifting systems. There is a limited user interface, with a single button being used to adjust autonomous mode thresholds. There are no handlebar mounted controls or display

The LaPierre eiShock uses a front mounted accelerometer to control the rear shock mode. It is the most complicated system of any of those presented, with both a stem mounted screen and accelerometer and central controller, with bar-mounted control buttons as well. A proprietary battery, complicated cadence sensor, and inability to adjust the front shock make this system the least user-friendly and most cumbersome.

The Fox iCD remote creates the best user interface of any remote suspension control, with integrated and ergonomic controls and display, and well-contained motors to adjust the suspension. Power and data are sent to each of the components through a single wire, and it can be integrated into the existing power and display systems for Shimano electronic shifting.

A live version of the document can be found here.

Concept Development

Our team brainstormed multiple concepts and methods to automatically adjust the suspension system of a mountain bike, base on different types of terrain. We started by writing up a morphological chart with as many ideas for each sub-function possible. The early results of the brainstorming are shown below.

Brainstorming Morph Chart

Brainstorming Morph Chart

Using in-person brainstorming sessions and individual explorations, these concepts were developed and expanded to create the morphological chart in the section below.

Morphological Chart

Our team worked through all of the sub-functions identified in the functional decomposition and came up with possible solutions to those functions. This was then used to create our morphological table. This was used to help come up with a list of possible design concepts. These concepts were then compared to each other using a Pugh analysis to see which concept would provide the best solution for our customer. The morphological table was formed by making a list of the sub-functions that the system needed to solve the design problem. All of the possible ideas for each sub-function were then listed in the table. Our morphological table is shown below:

Morphological Table

Morphological Table

Using this morphological table enabled us to create a few system concepts. These concepts incorporated the various sub-function solutions that were generated in the Morphological Chart. The image below shows the three system concepts that were generated.

Concept Generation Chart

Concept Generation Chart

These three system concepts were generated were compared to each other to see which concept would be the best option. This comparison can be found in the Concept Selection Section below.

A link to the live document can be found here

Below are the 3 sketches that depict the possible components of each Concept from above. All components are drawn over an actual image of the Kona Hei Hei mountain bike.

Lidar Concept on Kona bike

Lidar Concept on Kona bike

Ultrasonic Concept on Kona bike

Ultrasonic Concept on Kona bike

Ground Feeler Concept on Kona bike

Ground Feeler Concept on Kona bike

Concept Selection

Concept Pugh Chart

Concept Pugh Chart

Above is the final Pugh Chart that was used to determine which design would be the best to go forward with. Note that the best design identified by the Pugh Chart is the phone based design. The low-cost sensor and reduced onboard hardware and processing power that would be provided by distributing processing load to a mobile phone make this design a winner for both weight, and price. The group at the moment does not have the specific expertise that is required to write a market-leading mobile phone application that would be capable of performing this function. Due to this technical limitation, we have decided to proceed with the Lidar-based system which will provide more accurate sensor technology coupled with an entirely self-contained system that is not reliant on having an expensive mobile phone present. With that said we do plan to look into the possibility of expanding the concept to include a mobile phone application. We will be looking into this technology to find sources that may help us with this option because it would be an extremely viable and marketable system given the current trend in phone technology.

Feasibility: Prototyping, Analysis, Simulation

Minimum Sensor Sampling Rate

Question: What is the minimum rate at which the forward facing sensor must take samples to notice a 6" log while the system is moving at 7 m/s

Assumptions:

  1. A 6" log is the minimum sized object for which the forward sensor must adjust.
  2. The worst case condition for the sensor seeing the log is when it is moving perpendicular to the measurement line.
  3. Because of the Nyquist-Shannon sampling theorem, the minimum frequency must be doubled to ensure at least two samples while the log is in view.
Log moving through the sensor's field of view

Log moving through the sensor's field of view

Moving at 7 m/s, the 6" (.1524m) log will move past a stationary reference point in .0217 seconds. At least one sample must be taken during this time period, yielding a minimum sampling frequency of (1/.0217)=45.9 Hz. Doubling this rate to ensure that multiple samples occur over the time period that the log is in view yields a minimum frequency of 92 Hz.

Result: A minimum sampling rate of 100 Hz will ensure that an obstacle of this size will be seen by the sensor. The Garmin Lidar-Lite v3 sensor is capable of ~3x this sampling rate, confirming its viability as a forward facing sensor. A majority of the ultrasonic sensors identified in research are not capable of measuring at this frequency

Minimum Sensor Distance Required

Question: What is the minimum range at which the forward facing sensor can "see" an oncoming object for the system to change the suspension in time?

Assumptions:

  1. maximum bike speed is 15 m/s
  2. Servo response time ~ 130 ms
  3. Lidar response time ~ 4 ms
  4. micro-controller processing time ~ 20 ms (worst case)
Bike moving forward at 15 m/s

Bike moving forward at 15 m/s

The minimum distance can be found by using the following equation: d=v*t, where v is the bikes max velocity and t is the max time it would take for the system to detect a change in terrain and change the suspension accordingly. The time t can be found by the following equation: t = servo response time + micro-controller processing time + Lidar response time. Knowing this, the total system response time is ~154 ms. Assuming the max velocity the bike will be moving is 15 m/s, the minimum distance can be found. The minimum distance is d = v * t = 15 m/s * 0.154 s = 2.31 m.

Result: A minimum sensor range of 2.31 m will ensure that the system can detect a object and change the suspension in time before the bike reaches the object.

Ideal Measurement Distance

Question: What is the ideal distance for the sensor to measure?

Assumptions:

  1. A signal to noise ratio (SNR) less than 20% will yield usable results
  2. The Garmin Lidar Lite V3 has a sensor accuracy of +/- 1%
  3. From the above analysis a 6" log is the minimum sized object to detect.

A 20% noise signal from a 15.24 cm object is ~3 cm. Measuring at a distance of 3m will give a 1% measurement error of 3cm at this range

Result: Measuring at a range of 3m will give us a SNR less than 20% when interacting with objects larger than 6". This value is also outside of the minimum sensor range identified above, which may allow for a higher max system speed.

Sensing Terrain via Lidar Analysis/Simulation

Diagram of Parameters used in Simulations

Diagram of Parameters used in Simulations

To test the feasibility of the forward facing lidar sensor a simulation was made where a function that represented the oncoming terrain was input. this simulation output the status of the suspension (locked = 0 or open = 1) and the values that the Lidar sensor would read. Below are some examples of how the system would react given different oncoming terrains:

A Simulation of a Rolling Terrain

A Simulation of a Rolling Terrain

The above image is a simulation of how the system would respond to rolling terrain. This is common a obstacle seen in cross country courses and is a good example of what the system would be subjected to in practice.
A Simulation of a Lip or Raise in Terrain

A Simulation of a Lip or Raise in Terrain

The lidar based system should respond well to a sudden change in height in the oncoming terrain. The image above shows a simulation of how the system would react to a sudden change in height.
A Simulation of a Hill

A Simulation of a Hill

The above image shows how the Lidar-based system would respond to a steep oncoming hill.

The most important use of the Lidar in the Lidar-based system is detecting the sudden change in terrain. This is the proactive aspect of our system. If once the bike itself actually hits the terrain that the Lidar sensed the suspension will already be adjusted. As the bike rides along the rough terrain the sensors on the bike will used to keep the suspension open or closed. It is not important that the Lidar sees past the initial change in terrain because it will be turned up while in rough terrain.

Here is a link to the code that was used to create these simulations.

Sensing Terrain via Accelerometer Simulation/Analysis

The total terrain sensing system will be a combination of both a proactive sensor and a reactive sensor. The reactive sensor that the group chose to use is an accelerometer. because an accelerometer measures acceleration, we can take the second derivative of the height of the terrain to get what the acceleration will be. This is the principal used the simulations below.
A Simulation of a Rumble

A Simulation of a Rumble

The above image is a simulation of how our system would respond to a rumble in the terrain using the accelerometers as sensors.

A Simulation of a Gradual Hill

A Simulation of a Gradual Hill

The above simulation illiterates how our system will not react to slight changes in the terrain. a good example of this would be if a gradual hill. if the rider is on a hill than he/she will want the system to be locked out so that they have maximum pedal power.

Ideal Housing Structure

Designing the structure that will be used to mount all the components of our project will be the best way to protect and secure the device from weather and normal mountain biking conditions. A custom design will allow us to make the structure a specific shape, and gave us a few possibilities with materials to use. The following types of materials were looked into and a 3D printed structure was determined to be best for our early product prototypes.

Housing Materials Table

Housing Materials Table

Worst Case Battery Duration

Question: Can a battery run the system for 3+ hours?
Battery Duration Feasibility

Battery Duration Feasibility

The above image shows the data assumptions for calculating the duration of a 6V battery powering the design. The battery can last for 1400 mAh and the system consists of 4 devices. The ideal duration the system will run for is approximately 4.2 hours. A realism modifier of .7 was applied to this duration to account for unexpected factors. The table assumes all devices are running at max specs for the entire duration the system is on.

Systems Architecture

On a very high level, the system architecture will follow the flow identified below.

 System Architecture

System Architecture

The oncoming and current terrain under the bike as well as user inputs will be processed to determine the ideal mode for each suspension part, with system data such as current mode and battery life outputted to a handlebar mounted display.

Designs and Flowcharts

The Flowchart below shows a more in-depth view of the system architecture from above. It is based on the functional decomposition above.

Concept Design Flowchart

Concept Design Flowchart

Power Flow

This section details the components of the system that will require distributed power from the battery. Power to the servo and sensor components is switched by the microprocessor to allow the system to limit power consumption while in manual mode, or when the battery is low.

Components:
Microcontroller: Receives data, processes, and makes decisions on the actions to take based on the data it receives.
Accelerometer: Measures acceleration in at least one axis
Battery: Supplies electrical power to the system
Regulator: Takes raw battery power and limits its voltage level and current
Fuse: Protects the circuit and the user from high current draw
Servos: Electromechanical devices that the system uses to control the suspension.

External System:
External Charger: Pre-existing charging system for charging spare batteries
Battery: Supplies electrical power to the system

 Power Flow Diagram

Power Flow Diagram

Risk Assessment

Updated Risk Assessment chart for phase 2.
Updated Risk Chart

Updated Risk Chart

Plans for next phase

Updated Gantt Chart

Updated Gantt Chart

Key Goals for Next Phase

Key Questions for Next Phase

Will lidar process the terrain fast enough?

Will the servos adjust the suspensions fast enough?

Is the accelerometer sensitive enough?

Individual 3 Week Goals

Each member of the team has mapped out their goals and tasks for the next three week phase of the MSD 1 project. Individual plans are listed below

Home | Planning & Execution | Imagine RIT

Problem Definition | Systems 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