Homepage Knowledgebase GitHub

Motor stalling at any speed

We are working on an AUV with a Myxa controller to run a BlueRobotics T200 thruster (https://bluerobotics.com/store/thrusters/t100-t200-thrusters/t200-thruster/). We are using a custom LiIon battery 4S (600Wh).
We succeed to make it works but for unpredictable reasons, the motor starts to stall at any speed command.

You can find our file parameters below.
20200611_Zubax-Config_4S.yml (1.9 KB)


What does it mean? You are sending different speed setpoint and motor doesn’t spin stably at any setpoint or the motor stalls when the speed exceeds particular value?
I suggest you to perform motor identification first. Maybe, the motor parameters have been changed.
If it doesn’t help try to tune m.flux_linkage as it described in the Quick Start Guide.
As I can see from your plots, the motor doesn’t spin up confidently. It seems like the thruster requires a quite big torque at low speeds. The current is not enough to maintain its rotation. Increase the m.spup_curr_end parameter. You can read more about the spinup tuning in the Quick Start Guide. It would also be nice to set the m.min_current parameter equal to m.spup_curr_end.
Finally, as I can see from the parameters list, the m.voltage_ramp parameter is too small. If you control Myxa in RPM control mode, set it to the maximum value in order not to decrease the bandwidth. The bandwidth in RPM control mode should be constrained by acceleration/deceleration rates and speed controller. As I can see you have set the control mode parameter to RPM control mode in RCPWM interface settings.

I changed the spinup tuning with the parameters from the Quick Start Guide

  • ctl.spinup_durat = 0.5
  • m.spup_curr_begn = 0.5 × m.max_current
  • m.spup_curr_end = 0.05 × m.max_current
    The motor was working normally with Kucher and the navigation software of the AUV (propeller command with PWM). I launched a mission and the motor was running normally. Then I sent some PWM propeller command to see what is the maximum speed and at a moment (the speed was increasing), the motor has stalled. And after that it was stalling at any speed (command with Kucher and PWM).
    Then, I did a motor identification and the motor was running normally during the motor identification but after the motor stalled when I send command with Kucher and PWM.


So, you have stable operation in static mode and unstable operation in dynamics. In dynamics, stability is determined by the bandwidth of the current control loop and the speed controller in the speed (RPM) control mode or by the voltage ramp in the voltage control mode. As far as I know you are using RPM control mode for RCPWM interface. Please try to tune the speed controller as described in the instructions attached. Telega tuning procedure in RPM control mode.pdf (208.4 KB)

We applied your attached document and we still have the same problem (as shown on the video).

Before that, we changed the Mixa controller with a new one with this configuration : config_batterie_4S_new-myxa.yml (1.9 KB)

We launched a guided mission with a speed increasing slowly. Everything runs perfectly as shown in the log (but with a saturation of the controller at the end):

Then, we launched the same mission without change anything and the motor stalled during the mission as shown in the log:

We don’t know what could happened and what the problem is.

With Kucher, we can see that the hardware fault flag is at 1, what is this fault?


Ok, I see that you haven’t followed all recommendations. I’ve corrected a little bit the config file. Please try it. config_batterie_4S_new-myxa_corrections.yml (1.9 KB) Then I’ll give you more recommendations regarding thruster tuning.

The error codes description you can find here. Please attach the screenshot of the Kucher while the fault occures.

I have uploaded your configuration file and it works fine (we have understood that in RPM mode it is not working well and in Voltage Control Mode it is fine).
Thanks for your great help :+1:.

For the hardware fault flag, I do not have an error code:


On the screenshot above there’s no Faults because the Fault indicator has green check mark. The number just indicates the number of faults occurred since the firmware has started.

OK, thank you for this information.