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.

In the initial announcement of the new moteus C++ library, the only transport that was supported out of the box was for the mjbots fdcanusb. That has now been upgraded so that Linux socketcan devices are supported out of the box as well!

You need version mjbots/moteus e33f188b035c7 or newer and for simple cases, no changes to source code are required at all.

For a long time, moteus has had a python library, that lets most people quickly develop motion control applications. However, python is not a suitable solution in every domain. Embedded systems often either don’t have access to python, or cannot tolerate the resource or timing penalties it imposes. In some cases, managing interoperability between python asyncio and systems using legacy python IO like ROS can be challenging. For others, python is just not familiar. The new C++ client library included in the moteus repository is designed to handle all of these scenarios with a flexible, yet ergonomic approach that makes simple things simple, and complex things possible.

For a while now moteus has had the ability to configure what action takes place upon a CAN message watchdog timeout during position control mode. If configured with ['servo.default_timeout_s'](https://github.com/mjbots/moteus/blob/main/docs/reference.md#servodefault_timeout_s) moteus requires that CAN messages be sent at a regular rate. If ever a message is delayed by more than the timeout period, the mode switches in a latching manner to the “timeout” mode, where a special action is undertaken. This is configured with ’servo.timeout_mode’ in tview, and as of firmware release 2023-07-25 the available values are as follows:

With the release of more flexible I/O support, the moteus controller auxiliary port can be used to monitor encoders using an onboard UART. Now, with firmware release 2023-02-01, those UART pins can be used as an arbitrary logic level serial port controlled by the application! Let’s see how to use it below.

First, you will need to look at the pin configuration table to find pins that support UART functionality, and configure them as UART in the “aux?.pins” configuration tree. Next, “aux?.uart.mode” should be set to “kTunnel”, along with the desired baud rate. That’s it on the configuration front.

The moteus controller, when it implements its control algorithms, uses the internal RC oscillator of the onboard STM32G4 microcontroller to calculate things like velocity and to advance position over time. Typically, this is accurate to within 0.5% which is more than sufficient for most applications. However, there are cases where it does matter.

One common case is when multiple moteus controllers are operated together, and either the relative velocities of the controllers must match closely, or the time required to complete long trajectories must match closely. For example, if a trajectory would take 100s to complete, then a 0.5% difference in clock rate between two controllers would result in one completing 0.5s before the other.

One of the oldest requested features for the moteus brushless controller has been a form of trajectory control beyond constant velocity trajectories. For most applications this is not an actual deal-breaker, because arbitrary trajectories can be approximated by piecewise linear constant velocity trajectories in the application layer. However, for many people, that is big hurdle to jump over to start with, and for some, it can actually limit application effectiveness because a fair amount of CAN bandwidth is required to achieve the high rate control necessary for smooth motion.

Being a switch mode 3 phase motor driver, the moteus controller changes the current flowing through the phases of a motor by rapidly switching the phase terminals between the positive input voltage and the input ground. The control of this switching is denoted “pulse width modulation”, or PWM for short. To date, the rate at which it has switched has been fixed in firmware at 40kHz. As of release 2022-03-12, this can now be altered anywhere between 15kHz and 60kHz to better optimize peak power capability, control bandwidth, maximum speed, and heat generation.

With the r4.8 release of moteus, a not-yet-announced feature was included – the ability to have an off-board primary encoder! It didn’t get announced at the time, because the connectors necessary to populate the board were not obtainable. In fact, that is still the case, but I’ve located a substitute part which works well enough, so here we go!

Theory

The moteus controller uses an absolute magnetic encoder to determine the relationship between the rotor and stator of the motor at each given instant. That allows it to produce torque in the motor at any speed, from standstill to the maximum possible speed. Until now, the only magnetic encoder that was supported is the one mounted to the backside of the board. This is largely acceptable, as moteus is intended to be used in integrated applications.

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!