College Applications are over!

You may know that I’ve been on a robotics team called Team Inspiration since the end of 2021, and competed in the RobotX competition with them (as the only team with high schoolers) and did pretty well (we’re listed as Advancing Science, Technology, and Art)! Prior to me joining the team, Inspiration did really well in the 2020 robosub challenge by placing first overall. For 2023, we’re participating again - this time looking to make our robosub, Onyx, the most advanced that it possibly could be.

In Graey, our 2020 robosub, we were limited by low runtimes due to too low of a battery capacity. In addition, our wire management was poor because of the high number of peripheral devices we hoped to use and a lack of an unoptimized power supply system. To be able to support even more devices and clean of up our wiring, I was tasked with building a unified power distribution board, and to make it more advanced, give it hot-swapping capabilities between two batteries.

Conceptual Design

Here are the requirements:

• Hot swap capability
• At least three 12V power supplies for greater than 2A
• At least three 5V power supplies for greater than 2A
• At least three 3V power supplies for greater than 1A
• Power outputs to ESCs

Although the power supplies would be straightforward, I was concerned about how hot-swapping could be done. To do this, I chose to use a microcontroller for a few reasons:

• Although hot-swap controllers exist, they are fairly rare and most were out of stock
• I have experience with microcontrollers and programming them for this would be simple
• Using a microcontroller provides opportunities to interface to a high-level-controller for data logging / reporting
• Using a microcontroller gives the board expansion capability
• Using a microcontroller gives some intelligence to the system in handling / taking care of batteries - you’ll see what I mean

Lets talk about what hot-swapping actually is, or at least what this board should be capable of. In general, hot swapping refers to being able to swap power supplies while a system is live / on. Since power must always be connected, however, the only way that this can work is that there is a backup / second battery installed for the system to switch to when an active one is connected. Thus, the system requires at least two batteries. Although you can then argue that both batteries can just be put in parallel, this means that both batteries will be low at a low battery state, making the battery to be swapped ambiguous. Ideally, the live batteries are separated so that only one is being drained at once (the caveat to this is that the system should use both batteries in parallel when both batteries are empty to prevent deeply discharging either one as much as possible), and when it’s empty, can be removed and charged while the system swaps to the second, still full, battery.

With this in mind, here’s what the system should be able to handle:

1. Both batteries in: when one drops to a low voltage, switch to the next
2. Both batteries in: when an active one is removed, switch to the next
3. Both batteries in: when both are low, put them in parallel to preserve battery health as much as possible
4. One battery in: when the battery is low and a charged one is installed, switch to the charged one

Now the benefit of using a microcontroller is a little more clear: certain parameters, like the voltage at which batteries are switched and deciding when to put batteries in parallel can be configured in addition to a bunch of other stuff that I’ll show later. You might argue that I could’ve used a hot-swap controller in addition to a microcontroller for system configuration / those peripheral actions, but I thought this would bloat the problem since it could probably be handled just by the microcontroller as long as the microcontroller could react quickly enough to swaps like 2. where an active battery is removed. This means that the entire system rides on the premise that the microcontroller can switch fast enough… if it can’t, the board can be scrapped.

To hopefully mitigate this issue, I added a LM393 digital comparator that compared the battery voltage line to about 7V (half the voltage of a full battery - in reality, if the 4S lipo ever reaches this, it’s definitely dead) and connected to two hardware interrupt pins, the idea being that if either battery dropped below 7V, which would mean that it had been disconnected, that a hardware interrupt would be able to handle the switching faster than just a loop.

By the way, to protect the batteries while in parallel, we decided to use two ideal diodes, one for each battery, to create a digital ‘or’ with a low voltage drop.

KiCAD

Some of the components used:

• ATSAMD21G18 (microprocessor)
• GD25Q16CWIGR Flash memory
• SD Card slot (for error logging)
• CSD25404Q PMOS as the main battery switch (4 for each battery)
• ACS781 current monitor (this is a very similar one to that used for pixhawks
• PCT2075 thermometer to verify that the board isn’t heating up (too) much
• A buzzer (for signaling when battery states change / errors)

Power supplies:

Only since I’d used them before, I chose the LM1805 LDO as the 3V and 5V regulators. This ended up being a very obviously bad decision, and I later chose to use switching regulators instead.

Here’s the complete and final bom.

Board iterations

Since I’d never used mosfets, I first made a simple test board around the CSD25404Q to make sure I could use it properly.

It worked, so I designed the rest of the board!

V1.0 of the board used those LDO’s, and since we were planning on soldering the ESCs directly onto the PCB with three-pin connectors to be able to detach the motors from the board, it doubled in length (in comparison to the logic and hot-swap circuitry).

We decided that this was a bad use of space, but since we still wanted to be able to easily disconnect the motors from the ESCs with connectors, I just split the board into two separate PCBs to be connected with a power cable. Here’s V1.1:

After a day of sitting on it though, it became obvious that this was still impractical and it made the most sense (and was the cheapest) to simply add pads to the bottom of the board for ESC power cables to be soldered onto. V1.2 came with a few additional upgrades / fixes as well after a design review on V1.1:

• 0805L400SLWR PTC self-resetting Fuses - these are super cool and increase in resistance in response to minute temperature changes
• USB C
• Better decoupling layout on microprocessor (previously, capacitance was too high - probably resulted an upload issue that I had on OpenServo with the same processor)
• Use of switching regulators: MPM3610 as the 3.3V power supply at 1.2A, and the MAX17573ATG+ as the 5V and 12V power supplies at 3.5A
• Replacement of transistors for driving various peripherals with smaller signal-level mosfets: RU1J002YNTCL

Here’s what V1.2 looks like:

And this is the one we’re getting manufactured.

Here’s the repository for the final kicad project for each version of the board.

Here are the board’s overall capabilities:

• 2x I2C thermometers (one on each side of board - one in a ‘hot zone,’ other not
• Buzzer
• 2x mosfet switches for each battery
• Independent battery voltage sensing
• Battery voltage interrupts
• SD Card / removable flash
• 16 MB on-board flash chip
• USB C (this took me a long time to add so I’m flexing it here)
• SWD port
• 2x Stemma QT I2C ports
• 2x Stemma QT analog inputs
• PTC fuses on 3V and 5V outputs
• Up to 100A current sensing on each battery
• 3x 1.2A, 3.3V outputs
• 3x 3.5A, 5V outputs
• 3x 3.5A, 5V outputs
• 3.3V and 5V outputs have 4A hold PTC fuses
• LEDs on all power outputs
• Microcontroller is independently powered!

It’s also 4 layer to be able to inlude an unbroken power and ground plane for the ESCs. All routing is done on the top or bottom layer.

That’s all for now!

Problems / Updates:

None so far, but I’ll definitely run into some while building and testing the board. Hopefully it all works out!

Yep, there are some mistakes… check out the next post :p