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!

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 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:

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.

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.

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.

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:

1. You no longer need to assign unique CAN IDs before daisy chaining controllers
2. The python transport lets client programs transparently operate across multiple CAN-FD interfaces simultaneously
3. 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.

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.

It seems that development of the mjcanfd-usb-1x and fdcanusb comes in spurts! After more than a year of silence, but shortly after announcing a new firmware with support for customizable sample points, we have a new firmware release with some exciting improvements, 2025-09-19 on github! The short is that the mjcanfd-usb-1x is now faster and able to successfully drive longer chains of controllers in a high performance pipelined mode. Read on for more details: