Power Management for boxing robot - Page 1
Forum section: electronics / projects

author: overthrowrobotics
author_rank: Contributor
timestamp: June 29, 2018, 06:02:21 pm
content: I've been working on a boxing robot for a number of years. It's two human sized robots that you control with a joystick or a Kinect camera (you do a left punch, it does a left punch). Hoping to sell these into arcades.I've been struggling with the main power board. I'm using large wormgear motors, they use a lot of current at startup (first 1/10th sec) and then it settles down. I don't want to put much of an acceleration ramp in them because I want them to be very quick from a dead stop. But this places a huge load on the power supply (1200W PC power supply at the moment) so I've added in 5 x 2.7V 350F capacitors (70F @ 120V) which seems to be working.Well yesterday I sent a motor controller up in smoke because one of the motors stalled and current/voltage shot through the roof and as I've now learned 60A slow auto fuses don't pop at 60A. After talking to the motor controller manufacturer (Basic Micro makes the Roboclaw, who is awesome btw, buy stuff from them) we came up with the idea of doing two things. First a voltage clamp on my power board separate from the one built into the motor controller. So if voltage goes above 13V (12V supply) it'll turn on a MOSFET and bleed voltage through a large 50W panel resistor. The second is a similar circuit that might turn on at a higher voltage (maybe 15V?) if the voltage clamp doesn't get things under control. It would turn on a MOSFET that would turn off a large relay, killing all power to the controllers.I'm now trying to figure out a good design for monitoring the voltage. I don't have experience with comparators but it seems like I would need two of them, both comparing supply voltage against motor controller voltage (voltage after the diode protecting the power supply). Any suggestions? I've attached the current schematic. On the right side of the schematic you'll see two different mosfets, the top one has nothing connecting to the Gate, that's where I need the circuit.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 29, 2018, 06:59:38 pm
content: If a motor controller blows up with a stalled motor, the motor controller is simply broken by design. Sorry, but this cannot be solved in any other place but by fixing the motor controller current control loop, so you need to talk with the motor controller supplier seriously about this.Any protection outside of the controller is likely doomed to fail since the capacitance in the motor controller DC bus can still kill it.A proper motor controller simply respects your current and voltage limits you set it up with and just works.If it doesn't have an active current limit and a DC link voltage sensing, it's not a motor controller at all; it's a toy, a Chinese eBay module, or a joke.But mistakes do happen in design, even by competent designers, so let's hope it's about that.

author: David Chamberlain
author_rank: Frequent Contributor
timestamp: June 29, 2018, 09:21:42 pm
content: I can't be the only one who just wants to see a photo of these robots.

author: overthrowrobotics
author_rank: Contributor
timestamp: June 30, 2018, 12:00:00 am
content: Thanks for the reply! Definitely not chinese junk, the Roboclaws seem to have a good reputation. I sent it back to them and they are going to repair/replace. I didn't have the voltage clamp configured correctly and the fuse was too big. So those two mistakes were on me. Either way with this being in arcades (hopefully) I'd feel better with some additional protection.Beyond the voltage clamp if the motor stalls and voltage climbs too quickly what's wrong with having a FET turn off a relay that cuts all power to the controllers? You think it won't work or is just overkill?The other issue is charging the supercaps evenly. I pulled the previous version of this board that had some small supercap balancing chip (ALD810025) on it but it's 80mA and for some reason it didn't seem to balance at all because I had 2 caps at 1V and 3 over 3V (2.7 MAX!!). So I'm also trying to think about how to limit charging to each cap to around 2.5V.We started off initially as robot vs. human. Here's an ugly version of the robot without any molded foam.and there's some other newer videos with some molded foam, LEDs, etc connected to it athttps://www.facebook.com/pg/OverthrowRobotics/videos/

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 07:23:05 am
content: Hi,1) Motor stalling cannot cause overvoltage (except due to internal design failure within the motor controller). Excessive overrevving (think about 1000's or rpm or more) by external mechanical source, creating BEMF voltages as a generator exceeding ratings of the components, could do that in a way hard to add protection against, but this is clearly not your case. The motor controller designers are responsible for measuring their DC link voltage peaking during worst case currents, and designing the layout, snubbing, and current limiting such as destructive overvoltage spikes do not appear. Even if they failed that, it's hard or impossible to fix thatoutsidethe product.2) A fuse cannot protect the motor controller semiconductors at all. It's never meant to do that. A fuse only protects against fireafterthe product has already failed, and thus, is highly important, but the wrong fuse size didn't cause the failure.So you are blaming yourself for no reason.Reputation, country and actual quality often do not correlate.I'm saying all this because, quite frankly, this is the truth, and I fail to see any other way to correct the issue than getting a non-failing motor controller which is implemented correctly. The current one would be very hard to protect from the outside reliably, because the failure happens in a very small and extremely quick loop inside the controller. If it's overvoltage in switch node caused by ringing, it cannot be clamped from the DC bus at all, let alone further away (inductance). If it's sudden overcurrent due to poorly designed current control loop, even if you designed a nice quicker-than-fuse eFuse circuit to protect it, the chances are there is too much DC link capacitance inside the product. If it is a lack of thermal protection, you can of course limit the performance externally by using the controller at smaller duty or lower currents, but this is inaccurate against corner cases (such as higher ambient temperature for whatever reason).Implementing these protections in the motor controller itself, tightly integrated, is robust, low cost, fairly easy, and the Right Thing to Do, and basic industry practice. While they are probably not junk - they look well designed in pictures - mistakes still happen; they just need to be corrected. What I'm saying is that a blowing motor controller is not a power management issue and you can probably do nothing to prevent it from happening again.

author: overthrowrobotics
author_rank: Contributor
timestamp: June 30, 2018, 03:07:02 pm
content: I've tried 3 other brands of motor controllers and this is the only one that allowed me to configure encoders, PID, etc how I needed and I've invested a lotmofmtime designing supporting PCBs for it and integrating software with it. Switching would set me back months. I'm working with them on this but my main design concern is preventing fire.On the voltage clamp issue (which I didn't configure properly), I'm still not clear why I couldn't build that functionality directly on my board?

author: yngndrw
author_rank: Regular Contributor
timestamp: June 30, 2018, 04:15:59 pm
content: So GeckoDrive have a simple circuit that they use to clamp overvoltage from deceleration of large loads, often used in CNC applications: (These are used when you're running near the drive's absolute maximum voltage rating and the voltage increase due to the back EMF while decelerating may push you over that limit)https://www.geckodrive.com/support/servo-drives/returned-energy-dump.htmlI'm withSiwastajaon the current limit and driver fault though. Looking at the BasicMicro site the smallest driver that they do (http://www.basicmicro.com/Roboclaw-Solo-30A-Motor-Controller_p_44.html) claims to offer "protection features including temperature,current, over voltage and under voltage limits" so with that in mind I can't see why a dead short shouldn't just trigger their over-current protection ? If they offer adjustable current limits in the drive, it should be able to run at that current limit all day long (Assuming it's cooled correctly and rated to the correct duty cycle), just like an adjustable current limit on a power supply does.Edit:Page 78 of theirmanualhas details about setting maximum current limits for both motors, (Along with a typo in the example for motor 1!) set this (Or these if you're using the dual controllers) to the rated continuous limit for the controler / motor and with enough cooling (Forced air cooling from a fan) you should never have a failure. The solo 30A controller than I linked to earlier has a voltage limit of 34V which you're well under with your 12V power supply so I wouldn't bother with the voltage limit circuit, you can always connect an oscilloscope and see what voltage it raises to when doing a dead stop though.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 04:47:08 pm
content: Quote from: overthrowrobotics on June 30, 2018, 03:07:02 pmI know the pain with module lock-in - this is one of the reason I went and rolled my own BLDC motor control in a similar situation (developing a robot). In the end, this was the right decision, since now we are not locked in anything, and can fix any issues that come by. Zero blown motor controllers so far, by the way - even counting the first prototype controllers. The development time for the controller was about 4 weeks (partially driven low by relaxed dynamic specifications at start), and the BOM is $10. I realized that integrating an existing one, which would cost 15-20 times as much (at $150-$200), would take approximately 2-3 weeks to integrate, then there would be a huge risk of the provider not to be able to provide, or vanish after providing crap (like happened with the LIDAR we had to use).Quote from: overthrowrobotics on June 30, 2018, 03:07:02 pmFor maximum fire prevention safety, the best course of action is to measure actual maximum current in actual use, then use a fuse calculated tightly. Remember that it's OK to run most fuses continuously near 100% of their nominal ratings (aim for about 90%), and at over 150% for short peaks (seconds typically). Remember to look at the DC current interruption spec of the fuse if this runs off a DC bus.QuoteIt's hard to believe that you could misconfigure the internal protection so that it doesn't protect the product from blowing up. It should default to a safe maximum, and adjusting it over this limit shouldn't be possible. Sorry, but they are playing games with you right here.Sorry, but it is just the truth that a motor controller can't just blow up when used to drive a motor, no matter what settings you configure it with.QuoteOK. Let's assume the issue was overvoltage as you (they?) say. Now, it's impossible to be caused by sustained excessive RPM (working as a generator) exceeding normal running RPM's, since you specified this happened with locked rotor condition, not running at massive speed; hence, if the reason is overvoltage, the only possible source for such overvoltage is inductive kickback from the motor inductance and/or power layout parasitic inductance. The first one would be caused by faulty-by-design drive algorithm inside the controller (regenerative boosting happening regardless of bus voltage measurement saying "nope"); the latter would be caused by poor PCB layout design and/or excessive current due to lacking current feedback hardware, or wrongly designed current limit algorithm (inside the controller). In any of these cases, there's nothing you can do: the first place that sees the overvoltage spike is the FET bridge inside the controller, and it blows upin dozens of microseconds, before the voltage even has any chance of rising through the DC bus capacitance and wiring inductance and getting outside the product. So the only place that can protect the FETs, are the FETs themselves, when driven correctly to begin with. This is how motor controllers are normally designed to work.Now, if the case was about huge RPM causing the motor to generate voltage higher than the maximum ratings,thenthis could be a slowly-occurring (milliseconds) case of overvoltage where you could add some massively beefy (and expensive) zeners, transient voltage suppressors, or create a crowbar circuit. But this is not likely the case. You would be physically turning the motor, with external mechanical source, over the RPMs of the "full speed (without field weakening)".And I wouldn't assume it has to be overvoltage. Are they telling you it is, and how do they know?Multitude of possible reasons exist, some possibilities are:- Parasitic LC overshoot in the bridge- Parasitic LC undershoot in the bridge if they use a bootstrap driver- Current control failing, causing said overshoot- Current control failing, killing the FETs in direct overcurrent- FETs desaturating due to gate drive issue, killing the FETs driven outside SOA- Thermal issue, with no thermal protection....All of these are things that are taken care of during the design of the motor controller. The customer cannot fix them, because all of them are so tightly and physically coupled to the high-speed MOSFET bridge inside the controller (of course, unless the customer is a motor controller designer themselves, capable of reverse-engineering and fixing others' electronics. But then it makes more sense to roll your own.)

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 04:54:59 pm
content: Quote from: yngndrw on June 30, 2018, 04:15:59 pmI have to note that when driving the motors without field weakening, any pure deceleration will always result in lower BEMF voltage than what was already generated by the controller - meaning that the controller won't blow up at that voltage.These active braking circuits serve afunctionalpurpose, however; if they are not used, decelerating a mass with active regenerative braking algorithm will result in the DC bus voltage increasinguntil the controller protects itselfand stops the regen braking. This protection is part of normal operation, but normally, it causes the motor to start freewheeling, and if the user expects deceleration, then this is not what they want - hence the braking resistors may be needed when there is inertia in the system and there is no battery pack.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 04:58:20 pm
content: Quote from the manual:"Choose a model that can support the stall current of the motor selected to insure the motor can be driven properly without damage to the motor controller"If this is true and not a documentation error, this sentence alone proves they haveno idea whatsoeverhow to build a motor controller, or what it even means. This level is expected out of $5 Ebay specials.BTW, if this is true, it also means they are overselling you 10 times of extra capacity in expensive MOSFETs, heatsinking, capacitors and gate drive. Having a working current mode pays itself back very easily, since now you don't need to design all components to sustain the stall current of the motor. The motor is thankful as well when not driven to full, resistance-limited stall current!Even the bare minimum design level doesn't have this kind of limitation at all. Fast current limit is not optional, it costs about 1-2% of the product cost to implement, and yes, it means you can safely run a 10000A motor with a 1A controller. It will happily output 1A.I'm sorry for you, but it really seems you need to find another controller.And this reallyisa can of worms. I have stopped using any modules completely, regardless of the good reputation, due to experiences like this.

author: rx8pilot
author_rank: Super Contributor
timestamp: June 30, 2018, 05:29:44 pm
content: joining the thread.......

author: overthrowrobotics
author_rank: Contributor
timestamp: June 30, 2018, 05:54:18 pm
content: I've been using these controllers for a few years of testing and haven't had this issue before. I sent them the motor to do some further testing. Right now they don't know what caused the problem. They're guessing it could be overvoltage but I think he also mentioned something like motor inductance or ripple current from the motor could cause a problem but I don't really understand fully what this means. I'll definitely know more on Monday. I sent a follow up email after my call with them about the current limit though, I'm curious why that didn't work.Not sure if I mentioned it but I'm using 3 x 150W motors and 2 x 50W motors. At startup the larger motors are pulling somewhere around 40-50A. I had originally started down the path of building my own controller by copying Pololu's design with an ST motor driver chip and an Arduino for PID. The chip would overheat constantly and I never got the PID programming right. It's just such a big project with so many pieces that I can't spend the time to become an expert in every area. I've tried the Sabertooth and none of them worked for my application (PID plus good Python and Arduino libraries) and I really don't want to design my own controller again. I'm years into this project and running out of money and time. Changing controllers now would be a set back I don't think I can survive unfortunately. So I've got to at least in the short term find some way to make these work. It could have just been one bad unit too.On the Voltage clamp. There's a maximum voltage setting, it defaults to 34V. I should have changed it to something like 13 or 14V but forgot to after a firmware update. No matter what controller I use wouldn't putting the voltage clamp completely offboard make sense? If something goes wrong on the board it can take the voltage clamp logic with it.There's no guarantee that some other controller even if properly designed couldn't have a bad unit and something go wrong with it. Under what condition would proper fuses not have prevented a fire? High voltage but current under the fuse limit? That's why I like the idea of some kind of relay that allows me to completely disconnect power to the controllers.On the Geckodrive's schematic any suggestion for what diodes to use? How about a larger rated transistor than the TIP147? Looks like it's rated for 10A.

author: Ian.M
author_rank: Super Contributor
timestamp: June 30, 2018, 06:55:23 pm
content: Without getting into the can of worms that is GeckoDrive, their drives and their application notes, you appear to have two requirements - to load the DC bus if its voltage rises during braking, and to rapidly shut off the power if the DC bus voltage rises above a max. limit threshold.The first is basically a shunt regulator, and the second is the well-known crowbar circuit.The T.I.TL431datasheet contains examples of both (figs 21 & 22).Due to the extremely large capacitance you've added on the output of your DC supply, the fuse in the crowbar circuit *MUST* be between the extra capacitors and the drive. The TRIAC has to be chosen to have a pulse overload capability sufficient to blow the fuse without damage to the TRIAC. If you have little safety margin you are likely to run into trouble if a different fuse is substituted with fusing characteristic (time-current) curves that are significantly different, such that more energy is required to blow it.For the shunt regulator circuit, it may be desirable to use aSziklai pairas very high power super-Beta or Darlington PNPs are rather uncommon, and a Sziklai pair lets you use NPN power transistor(s). If you add a high power series resistor in the collector circuit of the transistor in fig. 21, of value slightly less than Vo/Imax, you can shift much of the dissipation from the transistor to the resistor, cheaply doubling (or more, depending on the transistor's DC S.O.A curve) the max power it can handle.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 07:53:09 pm
content: I simply fail to see how a boxing robot as shown in video, and equipped with those huge supercaps, could run into DC bus rising due to excessive regeneration. That could happen with a flywheel-like mass, or on electric mobility when decelerating or going downhill.No matter what you do, you cannot continuosly inject kinetic energy into it. Even if you are able to push its arms for a second, the next second it's hitting back and losing the regenerated energy.(And still, it's the motor controllers job to stop regenerating if the DC bus is getting out of their safe limits.)Hence I'm suggesting the problem is elsewhere. The fact that manufacturer is talking about "motor inductance" and "ripple current" points that way as well - these terms have nothing to do with DC bus rise due to excessive regen. I think they may know what's going on.Motor inductance is a relevant term only when talking about the motor controller's internal design in normal operation mode, since the current limit circuit will have a certain minimum motor inductance it safely works with. However, the motor inductances are huge compared to what modern, cheap current sense electronics can deal with, so this is very rarely an issue. Decent motor controllers typically have minimum motor inductance listed in the datasheet. But this should be a problem only with very special motors (such as extremely low-voltage&massive-current, or air core motors).

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 08:06:40 pm
content: Looking at your schematic again, I can see you have added diodes to prevent the motor controller from regenerating into the cap bank. What's the purpose of these diodes? If you leave out these diodes, your huge capacitor bank would help absorbing any energy coming from excessive regeneration, if that really is the cause (I still think it probably isn't). In my previous post, I didn't notice these diodes.Either way, it still shouldn't just blow up. But now that I understand you have zero extra capacitance on the bus, removing the diodes might help solve the problem externallyifit is a failure in their DC bus monitoring and regeneration control system.If you look at their manuals, they kind of seem to assume you are connecting the controller to a battery. If that's the case, they might really have skipped some overvoltage protections, trusting there always is a battery connected which can absorb the regenerated energy in most cases. The supercaps are fine, but the diodes prevent them from taking the energy in.In any case, when looking at their manuals, it's evident they have no clue what they are doing. Motor control is a cool thing, but these controllers are not, and they are preventing you from getting the benefits ofrealmotor control - such as torque control, which is a super cool thing - as well as causing reliability issues, possibly also wearing motors out prematurely. But I understand very well you cannot afford to start another sourcing run and need to go on with what you have now. And quite frankly, I don't even have a clue what to suggest. I have seen so many bad motor controllers that I always just roll my own (application specific; doing a generic, marketable, catch-all product would be a huge endeavor).

author: overthrowrobotics
author_rank: Contributor
timestamp: June 30, 2018, 09:37:22 pm
content: Those diodes were to prevent the caps from being charged without the precharge resistor. When they are at 0V and I try to charge them without that 5ohm 50W resistor the power supply shuts off from over current. Could regen voltage potentially overcharge the caps though?What you can't see in that video with the latest version of this robot is a motor that moves the entire robot along an arc (about 140 degrees around). There's a lot of friction since the robot is basically rolling on ball bearing wheels, a lot more than the other 4 motors have. I can take a picture or short video of that movement if it helps explain it.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 30, 2018, 10:06:05 pm
content: Oh, you need a precharge. A correct way to do it to use the power resistor as you have it, but bypass that resistor using a contactor or MOSFET after the precharge is finished (based on voltage measurement with a safety timeout, or if you are lazy, just time). Be sure to include thermal cutoff for the power resistor. And don't run the motors while precharge is on-going, so that current flows through that resistor into the caps, not the motors.Also, be sure to add a drain resistor so that the supercap bank doesn't stay charged up for too long - and definitely add fuse to the cap bank, protecting miswiring and accidents.But, ultimately, a CC/CV supply - i.e., one which doesn't go into failure mode but charges the caps happily using constant current - would be so much easier and make so much more sense, you could just ditch the precharge resistor and all the diodes completely. Even though a CC/CV PSU is more expensive and more difficult to source, it could still pay itself back quite quickly in reduced complexity and fewer things to go wrong.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 01, 2018, 02:13:44 am
content: Funny you say that as I did exactly that with a contactor but the board had a 3 pin diode reversed (can't reverse it unfortunately). There were a few other mistakes so I decided to just redesign with the BQ33100. The design used an Arduino to monitor the voltage of the caps and then turn on a MOSFET that controlled the contactor. One problem is that the caps charged so unevenly that when they when stack voltage was near 12V I still couldn't bypass the power resistor without the power supply shutting off.I figured I could do without the contactor at the expense of only being able to charge the caps more slowly which is probably ok.Where would a drain resistor go? What's wrong with leaving the supercaps charged long term?I'm using the power supply to power a pc also and would prefer something easy to source but maybe I should look into a constant current one.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 01, 2018, 02:17:20 am
content: Just got an email from the motor controller manufacturer. He tested my motor and said the inductance was 50uH and that was causing excessive ripple. He said to add 5000uf at the motor controller power in terminal. He said that the diode in front of the supercaps was preventing them from helping. He said motor also showed 1.4 ohm resistance and it pulled 8.5A startup dropping to 2A when up to speed.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 01, 2018, 08:20:41 am
content: Well, 50uH indeed is quite low (you may want to double check that yourself), but with no minimum inductance spec available from the controller manufacturer, how could you know?If it's about too low motor inductance, the only real cure is to add inductance; or find a motor controller with faster current control loop!In any case, with 1.4 ohms of resistance (which is a lot), even if the inductance is too low, the current is so well limited by the motor that nothing should blow up.It's good to hear they have an actual engineer working on it. It's well possible they come up with a fix.Draining resistor on the cap bank is important for safety - you don't want to accidentally short it, it can cause burns. People tend to assume that an unpowered product is safe.

author: yngndrw
author_rank: Regular Contributor
timestamp: July 01, 2018, 02:54:47 pm
content: Quote from: overthrowrobotics on July 01, 2018, 02:13:44 amIf you're looking for decent high-current power 12V supplies, I'd suggest looking at server power supplies. They are 12V, high current (Often ~80A) and have remote voltage sensing. Here's an implementation of a constant current limit using the remote voltage sense input to limit the current:https://endless-sphere.com/forums/viewtopic.php?f=14&t=47415This circuit is for a stack of four power supplies, but the same idea will work for a single power supply. Please note that the minimum voltage on that particular power supply is 8V so it can't go right down to 0, however there's also a current share pin which I'dsuspectis a better option for making a constant current power supply. Your mileage may vary, but I'd look into them if I were building something like this.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 01, 2018, 03:27:45 pm
content: Checked Ebay and server power supplies are cheap. They won't fit in the case I built but I can redesign later. Definitely something to consider down the road. Thanks for the link.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 02, 2018, 01:32:35 am
content: Here's another issue I just ran into. I took the previous version of this design that had a few mistakes like I mentioned so I can't fully test it. But the supercapacitors are installed in series with ALD810025 and ALD910025 balancing mosfets. I just connected a power supply to it and gave the 5 caps (in series) 12V. When I did that the first cap closest to V+ overcharged at around 3V, then the next one was around 2, then approximately 1.5, 1, 0.5 for the rest. Even without the balancing mosfets why would they charge so unevenly? I waited a day until they were half drained and then charged at 2.7V@10A for each individual cap. They all charged to that voltage without issue.If it was difference in capacitance for each supercap the odds that those difference would be in the exact order they're installed seems pretty low. It just so happens that the first one has the highest capacitance the last one has the least? What else could cause this?

author: Ian.M
author_rank: Super Contributor
timestamp: July 02, 2018, 02:21:02 am
content: Schematic?For a series string of supercaps, you need shunt balancing to equalise the voltages on each of them, so "... the supercapacitors are installedin series withALD810025 and ALD910025 balancing mosfets ..." doesn't make much sense.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 02, 2018, 03:01:08 am
content: Worded weird, sorry. The supercaps are in series. I'm also using ALD810025 and ALD910025 balancing mosfets in an attempt to keep the voltages on all the caps equal. This schematic layout is pretty lousy, it's before I cleaned things up in the latest version. In this one the diodes were put in backwards by an EE I had helping me with it so I couldn't get power to the motor controllers. The relay control MOSFET was also designed wrong. Ignore all that. Focus on the supercaps. On the terminal block for SC1 and 12V-PCIE there was a relay and a 50W 5 ohm resistor connected in parallel. When the relay was off all power to the supercaps flowed through the resistor. When the relay was on power flowed in parallel without a resistor on the second path (hope that made sense). I would then use the Arduino to monitor voltage on the caps and when they got 80-90% full the idea was to then turn on the relay.Here's the datasheet for the ALD chips.http://www.aldinc.com/pdf/ALD810025.pdf

author: Ian.M
author_rank: Super Contributor
timestamp: July 02, 2018, 04:02:28 am
content: I was right - they are shunt balancers. However they cant handle much current - 10mA at 3.92V so are unsuitable for rapid charging applications unless you limit the charging current if any cell voltage gets too high. If one of the caps has 5% less capacitance than the others, it would reach 2V when the rest of the string only had 9.5V across it. However as that's after the relay shorts out the resistor, the charging current could be in excess of 10A at that moment, and there's no way the balancer can shunt 5% of that current as it needs to. It also doesn't help that your potential dividers for voltage monitoring are so low impedance that they draw more current than the balancer can handle without excessive voltage across the cap. e.g. over 6mA will be drawn from the junction of the top two caps, but the balancer wont pass 3mA till the cap voltage is above 3.3V, so is essentially useless.You need to totally re-think this section, starting with scaling the potential divider resistors up by about three orders of magnitude, so the imbalance they introduce is down around 10uA, which the balancers can handle at a cell voltage of 2.6V, which will then mean you need buffer OPAMPs between the dividers and the ADC channels - and they'll need to be MOSFET or FET input ones to get low enough input leakage currents.You are also going to need to either redesign the balancer to be able to handle about 100mA at 2.7V per cap (possibly using, for each one, aTLV431shunt regulator + a PNP transistor to boost it and three resistors) or add active balancing during charging controlled by the Arduino.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 02, 2018, 05:29:36 am
content: The redesign is the schematic I posted at the top of the thread. The balancing mosfets I was thinking about using are 1.7A. I just thought it was weird that they charged so unevenly which is why I posted about it.

author: Ian.M
author_rank: Super Contributor
timestamp: July 02, 2018, 06:08:19 am
content: Yes, the BQ33100PW looks like a far more capable balancer, but it still cant shunt more than 27mA at 2.7V/cap (set by the 100R drain resistors) when balancing if you follow their Application Reference Schematic, so as you haven't implemented the external charge control MOSFET, there is still a risk of catastrophic imbalance at powerup if one of the caps starts going bad. I'm sure you can increase the max balancing current: dropping those drain resistors to 10R 1W would probably be a good start*, which reduces (but does not eliminate) the risk of catastrophic imbalance. To eliminate that risk, it need control of the charging supply so it can cut it off if it detects a fault.* You'll need to check its datasheet in detail to see if there are other changes that must be made if you change them.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 02, 2018, 06:36:01 am
content: I have a message into TI about those resistors and if I can drop to around 4 ohm with the right MOSFET. I see now why I need the BQ24640 which is the charge controller and the BQ33100 would send a signal to turn off charging if it gets too imbalanced. The BQ24640 requires 1.5 to 2V extra for charging. So if I'm charging to 12V I need to get a boost circuit up to 14V but I'm not sure what would be a good choice for that.

author: Ian.M
author_rank: Super Contributor
timestamp: July 02, 2018, 03:59:45 pm
content: I don't think you need the BQ24640, so you don't need to boost the charging voltage - which would defeat the purpose of adding supercaps to your DC bus to help stabilise its voltage anyway.However you do need the external charge control MOSFET switched by the BQ33100 CHG pin, and you also need to implement a circuit to short out your charge current limiting resistor once the voltage drop across it is near zero.The charging resistor can be shorted by a sufficiently large MOSFET. Use an OPAMP to amplify the current sense voltage at the BQ33100 SRN, SRP pins and compare it with a threshold to determine when the charging current has fallen to near zero. If the CHG pin is high, ignore zero current detection as the BQ33100 has turned off the charge control MOSFET. Once the curent has been near zero, with the CHG pin low for a small time, turn on the MOSFET that shorts out the charging resistor and keep it turned on until CHG goes high. Alternatively (with much less analog circitury and discrete logic), program a MCU to monitor the BQ33100 status over SMbus to get the charging current and state of charge and also monitor CHG (for fast response) and have the MCU control the MOSFET that shorts out the charging resistor.

author: overthrowrobotics
author_rank: Contributor
timestamp: July 02, 2018, 04:36:27 pm
content: I could charge 100% of the time through the pre-charge resistor. I could size it so that it charges at 10A and it would be just as fast as the BQ24640. I could still use CHG to turn on/off the MOSFET after the pre-charge resistor. Would I then even need to monitor SRN or SRP?Something like this?Edited: I just moved the diodes coming from the supercapacitor out so that if the relay is turned off the caps can't power the motor controllers.