Difference between revisions of "F16: E-Bike"

From Embedded Systems Learning Academy
Jump to: navigation, search
(→‎My Issue #1)
(→‎Hardware Interface)
 
(126 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
=== Grading Criteria ===
 
−
<font color="green">
 
−
*  How well is Software & Hardware Design described?
 
−
*  How well can this report be used to reproduce this project?
 
−
*  Code Quality
 
−
*  Overall Report Quality:
 
−
**  Software Block Diagrams
 
−
**  Hardware Block Diagrams
 
−
**:  Schematic Quality
 
−
**  Quality of technical challenges and solutions adopted.
 
−
</font>
 
−
 
 
== E-Bike ==
 
== E-Bike ==
  
Line 17: Line 5:
  
 
== Objectives & Introduction ==
 
== Objectives & Introduction ==
−
Show list of your objectives.  This section includes the high level details of your project.  You can write about the various sensors or peripherals you used to get your project completed.
+
 
−
<br>
 
 
1. Allow a motor to propel a bike forward when a button is pressed <br>
 
1. Allow a motor to propel a bike forward when a button is pressed <br>
 
2. Create a battery driven power circuit that can support an embedded system and can be charged without a wall adapter <br>
 
2. Create a battery driven power circuit that can support an embedded system and can be charged without a wall adapter <br>
Line 66: Line 53:
 
| Get A/D on LPC working  
 
| Get A/D on LPC working  
 
Output reading to an external screen
 
Output reading to an external screen
−
| A/D Completed
+
| Completed
−
Screen is a WIP
 
 
| 11/18 (A/D)
 
| 11/18 (A/D)
−
TBD (Screen)
+
12/06 (Screen)
 
|-
 
|-
 
! 5
 
! 5
Line 75: Line 61:
 
| Get MOSFETs working with motors  
 
| Get MOSFETs working with motors  
 
Finalize power circuit build
 
Finalize power circuit build
−
| WIP
+
| Completed
−
| TBD
+
| 12/17
 
|-
 
|-
 
! 6
 
! 6
Line 87: Line 73:
 
| 12/09
 
| 12/09
 
| Mount hardware and begin testing
 
| Mount hardware and begin testing
−
| Pending
+
| Completed
−
| TBD
+
| 12/18
 
|-
 
|-
 
! 8
 
! 8
 
| 12/16
 
| 12/16
 
| Fix defects, finish report, and clean up code
 
| Fix defects, finish report, and clean up code
−
| Pending
+
| Completed
−
| TBD
+
| 12/19
 
|-
 
|-
 
|}
 
|}
  
 
== Parts List & Cost ==
 
== Parts List & Cost ==
−
Give a simple list of the cost of your project broken down by components.  Do not write long stories here.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 106: Line 91:
 
! Part Name
 
! Part Name
 
! Quantity
 
! Quantity
−
! Cost ($)
+
! Cost ($) per 1 part
 
|-
 
|-
 
! 1
 
! 1
Line 116: Line 101:
 
| LCD Screen
 
| LCD Screen
 
| 1
 
| 1
−
| 10
+
| 11
 
|-
 
|-
 
! 3
 
! 3
Line 126: Line 111:
 
| Push Button
 
| Push Button
 
| 1
 
| 1
−
| Free
+
| 0.93
 
|-
 
|-
 
! 5
 
! 5
Line 141: Line 126:
 
| Circuit Case
 
| Circuit Case
 
| 1
 
| 1
−
| Cost
+
| 8
 
|-
 
|-
 
! 8
 
! 8
 
| Screen and controller case
 
| Screen and controller case
 
| 1
 
| 1
−
| Cost
+
| Free
 
|-
 
|-
 
! 9
 
! 9
Line 171: Line 156:
 
| Buck Converter
 
| Buck Converter
 
| 1
 
| 1
−
| 10
+
| 9
 
|-
 
|-
 
! 14
 
! 14
 
| Terminal Block
 
| Terminal Block
 
| 2
 
| 2
−
| Cost
+
| 0.70
 
|-
 
|-
 
! 15
 
! 15
 
| Resistors
 
| Resistors
−
| 4
+
| 6
−
| Free
+
| 0.10
 
|-
 
|-
 
! 16
 
! 16
−
| Diodes
+
| Rectifying Diodes
−
| 2
+
| 7
−
| Free
+
| 0.10
 
|-
 
|-
 
! 17
 
! 17
−
| Nuts
+
| Plastic Standoffs
−
| 5
+
| 16
−
| Free
+
| 0.10
 
|-
 
|-
 
! 18
 
! 18
−
| U-Bracket
 
−
| 2
 
−
| Cost
 
−
|-
 
−
! 19
 
 
| Small PCB
 
| Small PCB
 
| 1
 
| 1
 
| 1
 
| 1
 
|-
 
|-
−
! 20
+
! 19
 
| 8mm Motor Arbor Adapter
 
| 8mm Motor Arbor Adapter
 
| 1
 
| 1
 
| 8
 
| 8
 
|-
 
|-
−
! 21
+
! 20
 
| Skateboard Wheel
 
| Skateboard Wheel
 
| 1
 
| 1
 
| Free
 
| Free
 +
|-
 +
! 21
 +
| Bike Rack
 +
| 1
 +
| 14
 +
|-
 +
! 22
 +
| Zipties
 +
| 14
 +
| 0.4
 +
|-
 +
! 23
 +
| Bungee Cord
 +
| 3
 +
| 0.90
 
|}
 
|}
  
 
== Design & Implementation ==
 
== Design & Implementation ==
−
The design section can go over your hardware and software design.  Organize this section using sub-sections that go over your design and implementation.
 
  
 
=== Hardware Design ===
 
=== Hardware Design ===
−
Discuss your hardware design here. Show detailed schematics, and the interface here.
+
 
 +
[[File:CmpE146_F16_T11_HardwareOverview.png|500px|center|thumb|Figure #1. Hardware Overview]]
 +
 
 +
<br> <br>
 +
The figure above shows a high level view of our system on the bike. We have the generator sending power to the main circuit to be rerouted to the battery when needed, the battery getting power from the main circuit and providing power to the circuit, the motor getting power from the circuit, the push button and speed controller on the handlebars sending feedback to the circuit based on user input, and the screen on the handlebars getting data from the circuit.
 +
 
 +
[[File:CmpE146_F16_T11_CircuitSchematic.png|500px|center|thumb|Figure #2. Circuit Schematic]]
 +
 
 +
<br> <br>
 +
Our hardware design consists of four major sections. The first section of the circuit is the generator which is in yellow on the diagram. Our generator design is driven by a 50W AC generator. It feeds varying voltage to a bridge rectifier circuit to smooth out the signal before going into a boost converter. The boost converter takes the 12-20V input and puts out a steady 42V at 2A. Our boost converter output goes to a MOSFET transistor. This transistor is controlled by a GPIO driver on the SJOne Board. When we want to charge, the MOSFET activates and sends the 42V, 2A electrical energy to the on-board battery. The on-board battery is the heart of our system. It is a 36V, 10Ah lithium polymer battery. Our battery is also the key component for our next major circuit section; the power circuit. <br>
 +
The power circuit sends power to 3 different locations; the ADC, the motor, and the SJOne Board. Starting with the ADC, we are utilizing a voltage divider circuit to step down the voltage to safe, operating levels for the LPC CPU on the SJOne Board. We are using the overcharge voltage of the battery with the ADC to measure how much juice is left in the battery for the user. Next, the power is sent to a buck converter. The buck converter steps down the voltage to the operating 5V that the microcontroller needs to operate. Finally, the battery sends power to the motor. <br>
 +
The SJOne Board is the key component in our next major circuit section which is the microcontroller in green. If the battery is the heart of the system, the microcontroller is the brain. We have it attached to 2 MOSFETs so it can control when we want to charge the battery or use energy to activate the electric bike motor. A user requests motor output through a different GPIO port from an on-board button on the handlebars. When the button is pressed, the SJOne Board will activate the motor MOSFET and the bike will be propelled forward with less pedaling required. The speed of the motor is controlled by a speed controller also on the handlebars. It is basically just a knob that can change the motor speed from zero to max, or 0A to 7A. Finally, the microcontroller contributes to the other major section which is the output of our system. <br>
 +
One of the output components is the motor mentioned already, and the other component is the screen on the handlebars. In addition to the output mentioned for the motor, we have a diode across it to protect our system from any spikes in current that might occur when starting and stopping the motor. Our other output, the screen, displays the battery level so a user knows how much juice they have left. The screen is the best way for our user to know what's going on with the system at any moment.
 +
 
 +
[[File:CmpE146_F16_T11_Motor.jpg|500px|center|thumb|Figure #3. Motor]] <br>
 +
[[File:CmpE146_F16_Generator.jpg|500px|center|thumb|Figure #4. Generator]] <br>
  
 
=== Hardware Interface ===
 
=== Hardware Interface ===
−
In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the '''Software Design''' section is isolated to talk about high level workings rather than inner working of your project.
+
 
 +
=====ADC=====
 +
 
 +
[[File:CmpE146_F16_T11_ADC.png|500px|center|thumb|Figure #5. ADC]] <br>
 +
 
 +
 
 +
The ADC interface utilizes the on-board 12-bit ADC built into the LPC1758 CPU. We needed to understand the pins, registers, and how they worked to give a digital voltage reading. The CPU uses a 12-bit successive approximation register to get the reading of the analog voltage as displayed in the diagram above. The max operating voltage it can read is 3.3V since that is also its reference voltage. With this in mind, we knew we had a sample size of 0.8mv which was accurate for our needs. After figuring all this out, following the manual for the driver and for actually computing information was easy. We are using a voltage dividing circuit to measure the overcharge voltage of the battery according to the table below. The overcharge voltage is sent to an ADC channel on the CPU (we had 8 different ones to choose from), and the voltage we read there gives us a percentage that can be calculated based on the known maximum value.
 +
<br> <br>
 +
Table 1: Overcharge Voltage Chart Readings
 +
{| class="wikitable"
 +
|-
 +
! Overcharge Voltage (V)
 +
! Battery Pct (%)
 +
|-
 +
| 42.0
 +
| 100
 +
|-
 +
| 41.4
 +
| 90
 +
|-
 +
| 40.8
 +
| 80
 +
|-
 +
| 40.2
 +
| 70
 +
|-
 +
| 39.6
 +
| 60
 +
|-
 +
| 39.0
 +
| 50
 +
|-
 +
| 38.4
 +
| 40
 +
|-
 +
| 37.8
 +
| 30
 +
|-
 +
| 37.2
 +
| 20
 +
|-
 +
| 36.6
 +
| 10
 +
|-
 +
| 36.0
 +
| 0
 +
|}
 +
 
 +
=====UART=====
 +
The screen on our e-bike utilizes the UART communication bus. In particular, we are using UART2 from the LPC1758 CPU. The details of the driver code and communication are given in the software section below. For the hardware interface, it's important to note that our screen's RX and TX complement the board's, and both devices share a common ground.
 +
[[File:CmpE146 F16 Screen.JPG|500px|center|thumb|Figure #6. Screen]]
 +
 
 +
=====GPIO=====
 +
 
 +
The general purpose input and output ports in our system play a very important role in the orchestration of current when charging the battery and activating the motor. We have an input port set to receive information from the push button on the handlebars. Once data is received, we use a general output port to activate a MOSFET controlling a motor if power is available to start spinning the front wheel. In terms of charging, we use the information from the ADC to determine when to send a high signal out of another general purpose output port. This high signal activates a different MOSFET that will allow charging current to flow into the battery.
 +
 
 +
[[File:CmpE146 F16 Basket.JPG|500px|center|thumb|Figure #7. Completed Box]]
  
 
=== Software Design ===
 
=== Software Design ===
 
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
 
Show your software design.  For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level.  Do not show the details of the code.  For example, do not show exact code, but you may show psuedocode and fragments of code.  Keep in mind that you are showing DESIGN of your software, not the inner workings of it.
  
 +
The software communication we have created has different tasks and functions to handle different events.
  
−
The software
+
[[File:CmpE146_F16_T11_TaskOverview.png|500px|center|thumb|Figure #8. Task Relationship Overview]] <br>
 +
<br>
 +
 
 +
=====ADC=====
 +
 
 +
The driver is initialized on startup already. The code we needed to add to achieve our goal follows the below psuedocode: <br>
 +
{
 +
      batteryV += adc0_get_reading(4) * sample_size
 +
      if sample_count == 500
 +
              calculate batteryPct
 +
}
 +
 
 +
=====MOSFET=====
 +
 
 +
All MOSFET decisions are based on GPIO input and the battery level. The decisions our task makes is based on the flow chart below.
 +
 
 +
[[File:CmpE146 F16 SoftFlow.png|500px|center|thumb|Figure #9. MOSFET Decisions]] <br>
 +
<br>
 +
 
 +
This task required 3 GPIO drivers being 2 output, and 1 input. The following pseudocode shows what we are doing in the MOSFET task:
 +
 
 +
 
 +
init {
 +
        configure p1.15 as gpio input for debugging motor
 +
        configure p2.1 as gpio output (generator)
 +
        configure p2.3 as gpio output (motor)
 +
        configure p2.5 as gpio input for external switch
 +
        initialize p2.1 as output (generator)
 +
        initialize p2.3 as output (motor)
 +
}
 +
 
 +
run {
 +
        if battery is less than 90 %, charge
 +
              activate mosfet at p2.1 (generator)
 +
        else if battery greater than 98%, stop charging
 +
              deactivate mosfet at p2.1 (generator)
 +
      if battery is under 10 %, deactivate motor
 +
              deactivate mosfet at p2.3 (motor)
 +
      else if battery is greater than 10 % and button pressed, activate motor
 +
              activate mosfet at p2.3 (motor)
 +
      else button has not been pressed
 +
              deactivate mosfet at p2.3 (motor)
 +
}
 +
 
 +
=====UART=====
 +
 
 +
The way we send data from the board to the screen is shown below in psuedocode:
 +
 
 +
void uart2_init(uint32_t baud) {
 +
        clear p2.8 for txd2 and p2.9 for rxd2
 +
        set p2.8 as txd2 and p2.9 for rxd2
 +
       
 +
        clear uart2 clock
 +
        enable uart2 clock
 +
        set data size as byte
 +
        enable DLAB bit
 +
        calculate speed value
 +
        disable DLAB bit
 +
}
 +
 
 +
void uart2_putchar(char out) {
 +
 +
    Store data in buffer
 +
    while(1) {
 +
      if (LPC_UART2->LSR & (1 << 5)) // wait until data is sent
 +
      break;
 +
    }
 +
}
 +
 
 +
void uart2_end() {
 +
        uart2_putchar(0xFF); send this 3 times to let screen know we are done sending info
 +
}
 +
 
 +
run {
 +
        send battery percentage
 +
        send battery voltage
 +
}
  
 
=== Implementation ===
 
=== Implementation ===
−
This section includes implementation, but again, not the details, just the high level.  For example, you can list the steps it takes to communicate over a sensor, or the steps needed to write a page of memory onto SPI Flash.  You can include sub-sections for each of your component implementation.
 
  
−
== Testing & Technical Challenges ==
+
*Communication between the board and battery
 +
**The battery talks to the board through the ADC.
  
 +
*Communication between the board and the LCD screen:
 +
**This was done with UART communication. We are sending single bytes to update the screen to reflect the proper level of battery remaining.
  
−
Describe the challenges of your project.  What advise would you give yourself or someone else if your project can be started from scratch again?
+
*Steps to activate the motor
−
Make a smooth transition to testing section and described what it took to test your project.
+
**User presses button
 +
**MOSFET task checks ADC battery percentage
 +
**If battery is over 10%, motor turns on based on current speed controller setting
  
−
Include sub-sections that list out a problem and solution, such as:
+
*Power for each component
 +
**Battery ---> Motor
 +
**Battery ---> Buck Converter ---> SJOne Board
 +
**Battery ---> Buck Converter ---> SJOne Board ---> Screen
 +
**Generator ---> Rectifying Bridge ---> Boost Converter ---> Battery
  
−
=== My Issue #1 ===
+
== Testing & Technical Challenges ==
−
Discuss the issue and resolution.
 
  
 +
===Software Challenges ===
 +
The software testing was relatively straight forward. We implemented tasks individually and tested them with lab bench equipment and breadboards, and then we integrated them together. Our integration testing came once the hardware was complete and we made changes accordingly. The most troublesome software came from the screen we picked to display our UART communication.
  
−
*Software Challenges:
+
*LCD screen
−
**LCD screen, It came with the wrong instructions and a very poorly made IDE
+
**It came with the wrong instructions; the baud rate was incorrect and the IDE for visuals was not the best. In addition, there is not a lot of support for it online. We solved the issue by using a UART simulation tool in the IDE to adjust the baud rate and practice the instruction set.
 +
*UART strings
 +
**The screen required a very particular string to be sent for data. This made us write a couple functions to convert the numerical readings to chars to write them to the screen.
  
 +
===Hardware Challenges ===
 +
Hardware testing was done as individual modules starting with the battery. We slowly built up from there and continued testing until we got a complete system. There were plenty of challenges along the way with so much hardware that are documented below.
  
 +
*Mounting the motor to the frame
 +
**When it came to mounting the motor to the frame, we ran into a couple of issues. We couldn't figure out how to attach the motor to the frame so that there was enough tension for it to drive the front tire.  We decided to rotate the motor 90 degrees and use a bolt to attach it to the frame and some Zip ties to keep it from rotating when driving the tire. We were able to use the old brake mounting location we no longer needed which made it secure.
 +
*Back bicycle rack kept shifting
 +
**When we installed the rack behind the seat we didn't realize the size of the circumference was too big around the seat pole so it kept rotating. Tightening it didn't help. We needed the rack to be stable because that's where our circuit goes, so we decided to add zip ties to it to keep it from rotating.
 +
*MOSFET Overheating
 +
**We ran into an issue once we had everything wired up. We realized once the motor was running for longer amounts of time, the MOSFET would heat up. We didn't fully solve this yet; we will be adding a heat sink later on. For now, the bike works in short bursts.
 +
*Wire management
 +
**The wiring management was messy because there are many connections, but we took our time to ensure we were hooking everything up correctly
 +
*Soldering different wire gauges
 +
**The power sections of our circuit, like the battery and motor, required thicker wire than the rest. We also had to solder these thicker wires to small pins such as those on the MOSFETs. Careful planning of where things would go and some soldering practice led to success.
  
−
*Hardware Challenges:
+
===Advice===
−
**Mounting the motor to the frame
+
*Try and get the design done as early as possible to leave plenty of time for testing
 +
*Don't work too fast as there are a lot of different connections
 +
*Understand the required voltage levels for each device before putting parts together
  
 
== Conclusion ==
 
== Conclusion ==
−
Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?
+
Our e-bike embedded system is a project we are very proud of. It integrated many of concepts we not only learned in CMPE146, but at SJSU during our undergrad education. The protocols, design processes, and algorithms incorporate something from many of our classes which makes us especially proud of the work we put in. We will continue testing and working on this project as our senior project next semester because the end product was very satisfying despite the long hours put in to reach it. Perhaps the biggest thing we learned was to create more time for testing to not only fix defects, but to improve on the original design. During testing, we had to adapt parts and change the circuit as new issues came up. While we are happy with the product now, we know there's still so much more we can do with it. Future work includes improving the grip between the motor and wheel, cleaning up the cables, doing more robust testing on the generator circuit, improving heat dissipation inside the circuit box, and removing the screen to display battery information on a mobile app instead. We were a little skeptical that we could complete all the tasks we outlined at the beginning of the project, but as we got more into it, it was easier to work on because things started getting more interesting and fun. We ended up hitting the core aspects of our initial objectives by doing a ton of research on thing we didn't know and polishing up on concepts we already had a strong grasp on. Ultimately, what we have built will be a part of the future for our planet in some form or another because our current energy consumption is not sustainable. Using the very prominent embedded systems concepts developed on our bike here, we hope we can continue to improve it and contribute to a healthier future.
 +
 
 +
* [[File:CmpE146_F16_Ebike.jpg|500px|center|thumb|Figure #10. Completed E-Bike]]
  
 
=== Project Video ===
 
=== Project Video ===
−
Upload a video of your project and post the link here.
+
*  [https://youtu.be/2iHFGF1MVpk Project Video]
  
 
=== Project Source Code ===
 
=== Project Source Code ===
−
*  [https://sourceforge.net/projects/sjsu/files/CmpE_S2016/ Sourceforge Source Code Link]
+
*  [https://github.com/randhawk/CMPE146-NimbleRide GitHub Source Code Link]
  
 
== References ==
 
== References ==
−
=== Acknowledgement ===
+
=== References Used ===
−
Any acknowledgement that you may wish to provide can be included here.
 
  
−
=== References Used ===
+
* [http://www.popularmechanics.com/cars/how-to/a181/1276826/ Mounting a Motor]
−
List any references used in project.
+
* [http://www.popularmechanics.com/technology/gadgets/how-to/a10245/pedal-power-how-to-build-a-bike-generator-16627209/ Pedal Power How To Build A Bike Generator]
 +
* [http://www.mrmoneymustache.com/2016/05/25/recipe-for-a-badass-diy-electric-mountain-bike/ Recipe for a Badass DIY Electric Mountain Bike]
  
 
=== Appendix ===
 
=== Appendix ===
−
You can list the references you used.
+
*[http://www.nxp.com/documents/user_manual/UM10360.pdf LPC1758 Datasheet]
 +
*[http://www.st.com/content/ccc/resource/technical/document/datasheet/bf/f6/23/6a/d8/7f/4a/e0/CD00000701.pdf/files/CD00000701.pdf/jcr:content/translations/en.CD00000701.pdf IRF630 Power MOSFET Datasheet]
 +
*[https://www.itead.cc/wiki/Nextion_Instruction_Set Nextion Screen Instruction Set]

Latest revision as of 09:24, 20 December 2016

E-Bike

Abstract

Electrics bicycles are the future of transportation. Our project helps build on this future by advancing electric bike design. We have two motors on the bike. One generates power to charge an on-board battery, while the other propels the bike forward as requested by user input. This allows the user to reach steady transportation speeds without the need to pedal constantly. A more effective future of transportation based on renewable energy is the way forward for us and the planet.

Objectives & Introduction

1. Allow a motor to propel a bike forward when a button is pressed
2. Create a battery driven power circuit that can support an embedded system and can be charged without a wall adapter
3. Show the user the current status of their battery

Team Members & Responsibilities

  • Nicholas Randhawa
    • Power circuit
    • A/D Converter
  • Alejandro Puente
    • Display battery level to external screen over UART
  • Shared Responsibilities
    • Hardware mounting
    • GPIO drivers
    • RTOS tasks to integrate everything

Schedule

Week # Proposed Completion Date Task Status Actual Completion Date
1 10/28 Finalize project idea and determine hardware requirements Completed 10/28
2 11/04 Order parts Completed 11/04
3 11/11 Draw schematics Completed 11/11
4 11/18 Get A/D on LPC working

Output reading to an external screen

Completed 11/18 (A/D)

12/06 (Screen)

5 11/25 Get MOSFETs working with motors

Finalize power circuit build

Completed 12/17
6 12/02 Create RTOS tasks to integrate A/D with the MOSFETs Completed 11/29
7 12/09 Mount hardware and begin testing Completed 12/18
8 12/16 Fix defects, finish report, and clean up code Completed 12/19

Parts List & Cost

Part # Part Name Quantity Cost ($) per 1 part
1 Bike 1 Free
2 LCD Screen 1 11
3 36V, 10Ah Rechargable Battery 1 250
4 Push Button 1 0.93
5 Speed Controller 1 10
6 SJOne Board 1 80
7 Circuit Case 1 8
8 Screen and controller case 1 Free
9 High Power MOSFET 2 4
10 250W DC Motor 1 50
11 50W AC Generator 1 30
12 Boost Converter 1 10
13 Buck Converter 1 9
14 Terminal Block 2 0.70
15 Resistors 6 0.10
16 Rectifying Diodes 7 0.10
17 Plastic Standoffs 16 0.10
18 Small PCB 1 1
19 8mm Motor Arbor Adapter 1 8
20 Skateboard Wheel 1 Free
21 Bike Rack 1 14
22 Zipties 14 0.4
23 Bungee Cord 3 0.90

Design & Implementation

Hardware Design

Figure #1. Hardware Overview



The figure above shows a high level view of our system on the bike. We have the generator sending power to the main circuit to be rerouted to the battery when needed, the battery getting power from the main circuit and providing power to the circuit, the motor getting power from the circuit, the push button and speed controller on the handlebars sending feedback to the circuit based on user input, and the screen on the handlebars getting data from the circuit.

Figure #2. Circuit Schematic



Our hardware design consists of four major sections. The first section of the circuit is the generator which is in yellow on the diagram. Our generator design is driven by a 50W AC generator. It feeds varying voltage to a bridge rectifier circuit to smooth out the signal before going into a boost converter. The boost converter takes the 12-20V input and puts out a steady 42V at 2A. Our boost converter output goes to a MOSFET transistor. This transistor is controlled by a GPIO driver on the SJOne Board. When we want to charge, the MOSFET activates and sends the 42V, 2A electrical energy to the on-board battery. The on-board battery is the heart of our system. It is a 36V, 10Ah lithium polymer battery. Our battery is also the key component for our next major circuit section; the power circuit.
The power circuit sends power to 3 different locations; the ADC, the motor, and the SJOne Board. Starting with the ADC, we are utilizing a voltage divider circuit to step down the voltage to safe, operating levels for the LPC CPU on the SJOne Board. We are using the overcharge voltage of the battery with the ADC to measure how much juice is left in the battery for the user. Next, the power is sent to a buck converter. The buck converter steps down the voltage to the operating 5V that the microcontroller needs to operate. Finally, the battery sends power to the motor.
The SJOne Board is the key component in our next major circuit section which is the microcontroller in green. If the battery is the heart of the system, the microcontroller is the brain. We have it attached to 2 MOSFETs so it can control when we want to charge the battery or use energy to activate the electric bike motor. A user requests motor output through a different GPIO port from an on-board button on the handlebars. When the button is pressed, the SJOne Board will activate the motor MOSFET and the bike will be propelled forward with less pedaling required. The speed of the motor is controlled by a speed controller also on the handlebars. It is basically just a knob that can change the motor speed from zero to max, or 0A to 7A. Finally, the microcontroller contributes to the other major section which is the output of our system.
One of the output components is the motor mentioned already, and the other component is the screen on the handlebars. In addition to the output mentioned for the motor, we have a diode across it to protect our system from any spikes in current that might occur when starting and stopping the motor. Our other output, the screen, displays the battery level so a user knows how much juice they have left. The screen is the best way for our user to know what's going on with the system at any moment.

Figure #3. Motor

Figure #4. Generator

Hardware Interface

ADC
Figure #5. ADC


The ADC interface utilizes the on-board 12-bit ADC built into the LPC1758 CPU. We needed to understand the pins, registers, and how they worked to give a digital voltage reading. The CPU uses a 12-bit successive approximation register to get the reading of the analog voltage as displayed in the diagram above. The max operating voltage it can read is 3.3V since that is also its reference voltage. With this in mind, we knew we had a sample size of 0.8mv which was accurate for our needs. After figuring all this out, following the manual for the driver and for actually computing information was easy. We are using a voltage dividing circuit to measure the overcharge voltage of the battery according to the table below. The overcharge voltage is sent to an ADC channel on the CPU (we had 8 different ones to choose from), and the voltage we read there gives us a percentage that can be calculated based on the known maximum value.

Table 1: Overcharge Voltage Chart Readings

Overcharge Voltage (V) Battery Pct (%)
42.0 100
41.4 90
40.8 80
40.2 70
39.6 60
39.0 50
38.4 40
37.8 30
37.2 20
36.6 10
36.0 0
UART

The screen on our e-bike utilizes the UART communication bus. In particular, we are using UART2 from the LPC1758 CPU. The details of the driver code and communication are given in the software section below. For the hardware interface, it's important to note that our screen's RX and TX complement the board's, and both devices share a common ground.

Figure #6. Screen
GPIO

The general purpose input and output ports in our system play a very important role in the orchestration of current when charging the battery and activating the motor. We have an input port set to receive information from the push button on the handlebars. Once data is received, we use a general output port to activate a MOSFET controlling a motor if power is available to start spinning the front wheel. In terms of charging, we use the information from the ADC to determine when to send a high signal out of another general purpose output port. This high signal activates a different MOSFET that will allow charging current to flow into the battery.

Figure #7. Completed Box

Software Design

Show your software design. For example, if you are designing an MP3 Player, show the tasks that you are using, and what they are doing at a high level. Do not show the details of the code. For example, do not show exact code, but you may show psuedocode and fragments of code. Keep in mind that you are showing DESIGN of your software, not the inner workings of it.

The software communication we have created has different tasks and functions to handle different events.

Figure #8. Task Relationship Overview


ADC

The driver is initialized on startup already. The code we needed to add to achieve our goal follows the below psuedocode:
{ 

      batteryV += adc0_get_reading(4) * sample_size
      if sample_count == 500
              calculate batteryPct

}

MOSFET

All MOSFET decisions are based on GPIO input and the battery level. The decisions our task makes is based on the flow chart below.

Figure #9. MOSFET Decisions


This task required 3 GPIO drivers being 2 output, and 1 input. The following pseudocode shows what we are doing in the MOSFET task:


init { 

       configure p1.15 as gpio input for debugging motor
       configure p2.1 as gpio output (generator)
       configure p2.3 as gpio output (motor)
       configure p2.5 as gpio input for external switch
       initialize p2.1 as output (generator)
       initialize p2.3 as output (motor)

}

run { 

       if battery is less than 90 %, charge
             activate mosfet at p2.1 (generator)
       else if battery greater than 98%, stop charging
             deactivate mosfet at p2.1 (generator)
      if battery is under 10 %, deactivate motor
             deactivate mosfet at p2.3 (motor)
      else if battery is greater than 10 % and button pressed, activate motor
             activate mosfet at p2.3 (motor)
      else button has not been pressed
             deactivate mosfet at p2.3 (motor)

}

UART

The way we send data from the board to the screen is shown below in psuedocode:

void uart2_init(uint32_t baud) { 

       clear p2.8 for txd2 and p2.9 for rxd2
       set p2.8 as txd2 and p2.9 for rxd2
       
       clear uart2 clock 
       enable uart2 clock
       set data size as byte
       enable DLAB bit
       calculate speed value
       disable DLAB bit

}

void uart2_putchar(char out) { 

    Store data in buffer
    while(1) {
     if (LPC_UART2->LSR & (1 << 5)) // wait until data is sent
     break;
   }

}

void uart2_end() { 

       uart2_putchar(0xFF); send this 3 times to let screen know we are done sending info

}

run { 

       send battery percentage
       send battery voltage

}

Implementation

  • Communication between the board and battery
    • The battery talks to the board through the ADC.
  • Communication between the board and the LCD screen:
    • This was done with UART communication. We are sending single bytes to update the screen to reflect the proper level of battery remaining.
  • Steps to activate the motor
    • User presses button
    • MOSFET task checks ADC battery percentage
    • If battery is over 10%, motor turns on based on current speed controller setting
  • Power for each component
    • Battery ---> Motor
    • Battery ---> Buck Converter ---> SJOne Board
    • Battery ---> Buck Converter ---> SJOne Board ---> Screen
    • Generator ---> Rectifying Bridge ---> Boost Converter ---> Battery

Testing & Technical Challenges

Software Challenges

The software testing was relatively straight forward. We implemented tasks individually and tested them with lab bench equipment and breadboards, and then we integrated them together. Our integration testing came once the hardware was complete and we made changes accordingly. The most troublesome software came from the screen we picked to display our UART communication.

  • LCD screen
    • It came with the wrong instructions; the baud rate was incorrect and the IDE for visuals was not the best. In addition, there is not a lot of support for it online. We solved the issue by using a UART simulation tool in the IDE to adjust the baud rate and practice the instruction set.
  • UART strings
    • The screen required a very particular string to be sent for data. This made us write a couple functions to convert the numerical readings to chars to write them to the screen.

Hardware Challenges

Hardware testing was done as individual modules starting with the battery. We slowly built up from there and continued testing until we got a complete system. There were plenty of challenges along the way with so much hardware that are documented below.

  • Mounting the motor to the frame
    • When it came to mounting the motor to the frame, we ran into a couple of issues. We couldn't figure out how to attach the motor to the frame so that there was enough tension for it to drive the front tire. We decided to rotate the motor 90 degrees and use a bolt to attach it to the frame and some Zip ties to keep it from rotating when driving the tire. We were able to use the old brake mounting location we no longer needed which made it secure.
  • Back bicycle rack kept shifting
    • When we installed the rack behind the seat we didn't realize the size of the circumference was too big around the seat pole so it kept rotating. Tightening it didn't help. We needed the rack to be stable because that's where our circuit goes, so we decided to add zip ties to it to keep it from rotating.
  • MOSFET Overheating
    • We ran into an issue once we had everything wired up. We realized once the motor was running for longer amounts of time, the MOSFET would heat up. We didn't fully solve this yet; we will be adding a heat sink later on. For now, the bike works in short bursts.
  • Wire management
    • The wiring management was messy because there are many connections, but we took our time to ensure we were hooking everything up correctly
  • Soldering different wire gauges
    • The power sections of our circuit, like the battery and motor, required thicker wire than the rest. We also had to solder these thicker wires to small pins such as those on the MOSFETs. Careful planning of where things would go and some soldering practice led to success.

Advice

  • Try and get the design done as early as possible to leave plenty of time for testing
  • Don't work too fast as there are a lot of different connections
  • Understand the required voltage levels for each device before putting parts together

Conclusion

Our e-bike embedded system is a project we are very proud of. It integrated many of concepts we not only learned in CMPE146, but at SJSU during our undergrad education. The protocols, design processes, and algorithms incorporate something from many of our classes which makes us especially proud of the work we put in. We will continue testing and working on this project as our senior project next semester because the end product was very satisfying despite the long hours put in to reach it. Perhaps the biggest thing we learned was to create more time for testing to not only fix defects, but to improve on the original design. During testing, we had to adapt parts and change the circuit as new issues came up. While we are happy with the product now, we know there's still so much more we can do with it. Future work includes improving the grip between the motor and wheel, cleaning up the cables, doing more robust testing on the generator circuit, improving heat dissipation inside the circuit box, and removing the screen to display battery information on a mobile app instead. We were a little skeptical that we could complete all the tasks we outlined at the beginning of the project, but as we got more into it, it was easier to work on because things started getting more interesting and fun. We ended up hitting the core aspects of our initial objectives by doing a ton of research on thing we didn't know and polishing up on concepts we already had a strong grasp on. Ultimately, what we have built will be a part of the future for our planet in some form or another because our current energy consumption is not sustainable. Using the very prominent embedded systems concepts developed on our bike here, we hope we can continue to improve it and contribute to a healthier future.

  • Figure #10. Completed E-Bike

Project Video

Project Source Code

References

References Used

Appendix

Retrieved from "http://socialledge.com/sjsu/index.php?title=F16:_E-Bike&oldid=33104"