Wednesday, August 28, 2019

TinyCross: Electronics Update

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...


  1. Great Progress! What size is the aluminium bars u are using for the frame?

    Second question:): Any reason why u have gone for a 4$ Fet in quantity and not 2-3 SO8 housing style FET? I refer to fets like tpw2r508



    1. The bars are 1010 profile (1in / 25.4mm square) extrusions from 80/20:

      I still wanted to use the MTI200WX75GD modules if they came in stock, so I choose a FET with top-side cooling that had similar specs and would fit completely inside the footprint of the MTI200. I think at the time there were no top-side cooling 5x6 SO8 FETs in stock that could match the performance (in a parallel pair). FET inventory is so volatile I take whatever I can get! Even the FDMT80080DC is out of stock now.

      In the future I also want to try a GaN motor controller. The EPC2053 is close to cost-competitive with Si now, and the switching losses would be so low! But for now I'm happy enough with big dumb FETs with very high pulse ratings.

  2. Hi Shane, thanks for the reply, do the bars flex a lot when driving? I wanted to use Hoverboard motors so I have less space between the bars and the tarmac.

    When I first heard of gan I wanted to use it for motor controllers but then I had a discussion with a friend from a local research facility, the use gan to drive the coils of a electron accelerator(a small one). They started using early gan systems devices, but had serious trouble in getting the bridge robust. But the later devices seemed to work better. They switched to EPS later but the layout of these is still highly critical. And when u think of the specs one typically need u need 2 or 3 in parallel and this with that high dV/dt and more di/dt.

    Strange that u have so much trouble getting FETs. But I may be I have not seen this because I ordered my last Buch of FETs at lcsc. To see if the Chinese ones can compete with one from a decent manufacturer.

    1. The bars do flex a little over the full length of a go-kart. On tinyKart, that flex was actually keeping all four wheels on the ground in lieu of any real suspension. For this new kart with actual suspension, I made the chassis a closed box so it's much stiffer.

      I do also worry about the ultra-high dV/dt on GaN. The layout would have to be very good, or they'd have to be artificially slowed down, negating their main benefit of lower switching loss. That's why I'm happy to stick to slow Si FETs with monster pulse ratings and lots of heat sinking for now.

    2. Here is a sneak peek of test driving:

      The main chassis box felt rigid, especially now that the suspension handles the uneven road surface. There's some flex in the suspension itself, but not because of the 80/20 bars. The aluminum plates attaching the A-arms to the main chassis twist a little. I didn't notice any handling issues from it, but I might increase the thickness on the longer ones anyway.

  3. Was the vid only front wheel drive or all wheel drive? Front suspension is looking very good. I like the view of the vid. Looks like it works great. The belts seem not to make noises as well. Nice and quiet run of the hole drive system. Great!

    Thats a good point having the flex of the bars as supspension. I have only good flat surfaces here around where i could drive this. So not Problem there.

    1. Yep, front wheel power only for the first test drive. I wanted to be able to see the controller in case it lit on fire!

      The suspension works nicely. I was worried since it's well below the normal load for the air shocks. Have to run very low pressures and I was worried there would be too much friction, but they seem okay. I'll have to see how it does at higher speeds.

      And yes, very quiet thanks to belt drive and FOC. Mostly tire noise. Can't wait to try it out in 4WD.

  4. Yes 4WD will be interesting. Are u thinking of implementing anti slip control or torque vectoring :)?

    1. Absolutely. I'll have speed data from all the motors as well.

  5. Fine looking forward to the blog post about it :).