CAN-FD communication has a number of configurable parameters in order to specify how long each bit period lasts, what amount of clock skew is permissible, and when to sample the physical layer to clock in each bit. For many CAN 2.0 applications, only the bitrate is configured and the sample point and skew parameters are left to a default. Optimizing them may be necessary if you want to control timing margins over a CAN bus with many hosts. Doing so is often not necessary though, as for CAN 2.0 different hosts can have different sample points and largely still interoperate.

Here’s a short and easy to report new feature for moteus. Thanks to Eli Rutan, as of firmware release 2025-07-21, the same sky AMT22 SPI 14/12 bit absolute encoder (formerly CUI Devices), is now supported in moteus firmware. It requires a 5V supply, so can be used with the moteus-c1, moteus-n1 and moteus-x1 in all the ways other external SPI encoders can be used.

Both 12 and 14 bit single turn encoders are supported. Multi-turn variants can be used, although moteus does not use or need the multi-turn functionality.

There are many configurable values and internal firmware limits in the moteus brushless motor controller that result in the output current being less that would exist in an ideal system or less than what was commanded. To date, the only way to know if any of these factors was resulting in limiting behavior was to know all of the possible limiting factors, and look at factor specific diagnostic values one by one to see which was the culprit. Now, as of firmware release 2025-07-21, moteus will report exactly which feature is limiting the output at any given point in time, making that diagnostic process much simpler.

Read on for more details.

moteus first added support for hall effect encoders way back in 2022, when many new encoder types were added. At that time, hall effect sensors were treated basically like any other encoder. However, because of their inherent low resolution, this resulted in them performing much worse than other encoder options, especially at low speed. In practice, very careful tuning of the encoder low pass filter was required to achieve useful performance and that performance would often only be valid in a narrow range of speeds.

Now, as of release 2025-07-21, moteus has a suite of new heuristics which drastically improve the performance of hall effect encoders at all speeds, and make them relatively insensitive to filter bandwidth selection. If you don’t care about the details, just upgrade your firmware following the instructions in the reference manual and be on your way! If you do care about the details, read on for more.

Way back in 2021, I described the approach moteus uses for filtering encoder values and its derivation from the “all-digital phase locked loop”. What I did not realize until now was that the formulas used in that derivation operated based on the “natural frequency” of the filter, not the 3dB cutoff frequency as I had intended. They are related by a constant, but this resulted in the bandwidth of the encoder being higher than expected. Here, I’ll set the record straight, and document how that effects moteus going forward.

TLDR: Now moteus has slightly less audible noise for the same effective control performance. Read on for the details.

mjbots.com now stocks PWM controlled cooling fans with RPM sense and mounting brackets that are compatible with the moteus-r4, moteus-n1, and moteus-x1. Check them out here:

Read on to see how much these can improve the performance of your system and what configuration options are available.

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.

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: