Well, that didn’t take long! Only a short time ago I announced the first release of the moteus performance analysis tool. In that short time frame, I basically did a complete rewrite (more on that later on), that added a bunch of new capabilities. You can now create nearly any table comparison you can imagine, enter custom motor configurations and even produce 2D graphical plots showing supply power, temperature, or efficiency versus speed and torque. Check out the tool live here, and read on to learn more.

Recently I showed I was able to use the new dynamometer fixture I built to capture detailed thermal modeling parameters for motor controllers and motors. In this post, I’ll describe how I turned that into the initial version of a tool that lets you compare the performance of different moteus controllers (and some others), along with different motors, to help design an overall motion system.

TLDR: Try it out: Moteus Performance Analysis Tool

In the last post, I gave an overview of what thermal metrics are relevant to motor drive applications and how they drive the important performance metrics of controllers and motors. In this post, I’m going to look at how to measure those thermal parameters empirically in at least a crude way, but with enough accuracy to be useful for practical design applications.

What do we want to measure?

There are a set of parameters that we would like to be able to measure that have some overlap between the controller and motor case. For both, we want to be able to measure:

One of the things I’ve been wanting to understand better for quite a long time is the thermal performance of moteus and motors when used in realistic applications. In many, if not most systems, thermal limits of one or another determine the eventual sizing of controllers and motors and are one of the most important performance factors. I’ve covered this before to a superficial degree in a previous post (customizable pwm rate) but it was far from a general solution. The newly provisioned dynamometer fixture, with its ability to accurately measure input current and power, provided a great opportunity for finally tackling this. This post will describe a bit of the motivation for the work and why you should care.

Long ago, in a workshop not so far away, I built a dynamometer for characterizing moteus controllers and motors. In the intervening 5 years, we released the moteus-r4.11, moteus-n1, moteus-c1, and now the moteus-x1! For each of these controllers, and the many firmware releases in between, this fixture has still served as a critical part of the validation procedure for new firmware releases and new product releases. However, it was time for a few improvements when tackling the moteus-x1, so here is a brief write up of the new result.

moteus is able to for many motors automatically determine all the relevant parameters that are necessary for control. That includes phase resistance, phase inductance, torque constant and pole count. The calibration routines have worked pretty well for a wide variety of motors and all the currently available moteus controllers, but when working to expand the supported envelope recently I undertook an effort to make that support even broader, specifically to improve accuracy when measuring resistance and torque constant, and to reduce outliers when measuring inductance.

One of the characteristic metrics of brushless DC motors is the Kv value, which describes the relationship between the angular velocity of the motor and its back EMF. Somewhat unexpectedly, this constant also completely determines the torque constant of the motor, i.e. the relationship between phase current and mechanical torque output (see this Things In Motion post).

Since the very first release of moteus, this Kv constant has been stored in moteus using somewhat non-intuitive units as motor.v_per_hz. That makes a lot of sense internally, as nearly all math the controller has to do can be natively done with those dimensions. However, as a user visible motor constant, it is completely opaque. Further, as a result of my incremental discovery of the math behind BLDC motors, the constant used by moteus had some additional “fudge” factors baked in that were then backed out through other “fudge” factors in the firmware.

Way back in 2019, I documented the approach moteus has used for encoder commutation calibration ever since. In principle, it commands a fixed voltage that is swept through a range of electrical angles. Assuming the voltage is large enough, this will drag the rotor around with it similar to if the motor was a stepper motor. While that is happening, the commutation encoder reading is recorded over time, so that a mapping can be made between commutation encoder and the electrical angle of the motor. When combined with the old dead time compensation technique, it resulted in relatively sinusoidal current waveforms and thus smooth motion of the rotor and a smooth mapping.

Way back in 2021, I wrote up a post detailing a method for improving the linearity of the relationship between applied voltage and current for moteus, particularly during the calibration phase. At the time, this did solve a real problem – during calibration, moteus applied a fixed voltage to the phase terminals, swept the electrical angle of that voltage, and hoped that the mechanical angle as sensed with the on-axis sense magnet matched well. However, as a result of some new work, I’ve found that the premise behind that approach was flawed and it needs some re-thinking. This describes what I found, and what’s being done to resolve it going forward.

This is the final post (hah! for now at least) in my series about implementing support for off-axis encoders in moteus (see previous iterations here: 1, 2, 3, 4, 5). In this one, I’ll share the recipe for how to set up an off-axis MA600 encoder using a ring magnet as the only encoder source.

Hardware

Parts list:

• moteus-n1 - https://mjbots.com/products/moteus-c1
• MA600 breakout - https://mjbots.com/products/ma600-breakout
• Diametric ring maget - https://mjbots.com/products/diametric-ring-magnet
• Hollow shaft motor

Magnet mounting: The ring magnet needs to be rigidly affixed to the rotor of the motor being driven. It may be necessary to construct a bracket to mount the magnet, or a fixture to position the magnet before using an adhesive.