Battery Monitor

From Black Metal Forest
Jump to: navigation, search
Click HERE to see many more pictures!

The Battery Monitor board is the heart of the Dax robot 48V power system. It's job is to record the voltage and currents from the removable battery pack, and provide a soft power up sequence for the drive motors. A state of charge system reads and writes the SOC to the Nonvolatile memory onboard the removable battery pack, along with other statistics. Battery safety is not handled by the Battery Monitor, but by the off-the-shelf Battery Management System built into the removable battery pack, although the Battery Monitor has some redundant emergency cutout limits as well.

  • High Accuracy SOC Measurement
  • +-32 Amps, +-2mA Accuracy
  • 30-60 Volt input
  • Separate motor controller pre-charge circuit
  • Remote E-stop button cuts power to motors
  • Read/Writes remote battery pack EEPROM and temp sensors
  • Onboard 60V to 5V buck converter for robot standby mode


INA233 Block Diagram, ( Datasheet)

The Battery Monitor has three jobs.

1. Provide a Power on/off sequence for the robot.

2. Track and record the state of charge of the battery.

3. Add an additional layer of protection for the battery.

The Battery Monitor resides inside the DAX robot, and the Battery Pack itself contains an ID chip.

The Battery Monitor board is fairly simple. The main IC is the INA233, which is essentially a fancy Shunt Monitor. It has a built in ADC, It has Voltage sensing and it multiplies Current and Voltage to get Watts, and also sums the Watts to get Watt-Hours. This Built in Summation would usually be done programmatically in the host micro controller, but this feature allows the MCU to do less work and provides better accuracy since no gap time of power flow is ever missed. The INA233 also has very low offset drift allowing a very high dynamics range. It can measure milliamps of current with +-2mA accuracy and also be able to measure up to +- 32 Amps. The INA233 only works up to bus voltages 36V, so the monitor is used in the "Lowside" configuration and the voltage is divided in half by a resistive divider before being measured.

Power on/off sequence

Power Button

A big power button with a blue LED ring light is prominently displayed on the back of the DAX robot. If the robot is off, pressing this button starts the power up sequence, like you would expect. As long as a battery is present, the Battery Monitor is providing a standby 5V power and it's accompanying Microcontroller is in sleep mode (A "Nova Node" located off board). The sleep mode and parasitic power consumption is low enough that the robot can remain in sleep mode for many months.

Power for the system, and power to the drive motors is switched on separately. Once the robot has booted up, the operator manually engages the motor power to begin driving. A pre-charge sequence slowly applies power to the motor controllers though a 100 ohm power resistor. Once the voltage across the motor controller is approximately the same as the battery voltage, a second relay bypasses the 100 ohm resistor to give the motors a low impedance connection to the battery.

This pre-charge song and dance is important to have because of the large capacitance in the motor controllers. Without it, a very large inrush current would flow into the capacitors, perhaps hundreds of amps for a fraction of a second, then cause a large over voltage (up to twice the voltage of the battery) to appear across the motor controller. The motor controller is not rated to handle over 60V so this would break it.

Pressing in the power button cuts power to the relay that provides power to the motors. This acts at a Emergency Stop that can be used by the public or our developers in the case of emergency. The robot stays on and tracks can be easily re-enabled by the robot operators. This feature has been used by software developers many times to stop runaway robots so I am very proud I came up with this extra safety feature. However there has been equally many times when kids have pressed the button out in public and the undertrained robot operator did not know how to re-engage the tracks, which was embarrassing.

Calculating SOC

Calculating SOC can be difficult. In designing this system, I had to explore how accurate the SOC needed to be for the DAX application. Planning efficient delivery routes for Dax requires solid and predicable data for power consumption as well the total capacity of the battery pack. I have found a recipe for SOC calculation that has worked well enough for our application.

As a test, each battery is discharged at 10 Amps until the internal BMS cuts out from low voltage protection. 10 Amps is a little more than DAX would usually draw on average, and will dissipate some of the packs energy before it is measured by the meter. The test result BMS Cutout Voltage and total AH capacity are saved and written into it's FRAM chip by hand.

One issue that had to be worked around was that the internal BMS would cut power suddenly and without warning if a single cell voltage got too low. To avoid this, a higher than minimum pack cutout voltage is used as a software limit to initiate a shutdown. For example, say the battery pack is known to cut out at 38V, we will initiate a smooth and safe shutdown if the pack goes below 42V. The BMS's 38V total pack cutout voltage is likely to increase as the pack ages but our 4V margin has prevented this from being an issue so far. This may be an issue in the future and one reason to design our own BMS eventually. Would could buy a better BMS that will at least communicate individual cell voltages so we have a warning of when the pack will cut out.

Some SOC systems out there use the discharging from normal operation as a chance to recalibrate the total capacity of the battery pack. However this is difficult to implement, since robots will rarely discharge from top to bottom. Instead of recalibration, The Dax system uses a constant AH statistic from the initial test that was done when the pack was new. We have not seen any degradation of capacity since we have been using our battery packs. We are keeping track of number of charges and discharges in the statistics as a kind of long running experiment on battery capacity degradation.

The only time we do an SOC recalibration of any kind is at the end of a charge. As the charger charges the battery pack, it slowly increments the state of charge percentage along the way. The battery pack might only reach 95% or even 102%, but once the pack reaches it's max voltage and the current settles down to 50mA, the charge is completed and the SOC is reset to 100%.

At the rare times when the robot has run out of charge in the field, our debug information has record the SOC is within 1% to -1% SOC. So far this system is working well, but if in the future we want better SOC data from degraded batteries, we have a path forward to implement it in software.

Battery ID Board

The Battery ID Board inside the battery pack

Inside each removable battery pack resides a nonvolatile memory chip. In this chip contains a load of data about the battery. Some information is static, like UUID number, cell count, chemistry type, ect. Some of the data is set-once information like Cutout Voltages and Total Capacity that are derived from testing each unique battery pack. Some information is updated once every 4 seconds, like State of Charge, Amp hours Used, and Total Discharge Time. Finally we have "watchdog" values that record worst values experienced, like the most extreme temperatures and currents the pack has experienced in it's lifetime.

The ID Chip itself is not an EEPROM but a FRAM type NVM. FRAM or Ferroelectric RAM uses Magnetism to "pop" the atomic structure of a special material into two different polarizations. FRAM can withstand "virtually unlimited" read and write cycles while a good EEPROM can only withstand about 100,000. I calculated over the course of 4 years, the Battery Pack is likely to exceed 30 Million writes which would be too much for EEPROM.

The Battery ID board is always under threat of being disconnected from power at any time, even in the middle of a write. In order to protect the information from corruption, a RAID 1 topology is used to provide redundancy and data repair. 4 copies of the data is written sequentially every time a single value is changed. For example If the write is interrupted, it is likely the first copy will be new data, the second copy will by a combination of new and old, and the last two will be old data. When the data is read in the future, the correct data will be assumed to be the two copies that exactly match each other. In this case the two old versions of the data will match, and all four copies will be overwritten with that version of the old data. Every time a FRAM Read is performed, the 4 copies are compared to each other, along with a CRC32. The only time this system has ever failed was because of a firmware bug.

Battery Charger

A charger with two battery packs next to it
Charger screen currently set to debug view

The Battery Charger uses the same Battery Monitor circuit board, and it provides the same Three functions. 1.Provides a Power on/off sequence, 2.Tracks and records the state of charge, and 3.provides an additional layer of protection for the battery.

The charger incudes a large AC-DC switching power supply with I2C programable voltage and current limit, up to 60V/13A. The Nova Node inside reads charging configuration settings directly from the Battery ID chip plugged into it, and then applies the correct settings to the power supply. This way the charger will be able to charge pretty much any future battery pack design, size or chemistry, without any update to the charger firmware.

This battery charger has a wall power sharing feature. Battery chargers of this size use a lot of wall outlet power. A standard 15A 120Vac building circuit would only be able to run 5 of these chargers simultaneously. Leveraging the CANbus transmitters already on our Nova Node PCB's, multiple chargers can communicate with each other. They collectively decide how to share the 15Amps available from the wall. I found XLR connectors and cables were a prefect fit for a CANbus network. Although it is over kill for this situation, XLR cables have a differential pair, a ground reference wire, and even a shield. They are robust, cheap, and different lengths can be purchased from amazon or any music store.

Development Processes

Although the Battery Monitor system is great now, it took time to get to this point. It took a few revisions, and even a complete switch in topology.

I Found a Real Bug With the INA233!

Novice Electrical Engineers are often quick to blame their partially misbehaving circuit on what they think is a defective or poorly designed IC. I must stress that it is almost never the fault of the chip. ICs are rigorously tested and documented before being mass produced, and if there are issues they are noted in the datasheet. One exception is Microcontroller ICs as they often have many bugs (and officially documented work arounds). That being said, during the development of the Battery Monitor I have found an critical issue with the INA233 made by Texas Interments that was not documented. I tracked down the source of the problem and reported it to TI on their forums. I provided a demo program so that they could recreate the issue on their end, and they were able to.

The Bug: The Watt-Hours accumulation system would go hay wire when the I2C communication was ran above 100Khz. At first I thought it was a signal integrity issue, but scope measurements showed the signal integrity was clean, and the strange data coming out of the INA233 was real. The manner in which the Watt Hour accumulator would malfunction was very strange. The system was set up to count Watts 30 times a second, but would report strange multiples like: 30,0,30,90,60,0,30,30,30,30,30,120,30. Even though I can't imagine why the bug was related to I2C speed, this problem never shows up at 100khz and the chip has worked flawlessly ever since. The forum conversation with TI is here

Original Topology Change

In the beginning, the Battery Monitor was inside the battery pack. One advantage was that the battery power plug was not energized unless engaged to via a CANbus command. Battery information was stored inside the Battery Monitor itself. Due to near 1-to-1 ratio between Robots and Battery Packs, it was not much more expensive to have a Battery monitor in each battery pack. However my boss insisted the Battery Monitor be located in the robot to reduce the cost of each pack.

Battery Cable Issues

Early versions of the Battery Monitor were plagued by battery cable failures. The battery Cable was soldered

Power Switch

I am glad that I Included s