1. Performance AutoShift System (P.A.S.S.)
13 July 2019
Performance AutoShift
System
(P.A.S.S.)
Members: Kody Glass, Rachael Bernyk, Mark Bissey
Faculty Advisor: Paris Wiley, PhD
Introduction of group members and project

2. 1: Performance AutoShift System
13 July 2019
1: Performance AutoShift System
A new form of an automatic shifting system that works with mechanical derailleurs and off the shelf drivetrains
Requires little to no retrofitting of a bicycle’s preexisting components
Briefly reintroduced our project for those who were not present for our first presentation. Kody explained that our project is based off of automatic shifting systems that already exist, we are just trying to make our system a bit more cost effective. We want to make sure that the system we build is easily transferrable so that people can attach it to bikes that they already own.

3. 13 July 2019
1: Goal and Market
Create a product that can be used in higher performance cycling, specifically cross country mountain biking where frequent, well timed shifting is important
For consumers looking for a relatively inexpensive alternative to high priced electronic shifting systems such as Shimano Di2 or Campagnolo EPS
Kody explained the goal of our project; we want to create an item that can be used in high performance cycling such as mountain biking or cross country biking. These types of cycling specifically require frequent and well timed shifting, so having the added features of an automatic shifting system would greatly benefit the rider in these conditions.
As well as our goal, Kody addressed the audience that we would like to target. This audience would be those looking for a cheaper alternative to the existing shifting systems already on the shelf, such as the Campagnolo EPS or the Shimano Di2.

4. 2: Project Driving Requirements
13 July 2019
2: Project Driving Requirements
Optimum Automatic Shifting Conditions; Eliminate unwanted shifting.
Two hour minimum battery life.
Quick, smooth shifting to pre-indexed shift locations.
Data recording and programmable rider preferences.
Motor must be powerful enough to move the derailleur its full range.
We decided that our top 5 driving requirements included the following:
Optimum Automatic Shifting Conditions
Two hour minimum battery life
Quick, smooth shifting to pre-indexed shift locations
Data recording and programmable rider preferences
Motor must be powerful enough to move the derailleur within its full range

5. 2: Optimum Shift Verification
13 July 2019
2: Optimum Shift Verification
Shift Conditions:
Cadence ±10% of preset user cadence setting. (Example: Preset = 90 rpm; shift up at 99 rpm or down at 81 rpm)
Shift if pedaling and the speed changes to a speed that matches that of the of the preset cadence at the next gear ratio. (Example: Freewheeling/Coasting on flat ground. Even if the user is pedaling slower than needed to engage the freewheel hub the system will shift to the optimum gearing for that speed.)
User selected shift. The shift action will be stored until the user is pedaling or cancels the shift command.
For the first driving requirement, we want to make sure to eliminate unwanted shifting. To do this we need to specify certain shift conditions. The cadence will be +/- 10% of the preset user cadence setting. Also, we will make it so that the bike shifts according to the travel speed and pedal speed in order to give it optimum usage. While an automatic shifting system is what we are aiming for, we realize that there will be bikers who still enjoy to shift the gears manually. Because of this, we will include the option of user selected shifting. This shift action will be stored until the user is pedaling or cancels the shift command.

6. 2: Optimum Shift Verification
13 July 2019
2: Optimum Shift Verification
No Shift Conditions:
Coasting and not pedaling forward.
Power input overloaded (Limits will be set after testing)
Power level measured using a power estimation formula PTotal = PRolling Resistance + PWind + PGravity + PAcceleration
MEMS Accelerometer, Gyro and Barometer will be used to sample real time ride conditions.
Constants will be used for values like rolling resistance and wind resistance
As opposed to shift conditions, there will also be no shift conditions. The system will not automatically shift gears if the bike is coasting or not being pedaled forward. Also, if the power input is overloaded, there will be no automatic shifting to take place. Once the limits are tested, values will be provided for the maximum power input.

7. 2: Battery Life Verification
13 July 2019
2: Battery Life Verification
Overestimations of constant current draw:
Screen – 150 mA
Motion Sensors – mA
Motor Control – 320 mA
Motor – 62.5 mA
If shifting twice per minute and at max motor current of 15 amps
Total = mA
Battery Capacity = 2000 mAh
Battery life = 3.4 hours
Battery life (using Digi-Key formula) = 2.38 hours
(30% additional estimated current draw)
For our second driving requirement, we would like our battery life to exceed a minimum of 2 hours. We realize that there will be cyclists that want to ride for longer than two hours, which is why we would like to maximize the battery life as much as possible. In this slide, we have provided an overestimation of what we believe the battery life will be. The values for these calculations are based off of the parts we will use, and calculated using the Digi-Key formula. The battery life we obtained here exceeds 2 hours, and also accounts for an additional current draw of 30%. Due to this, we are quite confident that we will be able to obtain a battery life of more than 2 hours.

8. 2: Shift Action Verification
13 July 2019
2: Shift Action Verification
Motor Speed:
Max Speed rpm
kv= 1293 rpm/V
Speed Needed to Move One Gear in 0.25s
Rotations Needed = 15
Distance to move = 1.5 cm
Worm gear pitch = 0.1 mm
RPM Needed = 3600 rpm
Duty Cycle needed from 11 Volt Battery
3600 rpm ÷ 1293 rpm/V = 2.78 V
(2.78 V ÷ 11 V) x 100% = 25 % Duty Cycle
(True values will be verified with testing)
For our third driving requirement, we chose shift action verification. We’ve calculated the duty cycle needed from an 11 volt battery as 25%. These are just rough calculations for now and will be verified during our testing stage.

9. 2: Data Recording Verification
13 July 2019
2: Data Recording Verification
The TFT screen being used includes a microSD card port
Even microSD cards in the Mb range will far exceed the data storage capacity need for this project
Must be a FAT16/FAT32 formatted microSD card
The microSD card can be read/written from any digital pins or the MISO/MOSI pins of the microcontroller.
As our fourth driving requirement, we chose data recording verification. We would like our automatic shifting system to be able to record data as the cyclist rides. The TFT screen that we will use includes a microSD port in which we plan to use for recording data. The microSD cards in the megabit range will exceed the data storage capacity that we will need for this system. The model of SD card that will be needed for this data storage is a FAT16/FAT32 formatted card. These cards can be read/written from any digital pins of the microcontroller.

10. 2: Motor Strength Verification
13 July 2019
2: Motor Strength Verification
Minimum force limit is about 36.7 N
Motor Stall Torque = N ● cm
Mechanical Advantage of Worm Drive = 31.42
Screw Diameter = 1 cm (Motor arm = 0.5 cm)
Lead of Screw Thread = 0.1 cm
Estimated Max Force of System = N
(Stall Torque x M.A.) ÷ (Motor Arm Length)
And as our last driving requirement, we chose motor strength verification. We calculated the estimated maximum force of our system to be about N. These calculations will also be verified during our testing stage.

11. 3: System Prototype Sketch
13 July 2019
3: System Prototype Sketch
Here is a sketch of our prototype drawn by Kody. It demonstrates the different parts that will be used and how our system will be put together.

12. 13 July 2019
3: System Diagram
This system diagram illustrates the microcontroller that we will be using and its different pins.

13. 4: Project Technical Trades
13 July 2019
4: Project Technical Trades
Lidar triangulation for terrain deemed unnecessary, noting premeditative shifting is not needed
Moved from servo to a brushed motor with a worm drive to eliminate stiction and increase battery life
Servos need current to hold position
Worm drive allows the motor to turn off after it is in position
Using potentiometer to monitor motor/derailleur position
Chose to use the Teensy 3.1 over other microcontollers for its compact design and extensive features.
64 kb of RAM, 72 MHz Processor, 34 Digital I/O pins, 21 Analog input pins, SPI and I2C (2) communication, etc…
Uses Arduino IDE and libraries with limited modification needed
1.4” x 0.7 “
The technical trades we made are listed here. We determined that the lidar triangulation for terrain was unnecessary due to premeditative shifting not being needed. We’ve also moved from using a servo to a brushed motor with a worm drive in order to eliminate stiction and increase the battery life of our system. We made this decision based off of the fact that servos need added current to hold its position while the worm drive allows the motor to turn off after it’s in position. We chose to use the Teensy 3.1 instead of other microcontrollers because of its compact design and its extensive features. Some of the added benefits of the Teensy 3.1 include 64 kb of RAM, multiple analog input pins as well as digital I/O pins, its small structure, and its use of Arduino IDE.

14. 4: Project Technical Trades
13 July 2019
4: Project Technical Trades
The motor driver is going to be designed and built instead of buying an of the shelf model
Adds complexity to the project and demonstrates electronics design abilities
Allows us to decide the parameters of the circuit
The crank based power meter design has been abandoned. An estimated power formula is being implemented as a replacement
This design is significantly less expensive
Uses inexpensive sensors that can easily communicate with the microcontroller.
PTotal = PRolling Resistance + PWind + PGravity + PAcceleration
A couple more of our technical trades are displayed here. We will be designing the motor driver instead of buying an off the shelf model. We decided to do this to keep our cost down. Also, designing our own motor driver adds complexity to our project and allows us to specify the parameters of the circuit that are needed for our system. Previously, we decided to use a crank based power meter, but that design has been abandoned. We now will use an estimated power formula instead. The estimated power formula is a much cheaper alternative,using inexpensive sensors that can easily communicate with the microcontroller.

15. 5: Project Testing Motor Strength Maximum Power Shift Conditions
13 July 2019
5: Project Testing
Motor Strength
Maximum Power Shift Conditions
Durability
Battery Life
Motor Control/ PWM/ Speed
The testing that will performed on our system includes the motor strength, maximum power shift conditions, durability, battery life, and the motor control/PWM/speed.

16. 13 July 2019
5: Motor Strength
Set up a test prototype so that the motor can use the mechanical advantage of the worm drive
Attach a hanging load of adjustable mass. Adjust the mass until the motor stalls or can no longer move the load.
The strength of the motor can be calculated using the amount of force needed to lift the mass against earths gravity.
This will also test the worm drives ability to resist backlash from the derailleur
In order to test the motor strength, we will set up a test prototype in order for the motor to use the mechanical advantage of the worm drive. We plan to attach a hanging load of adjustable mass and adjust the mass until the motor stalls can no longer move the load. From doing this, the strength of the motor can be calculated by using the amount of force needed to lift the mass against Earth’s gravity. The operation will also test the worm drives ability to resist backlash from the derailleur.

17. 13 July 2019
5: Maximum Power
Install the control unit without the motorized shifting unit.
Use the original mechanical shifter to shift the derailleur.
Using the control unit to record the estimated power shift the bike under heavy load.
Record the power at any time when the derailleur struggles to shift
This value will be recorded and compared other hard shifting recordings
A maximum power level can then be set to prevent the system from shifting until too much load
For testing the maximum power of our system, we intend to install the control unit with out the motorized shifting unit. We want to use the original mechanical shifter to shift the derailleur. In order to record the estimated power shift of the bike under a heavy load, we will use the control unit and record the power at any time when the derailleur struggles to shift. This value being recorded will also be compared to other hard shifting recordings. From this, a maximum power level can be set on the system to prevent the system from shifting until too much load.

18. 5: Durability and Battery Life
13 July 2019
5: Durability and Battery Life
Durability
Prototype the mounting systems until they are deemed strong enough to be used off road under rough riding conditions
Mount prototype and measure breaking force
Battery Life
Run the system under heavy use until the battery is drained
Measure time to deplete the battery
Use a battery of greater capacity if needed
Test until Battery life requirement is satisfied
Current battery choice is predicted to be sufficient
In order to test the durability of our system, we will prototype the mounting systems until they are deemed strong enough to be used for off road riding under rough conditions. We will mount the prototypes and measure their breaking forces.
To test the battery life, we will run the system under heavy use until the battery is completely drained. While doing this, we will measure the time it takes to deplete the battery. If we deem the battery life not long enough, we will use a battery of greater capacity. Then we will test the battery until the battery life requirement is fully satisfied.

19. 5: Motor Control Motor Controller/ H- Bridge
13 July 2019
5: Motor Control
Motor Controller/ H- Bridge
Simulate the motor control circuit using Pspice or similar software
Build a test circuit and test using the system’s battery or a bench power supply
PWM
Test the transients and output voltage of the motor controller at different frequencies
Find an ideal frequency
Use the microcontroller PWM pins to verify the design frequencies
Modify if needed and measure speed of motor to meet the shift time requirement
For testing the motor control, we will use software such as Pspice to simulate the motor control circuit. Once the simulation works properly, we will build and test a circuit using the system’s battery or a bench power supply.
As for the pulse width modulation, we will test the transients and output voltage of the motor controller at different frequencies. Through this process we plan to find an ideal frequency. We will then use the microcontroller PWM pins to verify that the design frequencies are appropriate. If we deem them insufficient, we will measure and modify the speed of the motor to meet the shift time requirement.

20. 6: Project Risk Inherent Risk Programmatic Risk
13 July 2019
6: Project Risk
Inherent Risk
Water Resistivity and Fragility
Mitigation: Seal the control unit, sensors and motor unit with rubber seals. Make robust, sturdy mounting points and containers
Programmatic Risk
Budget
Mitigation: Expensive concepts like the power meter have been replaced with budget-minded alternatives. The parts needed to complete this project are inexpensive or already purchased
Temperature
Mitigation: Sensors and other component affected by ambient temperature have been chosen so that their effective ranges far exceed the temperatures expected. High current components will be heat-sinked to avoid failure.
Expanding on our previous project risks, we have listed here the inherent and programmatic risks. Our inherent risk previously was the concern of water resistivity and fragility. What we will do mitigate this risk is seal the control unit, sensors, and motor unit with rubber seals. We would also like to make our mounting points and containers robust and sturdy,
Our previous programmatic risks include those of budget and temperature. What we’ve done to mitigate the risk of budget is trade out expensive concepts, such as the power meter, for more cost efficient alternatives. The parts that are needed to complete this project are inexpensive or already purchased. To mitigate the risk of temperature, we have chosen the components/sensors that are affected by ambient light so that their effective ranges exceed the temperatures expected for this project. Also, high current components will be heat-sinked to avoid failure.

21. 6: Project Risk Implantation Risk Developmental Funding
13 July 2019
6: Project Risk
Implantation Risk
Funding
Mitigation: The expected cost of the project is low enough that loss of employment should not effect the outcome or completion of the project
Management/ Scheduling
Mitigation (communication): A shared cloud drive has been created so that work progress can be easily updated and shared between team members. Team members are also easily contacted via phone conversations.
Mitigation (schedule): A well defined schedule has been set and can be easily be followed. Using the added time from having the Summer semester to work on the project will relax the schedule restraints.
Developmental
Compatibility
Mitigation: Components have been chosen for their compatibility.
Previously, we had concerns with our implantation risks of funding and management/scheduling as well as developmental risks such as the compatibility of our components. As far as our implantation risk goes, the main concerns were with funding and management/schedule. We have mitigated funding by lowering the expected cost of our project; it is low enough that the loss of employment of any of our team member should not effect the outcome or completion of this project. We’ve also mitigated our risk of management/scheduling. We’ve done this by creating a cloud drive so that the progress can be easily updated and shared between team members. We’ve mitigated our schedule risk by defining and setting a prompt schedule to be easily followed. We plan to use to extra time given over summer to work on our project.
Our developmental risk included that of compatibility. We’ve mitigated this risk by purchasing components that are compatible with one another.

22. 6: Risk of Schedule Un-Mitigated Mitigated 1 1
13 July 2019
6: Risk of Schedule
Un-Mitigated
Mitigated 1 1
Probability (Likelihood)
Probability (Likelihood) x x
Here, displays our risk of schedule, unmitigated and mitigated. The diagram on the left shows the risk of schedule prior to being mitigated, and displays the risk as being fairly low in probability, but very high in consequence. The schedule was neither premature, nor incomplete. The diagram on the right shows the risk of schedule after being mitigated. Here, it displays our probability being about the same as before, but the consequence being much lower. Now that we are further along in our project, our schedule is seeming to be more premature and on time now that we have a set schedule planned out.
Consequence
Consequence
Premature x
Incomplete
Premature x
Incomplete
Schedule
Schedule

23. 6: Risk of Performance Mitigated Un-Mitigated 1 1
13 July 2019
6: Risk of Performance
Un-Mitigated
Mitigated 1 1
Probability (Likelihood)
Probability (Likelihood) x x
Here, displays our risk of performance, unmitigated and mitigated. The diagram on the left shows the risk of performance prior to being mitigated, and displays the risk as being moderately high in probability, and moderately low in consequence. The performance of our system was neither exceeding our expectations, nor was it nonfunctioning. The diagram on the right shows the risk of performance after being mitigated. Here, it displays our probability being much lower than before, but the consequence remaining the same. Now that we are further along in our project, the performance of our system is expected to be more likely to exceed our expectations than to be nonfunctioning.
Consequence
Consequence
Exceeds Expectations
Exceeds Expectations
Nonfunctioning x
Nonfunctioning x
Performance
Performance

24. 13 July 2019
7: Schedule
Here, displays our schedule. Not much has changed from out last schedule other than the fact that is had been made more organized. Team members have been assigned specific tasks to work on in order to keep us on schedule.

25. 8: Bill of Material (BOM)
13 July 2019
8: Bill of Material (BOM)
This is our Bill of Material. Again, not much of this has changed since our previous one, aside from us choosing a few cheaper parts than previously.

26. 13 July 2019
9: Review Action Items
As for our review action items, all have been closed now that we have presented our PDR presentation and completed our final SRD documents.

27. Website Link: http://autoshiftsystem.weebly.com/
13 July 2019
Thank you!
Website Link:
Thank you for listening! We will take any questions.