Poor Tinytroller.
No, I haven’t killed it again…yet. After completing and testing a third full board, I decided to proceed immediately to vehicle testing. This time, I included all the anti-noise hacks from the very beginning, and also increased the gate resistance to 40 ohms from 30. It means I should probably stop investing big money into 2 amp gate drivers, since they’re definitely not being used to capacity now (the alternative is, of course, to design a bigger power stage to match).
The vehicle of choice is the slightly neutered Straight RazEr. Straight RazEr has sort of become a testbed for bad ideas; for a brief period, I converted its existing battery to 6S4P (from 12S2P) to try out the Hobbyking cartroller, and it was actually used day to day. Because the Cartrollers have no current limiting whatsoever, I replaced the stock “short melon” Turnigy C80/85 motor with a rewound one from the original Landbearshark drive pod. The rewound short melon has a torque constant roughly 3 times higher (correspondingly, a Kv 3 times less) due to being rewound with twice the turn count per tooth and re-terminated in Y instead of Delta. The increased core inductance and resistance made for a more friendly controller test platform. It was still capable of pulling a few thousand watts, though. The problem was that the original sensors I installed turned out to be very poorly timed, probably from me just stuffing them recklessly into the slots. If I wanted to use Straight RazEr as a test platform, I needed to move the sensors outside the motor in a manner that I could adjust and optimize their timing.
Fortunately, Straight RazEr’s frame had a useful cutout section next to the motor that I could clip a set of sensors on. I designed a mount for 3 Hall sensors that would latch on to a .25″ thick frame member, and stared at Make-a-Bot long enough for it to finish:
It’s not a Fancy Routed Sensor Board, but it holds 3 of them in the correct mechanical alignment of 17.14 degrees for a 14-magnet, 3 phase motor.
It literally clips on to the circular cutout section part of the frame and is retained solely by friction, which is fine since it doesn’t weigh very much and there is indeed alot of friction. During the initial “run-in” test with this board, I was actually tapping on the mount with a hammer to get it to move along the frame.
For the first time, I elected to mount Tinytroller properly like it was designed to be. I lined the bottom of the power board in some 0.5mm silicone padding, and made a quick rectangle of 1/8″ aluminum to space the edges of the board up. The whole assembly was then screwed to the underside of the 1/8″ aluminum top plate. So there should be no heat problems if Tinytroller is working correctly!
The first run was on a power supply in case the sensors were so far out of tune that it would just try to draw All the Amps (up to IMAX, of course). The test was mostly conclusive, but it revealed a very strange problem that did not come up earlier. Occasionally, the motor would ‘latch up’ into one state, and any attempts to move it physically were met with opposing torque. The controller would also seemingly run the motor, but it ran very rockily and draw huge pulses of current. I figured it was one of the current sensors giving bad data (causing the state table sequenced current reading to be garbage). After replacing both current sensors (goodbye, $8!), the problem still did not go away. More investigation discovered that some times, phase C’s gate drive did not shut down when commanded – meaning phase C was always active, whether high or low. Hence, the motor “preferred” a state where phase C was low since the bootstrapped high sides would eventually turn off.
Even stranger was its tendency to disappear and reappear with power cycles, and even just letting go of the throttle and then commanding it again. I replaced the IR21844 on phase C, but the problem was still occasionally coming back – so now I’m thinking logic instability, or half-dead Arduino. This Arduino Nano has been through a whole lot.
Since I figured that Tinytroller would explode or require servicing very soon, I didn’t bother installing the bottom plate onto SR, and instead just duct taped everything in. New in this pile of wires is a 40 amp fuse and holder – with the maximum current dictated by the sensors to be 40 amps, it shouldn’t ever need more…. right? I also put the battery back together in series (42 volts) for this test.
The results were semi-conclusive. When Tinytroller wasn’t spasming due to phase C’s instability and latching up, its 15v switching regulator was doing so. For some reason, immediately after power on or after a “latchup”, the 15v regulator would start buzzing at audible frequencies and its output voltage would drop to under 7 volts. For a regulator that is supposed to switch at 150kHz, being able to hear it means something has gone horribly wrong. Because 7 volts is well under the IR21844’s cutoff voltage, the effect is that the controller just “turns off”. It seemed unable to reset itself from this condition, but some times after a power cycle the problem would disappear, only to spontaneously reappear.
Having seen this issue once before, Shane immediately deduced that inrush current (from dumping the 40 volt battery onto the controller instantly, as SR has no precharge circuitry) could be causing the LM2594 to freak out. It’s probably reasonable to expect that a sudden step in voltage from 0 to 40 volts, with its associated ringing and overshoot, could put the regulator in an unknown state. Given that the “ON/OFF” pin is just shunted to be on at all times, I suppose it’s also not unreasonable for it to not be able to correct itself. Corroborating this explanation was that two successive fast power cycles usually solved the problem.
I decided to give the logic power a little bit of “rise time” on its input by inserting a resistor in series with the diode feeding the input capacitor. The resistor is 68 ohms, a value that I bought thinking I might need it one day for gate drive. With the 100uF input capacitor, the 10-90% rise time is about 10 milliseconds. The average DC current draw of the 15v side is low enough to keep the power dissipation reasonable, and I only lose about 3 volts to the resistor.
Gee, putting resistors in series with my regulators. It’s like I’m being forced back into the days of chained-resistor-linear-regulators like the Melontrollers or something. Afterwards, Straight RazEr was taken up and down the Halls of MITERS a few times, and I even tried a few full throttle launches to try and induce more failures, but to no avail.
I have yet to observe a single 15v regulator latchup since adding the resistor in, so I might make it a permanent feature of the board design… or search for proper inrush limiters in a compatible package, as it’s rather unsustainable to keep a fixed value resistor there in case I ever add more things to the 15v bus. I only saw the phase C latchup weirdness once during bench testing after adding the resistor, but never during on-the-ground testing. It literally could be a flaky ATMega pin on the Arduino board causing the Phase C problem. The only question left for me is to find out whether or not any of these problems carry over to the revised board. I’m fine with the only board hack on this design being “add a resistor to the regulator input”, but I think I’ll hold off on adjusting other parameters until I have a version of the new board together.
There is another thing I will change, however. Tinytroller has an interesting nonlinearity, dubbed “turbo lag”, which causes the current command to rise quickly as motor speed increases. This was amusing to see on Straight RazEr since it produced what felt like quadratic throttle. The reason for this is that my current sensor filters, both hardware (input to the Arduino) and software (the I_RC variable and associated code) are very slow. I designed them originally to filter the PWM frequency, which was 4kHz when most of the circuit schematic was drawn, and I merely copied and pasted it over. The hardware filters were designed with a 400 Hz break frequency in mind, one decade under (or 1/10ths) the PWM frequency.
Well, first off, I’m using 8kHz PWM, but the real problem is that I did the EE n00b thing where I was designing towards 400Hz as if it were 400 rad/s. So my actual current sensor bandwidth is something like 80Hz, a number easily reached by even the modified Melon at low speed: 80 electrical Hz = about 11 mechanical Hz, or something like 660 RPM. Near and beyond this speed, the magnitude of the current reading drops off quickly, which leads to the sudden increase in command in order to “keep up”. Luckily, 1/10ths of 8kHz in rad/s is about 5000, so I just need to change my filter resistors from 10K to 1K. We’ll see if that results in some more linearity.
On the other hand, I kind of like the turbo lag effect.