This post is going to be less of a project update, and more of a stream of consciousness monologue about one of the aspects of OpenADR that’s given me a lot of trouble. Power electronics isn’t my strong suit and the power requirements for the robot are giving me pause. Additionally, in my last post I wrote about some of the difficulties I encountered when trying to draw more than a few hundred milliamps from a USB battery pack. Listed below are the ideal features for the Nav unit’s power supply and the reason behind each. I will also be comparing separate options for batteries and power systems to see which system best fits the requirements.
- Rechargeable – This one should be obvious, all of the current robot vacuums on the market use rechargeable batteries. It’d be too inconvenient and expensive for the user to have to constantly replace batteries.
- In-circuit charging – This just means that the batteries can be charged inside of the robot without having to take it out and plug it in. The big robot vacuum models like Neato and Roomba both automatically find their way back to a docking station and start the charging process themselves. While auto-docking isn’t high on my list of priorities, I’d still like to make it possible to do in the future. It would also be much more convenient for the user to not have to manually take the battery out of the robot to charge it.
- Light weight – The lighter the robot is, the less power it needs to move. Similarly, high energy density, or the amount of power a battery provides for its weight, is also important.
- Multiple voltage rails – As stated in my last post I’m powering both the robot motors and logic boards from the same 5V power source. This is part of the reason I had so many issues with the motors causing the Raspberry Pi to reset. More robust systems usually separate the motors and logic so that they use separate power supplies, thereby preventing electrical noise, caused by the motors, from affecting the digital logic. Due to the high power electronics that will be necessary on OpenADR modules, like the squirrel cage fan I’ll be using for the vacuum, I’m also planning on having a 12V power supply that will be connected between the Nav unit and any modules. Therefore my current design will require three power supplies in total; a 5V supply for the control boards and sensors, a 6V supply for the motors, and a 12V supply for the module interface. Each of these different voltage rails can be generated from a single battery by using DC-DC converters, but each one will add complexity and cost.
- High Power – With a guestimated 1A at 5V for the logic and sensors, 0.5A at 6V for the drive motors, and 2A at 12V for the module power, the battery is going to need to be capable of supply upwards of 30W of power to the robot.
- Convenient – The battery used for the robot needs to be easy to use. OpenADR should be the ultimate convenience system, taking away the need to perform tedious tasks. This convenience should also apply to the battery. Even if the battery isn’t capable of being charged in-circuit, it should at least be easily accessible and easy to charge.
- Price – OpenADR is meant to be an affordable alternative to the expensive domestic robots on the market today. As such, the battery and battery charging system should be affordable.
- Availability – In a perfect world, every component of the robot would be easily available from eBay, Sparkfun, or Adafruit. It would also be nice if the battery management and charging system used existing parts without needing to design a custom solution.
- Safety – Most importantly the robot needs to be safe! With the hoverboard fiasco firmly in mind, the battery system needs to be safe with no chance of fires or other unsavory behaviors. This is also relates to the availability requirement. An already available, tried and true system would be preferable to an untested, custom one.
The rechargeability and safety requirements, as well as the need for three separate power supplies, are really non-negotiable factors that I can’t compromise on. I also have no control over whether in-circuit charging is feasible, how convenient a system is, how heavy a system is, and the availability of parts, so while I’ll provide a brief discussion of each factor, they will not be the main factors I use for comparison. I will instead focus on power, or rather the efficiency of the power delivery to the three power supplies, and price.
There were three types of battery chemistry that I considered for my comparison. The first is LiPo or Li-Ion batteries which currently have the highest energy density in the battery market, making them a good candidate for a light weight robot. The latest Neato and Roomba robots also use Li-Ion batteries. The big drawback for these is safety. As demonstrated by the hoverboard fires, if they’re not properly handled or charged they can be explosive. This almost completely rules out the option to do a custom charging solution in my mind. Luckily, there are plenty of options for single cell LiPo/Li-Ion chargers available from both SparkFun and Adafruit.
Second is LiFePO4 batteries. While not as popular as LiPos and Li-Ions due to their lower energy density, they’re much safer. A battery can even be punctured without catching fire. Other than that, they’re very similar to LiPo/Li-Ion batteries.
Lastly is NiMH batteries. They were the industry standard for most robots for a while, and are used in all but the latest Roomba and Neato models. They have recently fallen out of favor due to a lower energy density than both types of lithium batteries. I haven’t included any NiMH systems in my comparisons because they don’t provide any significant advantages over the other two chemistries.
- 1S Li-Ion – A single cell Li-Ion would probably be the easiest option as far as the battery goes. Single cell Li-Ion batteries with protection circuitry are used extensively in the hobby community. Because of this they’re easy to obtain with high capacity cells and simple charging electronics available. This would make in-circuit charging possible. The trade-off for simplicity of the battery is complexity in the DC-DC conversion circuits. A single cell Li-Ion only has a cell voltage of 3.7V, making it necessary to convert the voltage for all three power supplies. Because the lower voltage also means lower power batteries, several would need to be paralleled to achieve the same amount of power as the other battery configurations. Simple boost converters could supply power to both the logic and motor power supplies. The 12V rail would require several step-up converters to supply the requisite amount of current at the higher voltage. Luckily these modules are cheap and easy to find on eBay.
- 3S LiPo – Another option would be using a 3 cell LiPo. These batteries are widely used for quadcopters and other hobby RC vehicles, making them easy to find. Also, because a three cell LiPo results in a battery voltage of 11.1V, no voltage conversion would be necessary when supplying the 12V power supply. Only two step-down regulators would be needed, supplying power to the logic and motor power supplies. These regulators are also widely available on eBay and are just as cheap as the step-up regulators The downside is that, as I’ve mentioned before, LiPos are inherently temperamental and can be dangerous. I also had trouble finding high quality charging circuitry for multi-cell batteries that could be used to charge the battery in-circuit, meaning the user would have to remove the battery for charging.
- 4S LiFePO4 – Lastly is the four cell LiFePO4 battery system. It has all the same advantages as the three cell LiPo configuration, but with the added safety of the LiFePO4 chemistry. Also, because the four cells result in a battery voltage of 12.8V-13.2V, it would be possible to put a diode on the positive battery terminal, adding the ability to safely add several batteries in parallel, and still stay above the desired 12V module power supply voltage. LiFePO4 are also easier to charge and don’t have the same exploding issues when charging as LiPo batteries, so it would be possible to design custom charging circuitry to enable in-circuit charging for the robot. The only downside, as far as LiFePO4 batteries go, is with availability. Because this chemistry isn’t as widely used as LiPos and Li-Ions there are less options when it comes to finding batteries to use.
Power Efficiency Comparison
To further examine the three options I listed above, I compared the power delivery systems of each and roughly calculated their efficiency. Below are the Google Sheets calculations. I assumed the nominal voltage of the batteries in my calculations and that the total power capacity of each battery was the same. From there I guesstimated the power required by the robot, the current draw on the batteries, and the power efficiency of the whole system. I also used this power efficiency to calculate the runtime of the robot lost due to the inefficiency. The efficiencies I used for the DC-DC converters were estimated using the data and voltage-efficiency curves listed in the datasheets.
Due to the high currents necessary for the single cell Li-Ion system, I assumed that there would be an always-on P-Channel MOSFET after each battery, effectively acting as a diode with a lower voltage drop and allowing multiple batteries to be added together in parallel. I also assumed a diode would be placed after the 12V boost regulators, due to the fact that multiple would be needed to supply the desired 1.5A.
Here I assumed that a diode would be connected between the battery and 12V bus power, allowing for parallelization of batteries and bringing the voltage closer to the desired 12V.
Looking at the facts and power efficiencies I listed previously, the 4S LiFePO4 battery is looking like the most attractive option. While its efficiency would be slightly lower than the 3S LiPo, I think the added safety and possibility for in-circuit charging makes it worth it. While I’m not sure if OpenADR will ultimately end up using LiFePO4 batteries, that’s the path I’m going to explore for now. Of course, power and batteries aren’t really in my wheelhouse so comments and suggestions are welcome.