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.

Probably one of the most frequently asked questions in the mjbots Discord is “how fast can I send new commands to moteus”, or “how fast can I read the status from moteus”. That may be because you want to perform torque based control in your application and require high bandwidth, or just because you have a high torque to inertia ratio system that reacts on very short time-scales. No matter the reason, the principles that control the maximum rate you can send updates are the same.

The pi3hat repository, in addition to hosting a library for sending raw CAN frames using the pi3hat, has long had example source code demonstrating how to use that to communicate with a moteus controller. Recently however, C++ bindings were officially added to the primary moteus repository, that provide a more consistent, flexible and complete interface to moteus controllers. I’ve gone ahead and updated the pi3hat library to take advantage of that new interface, so now the pi3hat can be treated as just another transport like the fdcanusb.

I’m excited to announce a minor upgrade to the mjbots pi3hat product line, the pi3hat r4.5!

This has a few upgrades over the old r4.4b:

• The input voltage range is expanded from 8-44V to 8-54V.

• All CAN-FD ports have +-58V bus fault protection, up from +-12V.

• 0.1" pin headers are present for the Raspberry Pi I2C, UART, and for 3.3V and 5V outputs

Check it out at mjbots.com today!

Now that 64 bit Raspberry Pi OS is a real thing, I finally got around to updating the pi3hat libraries. Now, as of pypi 0.3.20, you can use the pi3hat library to run console only or graphical tview on the most recent Raspberry Pi OS!

There’s an updated release out for the mjbots pi3hat which features a useful bug fix and a minor feature.

First, the configuration of automatic retransmission was broken in several ways. The symptoms for previous versions would be that any attempt to change the CAN configuration for a bus would result in all channels attached to that controller having auto-retransmit turned off. Since it was by default on, that would typically result in a decrease in transmission reliability, and in some particular cases with arbitration conflicts, could result in frequent packet loss. Fixing this requires updating both the firmware on the device and the C++ and python libraries. Fortunately, this would only come up if you were communicating with non-moteus devices using the pi3hat, which likely isn’t that common.

People over in the mjbots discord frequently ask about how to build reliable XT30 cables, so I made a short video describing how I go about it!

The moteus controller, communicates exclusively over CAN-FD for command, telemetry, and diagnostics. It will accept either standard or extended frames, and until now, the ID format in terms of bits looked like the following:

33333222222221111111100000000
43210765432107654321076543210
XXXXXXXXXXXXXQSSSSSSSDDDDDDDD

Where:

• X: Don’t care
• Q: 1 for query, 0 for no query
• S: source ID
• D: destination ID

If the lower 8 bits matched the configured ID, all the X bits would be completely ignored and moteus would accept the CAN message as if it were destined for itself. This may not be super desirable, as it consumes nearly all of the available CAN-FD addressing space.

The pi3hat, among other things has 5 CAN-FD ports. You can use them to drive a lot of moteus servos, but they are perfectly fine CAN-FD ports generally. The C++ library has always been able to send and receive arbitrary frames (and recently at arbitrary bitrates), but the python interface was lacking, only exposing a portion of this functionality.

As of version 0.3.11, the python library (pip3 install moteus-pi3hat) now exposes everything you need to be able to send and receive arbitrary CAN frames from any of the ports, as well as configure all the timing options for waiting for responses from slave devices.