I’ve previously written about the moteus performance analysis tool and how it can be used to evaluate different motor control systems for performance purposes. The tool described there is entirely a web based application that requires clicking around in the HTML interface in order to configure an analysis.

Now, there is newly added feature in the main moteus git repository that provides a command line interface (CLI) to the analysis kernel! This capability lets you run sweeps through various parameters or motor configurations much more easily than before, or even wrap the analysis in an optimization loop without resorting to browser based automation techniques.

For some time now the moteus python library has had a convenience function to repeatedly execute a command until moteus determines that the trajectory has completed. This helps a lot with simple applications with a single device, but as soon as multiple controllers are involved in the same machine numerous problems appear:

Watchdog timeout: moteus has a watchdog timeout and unless all devices are sent commands on a regular basis, they will fault. This is easy to do with set_position_wait_complete, which by definition only sends commands to a single device.

TLDR: As of firmware 2026-01-21 moteus now has a maximum modulation depth that is 6% larger than before. That means the maximum speed for a given voltage is that much higher. Read on for the effort invested in making that happen.

In a mini-project inspired by a Discord chat about a Rubik’s cube solver, I decided to undertake a project to see how quickly I could get moteus to make a controlled 90 degree movement and a controlled 180 degree movement. The project ended up involving a fair amount more work and theory than I had expected, but resulted in an overall solution that is relatively close to optimal for the specified moteus and motor. If you find text too hard, you can watch the video below, otherwise read on to see the details:

Most users of the moteus brushless motor controller will perform diagnostics and monitoring over CAN-FD, using something like tview, the moteus python library or the moteus C++ library. These options are great, since CAN-FD works over long distances, allows multiple devices to be multiplexed and is relatively immune to EMI or other electrical disturbances. The biggest downside is that at best, you can capture telemetry a few thousand times a second. For instance here, 2.5kHz is the maximum achievable update rate with a pi3hat and a single moteus.

What should you do when you want to monitor events that happen faster than that? Well, moteus has a solution for that too, and while it isn’t nearly as convenient, it does get the job done for many uses. It is called “high rate debug output” and lets moteus emit small amounts of telemetry data at every single control cycle, so up to 30kHz. In this post I’ll show how to configure and use it, how to capture the resulting output, and how to plot it or otherwise make use of it.

Way back in 2020, I wrote about the motor saturation model that moteus uses to accurately calculate torque when a motor is operating in a region where the stator becomes saturated. What I didn’t write about was a method for actually determining those fit parameters for a given motor. This isn’t too critical, as most position mode applications don’t require the applied torque to be terribly accurate, but in some cases it does matter. When that is the case, there is now a tool that can calculate parameters appropriate for entering into moteus. Read on to find out more!

Yesterday I dropped a big update to the official moteus documentation that should hopefully improve it across many dimensions. If you’re impatient, go to the new URL and check it out:

• https://mjbots.github.io/moteus/

Or read on here to get a feel for the things that have changed.

Recently I announced an updated version of the moteus performance analysis tool. It’s development was unique in that I used the Claude Code agent to do basically the entire project, modulo copying the simulation logic from the original mpat tool. It was my first attempt at using any of the LLM based coding agents and I have a few takeaways:

Using the newly data from the newly released moteus performance analysis tool, we’ve gone and updated the rated output currents for each moteus controller. The conventions for such ratings are measured at 24V supply voltage with the default PWM frequency selected.

In addition, each value has a link to the mpat page which shows that value in context, so you can see for instance that the 62A current with maximum cooling for the moteus-x1 requires even more cooling than just a 12V fan alone provides.

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.