Revision 4 - S2022 (Rishith Bomman)

Owned by Ari Wasch
Last updated: Dec 01, 2022 by Farris Matar
4 min read

Power Distribution Board

The Power Distribution Board (PDB) takes in 12s1p LiPo battery power (ranging from 36V to 50.4V) and supplies 17V to the NVIDIA Jetson and 5V to the custom PCBs onboard the rover. The board’s main purpose is to handle the regulation and distribution of power to the various subsystems of the rover. Additionally, the board also has a Battery Management System (BMS) onboard for battery state of charge (SOC) reading and passive cell balancing.

The voltage conversion is done using DC to DC buck converters for both the 17V and 5V power rails. Reverse polarity protection is employed via a P-channel MOSFET. Additionally, each load output is controlled by a smart high side switch for enable control via firmware and overcurrent protection.

The PDB is also responsible for controlling the LED matrix and interfacing with the 4 URM04 ultrasonic sensors on the rover for close-range obstacle detection.

Block Diagram

Design Choices

LT3845A Buck Converters

Part Selection: Used for it’s wide range of input and output voltages, allowing the same circuit to be reused for both the 5V and the 17V rails, reducing design complexity. It also uses external FETs and is synchronous, allowing higher efficiency and the ability to adjust the external FETs based on the required current output. Using the same circuit for both rails also makes rework and fixing mistakes easier, as any issues discovered during testing will most likely be replicated between the 2 circuits, making it easier to diagnose and rework/redesign.

Specifications:

  • 5V buck converter: Maximum 10A at 5V output (for approx. 2.5A for each 5V output). Input voltage can be as high as 60V, thanks to the high voltage rating of the IC, input capacitors, and MOSFETs

  • 17V buck converter: Maximum 4A at 17V output. Input voltage can be as high as 60V, thanks to the high voltage rating of the IC, input capacitors, and MOSFETs

Recommendations for future revisions:

  • If possible, continue using this IC to avoid having to redesign and retest completely new circuits. This may be difficult due to stock issues, so it may be beneficial to buy extras for inventory once it’s in stock again

  • Additional recommendations may be added post-testing

BD82006FVJ-M High Side Smart Switches

Part Selection: Chosen due to limited stock of smart high-side switches, provided some fault diagnosis, overcurrent protection, and enable control.

Specifications:

  • 2.4A typical, 3.0A maximum output current limit

  • Overcurrent fault signal

  • Overtemperature protection

  • 2.7V to 5.5V input voltage range

Recommendations for future revisions:

  • This part has a fairly high Rdson (70mOhms), which means at higher current outputs this will cause a significant voltage drop

    • Ex. at 2A load, the 5V rail will drop by 140mV, a fairly significant amount

  • Recommend using a different part with lower Rdson, perhaps one that uses an external FET so that the resistance can be minimized. Overcurrent and overtemperature protection would still be good to keep (i.e. in case of shorts), but good performance during typical operation should be prioritized

  • Another recommendation is to provide the option to manually enable/disable the load switch without firmware. For example, having pin headers to provide the option to pull up/pull down the enable signal using a jumper wire

BTS5014SDAAUMA1 High Side Smart Switch

Part Selection: Chosen due to limited stock of smart high-side switches, provides enable control. Apparently fault diagnosis and current sensing can be implemented, but the datasheet is a bit hard to understand on how exactly to implement this.

Specifications:

  • Very low Rdson (14mOhms)

  • High input voltage range (5.5V to 20V)

Recommendations for future revisions:

  • Recommend using a different part, one where the fault detection and diagnosis is easier to understand and implement. The most important faults to have protection against are overcurrent and overtemperature conditions

  • If possible, use the same part as the 5V load switches. This may be difficult due to the small number of parts that are capable of both 5V and 17V input voltage, but it would be very helpful in reducing circuit complexity, having the same benefits as the reusable buck converter IC. However, this isn’t a hard requirement

Reverse Polarity Protection

Reverse polarity protection circuit was implemented on the VBAT connector to avoid damage to the board in case the battery was connected the wrong way around. See the page on our wiki for details ( ).

Recommendations for future revisions:

  • Keep as is, so long as no issues are discovered in the future

STM32F446RET6 MCU

The STM32 MCU is the standard MCU used across many of the UWRT boards, primarily for its compatibility with the Arm Mbed firmware development OS, which is what’s used by the firmware team. It is highly versatile and able to communicate with several interfaces and functionalities, including UART, SPI, I2C, USB, PWM signals and more.

Part Selection:

  • Chosen for its compatibility with the firmware team’s development tools

  • Can communicate over UART, which can be converted into CAN (to communicate with the Jetson/rest of the rover’s PCBs) or RS-485 (to communicate with the ultrasonic sensors) using transceivers

  • Can send PWM signals for the LED matrix

  • Lots of GPIO to enable/disable all the load switches, as well as receive any fault/status signals for fault diagnosis

Recommendations for future revisions:

  • We have some of these in inventory, but if we intend to keep using this MCU we should consider keeping an eye out for when they go on stock again to buy more. Alternatively, we could look for a different MCU. It would still need to be compatible with the firmware team’s development tools, so coordinating with them will be required. Note that since this board only needs PWM, UART, and sufficient GPIOs, we don’t need to find an MCU that’s as versatile and could select MCUs on a case-by-case basis on what’s required for the board, but this could be difficult. Either way, there should definitely be a plan made for MCUs on future boards.

Testing Results

Place to put a running list of results from testing the board and make note of any issues or odd behavior.