In the last post, I covered the goals behind more flexible I/O support in the moteus brushless controller. This time, I’ll start to cover the configuration model that I implemented to make that support work. It is broken up into 3 distinct phases, auxiliary ports, sources, and sinks.

Auxiliary port pin configuration

To begin with, the available connectors and external pins on moteus are organized into “auxiliary ports”. For the moteus r4.3/4.5/4.8/4.11, the correspondence is that the external primary encoder connector, if present (r4.8 and newer), is “auxiliary port 1”. The ABS port and some on-board debug pads are “auxiliary port 2”. For each port, there are two levels of configuration, at the pin level and the function level.

The moteus controller, being a brushless servo drive, needs to use encoders to measure things like how the rotor is positioned relative the stator, and possibly output shafts that have passed through a reducing stage. The support for this has gradually expanded over time, but is still relatively limited as far as those things go. The available options are:

• Primary encoder (used for commutation)
  • The onboard AS5047P
  • An external AS5047P
• Auxiliary encoder (optional, for measuring the output shaft)
  • I2C AS5048A
  • I2C AS5600

However, the moteus hardware has always been capable of more, both because the processor is a very capable one, and the exposed IO pins are relatively flexible. While looking at some future designs that incorporate even more IO options, I decided it was time to update the firmware to finally start taking advantage of that flexibility.

Here’s yet another update to the moteus line, moteus r4.11!

r4.11 is electrically, mechanically, and software compatible with r4.3, r4.5, and r4.8.

This revision supports two alternate footprints for the CAN-FD transceiver to better support component availability and refines the power stage for the DRV8353 gate driver. moteus r4.8 was the first version to use the DRV8353 because of, once again, component availability issues. However, it was developed on a very abbreviated schedule. With r4.11 the EMI is much improved over r4.8 and r4.5, and the efficiency is much better than r4.8 at all input voltages and PWM frequencies.

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.

The most recent moteus firmware release, 2021-12-03, added not one, but two new control modes for less common applications. Previously, mentioned was the “voltage_control_mode” for using gimbal style high resistance motors without changing the sense resistors. In this post, I’ll describe a similarly named, but very different mode “fixed voltage mode” for operating brushless motors as if they were a stepper motor.

For some applications, you don’t care about torque control, or about power consumption at all. Traditionally you would use a stepper motor in those applications, with a correspondingly less expensive stepper motor driver. However, in some cases you may still want to have high rate trajectory control, CAN based telemetry, or have already standardized on moteus controllers for other moving parts of your solution. There are two new options that can be used in such situations:

The moteus brushless controller can drive many motors out of the box, but until now it has been challenging to use with gimbal style brushless motors. They are wound with thin wire so that they have a very high winding resistance, and thus can be driven by inexpensive low current controllers. Using something like moteus with a gimbal motor isn’t absolutely necessary, but does give benefits in terms of high performance trajectory tracking and torque control.

The initial implementation of auxiliary encoders for moteus supported exactly one encoder, the AS5048B. The hardware can support any I2C based encoder, so supporting additional encoders has always been on the TODO list.

I’m excited to announce, that as of firmware release 2021-12-03, AS5600 encoders are now supported as well. They are a lot cheaper than the AS5048 as they have a much lower update rate and resolution, but that isn’t necessarily a problem if it is only used to disambiguate a modest gear reduction.

To use the moteus brushless controller with a motor, you first have to calibrate it with moteus_tool (for history, see “Encoder autocalibration” and “Auto-tuning current control loops”). This calibration process is primarily used to measure the mapping between electrical phases and the encoder, but as a secondary parameters also measures the winding resistance and Kv of the motor and determines the parameters necessary to set the current control bandwidth.

Motivation

To date, this process can be used with any motor, but making it work can involve fiddling with a number of inscrutably named command line parameters to moteus_tool. --cal-power, --cal-voltage, and --cal-speed are all there, however they don’t really do what you think based on their name, but it is necessary to adjust them to make many motors work.