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.

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.

The moteus line of brushless motor controllers currently require a CAN-FD host to send commands in order to actually execute a motion profile. moteus has long provided a python library that can be used on desktop operating systems to send commands and parse responses, and recently added a C++ one as well. Next up, and described in this post, is a library for Arduino which provides the ability to command and monitor brushless motors using moteus motor controllers.

I’m excited to announce a big price drop for the moteus-r4.11 controller for both single units and in volume!

Quantity	Old	New
1-10	$104	$79
10-99	$99	$75
100-499	$94	$71

We’ve been scaling up production, which enables these reductions of about 25% across the board. moteus-r4 is now by far the most cost effective motor driver with integrated encoder in its class. Here’s a quick comparison with similar products:

	ODRIVE S1	Tinymover R5.2	moteus-r4.11
Voltage	12-50.5V	12-38V	10-44V
Continuous phase current	40A	Not specified	22A
Peak current	80A	40A	100A
Dimensions	66mm x 50mm	40mm x 36mm	53mm x 46mm
Open source	Proprietary FW and HW	GPL FW, Proprietary HW	Apache 2.0 FW and HW
Price	$149	$108	$79

I personally am looking forward to all the new projects that these lower prices enable! Check it out below or join the mjbots Discord to chat and get some ideas for how you can use a moteus-r4.

I’ve been looking for a new motor control project to tackle that is both interesting, and a bit more unique than another Ascento clone. Looking around, I was surprised at the current paucity of robots capable of more advanced juggling feats. There are quite a few that can manage 3 balls, and nearly none I’ve found that can manage more, with the exception of Nathan Peterson’s inclined ball roller. I figure that I have access to lots of factory second moteus controllers, which are capable of quite demanding control applications, so I should be able to put something together.

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.