Wednesday, August 12, 2015
Tuesday, May 12, 2015
Monday, April 20, 2015
Code Is Coming Along
Our Buck-Boost Converter has been finalized, and the PCB has been sent. While we wait for that part to come in, we're working on our code. We have finalized a lot of code thus far in preparation for the PCB. The speed algorithms have all been written, including the PID controller. As of now the PID isn't truly a PID, in that it simply tests for the current error and adjusts proportional to the error. But we felt that this kind of acceleration program would be best because it gradually adjusts between two speeds. Other than that, we also have the code for reading the node voltages from the two power sources and we can read the current from both power sources. All that's left to do at this point is to test the code using our actual circuit (and our PCB) and then to write the control system.
Thursday, April 16, 2015
Update: Circuits and Code
We haven't posted in a while, but since our last post, we have made loads of progress. First, lets talk about circuits. In our last post, we said how we have tested our PWM amplifier circuit. Since then, we have actually been using our amplifier circuits to test the Buck-Boost Converter circuit. As we said before, this circuit is used to power the motor through a motor controller by providing two power sources. The idea is then to use PWMs to trigger transistors to activate the super capacitor as needed, and also to charge the super capacitor when we are in the state of regenerative braking. Since then, we have been working to test our Buck-Boost Converter circuit, which has been working as expected. Initially, we tried to PWM our transistors without using the amplifier circuits just to see whether it would, but we found that the capacitor and battery currents didn't add up to the current going into the motor. After we realized, in our sleepless state, that we needed our amplifier circuits, we put a PWM of 1 ms period and 25% duty cycle through our amplifier circuit into the boost transistor and we saw an increase in the capacitor current, a drop in battery current, and no change in the final current, which is our desired behavior. We tried a few other duty cycles and they all seemed to work well in terms of matching up currents. However, we did notice that there were maybe 15 mA unaccounted for between the battery and the supercapacitor. After some careful analysis, we realized that some current was naturally going to be lost to ground when we are switching with the boost transistor. Thus the Buck-Boost converter was working properly.
However, we ran into some issues when it came to reading values from the circuit. In order to write the control system and the PID, we needed to know four things about the circuit: the battery voltage and current, and the supercapacitor voltage and current. Our strategy for finding voltage was just to plug the desired node into an AnalogIn pin on our mBed, and our strategy for finding current was to place a small resistor just in front of the power source, measure the voltage drop across that known resistor, and use Ohm's law to find the current. Initially, we thought that we'd plug the desired nodes into AnalogIn pins directly. But then we realized that if we did so, we would fry our mBed, as the voltage levels we were dealing with were at least 17 volts. Our next instinct was to take the two voltages and run them through a subtractor circuit, which would give us differences that range between -1.65V and 1.65V, to which we could just add a total of 1.65V to give us a total range between 0 and 3.3V. This sounded practical to us because the AnalogIn pin would be able to read in these values and we could backtrack to find the voltage drop across the resistor. However, we ran into issues with getting our subtractor circuit to work. With a gain of 1, we thought that it should not amplify the difference at all, but we were getting strange values for the difference. Eventually, we came across the hypothesis that it might have something to do with the the offset null output, but we had since decided to scrap the idea for what seemed like a better one at the time. We realized that we could use a voltage divider circuit with high resistor values that lead to ground, measure the voltage drop across the smaller resistor, and backtrack to find the node voltage. This seemed to be the solution we were looking for, but for some reason, on the battery side, the readings we were getting didn't make sense. Somehow, a battery giving out 18 volts somehow was only giving 17.82V, which is understandable given internal resistance. But what was stranger is that the voltage drop after the resistor gave a voltage of 18.28V, which meant that either current was going into our battery, or we were measuring incorrectly. This is where we left off for the night.
The only things left to do circuit-wise is to make sure that we can read node voltages properly, and make sure we can read the encoder properly. We saw from the oscilloscope that the encoder gives us a sine wave where the frequency corresponds to how fast the wheel is spinning relative to its top speed. But we were unable to read this using AnalogIn pins, as our frequency determination algorithm gave us frequencies far less than the true values. Instead, we decided that we will convert this sine wave into a square wave using a two stage differentiator circuit. We will then feed that output into an InterruptIn pin and use the interrupt function to determine the frequency. This calculation is important for the control system and PID controller.
We made lots of progress with our circuits, and now our next steps are to fix our voltage reading problem, quickly make and test our differentiator circuit, and start writing the control system and PID controller. Our plan is to finish all circuitry tomorrow and Friday, and to work on the code over the next few days, having something very close to finished by Monday. On Monday, we want to get a very basic demo working, and from there we will start working on our extras.
However, we ran into some issues when it came to reading values from the circuit. In order to write the control system and the PID, we needed to know four things about the circuit: the battery voltage and current, and the supercapacitor voltage and current. Our strategy for finding voltage was just to plug the desired node into an AnalogIn pin on our mBed, and our strategy for finding current was to place a small resistor just in front of the power source, measure the voltage drop across that known resistor, and use Ohm's law to find the current. Initially, we thought that we'd plug the desired nodes into AnalogIn pins directly. But then we realized that if we did so, we would fry our mBed, as the voltage levels we were dealing with were at least 17 volts. Our next instinct was to take the two voltages and run them through a subtractor circuit, which would give us differences that range between -1.65V and 1.65V, to which we could just add a total of 1.65V to give us a total range between 0 and 3.3V. This sounded practical to us because the AnalogIn pin would be able to read in these values and we could backtrack to find the voltage drop across the resistor. However, we ran into issues with getting our subtractor circuit to work. With a gain of 1, we thought that it should not amplify the difference at all, but we were getting strange values for the difference. Eventually, we came across the hypothesis that it might have something to do with the the offset null output, but we had since decided to scrap the idea for what seemed like a better one at the time. We realized that we could use a voltage divider circuit with high resistor values that lead to ground, measure the voltage drop across the smaller resistor, and backtrack to find the node voltage. This seemed to be the solution we were looking for, but for some reason, on the battery side, the readings we were getting didn't make sense. Somehow, a battery giving out 18 volts somehow was only giving 17.82V, which is understandable given internal resistance. But what was stranger is that the voltage drop after the resistor gave a voltage of 18.28V, which meant that either current was going into our battery, or we were measuring incorrectly. This is where we left off for the night.
The only things left to do circuit-wise is to make sure that we can read node voltages properly, and make sure we can read the encoder properly. We saw from the oscilloscope that the encoder gives us a sine wave where the frequency corresponds to how fast the wheel is spinning relative to its top speed. But we were unable to read this using AnalogIn pins, as our frequency determination algorithm gave us frequencies far less than the true values. Instead, we decided that we will convert this sine wave into a square wave using a two stage differentiator circuit. We will then feed that output into an InterruptIn pin and use the interrupt function to determine the frequency. This calculation is important for the control system and PID controller.
We made lots of progress with our circuits, and now our next steps are to fix our voltage reading problem, quickly make and test our differentiator circuit, and start writing the control system and PID controller. Our plan is to finish all circuitry tomorrow and Friday, and to work on the code over the next few days, having something very close to finished by Monday. On Monday, we want to get a very basic demo working, and from there we will start working on our extras.
Sunday, April 12, 2015
Drive Motor Trouble
We're going to be up late tonight working on a lot of different things for the ProtoDrive 3.0. As of now, we are making sure that we can properly run motors using PWM signals from the mBed at our desired duty cycle. Initially, we were having trouble getting our desired duty cycle to match up to the speed of the motor, so we decided to tweak the PWM period to find a sweet spot. We eventually settled on a 10 ms period (100 Hz) and are varying our duty cycles from there. Using test duty cycles of anywhere from 1 to 99%, we determined that the motor is now behaving exactly as expected from direct control. Now it's time to test our DC to DC converter circuit by applying PWMs to our Buck and Boost transistors to see if the circuit is working as expected.
Friday, April 10, 2015
Testing the Amplifier Circuit
Late last night we were able to test our amplifier circuit using a PWM signal from our mBed. We connected the original PWM signal to the oscilloscope to ensure that PWMs were outputting as we expected. Initially, we were perplexed by a strange issue. The PWMs seemed to have a peak-to-peak amplitude of only 0.33 V, when we were expecting 3.3 V. The fact that this was lower than expected by exactly a factor of ten was the difficult part to understand. We eventually realized that we foolishly had the probe set to x10, which reduced the amplitude on the oscilloscope. After we remedied this issue, we got the following correct output on the screen:
After we ran our signal through our amplifying circuit, we got this output:
We chose to have the circuit amplify to approximately 5.1 V to account for any additional load or voltage lost due to heat.
Because the circuit is behaving as expected, we went ahead and designed a PCB. The schematic looks like this:
After we ran our signal through our amplifying circuit, we got this output:
We chose to have the circuit amplify to approximately 5.1 V to account for any additional load or voltage lost due to heat.
Because the circuit is behaving as expected, we went ahead and designed a PCB. The schematic looks like this:
Thursday, April 9, 2015
Buck Boost Converter and Amplifier Circuits
Over the past week, we have been working on the circuitry required for the project. The main piece of circuitry is the Buck Boost Converter, which is a DC to DC converter used to integrate both a LiPo 4.5 V battery and a 128 mF super capacitor.
The main feature of this circuit besides the two power sources are the two transistors in black, which are located in the middle of the circuit. The boost converter is the transistor lower on the image. This transistor is triggered whenever we need to draw more power from the supercapacitor. The buck converter is the transistor on top, and is primarily used for regenerative braking. The basic idea behind regenerative braking is that when a vehicle is slowing down, there is lost kinetic energy that can be converted to electrical potential and used to charge the supercapacitor. Each of these transistors, in our final design, will be given a PWM signal to the gate pin so as to not only determine which transistor is on, but also how long it is on. The two buttons on the circuit were used to test basic charging and discharging of the supercapacitor.
The second circuit we have been working on this week is a simple amplifying circuit to convert the 3.3V PWM of the mBed microcontroller to 5V. This circuit is a simple amplification circuit using two op-amps.
Our next steps from here are to test the amplifier circuit using PWM signals from an mBed (we've only tested thus far using 3.3V VDD). More importantly, however, our goal is to write the control system using various inputs from the buck-boost converter circuit, as well as drive and load motor speeds, and determine which of the two transistors needs to be on, and for what duty cycle/period. Our goal is to finish writing the control system by Monday April 13th and to be able to run simple tests by April 16th. These simple tests should include being able to run both the load and drive motor, being able to test regenerative braking, and being able to boost the drive motor when there is a high load.
The main feature of this circuit besides the two power sources are the two transistors in black, which are located in the middle of the circuit. The boost converter is the transistor lower on the image. This transistor is triggered whenever we need to draw more power from the supercapacitor. The buck converter is the transistor on top, and is primarily used for regenerative braking. The basic idea behind regenerative braking is that when a vehicle is slowing down, there is lost kinetic energy that can be converted to electrical potential and used to charge the supercapacitor. Each of these transistors, in our final design, will be given a PWM signal to the gate pin so as to not only determine which transistor is on, but also how long it is on. The two buttons on the circuit were used to test basic charging and discharging of the supercapacitor.
The second circuit we have been working on this week is a simple amplifying circuit to convert the 3.3V PWM of the mBed microcontroller to 5V. This circuit is a simple amplification circuit using two op-amps.
ProtoDrive 3.0 Proposal
ProtoDrive 3.0 Project Proposal
TEAM NAME - Bowser
TEAM MEMBERS - Pranav Kunapuli and Rron Rexha
TA MENTOR - Vincent Pacelli
TASK ALLOCATION
Rron will be responsible for the circuits involved in integrating the battery and supercapacitor, such as the power system and the motor system circuits. Pranav will be assisting Rron with the motors. Pranav will be responsible for programming the logic using an mBed microcontroller as well as the use of motor controllers, current sensors, and encoders.
MOTIVATION
In the past, electric vehicle power system control software has been solely tested using software simulations rather than hardware. While the software may pass certain simulation tests, once the car is fully developed and the system implemented with hardware, engineers may find that the simulations do not emulate the real-world conditions of the car. Such realizations then call for expensive and time consuming changes to the car. The ProtoDrive project aims to provide a physical platform on which control software can be tested prior to full-scale implementation in electric vehicle drive trains. The project has been attempted in the past, but there have been several shortcomings and areas for improvement. Our primary motivation for attempting this project is to recreate the ProtoDrive from scratch and to successfully link the super capacitor into the system so that it charges and discharges on command.
GOAL
Our final goal is to have a hardware system that can run a DC motor using a combination of a battery and supercapacitor. The Protodrive will asses the simulated situation and accordingly draw power from the battery, the supercapacitor, or both. Our final project will also incorporate the regenerative braking from Protodrive 2.0, which charges the supercapacitor by effectively spinning the motor in reverse during braking.
TESTING AND EVALUATION
We will test our final project using Matlab simulations, as well as current and voltage plots to ensure proper draw from both the battery and the supercapacitor. For the demo, we plan to run the system through a simulated test that demonstrates the varying draw from the battery and supercapacitor as well as the regenerative braking. As an extra task, we intend on printing the circuit on a PCB and incorporating larger motors into our system that can draw more power and theoretically drain the battery, as a realistic electric vehicle would do.
PROJECT TASKS
Baby step: Run a DC motor using an mBed and an encoder to control the speed
Step 1: Run the motor using a battery
Step 2: Use a second motor as a load motor to provide resistive force on the drive motor
Step 3: Add DC to DC converter to allow motor to be run by both supercapacitor and battery. Program the mBed to decide which power source to use based on resistance.
Step 4: Use regenerative braking to charge supercapacitor
Extra Steps: Print a PCB of the circuit, incorporate larger motors.
EXPECTED PARTS
- 2 DC Motors, 2 Motor Controllers
- 2 LiPo Batteries
- 1 mBed Microcontroller
- 1 Supercapacitor
- 1 Relay
- Current sensors
- 2 Temperature Sensors (for safety)
OVERALL SYSTEMS
- Motor system, Power system and Control system
TIMELINE
Sprint 1: March 23rd - 29th
- Finish baby steps
- Begin on running motor with battery, add load motor and test system with load motor
- Build DC to DC converter for Step 3
- Read up on Matlab
Sprint 2: March 30th - April 5th
- Integrate the supercapacitor
- Use DC to DC converter from Sprint 1
- Write control algorithms
- Read up on Matlab
Sprint 3: April 6th - 12th
- Incorporate sensors
- Begin writing Matlab tests and simulations
- Design the PCB
Sprint 4: April 13th - 19th
- Finish Matlab data output and simulations
Sprint 5: April 20th - 24th
- Final tests
- Find and fix any remaining issues
- Rehearse demo
Subscribe to:
Posts (Atom)