Where I left off, TinyCross was at the rolling chassis stage. Mechanically, it went together relatively smoothly, most of the issues having been worked out in CAD. There are a few minor tweaks I'd like to make to make it lighter and narrower, but they're low priority compared to getting a first test drive in. So, on to the electronics.
It always looks so clean until you start adding wires.
I've already done a post on the motor drive design. Since the kart is four wheel drive, one will control the two front motors and one will control the two rear motors. For now I've only built up one, just in case there are any observations from the first build that would require changing parts on the second. Here's what the power side looks like:
TxDrive, power side.
It's one of the weirdest power layouts I've done for a motor drive. The design supports two different FET configurations: one with a single MTI200WX75GD per motor and another with a six FDMT80080DCs. Since the MTI200's are perpetually out of stock, I committed to the FDMT solution for this build. It really doesn't look like enough FET, but on paper they're almost identical to the MTI200. I especially like the 1453A pulsed current rating. The board is four layers but only 1oz copper, so I also reinforced some of the high current density paths with 1mm bus wire and copper braid.
The FDMT 8x8 SO8 package creates a few other advantages in this configuration. The parasitic inductance is lower and there's room for local ceramic capacitor decoupling near each half bridge, which will help contain switching transients. The entire power side is also at or below 1mm in height, so the whole surface area of the board, include the somewhat overworked 12V to 5V LDO, can be heat sunk to the chassis through some thermal pad:
TxDrive, signal side.
On the other side of the board, each half bridge gets a 12mm-wide vertical slice with its phase wire exit, gate drive, current sense, and 2x47uF aluminum polymer bus capacitance. An additional 820uF of bulk capacitance per motor gets folded over into the unused volume. The signal board sits in the middle and carries the MCU, its power supply, a CAN transceiver, and the encoder interface.
Two pairs of 12AWG inputs, each with 4mm bullet connectors, support up to about 150A of peak battery current. I find it easier to deal with two 12AWG wires than one 8AWG wire. The six phase outputs are also 12AWG, so everything can pass through a common size grommet on the eventual enclosure. The only other connections are CAN (twisted pair) and the encoders (9-conductor shielded ribbon cable).
The ribbon cables and phase wires run in parallel down each upper A-arm to the motors. This is the scariest run of wire for many reasons. Electrically, the phase wires are high-dV/dt EMI sources that will capacitively couple onto the encoder cable. This is the main motivation for using shielded cable and three-phase optoisolated Hall signal configuration. Mechanically, these wires pass through several moving parts. (The encoder cable even passes through the drive belt loop!) They need enough slack to accommodate the entire steering and suspension travel, but the slack needs to be in the right places, with good strain relief everywhere else. The routing is actually pretty clean, and will get cleaner once the drives and encoders have their covers installed.
Front wheel drive fully wired up.
That's all just for the front drive; everything will get repeated for the rear. That means that in total there are four pairs of 12AWG DC wire to route out from the central battery input, and up to 300A of total peak battery current to deal with. And this is where I get to spread the good word about MIDI fuses. They are by far the most power-dense fuse format. I've always used the car audio ones, with questionable voltage rating, but Littelfuse makes some serious ones as well, up to a 75V / 200A model rated to break 2500A! Their triple fuse holder is also perfect for my circuit.
Main power input.
The two battery inputs (each a series string of two Tattu 6S 10Ah Smart packs) get the same dual 12AWG treatment, with back-to-back thick #10 ring terminals (the wonderful McMaster 7113K17) bolted to individual fuses.These connect to a bus bar that feeds the full 4x12AWG positive group. This goes through a master power switch and then splits off two and two to the front and rear drives. Meanwhile, a separate 30A fuse feeds off the bus bar through a small switch to the charger and steering wheel board.
The...steering wheel board?
I am really trying to minimize the number of microcontrollers (and also the number of firmware images) on this kart. Each drive has an STM32F303 that's pretty busy running two motors and really shouldn't be doing anything else. But I can stuff every other process onto a single high-level controller. This controller needs to handle driver interface (including throttle read-in), CAN communication with the drives, and ideally battery management. This constrains it to be somewhere near the center of the kart, and the steering wheel seemed like a logical place.
Why have I not grip-taped my steering wheels before?
I've also always wanted to have an OLED steering wheel display. Having live data will definitely help with troubleshooting. Although it's not absolutely necessary, I decided to use the STM32F746 for this board since it has the DMA2D graphics driver. The OLED is 4-bit monochrome, which isn't a natively-supported output format for the DMA2D. But as long as you're blitting even numbers of pixels, you can still make it work. The interface between the OLED and the main board is a SPI variant, good enough for a 50-60Hz update rate. I was originally going to put it on headers, but for clam shell serviceability it was better to just use thin wires.
Display interface and "hot" side of the BMS.
Also on that side of the board is the battery management system (BMS) cell balance circuitry. This got out of hand quickly since I left almost no room for it: the entire area under the display is pretty much off-limits. But I managed to cram 12 cells worth of balance circuit on each side with the resistors themselves sinking heat into the steering wheel metal. To facilitate routing, the circuit alternates FET/resistor placement for the odd and even cells:
Cell balance group.
To discharge an individual cell, a square wave is driven onto its charge pump, which turns on the its FET. This happens to the cell(s) with the highest voltage until they are evened out. Usually this is done during or after charging. During discharge, it's sufficient to just monitor the cell voltages and stop when any one cell reaches a low voltage threshold.
Accurately measuring individual cell voltages is itself an interesting challenge. The main problem is that the cells are offset by up to 48V from the ADC ground. Of course, it's possible to use simple voltage dividers to bring the signals down to below 3.3V. But it would be better to have individual differential measurements of each cell. This means a lot of op-amps or...
One op-amp and a 72V analog multiplexer for cell voltage measurement.
I found some 72V analog multiplexers (MAX14753) that can feed the inputs of one nice op-amp. The muxes are dual 4-to-1 selectors cascaded and wired such that the two outputs are always adjacent cell nodes, which drive the inputs of a differential amplifier. This all fits in a pretty small footprint on the opposite side of the board from the cell balance circuitry. Also on this side of the board are all the connectors, the logic and analog power supplies, the charge cutoff FETs, buffers for driving the cell balance charge pumps, a very sad SD card holder with a reversed footprint, the STM32F7 itself, and a mystery component.
The crowded side of the steering wheel board.
Right now the main purpose of this board is to act as the high-level controller for commanding torque and reading back data from the motor drives. The BMS functionality is a secondary objective, since I can still monitor pack voltage through the drives and charge off-board. The torque command comes from a nice trigger stolen from Amazon's second cheapest RC car transmitter. Like tinyKart, this means all the controls are on the steering wheel - no pedals. The trigger is bidirectional, so it can command positive and negative torque.
All four motors receive a torque command over CAN at 1kHz that they apply to their current controllers. The motors then take turns replying with their crucial data (electrical angle, speed, voltage, current, and fault status) at 250Hz, and their less important data at 50Hz. This should allow for some fairly tight feedback loops through the central controller for things like speed control, traction control, and torque vectoring. There's also that mystery component, which is controls-related.
For now, I'm just starting to test the power system with the front drive only, quite honestly so I can see the fire when it happens. The two motors will just get the same torque command, ramping up slowly to full voltage/current. I did as much testing as I could on power supplies, but it's finally time for batteries. Here's the first batteries-in test, at a very easy 6V/20A (peak line-to-neutral quantities) limit:
It's nothing exciting, but the first batteries-in test is always a bit scary since there's no longer a CC/CV supply keeping things from going out of hand. After I do some wiring and software clean up and make sure the data logging is working, I'll ramp up from there toward the full 24V/120A, and then full four wheel drive. I've learned to expect smoke at some point during this process though, so I'm holding off on building the second drive until I see what fails on the first...
