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.

The new features and capababilities for moteus just keep coming! Here is another relatively straightforward one available in firmware release 2026-01-21, support for PWM (pulse-width-modulated) inputs. If an appropriate pin is configured, moteus can report the period and duty cycle of a PWM input to applications. This can be used to monitor the fan RPM for the moteus cooling fans on moteus-c1, moteus-n1, or moteus-x1, or could be used to read the value of a RC receiver output. Read on to learn how to use it and what the limitations are:

I’d like to announce more encoder support in moteus, this time for BiSS-C encoders in unidirectional mode. BiSS-C is a protocol often used in higher end industrial encoders that uses a RS-422 wire level signaling scheme. This support works out of the box for moteus-n1 and moteus-x1 which have a RS-422 connector already included. All you need is to have firmware 2026-01-21 or newer installed and to follow the documentation for upgrading.

If you want to see a specific configuration example, or read about how the feature was implemented, read on!

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.

Back in 2022 moteus added support for acceleration limited trajectories. This was a highly requested feature and has been used for all sorts of applications since. However when working on the recent trajectory optimization effort it became obvious that there were still some lingering stability issues on two fronts. First, when decelerating, there would occasionally be single control cycles where an acceleration was instead commanded. Second, termination at the end of a move would often involve small amounts of overshoot or oscillation. You can see both in one of the plots from that post here:

I’ve known about this for several years now, and occasionally have spent a few minutes trying to think of alternate formulations that would be more stable. With my recent attempts to use Claude Code, I thought maybe it could help here too since at least this part of the firmware is entirely tested by host side unit tests? Well, the answer was I suppose it did help, but not exactly in the way I originally intended. Read on for more details, or upgrade to moteus firmware 2026-01-21 if you just want the fixes.

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.

Wow, the updates to the graphical moteus monitoring application tview just won’t stop! We’ve had a lot of changes recently (python console, fault text decoding, fault monitoring, UUID addressing) and now here is yet another long requested big quality of life improvement – recording data to log files! As of pypi moteus-gui version X, tview now can write log files in either the .jsonl format as a single file or as a set of CSV files. Continue reading for more details!

Following a brief period with no stock, we’ve restocked the original 32mm x 22mm x 4mm diametric ring magnet at mjbots.com. Additionally, there are now 4 new sizes to choose from:

• 44mm x 30mm x 4mm - N35H
• 24mm x 16mm x 3.5mm - N35H
• 21mm x 14mm x 2.5mm - N45H
• 19.5mm x 12mm x 2.5mm - N35H

This should hopefully let you use low cost (albeit low accuracy), off axis diametric ring magnets in even more applications. Good luck!

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!