Created by Richard Banks on May 01, 2013. Last modified by Robert Nelson on Sep 08, 2017
Introduction
The South Dakota School of Mines and Technology (SDSM&T) Autonomous Underwater Vehicle (AUV) Team was challenged with providing its submersible vehicle with power from nine batteries and electronic propulsion control throughout its mission of exploring extreme underwater environments. We accomplished this with two project efforts, producing the AUV Smart Power System, and the AUV Electronic Propulsion Control System.
AUV Smart Power System
Through team discussion and evaluation of methods in use, the AUV Smart Power System senior design group developed strategies for handling these complications. During switching of these batteries, an echo of their state is used to eliminate problems with communication and switching delays. For redundancy, multiple controllers are used to step in when a primary controller fault occurs. For a diverse system, a “Rogue Mode” protocol is implemented to handle communication loss in this system. This protocol allows the AUV to operate even after partial or total communication loss, and with each independent source having no knowledge of the other sources’ activity. Through this approach, the AUV Smart Power System senior design group was able to develop a more diverse control system with methods easily applicable to other power control systems.
The mission of the SDSM&T AUV Smart Power System senior design group was to create a modular system capable of powering the Autonomous Underwater Vehicle for a five hour period. This system will utilize smart battery management and report all relevant battery data to the AUV’s head node. The complete power system must be pressure resistant up to 1500 psi, withstand temperature swings from 20⁰F to 200⁰F, supply 12 Volts unregulated for a three hour mission plus two hours of backup, and communicate using I2C protocol.
The Smart Power System group built three complete battery containers, the redundant Master Battery Brain (MBB) system, program for the Sub Battery Brain (SBB), program for the MBB, all components necessary to completely finish the system, along with detailed documentation. The SBB program switches between the two power buses, have voltage, current, and coulomb monitoring, detect battery depletion, and terminate battery usage upon depletion. The MBB program has smart control of battery usage, controlling all batteries to meet the sub’s power needs, and sends relevant data to the head node. It also implements a smart switching algorithm.
Overall Design Concept
Due to the long mission time, the power system consists of a total of 36 20Ah 3.2V LiFePO4 cells, making a total of nine 12V batteries. Each of these batteries will be contained in a waterproof container consisting of the following devices:
- One Arduino Nano (Digi-Key Part Number 1050-1001-ND) as the SBB
- Two Power Switching Boards (PSBs)
- One 4066 Chip - Quad Bilateral Switch (Digi-Key Part Number 296-28986-2-ND)
- Four LiFePO4 Battery Cells
Figure 1: Overall Design Concept
Additionally, three other Arduino Nanos will compose the redundant MBB system. As for communication, the MBBs and SBBs will utilize I2C and the Arduino Wire library. The MBBs will communicate to the SBBs their intended bus state while the SBBs communicate to the master MBB the following: PSB bus voltage, PSB current, battery voltage, coulomb count, battery depletion status, and bus state.
MBB Design Concept
The Master Battery Brain complete setup consists of three redundant controllers inside the head node, as shown in Figure 1. The code to implement the controllers is Appendix E, and the documentation is in Appendix D.
Figure 2: MBB Schematic
This controller system is the main brainpower behind the smart power system; therefore, redundancy is necessary and crucial in case of controller failure. Only one controller will be “main master” at a time; this controller will be in charge of determining the state of each battery, collecting the batteries’ data, and speaking to the AUV computer in the head node. The other two spare masters will constantly be checking the functionality of the main master to ensure it is communicating successfully. If ever the main master does not successfully communicate back to the first spare master, this spare will take over as main master and begin communicating to the sub controllers. Similarly, the second spare master consistently checks the status of the main master and the first spare master. If both the main master and first spare master become faulty, then the second spare master takes over control of the power system. This routine ensures that there will always be one main master in control of the SBBs at any given time as long as all three are not faulted. In addition to detecting and compensating for a primary master failure, the MBB also does the following:
- Sends a request to all nine containers for their battery data
- From the data, the MBB calculates the total battery life remaining for each container
- Sends power system data to the head node
- Controls battery container bus state with a smart switching algorithm (discussed below)
Battery Container Design Concept
The nine battery containers on the submarine will supply power to either the clean or dirty bus. The SBB inside each battery container will perform the following tasks:
- Controls the PSBs’ state
- Reads data values from the PSBs
- Calculates the battery coulomb count
- Determines if battery is depleted and communicates its status to the MBB
- Sends all requested data to the MBB
- Contains communications loss protocol (discussed below)
Figure 3: Battery Container Block Diagram
Additionally, a 4066 microchip is used in order to isolate the Arduino communication after power loss. The necessity of this chip will further be discussed in the testing section. The code for the SBBs is Appendix G. The documentation for the SBBs is Appendix F.
Power Switching Board (PSB) Operation
The Power Switching Board (PSB) serves the purpose of controlling power flow and conditioning measurements from each battery for a microcontroller to read. Each PSB is dedicated to one bus on the submarine, resulting with two PSBs in each battery container. The connections are shown in Figure 4 below, with terminals for 5V in, 4.5V-76V in, current sensing, voltage sensing, and switching control. A bill of materials, schematic, and Eagle PCB file for manufacturing are available on the SVN. This board is designed to operate at up to 30 amps but long term discharge current should be kept below 13 amps because of overheating issues.
Figure 4: PSB Connections
A description of each terminal is a follows:
Vin: Main input voltage which will be wired to each battery container switch. This terminal requires a minimum of ~5V to cause current flow because of the circuit configuration. Do not surpass 14V or the analog voltage sensor will exceed 5V; this would make the voltage unreadable by the microcontroller. This can be avoided by resizing the voltage divider
Vout: Output voltage terminal. The voltage at this terminal may dip under heavy load.
5V: Power for the voltage followers used on the VSense and ISense terminals.
VSense: Analog 0-5V output proportional to Vin terminal. This Vsense terminal is from a voltage divider circuit with 680K and 470K ohm resistors. This is then put through a voltage follower circuit before the terminal shown in Figure 5.
4.5-76V: This is the voltage supply for the current sensing chip. Normally this is just jumpered to the 5V terminal.
ISense: Analog 0-5V output proportional to current flowing through a 0.02 Ohm resistor. This voltage is then measured by a TASA amplifier. This Isense terminal is from a voltage divider circuit with 680K and 470K Ohm resistors. This is then put through a voltage follower circuit before the terminal shown in Figure 5.
Switching Control: This controls the mosfet that does the switching of voltage throught the board. This terminal is wired normally closed. With no voltage at the terminal, current is allowed to flow, while 5V stops current flow.
Switch Bypass: This terminal is not normally used during operation. For troubleshooting purposes, this terminal is a bypass of the mosfet while still allowing the board to measure voltage and current levels.
Figure 5: PSB Bottom Side Component
Troubleshooting
VSense terminal reads none or incorrect voltage: The voltage follower circuit is either faulted or improperly configured. If an improper voltage is measured the voltage divider circuit will need to be modified. If no voltage is measured check that the Op-Amp shown in Figure 5 is receiving 5V, then jumper 5V into input pin 3. If the Op-Amp is functioning properly 5V should be measured on the VSense terminal. If this is not the case the Op-Amp will need to be replaced.
ISense terminal reads none or incorrect voltage: The voltage follower circuit is either faulted or improperly configured. If an improper voltage is measured the voltage divider circuit will need to be modified. If no voltage is measured check that the Op-Amp shown in Figure 5 is receiving 5V, then jumper 5V into input pin 3. If the Op-Amp is functioning properly 5V should be measured on the ISense terminal. If this is not the case the Op-Amp will need to be replaced. If the Op-Amp is functioning properly the TASA current amplifier shown in Figure 2 will need to be replaced.
Power System Bill of Materials
| Power System Bill Of Materials | ||
|---|---|---|
| Item | Part # | Distributer |
| Tenergy LiFePo4 20Ahr | Tenergy | |
| Arduino Nano | 1050-1001-ND | DigiKey |
| Aluminum BusBar | ||
| PCB Board – 2 layer | Advanced Circuits | |
| Wire 14 AWG | ||
| Schottkey Diode 40A | MBRB4030T4G | DigiKey |
| Optocoupler | LH1540AT | Vishay |
| OpAmp | MCP6231-E/P-ND | DigiKey |
| MOSFET Pchan | IRF9Z10PBF-ND | DigiKey |
| MOSFET N chan | IRF520NPBF-ND | DigiKey |
| PMOSFET | FQP27P06-ND | DigiKey |
| Current Sense | MAX4080TASA±ND | DigiKey |
| Power Resistor | PF2472-0.020-ND | DigiKey |
| Cap | P6473-ND | DigiKey |
| Term Block Small | 277-1273-ND | DigiKey |
| Term Block Big | A98275-ND | DigiKey |
| Heat Sink | EV-T220-38E | DigiKey |
| I2C isolator chip | 568-1694-5-ND | DigiKey |
| 14 pin IC socket | A100205-ND | DigiKey |
Echo Battery Switching
Echo battery switching is the switching of batteries with an echo received from communication with the SBBs. As mentioned earlier, the smart power system will have nine batteries turning off and on over the mission of the AUV. Due to the fact that any interruption in supply would cause a blackout condition, the switching of these batteries needs to be completely seamless. To facilitate this, the design includes several key items such as an echo state, blackout prevention, overcurrent protection, and advanced depletion detection.
The goal of any power system is to reliably supply power to a load; the AUV power system ensures this by always knowing the bus state of every battery. Due to communication delays, it is possible that the MBB could assume a battery is in the communication transmitted state and take its next actions before confirmation of the battery state has been received. Obviously, if a communication delay was too great and another switch occurred before confirmation, there could be none or too few batteries supplying the AUV. Therefore a confirmation of battery state echo is received with every communication exchange in order to provide consistent power to the AUV.
Before switching, the power system controller is required to analyze the impact of all actions. This decision starts by looking at the current number of batteries in use and any desired switching that would resultantly reduces this number. When this number is reduced below a certain level that will either cause a current overload or blackout, no more switching assignments are allowed until the next switching cycle. These switching cycles are effectively controlled by the battery state echo. When the echo matches the last transmitted state, the switching cycle can begin again. After repeated cycles, even with a limited number of batteries, all desired switches can occur in a seamless fashion. During end of mission cycling, this switching can become difficult with few batteries available. To account for this, the system is designed to bypass this safe switching practice in order to best fulfill the power requirements of the system during low supply capability situations.
Towards the end of mission time, as depleted batteries become more prevalent, it is very important for advanced depletion detection. Besides percent life calculations from coulomb counting, it is necessary to allow the power system controller to anticipate the depletion of a battery so that it can move replacements for reliable power supply. To accompany this, each SBB will constantly analyze its batteries condition (voltage and current characteristics) to determine if it is near depletion. It will then report its impending depletion status to the MBB while continuing to supply power; this allows sufficient time for a replacement to be made.
Communication Loss Operation
In the event of communication failure between the MBB controllers and the SBBs, appropriate actions need to be taken for a consistent power supply. Communication could be lost for a variety of reasons but the result is the same; the power system needs to be able to continue to supply power to the AUV. During a communication loss, a SBB has no knowledge of what other SBBs are doing and what the system power demands are; what it will be aware of is the voltages on the clean and dirty bus and the current of the battery while on one of these buses.
Communication loss is most likely to occur if the MBB makes a mistake and removes power from the clean bus, effectively removing power to itself (causing a reset), or else some temporary communication loss occurs. During communication loss, each SBB can assume the last commanded state is appropriate. While the communication loss continues, the SBB watches the voltage on each bus. If a bus voltage becomes zero volts, it is safe to assume no batteries are supplying that bus. Then based on a predetermined delay determined by the SBB’s I2C address, the SBB will switch to that bus and commit to it regardless of subsequent events. This will allow the system to continue to supply power until communication is resumed.
Testing
PSB Operation
Of the PSBs we received upon starting this project, only a few were completed and fully functional. In order for the power system to be operational we needed these boards. The devices that required testing were the components that gave the board the abilities to perform switching, analog voltage sensing, and analog current sensing. After fully assembling these boards, we proceeded to test them by connecting a power supply to the Vin terminals. After applying a test load to the bus terminals, the amperage on the power supply would change. After applying 5V to the switching control pin, the current would raise and lower if functioning appropriately. While current was flowing, the voltage and current sensing pins were measured for an appropriate voltage level.
After testing we discovered five boards had at least one defective component. The current sensing circuit was especially difficult to troubleshoot because of the fact that it included both a current sensing chip and an Op-Amp. This was isolated by inputting an arbitrary voltage into the Op-Amp follower circuit. From there, the required component to replace was found. A more detailed explanation of the power switching boards is contained in the power switching board manual, Appendix C.
Figure 6: SBB and PSB Layout
Redundant MBB Program
In order for reliable power system operation, three redundant MBBs are used in coordination with each other. These will be tested to check that after the failure on the primary MBB, a redundant MBB takes over. This was tested by putting an oscilloscope on the I2C clock pin; during operation this pin reads a square wave. After removal of the first MBB, the clock pulses died temporarily. This showed that communication halted because of no master being present. Shortly after the clock pulses resumed, which displayed and confirmed that the second MBB took over. After removing the second MBB the results were the same with the third MBB. This shows that after primary MBB loss, another MBB will always take over. After testing this, changes were made to the MBB program to allow multiple communication failures to occur before taking over. This step was necessary since we had periods when two MBBs tried to become master at the same time. The redundant MBB schematic is Appendix B. The code for the redundant MBB program isAppendix E with a Doxygen documentation file in Appendix D.
Figure 7: Master Battery Brain Board
I2C Communication
The power system uses I2C communication for all the micro-controllers to communicate with each other. This needs to be verified for proper operation in order for the power system to function. This was tested by watching the serial output from communication with the MBB. By viewing this, we were able to successfully see data from all SBBs on the communication bus.
During testing, we noticed that communication would halt after an SBB lost power. After testing with a logic analyzer, we realized that the communication was being pulled to ground. This is a result of the Arduino pins being sent to ground while power is turned off. To solve this issue, we inserted a 4066 isolator chip. Upon installation of this chip, we were able to confirm that communication resumed after power loss.
After putting all three redundant MBBs in the system with three SBBs active, we began having intermittent communication issues. After viewing the I2C clock pulses with an oscilloscope, we were able to see communication had halted. Through research, we found out pull-up resistor sizing on the I2C lines is fundamentally important. We had a pull-up resistor set on each redundant MBB which resulted in too high of a current for the Arduino pins to pull down. After this test we changed the I2C bus to only have one set of 4.7KΩ pull-up resistors. We were then able to see the waveform in Figure 5. From this, we now know the I2C bus is sensitive to the number of devices on it and the amount of pull-up current used. For any future changes in the bus size, the pull-up resistors should be tuned to get the same waveform on the clock pin as in the figure below. The schematic for our I2C communication setup in the MBB is shown in Appendix B. The schematic for the I2C isolation in the battery container is shown in Appendix A.
Figure 8: Waveform of I2C Clock with Properly Sized Pull-Up Resistors
Smart Switching Algorithm
The MBB needs to regulate the SBBs’ battery bus status to prevent current overloads or blackouts. Current overload was tested by putting a false load into the MBB program and watching the resulting changes in bus status that occurred on a logic analyzer. Resultantly, the MBB automatically adjusted the number of batteries on every bus to keep current to an ideal value. This proved the operation of that aspect of the smart switching algorithm worked. By looking at the changes as they occurred, we were able to see that there was a delay in between every, confirming echo switching was occurring. Also while switching, it was confirmed that the number of batteries on each bus never went below one and never went below the minimum number to safely provide current to the system. The code for this switching in the MBB program can be found in Appendix E with a Doxygen documentation file in Appendix D.
Battery Depletion Detection
It must be verified that after a battery is depleted it is removed from operation and the MBB is notified before removal. Battery depletion detection is required to prevent degradation of the battery functionality. Depletion detection was tested using a power supply as a battery. After turning the voltage below a cutoff value, the SBB will continue to supply power for a short period of time but report itself as unavailable to the MBB. This functionality was verified using a logic analyzer and the MBB serial print. The logic analyzer verified that a new battery was set to the depleted battery’s bus location well before the SBB actually turned off its PSBs. After this test, a change was made in that a bit was set to lock the SBB into a depleted state. This change was required because, after unloading a battery, its voltage levels increase above the cutoff threshold. Fluctuating voltage levels would result in the SBB continually being assigned on and off a bus. The code for battery depletion detection can be found in Appendix G and a Doxygen file is in Appendix F.
Battery Discharge Optimization
The power system needs to be tested so that it will use battery life as efficiently as possible. This was verified using discharge characteristics. After discharging a battery at 1 Amp and then 15 Amps the result is shown in Figure 9. This test resulted in us inserting an ideal current section in the MBB code that determines the required number of batteries on each bus based on an ideal current.
Figure 9: Low/High Current Battery Discharge Test
Conclusion
The AUV Smart Power System senior design group successfully achieved its goals. We designed the battery container internals and redundant MBB setup; as well as produced a program for both the MBBs and SBBs in the power system. We fully tested the functionality of our system and verified it is capable of supplying the power requirements of the AUV. The MBBs safely manages the SBBs over I2C and provides consistent power. Even under communication loss, the SBBs were tested to be capable of power supply. Our goals were steadily achieved over the course of our senior design semesters with little climax of workload at the end. We stayed well within our planned budget and still have an excess of monies left in the power system funding we received. At the end of our senior design, we delivered three fully functioning battery container internals and a redundant MBB setup.
The majority of the power system specifications were met except for a few unconfirmed requirements. All of our components, besides the battery cells themselves, were crush tested to 2000 psi. We calculated the power requirements over the duration of a mission and were able to supply a three hour mission with a dwindling capacity for the two hour emergency reserve. The temperature specifications could not be tested due to a lack of a testing device and a full system pressure test could not occur due to size restrictions. Our communication requirements were satisfied during testing as well.
This year we made a large impact on the power system and produced a functioning project. If this system is going to be fully utilized, future work will be required. With the documentation, we have provided a more directed task than we received. Future work to be done should start with a design of a circuit board for mounting the redundant MBBs. This would create a more finished product for mounting in the Head Node. Upon entry to this project, we were given the PSBs for control and measurement of power flow. While these boards work well, their upper level current handling capabilities do not support long term discharge. Also in order to switch between the clean and dirty bus, each battery container requires two PSBs. If a redesign of the PSBs occurred, the two boards could be combined into one PSB, as well as include mounting for the SBB. Voltage regulation was discussed often in this project; this could be future work as well if voltage regulation is required and current regulation could be included in the circuit. Additional changes that would make the system more diverse are advanced communication loss handling in the SBBs and a voting system in the redundant MBBs. Some future work that would be required before the full operation of the AUV could be achieved is manufacturing of at least nine battery containers. Currently we have produced one fully functional battery container and only the internals for two additional battery containers. After more battery containers are manufactured, the internals could be constructed and installed as well.
AUV Propulsion Control
This portion of the AUV Senior Design Project was to build an electronic circuit that can perform two tasks. The first task is to control the main and secondary thrusters of the SDSM&T Autonomous Underwater Vehicle (AUV). The second task is to allow a controls engineer to perform a system identification of the propulsion system by interfacing with a frame-mounted force transducer. The completed system is accessible to engineers with a limited knowledge of advanced microelectronic circuits, and to this end, I created a User Guide as an aid to the engineer.
Design Development
When I was hired as Lead Electronic Propulsion Control Engineer, the Team Leader presented me the specifications for design as outlined at Figure 10.
Figure 10: Design Specifications
In response to these requirements, I developed the block diagram at Figure 11.
Figure 11: Development Block Diagram
For the final design, I selected the Atmel XMEGAB1 development board (Digi-Key Part Number ATXMEGAB1-XPLD-ND) for its USB communications capability, LCD interface, multiple general-purpose input/output ports, small size, and processor speed. The main code contains the following modules:
PWM Control of Motor (Underway Mode)
The Atmel XMEGAB1 is programmed using the AVR On-Chip Debug System (Digi-Key Part Number ATJTAGICE3-ND).
In Underway mode (AUV is in operation in water environment) I control the motor speeds by Pulse Width Modulation (PWM). To provide current to the motor, we use the Turnigy Car 60 Electronic Speed Controller (ESC), which accepts a 400 Hz PWM signal and provides full forward power at 84 percent duty cycle, and full reverse power at 36 percent duty cycle, with a deadband (idle power) between 58-62 percent. I use the 16-bit TIMER0 in Output Compare Mode to generate the waveform, with a routine to provide over and under current protection. I vary the TOP value by software, so that the full range of motor speed selection is available, and the entire routine is conducted by Interrupt Service Routine (ISR) so that processor latency time is eliminated.
PWM Control of Motor (System Identification Mode)
In System Identification Mode (AUV is in test configuration) I control the motor speeds by Pulse Width Modulation (PWM) according to a sine wave whose period, frequency, and modulation I control by software. I use the same 16-bit TIMER0 in Output Compare Mode to generate the waveform as before, adjusting the TOP value by reference to a 16-bit resolution sine value, which I reference by lookup table (Appendix 2).
Throttle Control (Underway Mode)
My current configuration includes a 10KΩ potentiometer throttle to provide thruster speed commands. I use the chip’s ADC to convert the voltage to a digital value for the program to resolve into speed commands. I sample the throttle value in software by initializing one ADC channel and then bring the 10-bit ADC value into the algorithm by ISR, therefore reducing processor latency. I had help with the ADC coding from Scott Schmit.
LCD Display
I use the XMEGA LCD display to provide the current PWM value, displayed as a voltage, and the mode of operation the circuit has been configured for. See Scott Schmit’s wiki on how this works. Figure 12 shows a sample display.
Figure 12: Sample LCD
I modified Scott Schmit’s code to provide for the two data lines and the icons shown in Figure 3. The bar graph icon gives a graphical display of the full range of engine speed selections. This sequence shows the board configured for Underway Mode (U).
Reading of Force Transducer
My program has the capability of reading any force transducer with voltage rating up to 2 mV/V. The AUV Test Tank currently has a test frame installed, and an Omega Model LCUB-100G Load Cell Force Transducer attached. I currently have an amplifier board in circuit which provides a gain of 100, but the ATXMEGA 128B1 ADCs also have a gain option of 64, so the amplifier is not required.
I read the Load Cell ADC value using the same method as for reading the throttle, so that processor latency is not affected.
The diagram for system identification is shown at Figure 13.
Figure 13: System Identification Diagram
Data Extraction (System Identification)
Once the system identification session is complete, I enable the user to download the force transducer value into a VT100 terminal emulator. I use Atmel’s supplied USB library function for this, which creates a Communications Device Class (CDC) connection for the XMEGAB1 board. This appears in Windows Device Manager as a Virtual Communications Port, and enables serial communication similar to a Serial Print for Arduino or printf and scanf for other microcontroller boards.
Once I connect the board to the PC via USB, I open my terminal emulator (I use TeraTerm) and enable the logging feature and time-stamping to download the data file with time values. I open the data file using Excel and port the data into MATLAB for processing. My procedure and MATLAB code is at Appendix 3.
Module Configuration
The test throttle (used for underway mode) is a 10KΩ potentiometer (Digi-Key Part Number P3G7103-ND). The module is designed to house 6 controllers for control of 6 independent thrusters, so I used 25 mm standoffs (Digi-Key Part Number 25506K-ND) to provide support and spacing for the boards.
Test & Evaluation
I tested the System Identification feature by configuring the XMEGAB1 to vary the thrust (forward motion only) in a sinusoidal pattern, with a period of 16 seconds. The primary focus of my test was an evaluation of the capability to retrieve data from the chip, and not to perform a robust controls process application. For this test, I connected the system to the AUV’s Smart Power Battery System, and made a video record of the test which can be viewed at http://www.youtube.com/watch?v=4-H5dGNbo1E.
I obtained the plot shown in Figure 14.
Figure 14: Test Signals
For the test of the Underway mode, I configured the XMEGA to take inputs from the test throttle, and verified thruster operation from full reverse to full throttle. The test can also be seen on the YouTube video.
Conclusion
I have provided a working solution to the electronic control of the UAV thrusters, and an adjustable algorithm to begin System Identification of the propulsion system. Users can refer to the Quick Start Guide (Appendix 4) to immediately begin operating the motors or to perform controls testing.
In the future, controls engineers can begin a detailed study of the system shown in Figure 13. Electrical/Computer engineers may desire to port the code to a 32-bit processor, perhaps one with floating point capability, to provide for more precise sine value calculations. Once all the thrusters are built, these processors can be stacked and wired to control all six of the thruster assemblies.
Appendices
Appendix A.pdf (73.5 KB)
Appendix B.pdf (80.8 KB)
Appendix C.docx (441.8 KB)
Appendix D.pdf (110.3 KB)
Appendix E.docx (35.8 KB)
Appendix F.pdf (114.6 KB)
Appendix G.docx (29.0 KB)