Difference between revisions of "F16: E-Bike"

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

Parts List & Cost

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

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 Video

Project Source Code

• GitHub Source Code Link

References

References Used

• Mounting a Motor
• Pedal Power How To Build A Bike Generator
• Recipe for a Badass DIY Electric Mountain Bike

Appendix

• LPC1758 Datasheet
• IRF630 Power MOSFET Datasheet
• Nextion Screen Instruction Set