P16214: Bicycle Power Meter
/public/

Integrated System Build & Test

Table of Contents

After completing the subsystem build and test phase our MSD team noticed that we were a little behind our anticipated schedule. This led our team to add more meetings throughout the week to work on the subsystem testing. At this point in the testing our team is on the brink of integrating our subsystems together and testing them all as one integrated system. The main issue points that were focused on during this phase were the accelerometer testing and the strain gauge testing.

Team Vision for Integrated System Build & Test Phase

The team vision for the Integrated System Build and Test phase was to get our subsystem tests completed to the point to where we can test them as a whole system. Our team fell behind schedule due to unexpected issues seen within our strain gauge design and our accelerometer design. However, these issues are being resolved and are nearing readiness to be tested within the integrated system. Our team is planning to expedite these tests as much as possible to have our bicycle power meter functioning by ImagineRIT. Our team vision for this phase was also to come up with backup plans for the accelerometer in case the current plan to use the accelerometer to measure rpm does not work correctly.

Test Results Summary

As our MSD team continued to conduct our subsystem tests we continued to track our results of each test. The main issue items that were tested during this phase were the accelerometer test and the strain gauge circuit test. The test being conducted for the strain gauge was a static strain test to verify that our strain gauges can detect the correct amount of strain being put onto the crank arm. The accelerometer test was performed to verify that our accelerometer can detect the correct RPM as it is spinning around it's center axis. The results of the tests are described in more detail in the sub-sections below.

Strain Gauge Circuit

Continuing the static strain test from the last phase our team noticed an issue with the design of the orientation of the strain gauges. The original design of the strain gauge circuit had two strain gauges placed on top of the crank arm and oriented perpendicular to each other. Upon testing the team noticed an issue with this design.

The design containing the strain gauges perpendicular to each other would be ideal if all of the strain being placed on the crank arm were at the very end of the crank arm. This would cause one strain gauge to be in flexion while the other strain gauge would be in compression due to Poisson's ratio. However, our team noticed that when a rider is applying force on the pedal this causes the crank arm to twist rather than all of the force being applied directly down on the crank arm. This twisting action of the crank arm causes both strain gauges to react the same and therefore, the way our amplifying circuit was designed, it seemed as though we were not seeing any stain of the crank arm even though a force was being applied. This caused our team to redesign our strain gauge orientation.

Keeping with the idea of having one strain gauge in flexion while the other is in compression, our team decided to place both strain gauges in the same orientation but not one strain gauge would be placed on the top of the crank arm while the other strain gauge will be placed on the bottom of the crank arm. This will allow for both strain gauges to see the same amount of movement (flexion for one and compression for the other) regardless of whether the crank arm twists or not. With this new strain gauge design our team was ready to test if our strain gauges and amplifier circuit could accurately detect the amount of strain that we expect to see for our application. The following document shows how the Strain Gauge Test Setup was conducted.

The static strain test was performed by placing the crankset in a set of C-clamps with the crank arm oriented horizontally and parallel with the floor. With the crankset clamped in place weights were then hung from the pedal of the crank arm and our team documented the voltage values seen from the output of the amplifier circuit for the various weights as they were added to the pedal. As more weight is added to the crank arm our strain gauge circuit should see a linear relationship between the amount of weight being added and the voltage level that we see. The following images show how the static strain test was setup as well as how it was conducted:

public/Photo Gallery/Static Strain Test Setup.JPG public/Photo Gallery/Conducting Static Strain Test.JPG

After conducting the static strain test our team was able to see that our design will in fact be able to see the amount of strain that will be used in the application of the bicycle power meter. The following graph shows the results of the static strain test:

 Static Strain Test Results

Static Strain Test Results

The results of the static strain test show a very linear relationship between the voltage change and the added weight. This makes our team feel very confident that our bicycle power meter will be able to accurate detect the amount of power that a rider is producing while they are riding on the bike blender.

The complete results of the static strain test can be found in the Static Strain Test Results Spreadsheet.

Printed Circuit Boards

During the last phase our MSD team had ordered printed circuit boards (PCB's) for our strain gauge amplifier circuit. These PCB's were used in the static strain test to amplify the strain gauge signal coming from the wheat-stone bridge. Our team had used three of these PCB's during the static strain test. The results of the various PCB's being used can be seen in the Static Strain Test Results Spreadsheet as well.

The results of the static strain test shown above are for one of the PCB boards. The board that provided these results was the board that performed the best out of the three boards. Another board produced linear results shown above but then it seemed to saturate when the weight reached about 100 pounds. Also the third board that was created and tested provided inconsistent results.

At first our team thought that there may be inconsistencies between the manufacturing of each board but upon more testing our team was led to believe that the inconsistencies between the boards could be due to small differences in the wire-wound resistors that we are using in our amplifier circuit.

Accelerometer

The code for the accelerometer to detect RPM was created during the last phase and was able to be tested during this phase. In order to check that the code written for the accelerometer was producing the correct RPM a test was designed to rotate the accelerometer around it's center axis at a known RPM and to verify that the code was producing the same known RPM. The test was setup by placing the accelerometer on a breadboard with the bluno nano microcontroller and powering both of them using a battery. The breadboard was then placed in a lathe making sure to place the acceleometer directly at the center of rotation. The lathe then has known RPM's that we would be able to spin the acceleometer at and the bluno nano would then send the RPM calculated by the code via bluetooth communication to the bluno. With the accelerometer spinning our team was then able to see the constant RPM given by the accelerometer as it was spinning in the lathe. The following images show the test setup for the acceleometer test:

public/Photo Gallery/Setting up Accelerometer Test.JPG public/Photo Gallery/Accelerometer Test.JPG

After setting up the accelerometer test our team recorded some of the results that we were seeing with the accelerometer. Since the lathe that we were using in the lab was older, we did not feel confident that the RPM was calibrated to be spinning at the rate of what the machine said. For this reason we decided to measure the RPM's ourselves and then test the accelerometer's calculated RPM to our measured values. After obtaining the RPM values from the accelerometer our team was able to produce the results shown in the following graph:

 Accelerometer Test Results

Accelerometer Test Results

While the accelerometer was spinning in the lathe it did not produce a steady constant RPM but it did produce a range of RPM's. The graph above shows that the lower limit of the RPM's calculated by the accelerometer are very close to the measured RPM of the lathe. This made our team feel very confident that our accelerometer is producing results that will be seen in the application of our bicycle power meter. Our team plans to conduct a few more tests to try to get the accelerometer to give more consistent RPM values. Our team will also need to conduct testing to see if vibrations due to the bicycle moving will effect the RPM reading that is calculated by the accelerometer.

The complete results from the accelerometer test can be found in the Accelerometer Test Results Spreadsheet

Risk and Problem Tracking

As our MSD team continued our testing of the subsystems to prepare for the integrated system test we decided to revisit our risk assessment and our problem tracker. The up to date risk assessment can be seen below:

Updated Risk Assessment

Updated Risk Assessment

When our team looked at our risk assessment again we noted that our risks had not changed as we are nearing completion of our subsystems tests and are very close to integrating our subsystems into a whole system test. However as our team felt that our risk items have not changed we looked back at our problem tracker as problems continued to get solved and new problems arose. The following image shows our team's problem tracker:

Updated Problem Tracking

Updated Problem Tracking

The up to date and live documents for both the risk management and the problem tracking documents can be found in the Risk Management Document and the Problem Tracking Document.

Functional Demo Materials

As our MSD team continue to move closer to our end design through testing and correcting any issues that arise we have been documenting all of these changes and test results in our Test Plan Document.

Plans for next phase

As our MSD team gets closer to ImagineRIT and are nearing the end of MSD II we came up with a list of items that need to be completed by the end of next phase and ImagineRIT. The following list is a list of key items that need to be completed for our bicycle power meter to be fully functioning by ImagineRIT:

With this list of action items our MSD team hopes to expedite our testing and have our bicycle power meter fully functioning by ImagineRIT.


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