I have been using a set of four Panasonic 18650 LiPo batteries in a 2-cell stack configuration in Wall-E2, my autonomous wall following robot. for a little over three years now, and they are starting to show their age. So, I decided to replace these
with these
Three years younger, and with another 100 mAH (rated, at least).
Here’s a photo record of the process of changing out the batteries
Stay tuned,
Frank
Posted 08 February 2019,
After recovering from my bout with #include file hell, I’m back to working on Wall-E2, my autonomous wall-following robot. In a previous post I described the integration of the TP5100 charger module into Wall-E2’s system, but I have lately discovered that the TP5100 end-of-charge (EOC) detection scheme isn’t very reliable in my application. The TP5100 uses a current threshold to determine EOC, which works fine in a normal application where the battery pack isn’t simultaneously supplying current to the load, but in my application, Wall-E2 stays active and alert while it’s docked at it’s feeding station; it has to, in order to be able to respond to the EOC signal and detach itself. So, the current going through the TP5100 never goes below the idling current for Wall-E2, which is on the order of 300mA or so. This is enough to keep the charging current above the TP5100 EOC threshold, and so Wall-E2 hangs on to the charging station forever – not what I had in mind!
Life would be good if I somehow measure Wall-E2’s idling current while on charge and the total charging current. Then I could subtract the two values to get the excess current, i.e. the current going into the battery but not coming out – the current actually going into increasing the battery charge level. When this current falls below an appropriate threshold, then charging could be terminated. This scenario is complicated by the need to measure the current on the high side of the charging circuit and of the +Vbatt supply to the rest of the system.
Well, as it turns out, Adafruit (and I’m sure others) makes a high-side current sensor just for this purpose, based on the 1NA219 and INA169 chips. The INA219 module reports current via an I2C connection, while the 1NA169 module provides a open-emitter current source proportional to the current through an onboard 0.1Ω resistor (see this data sheet for details). My plan is to use two of these modules; one at the charging circuit input, and a second one at the 8.4V +VBatt supply from the battery to the rest of the system. Since Wall-E2 stays awake during charging, it should be simple to monitor both currents and decide when charging is complete (or complete enough, anyway). As a bonus, I should be able to extend the life of Wall-E2’s battery pack by terminating the charge at less than 100% capacity. See this very informative post by François Boucher for the details.
After the usual number of mistakes and setbacks, I think I have the dual current sensor feature working, and now WallE-2 charges by monitoring both the battery voltage and the actual charging current (total current measured at the charging connector minus the run current measured on WallE-2’s main power line). As a final test, I discharged the main battery pack at about 1A for about 1 hour, and then charged it again using the two-current method. As shown in the Excel plots below, Charging terminated when the actual battery charging current fell below 50mA.
Complete charge cycle, after discharging at approx 1A for approx 1 Hr
Last 20 minutes or so of charge operation, showing detail of end-of-charge behavior
two 1NA169 high-side current sensors mounted in the battery/motor compartment. Note the 3D-printed mounting plates.
Here is a showing the installation of the two 1NA169 sensor modules in WallE-2’s battery compartment. The one on the left measures running current, and the one on the right measures total current (charging + running).
The following figure shows the system schematic for WallE-2, with the two new 1NA169 sensors highlighted
System schematic with locations of new current sensors highlighted
Now that I have the current sensors and the new charge algorithm working, it’s time to go back an take another look at the charge/discharge characteristics of the Panasonic 18650B cells I’m using to see if I can extend their life with a more intelligent charge/discharge scheme. The following plot shows the charge characteristics for this cell.
Charge plot for the Panasonic 18650B LiPo cell
As noted by François Boucher, the red line above is the total energy returned to the battery during charge. As he notes, the battery acquires about 90% of its total capacity in the first 105 minutes of the charge period, when charged at 0.5C at 25C. My battery pack is a 2-cell parallel x 2-cell series stack, and currently I’m charging to a 50mA cutoff. According to Boucher, this is way too low – I’m charging to almost 100% capacity and thereby limiting the cycle life of the battery pack. Looking at the end-of-charge detail plot above (repeated below), I should probably use a charge current threshold of around 500mA charging current (250mA per cell in the parallel stack) for about 90% capacity charge.
End-of-charge detail with approximate 90% charge current highlighted
On the discharge side, Panasonic’s Discharge Characteristics plot below shows a discharge down to 2.50V/cell. WallE-2’s typical current drain is about 1A or about 0.3 – 0.5C, and the cutoff I’m using is 3.0V cell. From the plot, this gives about 3150mAH of the approximately 3300mAH available at 0.5C, or about 95%. So, it looks like I should raise the discharge cutoff voltage to about 3.2V or about 3000mAH of the 3300mAH available, or about 90%.
So revisiting WallE-2’s battery management seems to have paid off; I now have much better visibility into and control over charge/discharge of the 18650B battery pack, and at least some expectation that I can use WallE-2’s new found battery super powers for good rather than evil ;-).
Stay tuned!
Frank
Posted 26 August 2018
It’s been a year and a half since I last described the status and challenges in my ongoing campaign to create Wall-E2, an autonomous wall-following robot. The name ‘Wall-E’ was taken from the 2006 movie of the same name. In the movie, Wall-E was an autonomous trash-compactor robot that had all sorts of adventures, and my Wall-E2 autonomous wall-following robot certainly fills that bill!
From the previous system status report in early 2017, I described the following tasks:
Its been a year and a half since I updated the status of my ongoing campaign to create an autonomous wall-following robot. The robot system consists of the following main subsystems:
Since the last update, the battery and charging system has been updated from dual 1-Amp single-cell Adafruit PB1000C chargers utilizing a 5V source to a TP-5100 2-amp dual-cell charger utilizing a 12V source. This significantly simplified the entire system, as now the battery pack doesn’t have to be switched between series and parallel operation. Also, now the charging and supply leads are independent so the supply leads to the rest of the robot were upgraded to lower gauge wire to reduce the IR drops when supplying motor drive currents. See this post for details.
The motors were upgraded to provide a better gear ratio, although this was done before I realized that most of the traction issues were caused by IR drops in the battery wiring. The motor driver modules are unchanged, but I may later swap them out for more modern 3V-capable drivers so that I can swap in an Arduino Due microcontroller for the Mega (the Due has the same footprint/IO as the Mega, but has a much faster CPU and more memory)
The IR homing subsystem utilizes a pulsed IR beacon on the charging station coupled with dual IR sensors in a flared sunshade housing, backed by a Teensy 3.5 CPU configured as a null pattern matched-filter. The Teensy reports left/right homing error as a value between -1 and 1 over an I2C bus to the main microcontroller, which drives the motors to null out the signal. As the system stands today, the operating system can successfully home in on the charging station and connect to the charger. The robot knows its current battery voltage (charge condition) and therefore can decide to connect to the charger or to avoid it.
The front/left/right ranging subsystem is one of the most mature subsystems on the robot. The subsystem can successfully follow walls, and detect/recover from stuck’ conditions. The only thing this subsystem lacks is the ability to make consistent turns on different terrain, due to the lack of heading information (this will be supplied by the new tri-sensor module)
The I2C sensor subsystem is a new addition since the last update, and has yet to be fully integrated into he system. The subsystem consists of a Inversense MPU6050 6DOF solid-state accelerometer, and Adafruit FRAM (Ferromagnetic RAM) and RTC (Real-Time Clock) modules. The MPU6050 gives the robot the ability to sense relative heading changes, which makes it capable of executing consistent N-degree turns on both hard flooring like the kitchen and atrium areas and the carpet in the rest of the house. The FRAM and RTC units should allow the robot to remember its charge/discharge history, even through power ON/OFF cycles.
The relative heading capability has been tested off-line from the main operating system, but has not yet been integrated into the OS. Same for the FRAM/RTC modules. Integration of this subsystem was stalled for quite a while due to problems with the Arduino I2C (Wire) library, but these problem were just recently resolved by switching to a more robust I2C library (SBWire). See this post for details.
The operating system has evolved quite a bit over the course of this adventure, but its current state seems pretty stable. The OS is implemented as a set of modes, as follows:
This task has been completed, and along the way the charging voltage was changed from 5V to 12V, to accommodate the new 12V on-board battery charging system. See this post for details
This task has also been accomplished. See this post for details.
Posted 20 March 2018
I think it is important that Wall-E2 have an accurate measurement of battery voltage, so that he knows when he should be looking for his next charging fix, and more importantly, so he can stop and yell for help if the battery voltage gets dangerously low. In addition, I would like to monitor the battery voltage during charge, so Wall-E2 can report & display charging progress to any interested humans (like me). ;-).
From what I’ve read, it appears a LiPo cell can go down to about 3V without damage, or 6V for my 2-cell stack. So, my operating voltage range is from full charge (approx 8.4V) to empty (6.0V). My first cut at battery voltage monitoring was a simple 1/3 – 2/3 resistive voltage divider tied to an analog input; simply measure the voltage, multiply by 3, and voila – battery voltage!
Only it didn’t work that way; once the battery voltage dropped below about 7V, the drop across the Arduino Mega’s voltage regulator wasn’t sufficient to maintain regulated 5V, so the Mega’s bus voltage began to drop. At Vbatt = 6V, the Mega was still running OK, but the bus voltage was down to 4V, and the A/D reference was no longer what it should be – rats!
In addition, once I started looking at this issue, I realized I was throwing away most of the A/D dynamic range with the divider idea. with a 5V A/D reference and a 1/3 divider, the A/D input voltage only varies between 2.0 and 2.8V for an input range between 6 and 8.4V. In other words, I’m only using 0.8V of the available 5V range or about 16%.
So, I thought that maybe I should implement a level shifter, so the sensed voltage varies from 0 to 2.4 as the battery voltage varies from 6 to 8.4 – and then use the Mega’s internal 2.56V reference for the A/D operation. This would mean an immediate increase in dynamic range usage from 16% to almost 94%, and would increase resolution from about 15mV/count to about 2.5mv/count. To do the level shifting, I’ll need a 6V zener, such as the 1N5233B, available from Mouser for a few pennies each.
One last voltage issue to be addressed is the problem with the Mega’s onboard regulator dropping out for battery voltages between 7 and 6V – this is almost half of the available voltage range. Eventually I decided to address this problem by replacing (or rather, bypassing) the onboard regulator with a low dropout (LDO) regulator such as the LF50CV-DG , available from Mouser for less than $1 each. The LF50CV-DG can maintain 5V output down to well below my 6V battery voltage cutoff limit, so it is a good match.
I just received the LF50CV-DG regulator and 1N5233B parts from Mouser, so I’m in the process of installing them onto Wall-E2. The regulator will take the place of the MOSFET low-drop diode I installed on the Pololu Wixel Shield some time ago as part of my old PB1000C-based charging subsystem, and is now no longer needed. The following photos show the installation:
Wixel shield showing MOSFET diode to be replaced by LDO 5V regulator
LF50CV-DG LDO 5V regulator and 1N5233B 6V Zener diode installed on Wixel shield
Rear of Wixel shield showing regulator output connection to +5V bus
While testing the above arrangement, I managed to somehow kill my Mega 2560 SBC (I think my old power supply did it in, but I’m not sure). So, in the process of recovering from this mess, I also decided to replace my old Wixel shield for the latest version (v1.1) with updated level-shifting circuits and carry-throughs for the added pins on the UNO R3, Mega, and cousins. The new layout is shown below
Updated Wixel shield board with LDO 5V regulator and level-shifter circuit installed
Once I got everything back together, I started over with testing the LDO 5V regulator and level shifter performance, and ran into another problem. The original idea was to use the 1N5233B 6V zener to level shift 6-8.4V to 0-2.4V so the range would fit into the range obtainable using the Mega’s internal 2.56V ADC reference. This worked almost perfectly, but the combination of a slightly lower Vz (5.84 vs 6.00V) and a slightly lower Vref (2.42 vs 2.56V) caused the ADC to hit full scale (1023 counts) at about 8.26V (2.44Vref + 5.84Vz = 8.26V). Most unfortunate, as I really needed to accurately measure Vbatt to at least 8.4V, nominal end-of-charge voltage for a 2-cell LiPo stack.
So, I needed to expand the measurable voltage range at least a little bit on the top end. With the installation of the LF50CV LDO 5V regulator, I could now do that by reverting to the internal 5V reference, as the LDO easily maintains 5V output all the way down to 6V, the cutoff voltage for my battery stack. But, this wastes half the available ADC range, as the ADC input voltage for Vbatt = 8.4 is only 8.4-5.84 = 2.56V. So, after some more Googling through Arduino-space, I realized I could tie the Mega’s AREF pin to the Mega’s 3.3V output line and use ‘analogReference(EXTERNAL)’ to obtain an ADC range from 0-3.3V, corresponding to a Vbatt range of 0 to (5.84+3.3)= 9.14V – perfect!
After making this change I ran some measurements to verify the input range and accuracy, as displayed in the following Excel plot
Measured vs Calculated Vbatt, with raw ADC values
As can be seen in the above plot, the measured and calculated voltage plots are almost perfectly overlaid, and well within the accuracy requirements for effective battery management.
As usual, what started out as a simple plan (in this case, to accurately measure the battery voltage) rapidly metastasized into a full-blown hardware and software project, complete with howls of anguish and gnashing of teeth. The first idea was to use a simple 1/3 resistive voltage divider input to a ADC port referenced to 5V. This worked OK, but failed at battery voltages below 7V because the Mega’s onboard voltage regulator requires an approximately 2V input-output offset. Since I needed to measure Vbatt down to 6V, this was never going to work. In addition, the available measurement accuracy sucked because the 2.5V range of interest was being compressed into 2.5/3 = 0.833V, and with a 5V reference I was using less than 20% of the available ADC counts. The next idea was to replace the onboard regulator with the LF50CV LDO regulator, and use a 6V zener to level shift the range of interest to under 2.56V so that the Mega’s internal 2.56V reference could be used. This almost worked, but I ran out of ADC counts before I ran out of battery voltage – oops. The third (and last, I hope) idea was to change the ADC reference from internal 2.56V to external 3.3V using the AREF pin tied to the Mega’s 3.3V regulated output. This allowed the top voltage to go to a little over 9V, just about perfect for this application.
Stay tuned,
Frank
Posted 13 March 2018
In a recent post, I described my study of the widely available and dirt-cheap TP5100 1/2-cell LiPo battery charger as a possible replacement for my current Adafruit PB1000C-based battery charger. Based on the results of this study, it was clear the TP5100-based system was superior in all respects to my home-brew system:
I constructed a small charger module using some perfboard and a couple of 2-place screw terminals, as shown below (with the previous module shown for size comparison).
New TP5100-based charger module, with previous Adafruit PB1000C-based module below for size comparison. The orange box contains 4 Panasonic 18650 cells. Note the separate charge & load circuits
The following figures show the old and new schematics:
Old battery pack schematic
New battery pack schematic
Now that the load current doesn’t have to go through the charging module, I was able to replace all main battery wiring with #20 wire for lower IR drops, as shown below
Power wiring replaced with #20 wiring, and 2-pin Deans connectors
#20 wiring to main battery buss. Note in-line safety disconnect
The change to the new battery pack also considerably simplified the system hardware and software. The changes to the system schematic are shown below:
Old system schematic. Note the ultra-low-drop MOSFET diode required to keep Arduino Mega alive during charge. and the number of pins required for charge monitoring.
New system schematic. No requirement for diode, as full battery voltage is available at all times. Also, only two pins are required for charge monitoring
The operating system software has also been simplified. Now, instead of monitoring both cell voltages and four different status lines, only two lines have to be monitored. Also, there is now no requirement to correctly sequence the ‘Charger Connect’ and ‘Coil Enable signals in order to accomplish correct charging station connect-disconnect behavior. Now the system simply shuts off the motors when the robot connects to the station, and turns them back on again to disconnect. As an added benefit, the six charge status LEDs have been repurposed to show a crude approximation (based on battery voltage only for the moment) of charge status.
All these changes have caused one minor hiccup in the implementation of the charging station; the new charging voltage is +12V vs +5V as before. As you may recall, the charging station implements a square-wave modulated IR signal, and this signal is produced by a Teensy 3.2 and some associated circuitry, all of which expect +5V. This will require either a dual-output supply, or the addition of an on-board 12-to-5V regulator. This is still up in the air, but I suspect it will land on a simple 3-pin regulator.
So far, all the hardware changes (except for the charging station changes) have been accomplished, but the software changes have yet to be implemented and tested. Stay tuned!
Frank
Posted 24 February 2018
I have been working on Wall-E2, my autonomous wall-following robot, for almost three years now, and it seems like I have been struggling with the battery and charger arrangement for that entire time. I started out with 4 AA batteries, but quickly moved on to a pair of Sparkfun 2000mAh ‘flat-pack’ cells with Sparkfun chargers, with a relay to switch the batteries from series (RUN) to parallel (CHG) wiring. This worked, but not very well. The flat-pack batteries weren’t a good match for motor control, and I kept burning up charger modules as well. After struggling with this through several iterations, I finally abandoned it entirely in favor of a 7.4V 20C LiPo RC battery and an external charger. This worked much better, but forced me to manually disconnect the battery from the robot and charge it externally – not at all what I wanted. Later on I made another run at the 2-cell series/parallel switching strategy for charging, this time using Adafruit Powerboost 1000C charge modules, each capable of 1A charge rates. Again this worked (actually quite well), but I recently discovered that it has a fatal flaw – this design imposes significant IR drops on the way from the battery terminals to the motors.
So, I have once again been searching for a solution to the battery/charger problem. While wandering through the Googleverse the other day, I ran across a mention of the 1/2-cell TP5100-based charger module (about 9:50 from start), available for next to nothing on eBay.
Unfortunately, the available technical information on this module is also next to nothing, and what does exist is all in Chinese. Still, this module has the potential for vastly simplifying my charger setup, so I thought it was worth the effort to perform a thorough study.
In a previous post, I described an Arduino controlled charge/discharge test setup for testing operation of my 2-cell parallel/series switched setup, so I decided to modify it for evaluating the TP5100 module, as shown below
View of TP5100 module showing RUN & CHG indicator connections
Charger test setup, in discharge mode (note 1.1A discharge current)
Charger test setup, in charge mode (note 1.8A charge current)
TP5100 Module Test Circuit
Using this setup, I was able to cycle the battery between a 7.5V load and the TP5100 charge module. In order to keep the cycle times down to a dull roar, I set the software to switch to charge when the battery voltage dropped below 7.5V, resulting in the plots shown below.
In this case, the discharge current was about 1.1A, and the observed charge current was about 1.8A. The TP5100 modules seems to work as advertised – with a 12V 5A power supply and a partially charged battery, it successfully charged my 2-cell LiPo pack terminated the charge at about 8.4V (I’m not sure if it is terminating based on current or voltage).
Over the next couple of days, I performed three complete charge/discharge cycles using this same setup. Discharge was terminated at 6V, and charge was terminated when the TP5100 ‘complete’ output changed from open-circuit to active-low. As can be seen in these charts, performance was very consistent – almost 6 hours run time into a 7.5V load, and about 4 hours for a complete recharge.
So here’s what I know now about the TP5100 module
Here’s an annotated photo showing the pertinent features:
So, it looks like this TP5100 module will work fine for my 2-cell LiPo application, with the addition of an external 2-cell protection module like the one noted above. Not only will this solve my original IR drop problem, but it is much smaller and simpler too, as shown in the following size comparison shot. Oh well, at least I had a lot of fun building up and testing the original charger module ;-).
charger module and TP5100 size comparison
Stay tuned!
Frank
Posted 21 February 2018
In early January of this year I posted about finishing the integration of my new-improved battery charger & battery pack into my new-improved robot chassis. Between then and now I have been working on getting the new robot chassis mated up with the charging station (the new robot chassis is wider, and I also changed to larger diameter wheels) in preparation for renewed field testing.
Unfortunately, just as I was getting ready to move into field testing, my robot started acting funny. About half the time, it wouldn’t disengage from the charging station and instead would reboot. At first I thought the added weight of the new battery pack and robot chassis was causing the motors to stall, so I changed the code to have the robot disconnect at full motor speed rather than 1/2 as before. This made the problem even worse; now not only wouldn’t Wall-E2 disengage from the charger, it wouldn’t even move forward or backward under it’s own power! Clearly something was badly wrong, but I had no clue what it was.
Applying my time-honored troubleshooting – I simply put Wall-E2 aside for a few days and let my subconscious work backwards through all the changes since Wall-E2 had last worked properly. After enough time had elapsed, my subconscious reported back and said:
“You are an idiot. All of the complexity you added in your quest for an on-board charging system has placed that wonderful high-capacity battery pack at the far end of a long series of (relatively) high resistance circuitry, and the IR drop caused by full-speed motor currents is killing you!” “Oh, and by the way, you’re ugly too!”
Well, my subconscious is almost never wrong, and it only took me a little bit of testing to confirm it’s theory. I set the code up to go forward and backward at full speed, and monitored the CPU’s 5V regulated output line with my trusty oscilloscope. As soon as the motor command was executed, the 5V line drooped to less than 3V, and the CPU rebooted – oops!
So now I knew what was happening, and I (or my subconscious anyway) had a good idea why. To confirm the why, I bypassed all the charge-management circuitry and wired my 7.4V 7200mAh battery pack directly into the main robot power line, as shown in the photo below
7.4V 7200mAh battery pack wired directly into robot power
With this setup, the robot not only was able to move forward and backward at full speed, the thing damn near took my arm off when I tried to stop it – whoa!
So, the bottom line is that all the work I put in designing and implementing a really cool on-board dual-cell charge management system had the ultimate effect of making the battery unusable. The operation was a success, but the patient died! ;-).
So, where to go from here? It appears that I have to completely revise my thinking about battery charging and maintenance for Wall-E2. Instead of being in series with the battery, any charging/maintenance system must operate in parallel, and be completely out of the path between the battery pack and the load when the robot is running. Now I realize this is the reason most RC/Hobbyist multi-cell battery packs have a balance charging cable in addition to the main power cable; charging is done completely independently of the output path.
When I first started the charger project, my original goal was to avoid having to remove the battery from the robot to charge it; I wanted Wall-E2 to connect to power and charge itself without human intervention. At the time, I felt the only way to do this was to have the charging circuitry on board, so that only a single DC connection from the charging station was required. I thought the only way to make this happen was to use two of the Adafruit SBC1000 charger modules to charge each of the two cells independently. Unfortunately, the SBC1000’s grounds aren’t isolated, so this meant that I had to disconnect the two battery pack cells from each other to charge them independently and then switch them back together again to run the robot after charging. This worked (rather elegantly if I do say so myself), but had the unintended side-effect of putting too much high-loss circuitry and wiring between the battery pack and the motors.
Now that it is clear that I can’t interfere with the current path to the motors, I know I have to abandon the current charging module design, but what are the alternatives?
Stay tuned!
Posted 01 January 2018
What a way to start off the new year! The battery charger module for my autonomous wall-following robot Wall-E2 has been completed and tested, and now has been integrated into the robot – yay!!
If you have been following this saga, you will recall that I started working on an internal charging module for Wall-E2 well over a year ago, back in November 2016 with this post. Since then I have gone through several iterations, revisions, and mis-steps (including a semi mind-boggling deep-dive into the details of the Adafruit PowerBoost 1000C specifications in this post). Last month I finally got a complete system (two PowerBoost 1000C’s integrated onto a single PCB with appropriate control and battery switching circuitry) working, and was able to run extensive charge/discharge cycle testing using a simple test circuit and an Arduino Uno to run it. So, now all I had to do was stuff the whole thing back into the robot. This task was made possible by my earlier decision to upgrade Wall-E2’s ride to a slightly larger chassis, so instead of trying to cram 2Kg of battery/charger into a 1Kg space, I now had the pleasure of fitting 2Kg into a 3Kg space – nice! Here are some photos of the integration process.
Battery module shown in the ‘maintenance’ configuration.
Another shot of Battery module in the ‘maintenance’ configuration.
Front cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Front cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Rear cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Rear cover removed to show how the battery module fits into the robot. Note there is plenty of room for cable runs
Now that the battery/charger module has been integrated into the robot chassis, I will have to make some minor changes to the robot operating system to accommodate changes I have made along the way, but these should be easy and straightforward. Then, it will be back to field testing, I hope.
Stay tuned!
Frank
Posted 22 December 2017
After having worked out (hopefully) all the bugs in the Arduino Uno program and associated test hardware, I have moved on from testing just one of the Adafruit PowerBoost 1000C charging module in isolation to testing the entire 2-cell battery pack system, albeit with the smaller 2500mAh LiPo’s rather than the full-up 18650 stacks.
Full-up test of the 2-cell charging system using 2500mAh LiPo cells
Full charge of 2500mAh cells
After several days of testing, I never really got consistent results with this setup – I seemed to be always chasing intermittent problems of one sort or another. Then I finally figured it out (I think) – the problem wasn’t my setup, it was the proto plug-board I was using. This board was a cheap no-name plugboard I got off eBay, and apparently I got exactly what I paid for! ;-(. So, I reverted to my tried-and-true (but HUGE!) AP Products A.C.E. 236 plugboard that I have had around the lab for a couple of decades, at least. When I transferred the setup to this plugboard, everything started working better. In particular, the battery charging current went from about 0.5A to about 1.5A – a much more believable (and practical) figure than before. Here’s the new test setup.
New test setup with my trusty AP ACE 236 plugboard. Note charging current shown on current meter
After getting the hardware problems squared away, I started getting reliable charge/discharge cycle data, as shown in the curves below
Two complete charge/discharge cycles. Note the time axis is in minutes here
The next step in the process will be to replace the PKCell 2500mAh flat-pack LiPo cells with the 6800mAh pack (two series banks of 2ea Panasonic 18650 3400mAh cells in parallel) to be used in the robot.
Chg/Dischg testing with the Panasonic 18650 packs from the robot.
As shown above, I switched out the 2500 mAh flatpacks for the Panasonic 3400 mAh cells from the Wall-E2 robot. Initially I was somewhat disappointed with charging performance, as I was only seeing about 1 – 1.5A initial charge current for both 6800 mAh cells, instead of the 2+ A I expected to see. Eventually I narrowed the problem down to stray resistance in the testing circuit itself, through the plugboard, the plugboard wiring, and the relay being used to switch charging power to the battery module. When I bypassed these elements and connected the external MeanWell 5V power supply to the battery module terminals, the max current increased to slightly over 2A, as expected. This is actually very good news, as it means that the resistance of the PCB traces supplying power to the PowerBoost 1000C modules is low enough to not materially affect the max charging current – yay!
Still, even with the max charging current up at 1A/cell and with the PB 1000C’s PROG3 charge termination resistor reduced from 100K to 33K, it takes every bit of 10 hours to charge the battery pack from 3V to 4.2V, as shown below.
Panasonic 18650 6.8AH robot battery pack. Initial charge rate approx 1A per 2-cell parallel stack
Panasonic 18650 6.8AH robot battery pack discharge, 15 ohm load
While testing these battery packs for charge and discharge performance, I came to realize that I had over-complicated the test circuit. The original test circuit is shown below:
This circuit uses a relay to switch +5V power to the charger modules in the battery pack module, and also to switch the load in and out. As I gained more experience, I realized the relay contact resistance was substantially reducing the charge current, so I wired +5V directly to the battery pack; this worked because the Arduino running the test circuit keeps the battery pack parallel/series relay disengaged (meaning the battery cells are arranged in series) until the load voltage drops below a set threshold. So, this realization resulted in the following updated circuit schematic.
As shown above, I added the connections to the battery charger module, and the LED displays.
However, I have now come to realize that the other half of the relay isn’t necessary either, as the ‘Robot +’ line isn’t connected to anything until the test manager computer (Arduino Uno) recognizes the end-of-charge condition and changes the Coil Enable signal from HIGH to LOW, disabling the battery pack’s internal relay and changing the battery configuration from parallel (CHARGE) to series (RUN). So, now the test circuit can be reduced to just the LEDs and the load resistors, as shown below.
While I was making the other changes, I also cut the load resistance in half, from 15Ω to 7.5Ω to more accurately simulate the actual robot motor loads, and (finally!) managed to capture a complete discharge cycle, as shown below.
Complete Robot Battery Pack Discharge Curve, 7.5-ohm load.
The 7.5Ω load for this run provides a good approximation for the maximum current drain experienced by the robot under most operating conditions, so it is now safe to say that the robot should be able to run at least 6 hours on a charge, and that a full charge will take about 10 hours. So, the robot will spend more time on the charger than on the road, but that’s life in the robot lane.
Stay tuned!
Frank
Posted 15 December 2017
For the last couple of months I have been working on the battery subsystem for my Wall-E2 autonomous wall-following robot. Along the way I upgraded the robot chassis to provide more room for the on-board charger & battery pack, and created a PC board design for the module that charges the 2-cell LiPo stack in parallel and then switches to a serial configuration to run the motor. This post describes the first part of a testing program to validate the performance of the Adafruit PowerBoost 1000C charger module, and the idea of switching seamlessly from charging to powering a load.
By way of background for this post, I ran into some difficulties when I tried to integrate the full-up 2-cell, 2-PB1000C battery pack/charger combination into my Wall-E2 robot, and troubleshooting the problems using the complete operating system software proved to be somewhat tedious, I decided to start at the other end with a very simple test program running on an Arduino Uno, and a single PB1000C charger.
The Arduino test program is very simple; when it is initialized, it checks the battery voltage to see if is above or below a preset threshold. If above, it energizes a DPDT relay to connect the battery to a 15Ω load; if below, it de-energizes the relay, which disconnects the battery from the load and also connects 5V to the ‘USB’ (5V input) terminal of the PB1000C, thereby charging the battery. After that, the program alternately switches the battery between the load and charging states, recording the battery voltage every four seconds.
Battery Testing Hardware
Arduino Uno and test circuit. Note the yellow ‘charging’ LED on PowerBoost 1000C shown at middle right
After working the inevitable bugs out of the Arduino program, I got some reasonable battery cycling data, as shown in the following plots. The battery used in all these tests was a PKCell LP795060 LiPo cell, rated for 3.7V and 2500mAH. It is rated for about 5hrs at 0.2C discharge, but I was only seeing about 3hrs at 0.1C, most probably because I was terminating the discharge at 3.4V rather than the 2.75V used in the discharge tests.
Two complete chg/discharge cycles
Chg/Dischg cycles using PB2 (same battery as previous tests). Short cycles may imply battery wear-out
After the last test above, I was concerned that either the PowerBoost 1000C was not operating properly, or the battery itself was failing, or both. So, I changed the discharge termination threshold from 3.4 to 3.0V to be more consistent with the 2.75V cutoff used by the battery manufacturer. After making this change only, I got the following plot
Charge/discharge cycles after changing the discharge termination threshold from 3.4 to 3.0V
As can be seen from the above plot, the discharge and charge times were extended dramatically. Discharge (at approximately 220 mA or 0.1C) took well over 3hrs, and charge took about the same amount of time. So, it appears that both the PowerBoost 1000C modules are still working OK even after the abuse I put them through by plugging them into a PCB with wiring errors ;-).