ESC cuts out on high RPM
-
Hi there,
we are using a VOXL 2 Mini along with the Mini ESC and T-Motor F1404 2900KV Motors with GF-3028-3 propellers.
After calibrating, when running the ESC with the "--power 100" flag, the RPM reports to about 35200 rpm. In the ESC config, we have set the maximum RPM to around 36000 and the max_rpm_delta to 20000 to avoid cut outs.
In PX4, we have set the maximum RPM to 35000.But when spinning the motors to a high throttle, the ESCs begin to cut out and the motors try to restart spinning. The cut outs seem to happen around an indicated RPM of ~32000.
When setting the limit in PX4 to exactly 32000, everything works fine, except that there is a lot less thrust availabe. it almost seems as the VOXL-ESC is kind of limited to that RPM, even when changing the config file.Our ESC Config is posted at the end of this post.
But there is also one other thing we notices (maybe it could be important):
The indicated RPM value on the VOXL-ESC does not seem to be real. For example, our motor was bench tested in our lab with a maximum value of 31300 RPM at the above configuration. Also, when comparing the thrust (in grams) at a specific RPM on the bench with the same RPM setting via ./voxl-esc-spin.py --rpm, the thrust is much lower on the VOXL-ESC than on the bench at the same indicated RPM. Therefore the RPM tracking on the VOXL-ESC seems not to be working right. I believe that our ESC configuration is right, but please double check.Any help would be highly appreachiated since we want to finalize prototyping and start production soon.
Best regards
TomESC Config for T-Motor F1404 2900KV with GF-3028-3:
<EscParameters> <IdParams> <param name="id" value="127"/> <!-- 0-7 .. 127 means use hardware ID pins to read ID--> <param name="dir" value="2"/> <!-- 0=fwd, 1=rev, 2=fwd id-based, 3=rev id-based --> </IdParams> <UartParams> <param name="protocol_version" value="2"/> <!-- reserved for future use --> <param name="input_mode" value="0"/> <!-- reserved for future use --> <param name="baud_rate" value="2000000"/> <!-- communication bit rate --> <param name="char_timeout_ns" value="0"/> <!-- not used --> <param name="cmd_timeout_ns" value="100000000"/> <!-- timeout for incoming commands before ESC will stop the motor --> </UartParams> <TuneParams> <param name="pwm_frequency" value="48000"/> <!-- switching freqency of PWM signal going to motors. 24Khz and 48Khz are only options for now --> <param name="vbat_nominal_mv" value="14800"/> <!-- used for sanity checking and limiting of voltage-dependent funcions --> <param name="num_cycles_per_rev" value="6"/> <!-- number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm --> <param name="min_rpm" value="5000"/> <!-- minimum RPM that will be attempted, otherwise capped --> <param name="max_rpm" value="36000"/> <!-- maximum RPM that will be attempted, otherwise capped --> <param name="min_pwm" value="50"/> <!-- cap for minimum power to be ever applied. max is 999 --> <param name="max_pwm" value="999"/> <!-- cap for maximum power to be ever applied. max is 999 --> <param name="pwm_vs_rpm_curve_a0" value="202.34228349901161"/> <!-- this is actually motor_voltage vs rpm curve.. using legacy naming --> <param name="pwm_vs_rpm_curve_a1" value="0.32139836115838644"/> <param name="pwm_vs_rpm_curve_a2" value="3.1167552427764777e-06"/> <param name="kp" value="100"/> <!-- RPM controller proportional gain --> <param name="ki" value="30"/> <!-- RPM controller proportional gain --> <param name="max_kpe" value="300"/> <!-- maximum proportional erorr term (max is 999) --> <param name="max_kie" value="100"/> <!-- maximum integral error term (max is 999) --> <param name="max_rpm_delta" value="20000"/> <!-- cap for maximum rpm error used in RPM controller --> <param name="spinup_type" value="1"/> <!-- 0: traditional, 1: sinusoidal --> <param name="spinup_power" value="70"/> <!-- power used to during spin-up procedure --> <param name="latch_power" value="80"/> <!-- power used during latching stage of spin-up (out of 999)--> <param name="spinup_power_ramp" value="8"/> <!-- it will take ( 4096 / (spinup_power_ramp*10000) ) seconds to ramp sinusoidal start-up power from 0 to spinup_power --> <param name="spinup_rpm_target" value="5000"/> <!-- Desired RPM at the end of the sinusoidal spin-up procedure --> <param name="spinup_time_ms" value="1000"/> <!-- Duration of the sinusoidal spin-up procedure --> <param name="spinup_bemf_comp" value="1"/> <!-- 0: disable, 1:enable back-emf compensation in sinusoidal spin-up procedure --> <param name="motor_kv" value="2900"/> <!-- kV value of the motor. used in back-emf compensation during spin-up --> <param name="min_num_cross_for_closed_loop" value="100"/> <!-- exit latching mode of fixed power after this number of zero crossings --> <param name="protection_stall_check_rpm" value="1000"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor --> <param name="brake_to_stop" value="1"/> <!-- apply brake when stopping motor (or not) --> <param name="stall_timeout_ns" value="20000000"/> <!-- after spin-up, if no zero crossing is not detected for this amount of time, motor is considered stalled --> <param name="require_reset_if_stalled" value="0"/> <!-- require sending an array of zero commands to reset before next spin-up, if motor stalled --> <!--simple defualt chime--> <param name="tone_freqs" value="[200, 215, 225, 250, 0,0,0,0, 0,0,0,0]"/> <!-- 200 is 2000Hz, max 255 --> <param name="tone_durations" value="[10, 10, 10, 10, 0,0,0,0, 0,0,0,0]"/> <!-- duration of each tone in units of 10 milli-seconds. Poor naming!!! --> <param name="tone_powers" value="[60, 60, 60, 60, 0,0,0,0, 0,0,0,0]"/> <!-- max is 255 --> <param name="dt_threshold_ns" value="150000"/> <!-- during start up, ignore inter-commutation times less than this val, probably noise --> <param name="max_dt_ns" value="2500000"/> <!-- min and max values for time between two commutations. these are used as caps --> <param name="min_dt_ns" value="10000"/> <param name="dt_bootstrap_ns" value="2000000"/> <!-- filter bootstrap value for commutation dt during start up --> <param name="spinup_stall_dt_ns" value="6000000"/> <!-- during spin-up, if no zero crossing is not detected for this amount of time, motor is considered stalled --> <param name="spinup_stall_check_ns" value="30000000"/> <!-- time after beginning of spinup to start checking for spinup stall --> <param name="timing_advance" value="0"/> <param name="sense_advance" value="0"/> <param name="demag_timing" value="0"/> <!-- unused --> </TuneParams> </EscParameters>
-
I noticed one more strange behaviour. I disabled the maximum RPM limit in the voxl-esc-spin.py script. When setting the RPM to 32000, everything is fine, but when setting it to 33000, the motor spins backwards. This does not happen in open loop mode.
Any help would be apprechiated @Alex-Kushleyev
-
Can you please clarify which ESC board you are using? (Mxxxx number)I see, it is the mini ESC (M0129)The current UART protocol uses a signed int16 type to transmit the RPM information. One bit is used for the sign, so the range of RPM supported by this command is -2^15..+2^15, which is 32768 RPM in either direction. The ESC itself is capable of spinning faster (for example, using the PWM command) but the limitation in this case is the packet that is transmitted to the ESC.
I understand that this is an issue for you. If you really need to command RPMs higher than 32K, I can create a new packet that will have a larger range (lets say up to 65K in either direction).
Regarding RPM accuracy, please double check that the number of pole pairs in your motor is correctly specified in the param
<param name="num_cycles_per_rev" value="6"/>
, i double checked the model of your motor, it is 9N12P, so that is 12 poles (6 pole pairs - that seems correct). I would suggest using a optical tachometer with reflective tape on the motor to verify the RPM in real time. I believe the RPM should be within 1% accurate. You can check the RPM with your tachometer at several speeds, like 5k, 15k 30k RPM.In your test, where your maximum rpm was 31300, it is possible that a lower battery voltage was used, so the ESC could not achieve that high RPM. Maximum RPM depends on the battery voltage applied to the ESC.
Alex
-
@Alex-Kushleyev Thank you for your thorough answer!
It would be great, if you could send us a new packet with command RPMs up to 65K.
We will check the physical RPMs again with a optical tachometer. But the battery voltage was the same across all tests.
Best regards
Tom -
@TheRealKaufmann , we have another option to resolve this.
Since in the params we have the param for number of pole pairs (in your case 6), if we fake that param, say, we set it to 7, the ESC will think that the motor has more pole pairs and the ESC will think that the motor will spin slower than it actually is. Since the ESC does not really ever care about the number of pole pairs (it is only used to convert the electrical RPM to mechanical RPM), there will not be a performance issue. So if we do this, if you command 32768 rpm, the motor will try to spin at that rpm, but the motor will actually spin at 32768/67= 37333 RPM. So you could think of this as if we change the number of pole pairs in the ESC config, the ESC calibration and thrust to RPM curve will be different, where RPM* is the new rpm that is lower than actual.
If you look at how traditional ESCs are used, there is no notion whatsoever about commanding an RPM. With the proposed "hack" i am suggesting to simply change the mapping between the "pretend rpm" and actual rpm in order to increase the commanded RPM range.
There would be no changes in ESC firmware or PX4 code for this to work, which means you can use it immediately. However, you would need to do the following:
- change number of pole pairs in ESC params from 6 to 7
- perform new esc calibration of the feed forward term with propeller attached (our standard esc calibration)
- if you use thrust to rpm calibration curve anywhere, you would simply need to multiply your old rpm by 6/7 in order to get the lower "pretend rpm".
Let me know if you would like to try this approach. Otherwise, will need to wait a bit in order for us to update the ESC firmware with the new packet and PX4 firmware to make use of new packet.
Alex
-
@Alex-Kushleyev I apologise for my late answer. Thank you first of all for the quick solution! I actually modified the PX4 Firmware to give PWM commands instead of RPM, but your method seems way better. An actual fix would still be nice though
I could not test your RPM method until now. We actually had to order a new ESC (and are still waiting for it), because when spinning motor id 3 to around 80%, the ESC would cut out and currents of up to 30A were indicated in the current measurement. We tried to swap the motor, but that did not help. The weird thing is that at lower power settings (eg. 50%), the motor spins just fine. The other motor id's do not have that problem. I assume that ESC is no longer usable? Do you know what the cause could be? Temperature was always around 40 deg C.
Best regards
Tom -
what is the RPM and current draw of the ID3 right before it cuts out at 80% (in normal operating range)?
Are you commanding 80% right away or slowly ramping up to that power?
you could run a test where you slowly ramp to 80% with
--ramp-time 5.0
when usingvoxl-esc-spin.py
command. This will take 5 seconds to ramp up to the desired power. -
I am going to try to replicate your setup, can you please confirm motors and props you are using @TheRealKaufmann :
https://www.getfpv.com/t-motor-f1404-2900kv-3800kv-4600kv-motor-gray-red.html (2900kV)
https://www.getfpv.com/gemfan-windancer-3028-propeller-set-of-4.htmlthank you!
Alex
-
@TheRealKaufmann , i just discussed with the team and we will add a new packet that will allow +/- 65K RPM control of the ESC. The change will happen in two places, the ESC firmware itself and we will also update PX4 to send out the new packet..
I believe we also need to add a check of the outgoing RPM to make sure you don't send a negative RPM by overflowing int16 (in the current packet and the new packet). This is what you experienced, if I understood correctly.
For now, it's best that you set the RPM limit in PX4 to 32700 in order to avoid reversing motors in flight . I hope to provide an update later this week.
Alex
-
@Alex-Kushleyev said in ESC cuts out on high RPM:
what is the RPM and current draw of the ID3 right before it cuts out at 80% (in normal operating range)?
Are you commanding 80% right away or slowly ramping up to that power?
you could run a test where you slowly ramp to 80% with
--ramp-time 5.0
when usingvoxl-esc-spin.py
command. This will take 5 seconds to ramp up to the desired power.Hi Alex! We have tried both. It did not seem to have an effect on the outcome. Before the high current draw, everything seemed normal (I think it was 2-3A).
@Alex-Kushleyev said in ESC cuts out on high RPM:
I am going to try to replicate your setup, can you please confirm motors and props you are using @TheRealKaufmann :
https://www.getfpv.com/t-motor-f1404-2900kv-3800kv-4600kv-motor-gray-red.html (2900kV)
https://www.getfpv.com/gemfan-windancer-3028-propeller-set-of-4.htmlthank you!
Alex
Yes, that would be awesome. The setup is correct. Motors are 2900 KV, GF-3028 Props and 4S Battery.
@Alex-Kushleyev said in ESC cuts out on high RPM:
@TheRealKaufmann , i just discussed with the team and we will add a new packet that will allow +/- 65K RPM control of the ESC. The change will happen in two places, the ESC firmware itself and we will also update PX4 to send out the new packet..
I believe we also need to add a check of the outgoing RPM to make sure you don't send a negative RPM by overflowing int16 (in the current packet and the new packet). This is what you experienced, if I understood correctly.
For now, it's best that you set the RPM limit in PX4 to 32700 in order to avoid reversing motors in flight . I hope to provide an update later this week.
Alex
Thank you very much, that sounds nice. Yes, I believe a sanity check for the outgoing RPM be a good thing for the exact behaviour that we have noticed. When you provide the update, we will test right away. Our new ESC has also arrived
-
@TheRealKaufmann , I just received the motors and propellers and will begin testing today.
Can you please confirm that you are using 4S battery for testing? It seems so based on the params you initially provided.
Here what my test plan roughly looks like:
ESC
- perform basic tests in open loop across the whole range of 0-100%
- verify accuracy of RPM via optical tachometer (can be done in open loop mode)
- double check performance on ID3 at power > 80%
- perform calibration for RPM control
- limit the max rpm to 32700 in params for now and test RPM response in this range, adjust tuning params if necessary
- add a new packet to the ESC for +/- 65K RPM control input and update
voxl-esc
tools to allow this. Note that the feedback packet from esc contains unsigned RPM, so it is already supporting up to 65K
PX4
- add rpm limits to avoid reversing if rpm is exceeded (in case PX4 max rpm param is greater than 2^15)
- integrate new esc packet with PX4 (will take a bit more time)
I will keep you posted, hopefully first part will be pretty quick to at least unblock your testing with RPM limited to 32700.
Alex
-
OK, quick update..
I did a quick test.. ramp from 0 to 100% power runs fine on ID3, see image below.
optical encoder test was good, i did 3 measurements : ESC: 8040, 11800, 1850rpm, tachometer 8035, 11810, 18500. (rounded to closest 100rpm). The optical tachometer was very very close to reported rpm of the ESC.
I used the following command to do a quick ramp test:
./voxl-esc-spin.py --id 3 --power 100 --ramp-time 4.0 --timeout 5.0 --enable-plot 1
(btw, i just updated
voxl-esc
on dev branch to plot the total current, since M0129 does not have individual current measurement, but if you test one motor at a time, you will get current for one motor)got to about 33000 rpm at 100% power, 14.8V, about 5.8A current..
More details will follow as I tune for RPM control.