mjbots blog

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!

Fitting moteus motor saturation models

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

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!

moteus hardware CAN ID filtering

Thu, 20 Nov 2025 00:00:00 +0000

Recent improvements to the mjcanfd-usb-1x and the pi3hat were stepping stones to improved reliability for long daisy chains of moteus controllers. Another step in that process is the feature I’ll describe here, hardware CAN ID filtering in the moteus firmware. Let’s talk about how things used to work, what the problems were and how this new feature helps.

moteus_tool --read

Thu, 13 Nov 2025 00:00:00 +0000

moteus_tool has long served as the primary interface to moteus controllers from the command line for provisioning and diagnostics, especially so when used in headless environments where running a graphical tool like tview is not an option. As anyone who has debugged a moteus system from the command line can attest to, finding the contents of diagnostic stream channels is annoying at best and that is only if you know how to do it. In short, you have to use --console, and then type some undocumented text incantations .

Thus a new feature in moteus_tool: the --read CHANNEL command line flag, which reads a single instance of an arbitrary diagnostic channel from the device, then prints it to the console as JSON formatted structured data. Let’s check out what that looks like:

tview python console

Thu, 06 Nov 2025 00:00:00 +0000

The tview graphical monitoring application has been getting a lot of work lately. First was support for enumerating controllers by UUID, then monitoring faults and graphically highlighting them and then decoding textual values for fault codes. I’m excited to announce yet another improvement for tview, this one on the larger side: an interactive python REPL (read-evaluate-print-loop)! Available now in pypi moteus-gui v0.3.93.

The bottom console now has two tabs, the first and default remains the diagnostic console, where you can see what diagnostic messages the devices are emitting and send diagnostic channel commands directly to connected devices. The new, second tab, is labeled “Python” and provides access to a fully functional Python evaluation environment with full access to the moteus python library, including asynchronous operations.

Read on to see how to use it.

New moteus documentation page

Thu, 30 Oct 2025 00:00:00 +0000

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.

Device fault text decoding

Thu, 23 Oct 2025 00:00:00 +0000

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.

Device fault monitoring in tview

Thu, 16 Oct 2025 00:00:00 +0000

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:

Issue a totally reasonable command like d pos nan 0 nan to command the motor to hold position
Observe an OK come back
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.

UUID based addressing and python multiple device support

Thu, 09 Oct 2025 00:00:00 +0000

I’m excited to announce a significant usability improvement for all moteus controllers, command line tools and the python library! If your moteus controllers are on firmware version 2025-09-20 or newer and your moteus client tools are at 0.3.91 or newer, (and if you are using a pi3hat, it is on firmware 2025-09-20 or newer) there are some big improvements that you transparently get:

You no longer need to assign unique CAN IDs before daisy chaining controllers
The python transport lets client programs transparently operate across multiple CAN-FD interfaces simultaneously
tview will automatically open all controllers attached to all CAN-FD interfaces on the computer

Let’s dig into what this looks like from the command line, tview and what the practical constraints are.

pi3hat firmware release 2025-09-20

Thu, 02 Oct 2025 00:00:00 +0000

It has been a minute since there has been a pi3hat firmware release, but we have a new one out now, that fixes a longtime usability issue with the pi3hat as well as improves its ability to drive busses with many devices. The release, 2025-09-20 can be found on github with the source and firmware elf. If you’re not running into problems, there is no real need to upgrade, but read on to see if it is something you might be interested in.