mjbots blog

cargo add moteus

Thu, 10 Sep 2026 00:00:00 +0000

moteus has long supported python and C++ client side libraries for commanding and monitoring controllers over a variety of CAN-FD transports. Given that I’m not completely behind the times, it is about time to add rust support to that list.

If you’re reading this, you probably don’t need to hear an elevator pitch for rust. If you have been under a rock for the last 5 years, it is a systems level language with a strong type system and focus on safety, i.e. many classes of memory errors or threading race conditions are hard if not impossible to make.

UART command and control for moteus

Thu, 27 Aug 2026 00:00:00 +0000

It has been quite some time since moteus gained the ability to be controlled or monitored over a different communication channel. In fact, the last time was with the permanent switch from RS-485 to CAN-FD way back in 2019 with the first moteus-r4. So, I’m happy to share that as of firmware 1.1.2 moteus now has a second supported communication transport out of the box, logic level UART!

Why UART?

Often it is useful to deploy moteus in a system where it is controlled and monitored by a microcontroller, there is only a single moteus controller, and the total distance between the microcontroller and the moteus is short and without significant electromagnetic interference (EMI). In those cases, using a logic level UART on the microcontroller can save the additional complexity and cost of integrating a CAN-FD controller and transceiver into the host system.

moteus-n1 gate drive strength fix

Thu, 20 Aug 2026 00:00:00 +0000

Sometimes a bug report comes in that is simple. Sometimes a bug report comes in that is complex. This is the story of a bug report that looked very simple, but in the end was actually much more complex than I had initially expected. Further, it likely contributed to electrical damage on many deployed moteus boards, which is definitely not something I aim to do! Read on to learn more.

XT90H-M now at mjbots.com

Thu, 16 Jul 2026 00:00:00 +0000

I’ve got another very short post today, a new product announcement, the XT90H-M from AMass:

This is an XT90H-M, which mates to the XT90F-S that was already carried. It does not mate to any mjbots products directly, but can be handy if you are building harnessing in a system.

mjuart

Thu, 25 Jun 2026 00:00:00 +0000

Here’s a small new addition to the mjbots product portfolio, the mjuart - a FT231X breakout board, now available at mjbots.com.

This USB to 3.3V level UART adapter includes appropriate cables to connect to all of the possible auxiliary ports on each moteus controller:

moteus-r4 ABS: A ZH4 to ZH4 cable with RX/TX swapped
aux1: A ZH4 to GH8 cable
aux2: A ZH4 to GH7 cable

The FT231X can communicate without problems at up to 3 Mbps, which lets you capture high rate debug information from a moteus controller. It also works just fine with the yet-to-be-announced UART based control at its default baud rate of 921600 (or up to 3Mbps if you like living on the edge).

Host side SPMSM simulation for regression tests

Thu, 18 Jun 2026 00:00:00 +0000

When developing features for the moteus controller, testing on actual hardware has long been the primary way that new motor control features were validated. That includes “hero” testing on the lab bench, and the hardware-in-the-loop (HIL) dynamometer fixture used to validate each new firmware release.

While those are valuable techniques, dynamometer testing is not something that you can do rapidly, is limited to validating a small number of things at a time, and has a non-zero fraction of false positive failures due to unmodeled effects. To enable more rapid feature development, I wanted to test a lot of what was validated on the dynamometer fixture in a host side simulation. This would provide a lot of benefits:

It could run much faster than real time
100% deterministic
Multiple instances can run in parallel
Agents can use it as success criteria for validating development

Read on to see how it was done:

Limiting the maximum regen power in moteus

Thu, 11 Jun 2026 00:00:00 +0000

When using a servo controller, any time the motor needs to either decelerate or resist an external torque, the controller may “regenerate” energy that has to go somewhere. By default, moteus will apply that energy back to the input bus, potentially charging a battery if that is used as the power source. When the input voltage rises too high, either because the battery impedance is high or because a PSU is as the source, then moteus will apply “flux braking” to dissipate the energy in the windings of the motor instead of allowing the voltage to grow without bounds. This often works great, but in some common scenarios flux braking by itself can be inadequate. In order to operate stably, flux braking need to use a filtered version of the bus voltage. This means that if the bus voltage rises fast enough, the maximum configured voltage can be exceeded before flux braking has had a chance to actually begin dissipating significant energy in the motor.

RLS Orbis SPI support

Thu, 04 Jun 2026 00:00:00 +0000

Hot on the heels of BiSS-C encoder support intended for high end applications, I am excited to announce that moteus now supports the RLS Orbis SPI protocol for lower-end systems as of firmware version 1.0.0.

The RLS Orbis is an absolute magnetic encoder suited for use with diametric ring magnets and can be configured to use a number of different communication protocols. If you have a moteus-n1 or moteus-x1, then the newly released BiSS-C support already lets you communicate with them. However that left out the moteus-c1, which does provide the 5V necessary for an Orbis to function, but does not have a built-in RS422 transceiver.

moteus firmware version 1.0.0!

Thu, 28 May 2026 00:00:00 +0000

The first public version of moteus-r4 was announced way back in 2019. Since that time, there have been many new board variants and innumerable additional features and capabilities. Amazingly, through all of that, the CAN-FD wire protocol has actually remained backwards compatible the entire time! It is still possible to monitor that very first moteus with tview, and to command it using the register protocol with appropriate configuration. Many projects hem and haw about releasing a version 1.0 of their software, justifying breaking things from a users perspective over and over again. Here, we’ve actually maintained nearly complete backwards compatibility despite having a pure time based release versioning scheme.

Moteus performance analysis tool - CLI mode

Thu, 05 Mar 2026 00:00:00 +0000

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.

Native socketcan support for mjcanfd-usb-1x

Thu, 26 Feb 2026 00:00:00 +0000

Since the fdcanusb, and subsequently the mjcanfd-usb-1x, have been released, the only interface they presented to a PC host was a USB CDC (communication class device). That meant they appeared as a modem, on linux as /dev/ttyACMx and on Windows as COMx. Sending and receiving frames was pretty simple using a basic line based protocol.

This works fine as long as you are either using the mjbots tools, or designing a complete custom application. However, if you want to use the adapter with other CAN or CAN-FD based applications on Linux, there wasn’t a whole lot you could do. There was a simple daemon which, with a fair amount of effort, would make the hardware appear as a slcan device, but that was finicky and hard to get working and not terribly reliable.

moteus.move_to and moteus ruckig python example

Thu, 19 Feb 2026 00:00:00 +0000

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.

PWM input support

Thu, 12 Feb 2026 00:00:00 +0000

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:

BiSS-C encoder support

Thu, 05 Feb 2026 00:00:00 +0000

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!

moteus hardware ADC triggering

Thu, 29 Jan 2026 00:00:00 +0000

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.

More stable acceleration limiting

Thu, 22 Jan 2026 00:00:00 +0000

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:

Acceleration instability

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.

Optimizing fast movements

Thu, 08 Jan 2026 00:00:00 +0000

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:

Capturing full rate debug data from moteus

Thu, 01 Jan 2026 00:00:00 +0000

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.

tview logging

Thu, 18 Dec 2025 00:00:00 +0000

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!

More diametric ring magnets at mjbots.com

Thu, 11 Dec 2025 00:00:00 +0000

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:

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