Exciting news! All the existing moteus controllers in the world now have an upgraded default maximum power and upgraded rated maximum power as of release 2025-03-27! Depending upon the input voltage and PWM rate, sometimes nearly twice the amount. First, check out the comparison table, then the rationale:

	Old default max / rated	New default & rated
moteus-r4	340W / 450W	900W <= 30V, 400W >= 38V
moteus-c1	75W / 100W	250W <= 28V, 150W >= 41V
moteus-n1	340W / 1200W	2kW <= 36V, 1kW >= 44V

Background, why a power limit?

moteus brushless motor controllers drive 3 phase PMSM motors, accepting a DC input voltage, and outputting current to each of the 3 phases of the motor. It does so using MOSFET based switching, which alternately connects each phase to either ground, or the DC positive input. As that switching progresses, charge is either drawn, or replenished into, the onboard bulk capacitors.

This post is part of series examining how low-cost off-axis encoders can be incorporated into a moteus controlled motor system. For the history, see the previous entries: part 1, part 2, part 3, and part 4. We left off after having tuned the bias current trimming of the MA600 in order provide output from the encoder itself. When compared against a reference AksIM-2, that left an error profile that looks like:

In previous iterations of this series (see part 1, part 2, and part 3), I built a breakout board for the MA600 TMR encoder and mounted it in an off axis configuration with a diametrically magnetized 32mm OD ring magnet along with a reference AksIM-2 encoder to compare against. Now we can finally get to the part where we can start looking at what the reported values look like.

For my first experiments, I set up a moteus-n1 with the AksIM-2 as the primary encoder, and the MA600 in motor_position.sources.1 in a slot that was not used for anything. Having done that, I plotted the difference in reported angle between the MA600 and the AksIM-2 through a full revolution below, using the compensate_encoder.py script that is now in the moteus repo in reference mode.

In the previous post, I outlined a possible path to low cost off-axis encoders to be used with the moteus line of brushless controllers. The first step I took was to try and build a minimally sized breakout board that could be used with the MA732/MA702/MA600 line of hall effect angle sensors. You can get these off the shelf, for instance from tinymovr, but I wanted to see if I could make something a bit more compact, and that had the chip close to a board edge so that it could be used for off axis applications.

The moteus line of brushless controllers all have an integrated “on-axis” magnetic encoder. These encoders are designed to allow moteus to sense the position of a motor’s shaft directly, assuming that an appropriate diametrically magnetized sense magnet is attached to the rotating shaft and the moteus is mounted so that its sensor is positioned over the magnet.

This works great for many applications, but what about hollow shaft motors? moteus supports a few encoder types that will work for off axis encoders, most notably is the AksIM-2. This is a high performance off-axis encoder that gives great performance and is manufactured in configurations for a variety of hollow shaft diameters. However, it does have downsides. First, it comes with a commensurate price tag. In single quantities, the AksIM-2 and magnetic code disc are more expensive than an entire moteus brushless motor controller. Second, only the moteus-n1 has the necessary RS422 transceiver integrated into it. All other moteus boards need an external RS422 transceiver.

A permanent magnet motor controller like moteus has to, at the end of the day, apply voltages to the phase wires of a motor in order to induce currents. Those currents generate magnetic fields that push against permanent magnets in the rotor to make the motor move. I’ve looked at parts of this process before, see “Compensating for FET turn-on time”, but in this post we’ll look at an additional technique that can extend the effective modulation depth, thus increasing the maximum speed that a motor can be driven.

We’ve got a new firmware release for the moteus controllers up on github now, 2024-10-29! This update has a few new capabilities, a brief summary is below, while more detailed posts will come in the not too distant future:

MA600 Support: The MA600 from Monolithic Power Systems is an absolute magnetic encoder that uses a TMR (precision tunnel magnetoresistance) sensor. It is much more accurate with less noise than the AS5047P that moteus uses (or the MA732).

TLDR: As of firmware release 2024-05-20 moteus can now report a pretty good estimate of the electrical (and thus mechanical) output power going to the motor. You can get that through all the language binding options or in tview!

Background

Brushless motor controllers like moteus act like step down DC/DC converters. Their input is a higher voltage and low current, while the output to the motor is low voltage and higher current. If working properly, the output current is driven so as to produce torque at the output shaft.

When commanding a moteus controller, many of the registers defined in the reference documentation give explicit semantics when the value is passed as either a floating point NaN value or the “maximally negative integer” for integer encodings. Those that do not specify a meaning for NaN are “undefined” and anything can happen. For the most part, this isn’t a problem, but in one specific case users were repeatedly caught off guard.

Three common registers often set in position mode, (also accessible by the unlabeled first three arguments to “d pos”), are 0x020 “target position”, 0x021 “target velocity”, and 0x025 “maximum torque”. Target position has a defined meaning when set to NaN: the controller assumes that the target position is the current target position, or the sampled position if the controller is not yet in position mode. Maximum torque also has a defined meaning when set to NaN: it then uses the maximum torque as defined by the maximum phase current limit. However, target velocity had no such definition, and in practice when used, resulted in the controller becoming mostly non-functional.

As of release 2023-09-26, moteus controllers can now use CUI AMT21 series encoders for any encoder source. CUI’s AMT21 series encoders are rugged, with resolution up to 14 bits, and since they use RS485 for communication can be located a significant distance from the motor driver if necessary. Setting one up is easy with the moteus-n1, which is what I’ll cover here.

Hardware

The moteus N1 has JST GH-6 connector labeled “RS422” with all the pins necessary to power and communicate with an AMT21. Since the AMT21 is RS485, not RS422, it is required to tie the A and Y pins together and the B and Z pins together. An easy option is to do so in the harness, either by crimping multiple wires into the Molex terminal for the AMT21, or by splicing wires. The desired schematic looks like: