Here’s a short followup tview feature in the same vein as the recently announced fault monitoring. For various not-too-important technical reasons, the diagnostic method moteus uses to report faults in servo_stats.fault does not include a text shorthand like most other enumerations do. That means that users are constantly confronted with things like fault=33, or fault=39. Unless they are lucky and know to look in the relevant section of the reference, this doesn’t do a whole lot of good.

When using tview to monitor and control moteus controllers, there have been a fair number of limitations and “gotchas”. One of the biggest for newcomers is the distinction between error checking in the d pos command, and faults that can occur during position mode itself. When using the diagnostic protocol and issuing a command, for those commands which direct moteus to perform some control action, the controller will respond with an “OK” as long as the command itself is syntactically correct. Only then is it submitted to the online control loop, after which faults resulting from the command will manifest as the controller reporting a mode of kFault or 1, with a corresponding fault code. In the diagnostic tree view, those are shown as servo_stats.mode and servo_stats.fault.

So, what many newcomers do is take a moteus board fresh from the factory, which starts with servopos.position_min=-0.01 and servopos.position_max=0.01, and do the following in order:

1. Issue a totally reasonable command like d pos nan 0 nan to command the motor to hold position
2. Observe an OK come back
3. Don’t see the motor do anything

What those users don’t realize is that in order to see why moteus doesn’t move, you need to look at the current reported mode and fault, not at the response over the diagnostic channel.

Here I’d like to describe a solution to this problem that hopefully makes tview much easier in general with fewer instances of confusion resulting.

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.

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.