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. Read on to learn more!

For some time now, moteus has supported operating in what is called “voltage mode control”. In that mode of operation, the current control loop of the Field Oriented Control process is short circuited. Instead of modulating the output voltage to achieve a desired current, instead it is assumed that there is no inductance and the desired voltage can be selected purely using the phase resistance and back EMF. This is a useful mode of operation anytime the output current range is small relative to moteus’s ability to sense it, often but not always with gimbal motors. The drawback of the mode was that:

1. there is no torque control
2. you had to know it existed
3. you had to manually select it

However, as of release 2025-03-27 / pypi 0.3.77, moteus_tool will now attempt to automatically select voltage mode control if it looks like the motor is high resistance relative to the controller being used.

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.

This post will be short and sweet. https://mjbots.com now stocks mating solder cup MR30 and MR60 connectors:

• MR30 store links: Female / Male
• MR60 store links: Female / Male

As their name implies, MR30 are good for 30A peak (15A continous) and MR60 are rated for 60A peak (30A continuous). They have their own built in strain relief attachment, so no heatshrink is necessary during cable construction. Since moteus controllers have no connectors for motor phase wires, these can be used inline if you need to frequently disconnect and reconnect motors. We use them all the time here and figured that you might as well!

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.

I’m excited to announce the release of the newest moteus motor controller, the moteus-x1!

The biggest differences between the moteus-x1 and other moteus controllers is improved output phase current capacity. The x1 is rated for 25A continuous output phase current with no cooling and 60A continuous with fan based cooling. The other big improvement are 12V fan output pads with PWM support. Supporting high power cooling helps the x1 to achieve its higher output current rating.

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.