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.

Previously, the only suitable workaround was to stop the motor driver entirely by issuing a “stop” command, then re-starting control by sending a new position mode command. This works, but causes a moderate delay before control can be re-established, as moteus executes a self calibration procedure of several milliseconds before resuming control.

As of firmware release 2024-01-06, there is now a new command, “recapture position and velocity”, which can be used in these circumstances. It forces the control position and control velocity to match the measured values without exiting position mode. It can be sent using all the normal methods, i.e. through the diagnostic protocol with tview, or the register protocol with raw CAN frames, the python library or C++ library. A typical operation might look like:

initially start control by sending position mode command

after some time, set maximum torque to 0 to let the motor free-wheel

an external torque drags the motor far from its initial position

send the "recapture position and velocity" command

immediately after send a position mode command with nonzero max torque

Assuming that a velocity limit is in place, the following plot shows what the control position and actual position would look like with no mitigations in place, and with using the new recapture command.

For reference, the different means of commanding this look like:

• Diagnostic channel: d recapture
• Python: await c.set_recapture_position_velocity()
• C++: c.SetRecapturePositionVelocity()

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:

• servo.pid_position.kd – this is effectively the proportional constant in velocity control
• servo.pid_position.kp – this is effectively the integrative constant in velocity control
• servo.max_position_slip – this is the “anti-windup” term for the integral term

If an external torque is applied that exceeds the maximum torque that the system is capable of generating for an extended period of time, then undesired transients can emerge. In that case, the actual velocity can diverge arbitrarily from the commanded velocity. For instance, if a drag force were applied that exceeded the maximum commanded torque, the system could stop. If that external force is released, then there is a large discrepancy between the actual and commanded velocity, which results in a non-ideal transient response that may overshoot or oscillate.

The normal mechanism to enforce a slew rate for the commanded velocity in moteus is to use the trajectory velocity limit, either through configuration with servo.accel_limit, or by specifying a per-command acceleration limit. That limits the rate of change in velocity command, but does nothing in the case where an external force causes the controller to diverge.

As of release 2024-01-06, moteus now supports a new configuration option to help resolve this:

servo.max_velocity_slip

Like servo.max_position_slip, this limits the amount that the control velocity can diverge from the measured velocity. If set appropriately, it will result in a motor using the configured acceleration limit if an external torque is released, rather than attempting to instantaneously restore the commanded velocity. Selecting the value for this configuration does require some care. It must be significantly larger than the expected noise in velocity measurements, yet small enough to result in an effective clamping during expected transients.

The following plot shows an instance where an external torque causes the actual velocity to temporarily drop to 0. The left plots demonstrate what will happen if servo.max_velocity_slip is “NaN”, i.e. disabled, and the right plots show what will happen if it is set to 2 Hz. As can be seen, limiting the delta between the control and actual velocity can result in decreased overshoot or otherwise undesired transients when external torques are released.

This video gives a quick demonstration of the with and without as well.

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.

Overview

The encoder bandwidth selected, modulo some heuristics, was usually twice that of the current loop. This was a quick and dirty heuristic which worked alright for a long time, but didn’t have much of a basis behind it. While cleaning up calibration for gimbal-style motors, I decided to take another pass at this as well.

The two filters, current and encoder, serve different but inter-related purposes. The encoder filter, maybe obviously filters readings from the primary position sensor. Movement that is higher bandwidth than the filter will be not observable by moteus. Thus, if the platform is capable of movement at bandwidths higher than the filter, the control loop will be operating on incorrect data and will usually become unstable. However, as the bandwidth is increased, inherent noise from the encoder will result in the controller producing audible noise as it attempts to correct for the “noise” in the measurement in position and velocity.

The current loop similarly controls how quickly the controller can change the torque it is commanding. It is similar to the encoder filter in that higher cutoff values (i.e. larger bandwidth) results in higher performance but more audible noise. This should typically be around the same as the encoder filter, as most of the changes in the desired torque will come from encoder readings. However, the commanded torque (or position/velocity) can also change at potentially high rates in response to application demands, and thus there may be a need for it to be higher than the encoder filter.

Diagnosing inappropriate bandwidth

If the bandwidth is too low for either filter, performance and stability will degrade. For either filter, oscillation or vibration may result. Commanded movements may overshoot their intended target, especially at relatively high accelerations. Commanded torque will not track accurately.

If the bandwidth is too high for either filter, the primary downside is audible noise. If the limits within moteus_tool are circumvented, the filters themselves may become unstable, resulting in erroneous operation.

A special case of problems with a too-high encoder bandwidth occurs with encoders of extremely low resolution. The most common case here are using hall effects as the output position sensor. In this case, too high of a bandwidth will result in poor velocity sensing, and thus poor velocity and position control. In those applications, the range of usable encoder bandwidths may be very small for velocity or position control (although for torque control going higher is always fine).

Updated behavior

To better balance these factors, as of pypi 0.3.64, moteus_tool --calibrate is changing things in a few ways:

1. The biggest, is that it will now default to set the encoder bandwidth to be equal to the torque bandwidth rather than be equal to twice it. For most users, the only result of this is that motors will have less audible noise during operation. In some cases, the lower encoder bandwidth may result in instability or oscillation, but given that the torque bandwidth was already that low, this is unlikely.

2. Another change is with respect to high inductance motors. The most common types of high inductance motors are gimbal motors and hoverboard motors. Previously, a different heuristic would artificially limit the torque bandwidth to a low value. This has since been deemed unnecessary, so now these motors will calibrate with a larger torque bandwidth by default. For gimbal motors, that means they may become usable even without resorting to servo.voltage_mode_control (which bypasses the torque loop entirely).

3. Yet another change relates to hoverboard motors. There had been a heuristic to attempt to limit encoder bandwidth on all high-inductance motors. That inappropriately caught gimbal motors. Now this limit is only applied if hall effect sensors are used to measure output position, which is the only time it would be useful.

4. Finally, no bandwidths are allowed to be greater than 1/30th of the control update rate. With the default 30kHz control rate, that permits bandwidth up to 1kHz for both torque and encoder. At the lowest currently supported rate of 15kHz, that falls to 500Hz.