Project
| # | Title | Team Members | TA | Documents | Sponsor |
|---|---|---|---|---|---|
| 61 | Hip Hop Xpress: Power Management System for Converted School Bus |
Anabel Rivera Antonio Rivera Eros Garcia |
Ruhao Xia | design_document1.pdf final_paper1.pdf other1.pdf proposal1.pdf proposal2.pdf |
|
| Antonio Rivera (amr2), Eros Garcia (egarci90), Anabel Rivera (anabelr2) **Hip Hop Xpress: Power Management System for Converted School Bus** **Problem** - Dr. Patterson pitched his project, the Hip Hop Xpress bus, in class. This converted school bus will serve as a mobile educational platform to teach children about STEM through hip hop and music. It will contain DJ equipment, such as stereos and mixing tables, and various LEDs and other electronics throughout the inside and outside of the bus. In order to run the equipment while the bus is parked and the engine is off, we will need to implement a battery reserve. The bus is intended to be as flashy as possible, but it should also be as green as possible. To this end, the bus’s core electronics should be battery-driven and work for an extended period of time without running the engine. **Solution Overview** - Describe your design at a high level and how it solves the problem and introduce the subsystems of your project. Due to the scope of this project, a large portion of this project will be bought off-the-shelf. We will be focusing on creating a custom Battery Management System and Data Management subsystem. We will be designing a battery pack from lead acid batteries due to their robustness and since weight is not a concern for this project. The pack will be managed by a custom battery management system (BMS) PCB. This BMS will have the ability to charge the batteries from either the solar array, which we will help install on the roof of the bus, or via AC outlet. This BMS will also perform the basic tasks of monitoring voltage, current, and temperatures from the batteries. We will use voltage probes to directly measure the voltage from the batteries. To measure current, we were looking either attaching a hall-effect current sensor or creating a current sensing circuit at measure. For temperature, we will look at temperature sensors on critical points on the batteries. The data management system will use all of these sensors to provide an excellent picture of the condition of the batteries. This information can be used for applications such as emergency shutoffs or battery modeling. The battery modeling is especially useful as it can be then sent to a display, such as an LED display connected to a Raspberry Pi, to provide valuable information on the batteries. We can display information such as battery percentage remaining, outgoing power from the batteries, incoming power from the batteries, and remaining time that the bank can supply at the current power draw. The power data can be stored and transmitted for further analysis. # Solution Components ## Data Management This subsystem will clean and transmit sensor data for battery diagnostics, as well as save sensor data for analytics. The signals will be digital. These will be feeding into 3 microcontrollers, such as an Arduino Mega, which has a large amount (54) of digital pins. This system must process the sensor data to remove some noise. We will need to take into account the delay that will arise from processing. Having too much delay can affect the controls and be too late to be useful for shut-off purposes. By our power-usage estimates, we will likely need 18 batteries to provide the correct amount of power for this purpose. Therefore, there will be 54 sensors feeding into each of 3 Arduino Megas (162 total signals), and these 3 microcontrollers will be feeding into another controller capable of fast computations, such as a Raspberry Pi. The Raspberry Pi will communicate with the battery diagnostic subsystem. It will also take a snapshot reading every 30 minutes of all the sensor data and power usage data from the solar panels after post-processing and save it, likely as a .csv file for its ease-of-use. Readings can be displayed on a monitor and show information about energy generated from the solar panels as well as an estimate of how much time the batteries can continue to be used. We are exploring transmitting this data to an app, so quick diagnostic information can be viewed from outside the vehicle. ## Battery Management System: This system would be split up into four different subsystems: input power, output power, battery diagnostics, and power flow system. Input power subsystem: This subsystem would be able to take incoming power from various sources. The three primary input methods would be from the bus alternator, the mounted solar panels, and a grid connection. This system would then standardize it to a stable 12V line which would then feed into the power flow subsystem. ## Output power system: This subsystem would take in the 12V line and convert it to whatever the bus will need. Currently, we are looking at creating an AC line to power the majority of the electrical on the bus. Depending on how many DC components end up being needed on the bus, then we can add an additional DC line for those devices. ##Battery diagnostics: This subsystem would be in charge of handling all of the raw sensor data and making general decisions for the power flow system. This system would consolidate sensor information and, using triple redundancy, determine what values are true. In other words, we will have 3 of temperature, voltage, and current probes on each battery. This system would also be able to sense if a single sensor in a group is faulty. It will then flag the sensor to be replaced by the user. It would also be in charge of decisions for the power flow subsystem. This system will have three copies to allow for triple redundancy. (link:https://en.wikipedia.org/wiki/Triple_modular_redundancy) ## Redundancy subsystem: This system will be made to be as reliable as possible. This system would manage the Battery diagnostics subsystems and detect errors in the system. Due to the triple redundancy in the Battery diagnostics subsystems, it will be able to both detect errors and determine which of the subsystems is faulty. It would accomplish this via polling and use the majority rule to determine correctness. ##Power flow: This subsystem controls the power flow to and from the batteries. As incoming power increases compared to the load, this will allow excess power to be used to charge the batteries. As the outgoing load increases compared to the incoming power, it will change the direction of power flow from the batteries to the rest of the bus. This system is also responsible for individually charging/discharging/connecting/disconnecting each battery. This should increase the safety of the charge/discharge cycle. This will also have the ability to disconnect batteries from the circuit for safety purposes. #Criterion for Success Our demo would be split up into two different major tests based on which system that we are testing. One small scale test that can be run in the lab and another larger test in the bus. To test our PCB, we would run tests in the lab to force responses depending on the test. We can start by running the system under perfect conditions and show that the system can reliably charge and discharge the batteries. We would then test its ability to charge the batteries using excess incoming while a load is connected. The last test for perfect conditions would be to draw from the batteries while supplementing them with any incoming power. During these tests, the voltage and current readings on the oscilloscope should be stable and clean. Also, no components should overheat in this section. We will check the thermals using a laser thermometer We would then simulate errors in the system to show that the system will continue to function. We will simulate an error in the data subsystem to show that the redundancy subsystem will function. It should be able to determine the correct information from the three lines of data and flag the faulty battery diagnostics subsystem. Along with this, we can have the battery diagnostics subsystem flag faulty sensors by simulating sensor failure. We would ensure that each of the above subsystems are working using oscilloscopes and other lab equipment as necessary. The larger, and arguably more fun test would be demoing using the entire bus. We would show that our system is capable of running the bus without issue. We would have the bus running lights, speakers, etc. The system should then display as necessary information and should be able to run similarly to the first round of tests in the lab. |
|||||