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.

In what probably won’t be the last time, mjbots.com now has a new version of the pi3hat due solely to component shortages!

There are no top-level feature changes versus the previous r4.4. What is different is that the connector for the Raspberry Pi has reverted to the fixed height version that the r4.3 and earlier used, and the IMU is slightly better.

Happy building!

To date, the pi3hat CAN channels only supported CAN properties suitable for use with moteus controllers. Given that’s what most people are using them for, that’s fine. However, there was no real constraint behind that, just laziness.

Thus, I’ve released new firmware for the pi3hat that supports configuring the bitrate, FD-ness, and other properties of all 5 CAN channels.

• https://github.com/mjbots/pi3hat/releases/tag/0.1-20210111-1

Currently only the C++ library exposes the configuration functionality, but it will be easy enough to add to python when someone needs it.