Archives: Moteus

Wait for trajectory completion in tview

As of pypi 0.3.68, tview has gained the ability to delay execution of a compound command until the currently executing trajectory is complete. This can be useful for developing more complex motions that consist of multiple steps.

To use it, just issue a '?[optional_id]' in your command sequence. For instance, to move to position 1 and come to a stop, then move to position 0 when that has completed, you could do:

Debugging moteus calibration failures

When setting up a moteus controller with a new motor, you typically first run the automatic calibration sequence as documented in the reference manual. When your system is working well, that should be all that is necessary to enable moteus to perform accurate FOC based torque control of the motor. Then you can set up basic parameters and tune the position PID control loop. What happens though when the automatic calibration doesn’t work? This post shares the most common failure modes during calibration.

Optimizing moteus command rate

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.

moteus-c1

I’m excited to announce the newest addition to the moteus line of BLDC controllers, the moteus-c1! The moteus-c1 is a smaller, lower power, lower cost version of the moteus-r4 and moteus-n1, but still packs a big punch.

The top of the line performance metrics for the entire moteus lineup now look like:

moteus-c1 moteus-r4 moteus-n1
Input Voltage 10-51V 10-44V 10-54V
Peak Phase Current 20A 100A 100A
Continuous Phase Current 5A / 14A 11A / 22A 9A / 18A
Dimensions 38mm x 38mm 46mm x 53mm 46mm x 46 mm
I/O AUX1 D and E are present as through hole pads. AUX2 is identical to moteus-n1 AUX1: SPI, Hall, ADC AUX2: I2C and UART 3.3V only AUX1 and AUX2 support SPI, UART, Quadrature, Hall, and I2C. 5.5V and 3.3V provided on each connector. I2C pullups are configurable on each connector.
RS422 None None Built-in transceiver for RS422 based encoders
CAN fault tolerance 58V 12V 58V
Price $69 $79 $149

The upshot is that for low current motors where RS422 is not required, it is nearly as capable as the moteus-n1 for less than half the price!

moteus + Arduino

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.

recapturing position and velocity with moteus

Recently I covered a new feature for the moteus brushless controller that improved robustness for velocity control when external torques exceed the maximum allowable control torque. In this post, I’ll cover a feature that can be used for a similar situation in position control, “recapturing position and velocity”.

In some applications, while in position mode, it can make sense to limit the maximum torque during specific periods so that external torques are able to overpower the controller. The most obvious case would be if the maximum torque is set to 0, or the kp and kd scale are set to 0 temporarily. A problem then arises when resuming control, as the “control position” will be wherever it last was, despite the fact that the actual motor have have been dragged by the external torque some distance away. When the torque limit is released, a large transient can develop as the controller tries to instantaneously get back to the old control position.

BIG price improvement for moteus-r4

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.

max_velocity_slip with moteus

The moteus brushless motor controller supports several concepts of operation from within its primary “position” mode, including a velocity mode. As documented in the reference, you can run in that scenario using commands equivalent to the diagnostic mode command:

d pos nan V nan

Where V is the desired velocity. However, as with most control operations, there are a number of edge cases that can be useful to handle. When operating purely in velocity mode, the normal PID constants can be interpreted slightly differently:

Default bandwidths for moteus

moteus has long had both automatically tuned current control bandwidth and a built-in low-pass filter for encoder readings. During calibration, these are usually set with moteus_tool’s --cal-bw-hz option, which specifies the current loop (interchangeably called the torque loop) bandwidth. TLDR is that these heuristics have changed as of pypi 0.3.64, hopefully with only improved behavior. Read on if you want to understand more or if you need to resolve problems with something that changed for the worse.

New Project: Juggling Robot

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.