Tag Archives: moteus_r48

Voltage mode control for gimbal motors

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 problem

The primary challenge when using moteus with high winding resistance motors is the mechanism moteus uses to sense current through the motor phases. It has a set of 3 current sense shunts, basically resistors, that have a small voltage induced across them proportional to the amount of current flowing. When commanding a specific current, moteus continually adjusts the voltage on each of the phase windings until the desired current is achieved. These resistors are sized so that moteus has reasonable resolution up to its 100A maximum current rating. When used with a motor that has a maximum current of 1A though, almost all of this resolution is wasted.

In the past I have replaced the sense resistors on moteus boards in order to drive gimbal motors. That is the optimal solution, as it allows moteus to continue to sense the current through the windings and provide accurate torque control. But not everyone is set up to perform surface mount soldering, and accurate torque control at all speeds and temperatures is not required in many applications.

Voltage mode control

As of release 2021-12-03, moteus now has a new configurable option, called “voltage_mode_control”. In this mode, torque commands no longer use the current sense resistors for feedback. Instead, they use the calibrated phase resistance of the motor to derive what voltage would be necessary to achieve a given torque.

The downsides of this approach are that there are many factors that will make the mechanical output torque not match what was intended. For instance, the back EMF if the motor is moving at non-zero velocity, changes in the winding resistance due to temperature, or inductive coupling between the quadrature frames at non-zero velocity. All of these factors will reduce the accuracy of the torque command, so that the mechanical torque output will not match what was commanded. However, for many applications, the motor is not spinning quickly and precise torque control is not required.

Since this control mode takes effect only at the end of the normal moteus control loop, it means that all of the “position” mode control works as before. Thus the constant velocity mode, stop position, and the “within” mode can all be used without regard to whether the controlled motor is running in the normal “current mode control” mode, or in the new “voltage mode control”.

Results

With the new moteus_tool calibration mechanism, this means that gimbal motors can be used in a basic fashion out of the box with moteus by tweaking only a single configurable value: servo.voltage_control_mode. Here’s a video showing how that works with a real motor.

AS5600 support for moteus auxiliary encoders

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.

I tested this using an AS5600 evaluation board available from digikey:

Improved moteus_tool calibration

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.

I went to address this and make the calibration process more robust across a range of motor types, from small high speed motors, to large low Kv ones, high winding resistance, and low winding resistance. All of these can now be handled with mostly no additional options required.

The new process

In the new world, with no additional options, moteus_tool gradually eases up the voltage applied when measuring resistance and when measuring speed, so that it can be safely used with many motors with no additional tweaks. The power expended in the windings is limited to roughly 5W, which is about the only remaining necessary configurable parameter. You’d only need to change that for a very small motor for which 5W would unnecessarily heat it up.

The existing parameters all get new names which more precisely describe what they do. You rarely need to specify any of them anymore, but you can if for some reason you don’t want to trust the auto-detection mechanism.

NewOldWhat it does?
--cal-ll-encoder-voltage--cal-powerThe voltage used when spinning the motor open loop for encoder calibration.
--cal-ll-encoder-speed--cal-speedSpeed in electrical revolutions per second when spinning the motor open loop for encoder calibration.
--cal-ll-resistance-voltage--cal-voltageThe voltage used when measuring the winding resistance.
--cal-ll-kv-voltage--cal-kv-voltageThe voltage used when measuring the Kv parameter.
--cal-motor-powerThis new parameter controls how much power is dissipated in the windings when performing the encoder and inductance calibration with a default of 5W.
--cal-motor-speedThis new parameter controls how fast the motor is spun when measuring Kv with a default of 6Hz.

The old parameter names will continue to work for now and just emit a deprecation warning. Even so, the new parameters should now only very rarely be needed, as every motor I have tested works fine without specifying anything at all.

How to get it?

Just update your moteus python package to at least 0.3.30 and you’ll get all the new features in moteus_tool!

pip3 install --upgrade moteus

moteus firmware release 2021-09-19

This new release makes minor improvements to support for r4.8 moteus boards, notably it makes the Kv and winding resistance calculation more closely match that measured by r4.5 and decreases audible noise when controlling to 0 current or torque.

Get it from github: moteus 2021-09-19

Note, this does require a new version of moteus_tool to be able to flash over CAN, version 0.3.29. You can get it from pypi using any of the normal pip3 methods: https://pypi.org/project/moteus/

Compensating for FET turn-on time

A motor driver like moteus switches power to the phases of a brushless motor using a set of 6 (or possibly more), MOSFETs. The typical topology involves 3 high side N channel MOSFETs and 3 low side N channel MOSFETs arranged in 3 half bridges like this:

(example 3 half-bridge from DRV8353 reference manual)

Since the gates of these FETs need to be driven with potentially high voltages, and you never want the high side and low side to be on at the same time, typically a gate driver is used. For the moteus r4.5 and earlier controllers, the DRV8323 driver from Texas Instruments is what performs this function. This driver lets you configure the drive current for each of the gates for both operations, charging up the gate and discharging it. For high power drive systems, charging up or discharging the gate too fast can result in undesired transients like accidentally switching the other FET on due to capacitive coupling, or inductive ringing as the current starts moving through the FET instead of the body diode. If the gate charges too slowly, then the FET spends much of its time not fully on, which increases power dissipation in the FETs.

For the purposes of this write-up, this means that the FETs do not turn on or off instantly, and the turn-on time can differ from the turn-off time.

Control structure with PWM mapping shown

One of the lowest levels of control in moteus accepts a set of desired voltages on each of the 3 phases, and then selects a PWM duty cycle for the 3 phases which attempts to achieve those voltages. For most control purposes this mapping isn’t too critical, as usually it is driven by an outer current loop, which selects these values to try and achieve a desired phase current. Thus any non-linearities are mostly washed out, just reducing the control performance a bit. The times it is most important is during motor calibration when a fixed voltage waveform is applied for spinning the motor, and when the phase resistance and inductance of the motor are estimated.

To date, that function has used a relatively simple model that treats the 3 phases independently. For each phase, the voltage is mapped to a PWM using a piecewise linear approximation with two segments. This works reasonably well on the r4.5, and gets the resistance and inductive measurements into a usable territory.

Problems brewing

As a consequence of the global semiconductor apocalypse, I’m working on a new version of the moteus controller that uses a gate driver which it was possible to purchase with less than a year lead time. Unfortunately, it is more sensitive to failure induced by ringing than the DRV8323 was. Because of the abbreviated design timeframe, I left the power stage of the r4.5 alone when making this switch, and it had a fair amount of ringing when using the drive currents it is configured with by default. So, for the new board, it needs to be run with much slower gate drive waveforms than the r4.5 board could achieve.

Using the lower current results in a very distorted mapping between PWM and voltage on the phase terminals, such that calibration wouldn’t complete and measuring the phase resistance was not practical. You can get an idea of the problem by looking at the plot below of phase current during the motor calibration phase. The driving voltage is a sine wave, and the current is supposed to be a sine wave also. Because of the additional distortion, low voltage commands result in nearly no actual current production and there is a large undesired waveform when the three phases are active, but at different levels.

Thankfully current control mostly worked, although it likely suffered from degraded performance at small currents. Despite that, not being able to calibrate is a big deal, so I had to take another look at this control step to make it able to handle the larger non-linearity.

Quantifying the problem

I didn’t necessarily want to try and model the gate drive at a more detailed level to understand this, to tackled the quantification problem by brute force. I wrote a simple tool which commanded a fixed PWM on the A phase, and then did a 2D sweep over the B and C phases in a region where my power supply could provide sufficient current without undue heating. The plots of the B, and C currents as 3D surfaces are shown below (the A current can be found from those two currents).

B and C phase current vs PWM

I think numerically inverted that mapping, to determine the necessary B and C pwm values to achieve a given B and C phase current.

The C phase plot looked the same just mirrored. Notably, this has two distinct regions. There is a region which extends to infinity where the command B is related to the desired B 1 to 1 with a fixed offset. However, that region only seems to exist beyond a line that is related to the C command. On the other side of that line, the fixed offset is no longer required. I did a rough curve fit to this, which looks like:

In the above plot, the sampled data is now faded out, and the simple surface fit is fully saturated. It works plenty well, and is controlled by 2 parameters as before (since the dividing line between the two regimes seems to not be something that is likely to need to be configured).

Results

I reworked the mapping to always operate in terms of a B and C phase that are larger than the A phase, then shift things back to the correct phase and balance afterwards. That way this correction surface could be applied as is.

This new technique gives much better low-voltage performance, especially when more than one phase is active and when larger amounts of compensation are required. Here’s a plot showing the current waveform during a sinusoidal calibration sweep.

Comparison of PWM compensation methods

With the r4.5 board, you can see the low voltage performance improve a fair amount. With the newer r4.8 board and its higher required compensation, the improvement is dramatic.

moteus r4.8

I’m excited to announce the release of moteus r4.8!

Due to the ongoing semiconductor apocalypse, this minor release uses some alternate components which were easier to source. It remains compatible with the r4.5 and r4.3 both electrically, mechanically, and with firmware.

For now, the biggest win is that the board and the devkit are actually in stock!

A secondary win is that external primary encoders are now supported, via an unpopulated connector pad on the backside of the board. I’ll write up more about that in a later post.

Good luck building!