Showing posts with label PDB. Show all posts
Showing posts with label PDB. Show all posts

PDB Updates

Board updates!

Kill Switch

The first thing we needed was a kill switch to connect to the board and tell it when to turn both mosfets off. We chose to use magnetic swtiches so that we then wouldn't need anything to penetrate through the case (just the magnetic field). The switch connected to the board over a vertical JST-PH connector.

switch

Comms

We also wanted to be able to allow the board to communicate to the high-level-controller, a Jetson Xavier, to report battery data. This was done over usb with some simple Serial protocol. On the board side:

And on the HLC side (in python)

In actuality, this will be running in a ROS node with its own loop, so the while loop isn't necessary. We just included it here since the pyserial device needs to exist in order to buffer the serial data from the board.

Peripherals

Beeper: We added some beep commands to show when battery states are changing or a battery is low Current: By interfacing to the ACS781, we now have current data logged SD Card: Error data is logged on the card to hopefully help us in the case that something breaks

... and lots of redundancy in the code to make sure that this thing never fails!

You can see the full project here.

Problems / Mistakes

None so far! The board is working really well, and the sub is happily swimming in the water :D.

That's all for now!

PCB Building

Time to build!

We ordered our boards from PCBWay, and after a few weeks, we received all the components and the board. Here's what the boards looked like:

Board

Something interesting is that a few large via arrays on some of the boards were visibly slanted and one board had a broken 2nd layer zone:

Bad board

After contacting PCBWay, it turned out that the slanting was actually within their specification (the vias were connecting two large zones together so it was technically fine). The broken zone wasn't, but they immediately sent us more boards to replace that one, which was great.

Soldering

This is pretty standard, but it's still worth going over. The first step was to apply solder paste using a stencil. We used Kester 256. Since nearly all the components are on the top side of the board, there was no need for two pastes (it's common to use two different solder pastes with different melting points / curves so that the first side you soldered doesn't flow when you solder the second side).

solder paste

Then we placed the components. The area with the power supplies (where the inductors are) was a little bit tricky because the MAX17573ATG+ is a QFN, which can often have shorted solder joints after coming out of the oven, so we deicded to handsolder the passives around that chip later. Since the inductors are hard to handsolder due to having large pads underneath them, we decided to bake them too.

Components

After baking, it looks pretty much the same:

After baking

We then decided to finish soldering just the microprocessor section of the board to verify that this was working prior to finish soldering all the other components in the power supply section. It was then that we realized that there was a mistake with the reset button - the footprint was incorrect and the reset line would constantly be shorted to ground, causing the processor to be in constant reset and be unprogrammable.

mistakes

RESET_RAW should be on pin 2, not pin 1 or the grounding pin. We cut the RESET_RAW lines on pin 1 and soldered a wire between the grounding pin (now connected to RESET_RAW) and connected it to pin 2, which was then connecte to RESET_RAW pad next to the SWDIO port.

After finishing the soldering and some fixing:

Microprocessor

with the red wires used to fix the mistake with the reset button. To test the microprocessor, we burned an itsybitsy m0 bootloader over the SWDIO port using these instructions and uploaded a simple 'hello world' script, which worked!

Then we finished handsoldering the power supply peripherals:

Finished

And the board was finished! Here's the overall layout diagram:

Diagram

Errors:

Voltage sense

There was one mistake which put the board in jeopardy, however. The way that hot-swapping works here relies on the microcontroller being able to read the voltage of each battery and turn each on / off using a mosfet array. Here's the schematic:

shematic

The critical part is that the voltage sensing happens after the ideal diodes on each battery. The current travels from the battery &larr diode &larr board / voltage sense &larr mosfet array &larr rest of board. What we didn't know when designing the board is that mosfets can conduct in reverse. Thus, with one battery active (it's mosfets on), being able to conduct in reverse results in the mosfets for the disabled battery effectively putting both batteries in parallel (minus a small voltage drop on the enabled batter) at the voltage sense pin for the disabled battery. Thus, the voltage on the disabled battery can't be read - the microcontroller can't even tell if it's plugged in - when the other is on.

The fix to this was to change that 'chain' from earlier so that the voltage sense would occur prior to the diodes in order to isolate each sense pin: battery &larr voltage sense &larr diode &larr board... by cutting a few traces and soldering on a small jumper cable.

Mosfet Driving

The PMOS used CSD25404Q has a max gate to source voltage of ±12V. Unfortunately, a silly mistake meant that they would actually be subject to battery voltage (greater than ±12V), which would instantly kill them. The schematic shows a simple fix:

schematic

putting a 1k resistor right before the source of Q1 and after the bases of Q[3:6] divides the battery voltage for the bases using R12. Although it was a little tricky to solder that new resistor in, it was doable and worked well.

Other than that, the board worked great, with all the peripherals and power supplies working great!

Programming

It was then just a case of programming the board. This was fairly straightforward, with the overall logic being very simple:

Basically the same thing for each board... hopefully it's straightforward. There are a few edge cases, but everything is pretty easy.

Installation

This was pretty straightforward. With a few 3D printed brackets and some work in soldering the ESCs to the board, everything was assembled onto the electronics plate to go into the sub:

Insalled

With the ESCs zip-tied to the bottom: ESCs

Then we installed the entire electronics plate and connected all the peripherals into it, and it worked!

Working

More problems:

We discovered a few software bugs, but they were easy to fix and overall things worked well! In fear of having the board be shorted by dust, we also chose to conformal coat the board using silicon conformal coating. Unfortunately, some got into the reset button and made it unreliable, but an exposed reset pad and the SWDIO port allow the microprocessor to still be reset if necessary.

PCB Design

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, we decided to build 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, we were concerned about how hot-swapping could be done, and chose to use a microcontroller for a few reasons:

  • Although hot-swap controllers exist, they are fairly rare and most were out of stock
  • We had 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

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'll be explaiend later. You might argue that we could've used a hot-swap controller in addition to a microcontroller for system configuration / those peripheral actions, but we decided 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, we chose to add 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 we'd used them before, we chose the LM1805 LDO as the 3V and 5V regulators. This ended up being a very obviously bad decision something we later revised.

Here's the complete and final bom.

Board iterations

We first made a simple test board around the CSD25404Q p-channel mosfet to gain more experience in using it.

Test board schematic

Test board layout

It worked, so we continued on with designing 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).

Board V1.0

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, we just split the board into two separate PCBs to be connected with a power cable. Here's V1.1:

Board V1.1

ESC module 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:

Board V1.2

Board V1.2 CAD

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 we'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

20230508 Tuning In the O-Ring Size

  Parker handbook  4.3 Face Type Seals “Face type seals are sometimes rectangular. In designing such a seal to receive a standard O-ring, th...