Analyzing effectiveness of motors and controllers

[Brian]

I've had lots of discussions with various people about what motor and/or controller is "more efficient", and left most of them realizing I don't really know what that means. There are lots of reasonable-sounding ways to compare these things, so even deciding which one is interesting is hard before getting to the math. I'm planning to write some code to generate numbers, but I'm curious which numbers people think are interesting.

My end vision is to set up code that allows easily changing these factors independently of each other:

• Fuse current (aka battery current). I want to support simulations from fixed conditions with time-based profiles of fuse currents too.
• Battery voltage. I'm going to assume it stays constant to make comparisons easier, because voltage sag isn't all that big and it also affects all systems basically the same amount I think. For simulations, this is a min with the fuse current and motor power.
• Top speed. I think it makes useful comparisons way easier to do if the speed is the input parameter, and then the code automatically comes up with a ratio between ERPM and speed based on the other variables.
• Motor parameters. This means resistance and flux linkage. Need to be careful about defining what units the constants are in to stay consistent. Adding inductance to look at its effect on when you become voltage limited (with some flux linkage / current waveforms, it can be sooner than it would be just looking at resistance), and how field weakening affects things, seems hard and not super useful so I'm going to leave that for later.
• Motor power (burned as heat in the windings). This is kind of tied in with the motor and controller of choice, but it's also nice to be able to play with its effects and see what happens. For simulations, this is a min with fuse current and battery voltage. I think keeping motor power constant is going to be more useful than trying to define motor current in a useful way across different current waveforms.
• Current waveform. This is the difference between sinusoidal commutation, 6-step, 12-step, and what our custom controller does. Looking at how this affects the overall performance is going to be interesting. It's hard to analyze the affects of changes here by hand because the biggest difference between choices is trading off top speed vs torque, which does nothing when you keep the top speed of the system constant.
• Efficiency. I think just throwing in a simple multiplier to represent the difference between one reduction vs two etc is enough.

I'm deliberately avoiding looking at losses in the controller. In the custom controller, those are mainly driven by motor current (not motor power). In other controllers, I really don't know if they're motor current or switching losses. Regardless, I don't have a good way to estimate it for any controller, and anecdotally they seem to be fairly small (controllers don't get super hot). I suspect heat dumped in the motor is the limiting factor for most kart setups too.

Here's the things I think are interesting to get out of the analysis. I'm really curious to hear what numbers other people think would be useful here too:

• Stall force. This makes sense to compare with a constant amount of heat dumped in the motor (aka current through the fuse).
• Time to get down a typical straight starting at a reasonable speed. Numbers on how long typical power racing straights are, and how fast you come into them, would be very helpful.
• Information about the curves on the force vs speed graph where you transition between motor current limited, battery current limited, and voltage limited. This is probably mostly just the speeds at which the lowest-force one (aka the speeds at which your max force becomes limited by a different limit) changes, but I think looking at the shapes on an actual graph might be interesting too.
• How much force you get a given speeds. For quick analysis, I think extending the stall force number (0/4 speed) to 1/4, 2/4, and 3/4 might be interesting. Looking at the curves overlaid on a graph will definitely be interesting.

[Brian]

Fun fact: when people say "trapezoidal commutation", they commonly mean at least four different things. I just now finally convinced myself people really do talk about using all four (not sure whether they actually use all of them in controllers), and also that there are in fact four and not only three. I'm going to call them trapezoid, trapezoid_6step, trapezoid_4step, and square.

Here's an image of trapezoid_6step ("Six Step") and trapezoid_4step ("Trapezoidal"), along with sinusoidal (note that these three waveforms are annoyingly not scaled to be equivalent in any way):

Commutation-Waveforms.jpg (28.87 KiB) Viewed 51549 times

And then here's another of trapezoid_4step ("Modified Square Wave") and square ("Square Wave"), also along with sinusoidal (scaled towards equivalent input power looks like, but I haven't confirmed if that's actually what it is):

Sine-Square-Modified-Square-Waves.gif (5.05 KiB) Viewed 51549 times

People don't talk much about using actual trapezoids, which I think would be silly anyways. Regardless, I'm going to poke at it with my code because it's super easy.

Looking at this mess, I think I'm also going to attempt to come up with a useful way of overlaying the various commutation schemes on each other scaled intelligently.

Other commutation schemes I plan to implement:

• Sinusoidal (because it's simple)
• Constant-torque sinusoids (which is different for the motors we have, because they have harmonics on top of the sin wave)

With any of these schemes, there's the complicated question of what to do when the motor hits full speed. There are various options:

• Stop applying positive torque once you run out of voltage. This requires some fairly accurate motor modelling to successfully implement.
• Field weakening. This is where you phase-shift the current waveform, but keep the same one. I'm not sure if keeping the same one actually makes sense with anything besides sinusoidal, so it might be more complicated than that.
• Accept (more) torque ripple. There is a region where the controller can keep applying positive torque (with ripple) for the whole rotation, and another where it goes negative for some of the rotation but the average is still positive. I think common controllers do this, because it's not particularly hard with most commutation schemes. It's not really field weakening if you just limit the voltage at each point without phase-shifting so the inductance helps you reduce the voltage.
• Just limit the duty cycle. This is simple, but it's not a very good idea. It's prone to running lots of current which doesn't produce positive torque.

Of course, it generally makes sense to combine multiple of these in some form. Some of them also make more or less sense with different commutation schemes. Figuring out how to set up the math so these are all easy is turning out to be tricky.

The datasheet RPM numbers and data from a cheap controller with something like the BOMA/T20 at https://drive.google.com/file/d/1fmC6hs ... sp=sharing both imply simple controllers tend to do some field weakening (because they spin faster than they would if they just backed out to 0 current), but don't do a very good job and basically end up dumping lots of power into the motor at full speed. Some of the $30 kart controllers just cut out with some hysteresis instead, which seems to me like a simple alternative to heating the motor up like that (just stop applying power instead of getting into that region). I'm hoping to get a better understanding of what the various options lead to once I get more code written.