# (Platform 1.0.0) Bug in the most recent VOXL2 ESC Firmware (Random motors reverse directions each arm)

Source: https://forum.modalai.com/topic/2575/platform-1-0-0-bug-in-the-most-recent-voxl2-esc-firmware-random-motors-reverse-directions-each-arm
Category: VOXL 2 and VOXL 2 Mini (https://forum.modalai.com/category/26/voxl-2-and-voxl-2-mini)
Tags: voxl-2
Posted: 2023-08-16 16:34:20 UTC by John Nomikos 0
Replies: 34 · Views: 9509

## John Nomikos 0 · 2023-08-16 16:34:20 UTC

Good afternoon,

Recently, I updated the ESC firmware on one of our drones to the most recent firmware. And I gave the ESC generic params for the specific type of ESC that I am using (m0117). 

I noticed a peculiar issue when arming the drone. Each arm, a random motor would be spinning much slower than the rest. Upon closer inspection, whichever motor affected by this would actually reverse direction from what it was set to.

Every motor did this at least once. It feels random which motors are affected. As an example,

```
Arm #1: every motor spins correctly except bottom right which reversed direction and spins slower.

Arm # 2: everything spinned correctly.

Arm #3: top left motor reversed direction and everything else spinned correctly.

Arm #4: bottom left and bottom right reversed direction and everything else spinned correctly.
``` 

We saw this issue on two separate drones with different ESC parameters and most recent ESC firmware. I did not see this issue in the earlier ESC firmware.

I recorded a video of one of our motors. At the end of the video it shows the issue.

Here's a drive link to the video: https://drive.google.com/file/d/16pHMBFjkoxJK90SuMcxZnteA9qsAoME4/view?usp=sharing

**How to recreate the problem**

Step 1: Flash platform 1.0.0 on your VOXL2
Step 2: Reboot drone. Update ESC firmware by doing *voxl-esc update-firmware* command
Step 3: Load ESC params, choose whatever works best for you.
Step 4: Do whatever you need to do to setup your drone so that you can arm it on QGC.
Step 5: Arm drone on QGC. You may need to disarm and arm a few times to see the issue.

Please let me know if you have any further questions.

Thank you,

John Nomikos.

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-16 20:43:22 UTC

@John-Nomikos-0 ,

In order to resolve your issue, I highly recommend to switch the ESC params to use our new smooth spin-up procedure. You can see how to enable it in the following esc param file (note that your motor control params are different, so don't just take this whole parameter file and use it): 

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/Sentinel_V1/Sentinel_V1.xml?ref_type=heads#L69

You will need to enter the kV value of the motor (`motor_kv`) and i would recommend updating the `spinup_rpm_target` to the rpm that motor would normally spin at like 10% power (usually in the range of 1000-3000 rpm). You can shorten the spinup time (`spinup_time_ms`) as 1500ms (1.5 seconds) was chosen in this case for a relatively large propeller with a lot of inertia. You can use 500ms as a good starting point for small motors/props. Having long spinup time will not hurt anything though.

If you see that during the smooth spinup, the motor seems to "slip" and stall, then increase the `spinup_power` slightly, by 10 units or so. This "slip" can happen if the spin-up power is very low and there is just not enough force to keep the motor spinning during the initial phase.

Also, please update `min_num_cross_for_closed_loop` to 5 as in this example. `protection_stall_check_rpm` should be set to less than minimum nominal RPM. So If the lowest normal RPM that the motor + propeller can spin (say at 7-10% power) is 2000rpm, I would set the stall check to 1000 or 1250 to prevent false triggers. This stall detection will protect the motor from burning out if it gets physically stuck due to some external event (hits something or gets tangled).

Please try this out and let us know if it resolves your problem!

Alex

## Reply by John Nomikos 0 · 2023-08-21 21:31:18 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Are some of these settings changeable via px4 params? Like motor_kv

I am curious how these esc settings actually work. Do they overwrite px4 parameters?

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-21 21:35:31 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 , the ESC params / settings are completely separate from PX4. PX4 cannot modify the ESC params - all the ESC configuration is done through our tool `voxl-esc`. You should make sure the correct ESC params are installed before starting PX4.

PX4 just has the interface to control the ESC by sending the RPM commands to spin the motors.

Alex

## Reply by John Nomikos 0 · 2023-08-22 17:21:50 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev 

It worked! Thank you a lot. I did everything that you recommended

I had to up the spinup_power by a lot. It was originally at around 70. I stopped seeing issues at 130.

Thanks for the help!

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-22 18:35:01 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

That is great to hear!

130 spinup power sounds a little bit on the high side (however, I am not saying it is wrong). Are you able to share the part of the params that you updated, perhaps i can spot something that might be off or recommend a a change? I typically use spinup power of about 100 or less. Basically, if you are able to share the following params (this example is from the Sentinel V1 ESC params.

Another test that I typically do is check the current that the motor draws during the the spin-up phase. There are a few ways to do that, including `voxl-esc-spin.py` command that will print out the current drawn by each spinning motor (or just one, if you are spinning only one), including the current drawn during the start-up phase.

```
 <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
    <param name="spinup_power"        value="80"/>     <!-- power used to during spin-up procedure -->
    <param name="latch_power"         value="70"/>     <!-- 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="1500"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
    <param name="spinup_time_ms"      value="1500"/>   <!-- 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="880"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->
    
    <param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
    <param name="protection_stall_check_rpm" value="750"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor -->

```

## Reply by John Nomikos 0 · 2023-08-22 20:48:05 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Sure.

Here's what I changed (from esc_params_generic_m0117.xml)

```
<param name="spinup_power"        value="130"/>     <!-- power used to during spin-up procedure -->
<param name="spinup_rpm_target"   value="3300"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
<param name="spinup_time_ms"      value="500"/>   <!-- Duration of the sinusoidal spin-up procedure -->
<param name="motor_kv"            value="2400"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->
<param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
<param name="protection_stall_check_rpm" value="700"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor -->

```

Here's what it was before I changed it:

```
<param name="spinup_power"        value="70"/>     <!-- power used to during spin-up procedure -->
<param name="spinup_rpm_target"   value="1000"/>   <!-- 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="motor_kv"            value="0"/>    <!-- 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 -->
```

## Reply by John Nomikos 0 · 2023-08-22 20:51:05 UTC (in reply to John Nomikos 0)

Also, I am now running into a problem where the drone does not lift off and tilts everytime I arm and try to lift off. I never ran voxl-esc-calibrate though, so I will try that. I never knew that existed until I read it on [another forum post](https://forum.modalai.com/topic/2522/esc-calibration?_=1692737370059).

As a note I'm using 1804-2400kv motors

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-22 20:54:58 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 , thank you for the details!

I see that the following setting is not listed, please make sure that `<param name="spinup_bemf_comp"    value="1"/>` is set to 1. If you have it as zero, that would explain the higher than usual power required to keep the motor spinning during the spin-up. Basically, with back-emf compensation enabled, the spin-up procedure automatically adds more power as the motor spins up, as the back-emf voltage generated by the motor at higher rpms will counter the voltage that is applied to the motor. Once you set that parameter to 1, I believe you should be able to drop the spinup power back to 80 or so. please try!

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/Sentinel_V1/Sentinel_V1.xml?ref_type=heads#L75

Regarding the drone tilting, this could happen due to incorrect actuator (motor) mapping in PX4. If this is not done correctly, the thrust will be applied in wrong location and the vehicle will not fly.

Alex

## Reply by John Nomikos 0 · 2023-08-22 21:11:54 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thank you for the advice. Changing that parameter allowed me to set power back down to 80 with no issues.

Hmm also QGC does show that the actuators are mapped correctly. I also double checked that props are on right and are spinning the right direction. I will investigate further. I'm trying to fly it in VIO currently.

Is it necessary to calibrate the escs with voxl-esc-calibrate.py? I have not done that.

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-22 21:25:43 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

Yes, you should perform the ESC calibration - it should be done for best results whenever you have a new motor or propeller type. There is more information about it in the other thread you found. Then you would need to update your PX4 parameters for min and max rpm so the commanded thrust is properly mapped to what motors can achieve. 

Also, if you are experimenting with new motors and props, it is always better to fly in manual mode to make sure the basic flight is working properly and then test higher level modes like VIO. 

@modaltb , are there any other params that need updating if John is using a custom drone for his custom motor/prop combo?

Alex

## Reply by John Nomikos 0 · 2023-08-22 21:30:17 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev 

The interesting thing is that these aren't new motors and props. We got them working previously on the older esc firmware and even did PID tuning. Drone was flying smoothly. But of course, changing the ESC firmware parameters could have completely invalidated that.

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-22 21:47:06 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 , i see. In that case, if you kept the old control parameters the same (such as the calibration curve and gainst, etc), the new firmware should work the same. The new firmware only had changes that relate to the spin-up procedure. Therefore, if you have migrated your old params to the new params correctly (you could double check that all the control params should be the same between your old param file and new param file), then the issue may be somewhere else. You should try to fly in non VIO mode, just manual mode to check if the drone flies well manually.

Alex

## Reply by John Nomikos 0 · 2023-08-22 22:08:45 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev And just to confirm, the actuators tab should be where I am testing that the motors are mapped correctly, right?

We were seeing this problem when flying in stabilized flight mode as well. I can try manual next

## Reply by John Nomikos 0 · 2023-08-22 22:36:17 UTC (in reply to John Nomikos 0)

Even in manual mode it tries to eat dirt as soon as it tries to lift off. I triple checked, motors are mapped correctly and spinning in the right direction

## Reply by modaltb (ModalAI staff) · 2023-08-22 22:45:18 UTC (in reply to John Nomikos 0)

Hey @John-Nomikos-0  , you'll need to know how things are wired up to "quickly" be able to use this guide: https://docs.modalai.com/modal-esc-px4-user-guide/#actuator-setup-using-qgc

If you don't know the wiring, it becomes a fun guess and check game....

To reverse, you could try these I believe:

```
MODAL_IO_SDIR1
MODAL_IO_SDIR2
MODAL_IO_SDIR3
MODAL_IO_SDIR4
```

## Reply by John Nomikos 0 · 2023-08-23 03:02:52 UTC (in reply to modaltb)

@modaltb I have actually successfully been able to use the "Identify and assign motors" functionality, so I was using that to identify the motors. 

I'm going to try via command line just to make sure that the actuator test matches with what is expected

## Reply by John Nomikos 0 · 2023-08-23 14:59:07 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

Double checked using command line
actuator_test set

It matches what I see on the actuators tab.

~~Moving back to previous ESC firmware to see if problem persists.~~
Nevermind, I think I would need to plug into ESCs to do that

## Reply by John Nomikos 0 · 2023-08-23 21:22:18 UTC (in reply to John Nomikos 0)

Just to clarify, I am still unable to fly with the most recent ESC firmware. All of the motors are mapped correctly and the props are on right, but the drone still seems to eat dirt whenever I throttle it up. It even completely flipped over once. I tried in manual mode and same story.

Any other suggestions? I'm starting to run out of ideas :cry:

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-23 21:56:19 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 i have asked for help from our other devs, we will follow up with further suggestions.

## Reply by Eric Katzfey (ModalAI staff) · 2023-08-23 22:10:10 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 Is this on a custom drone? Seems like perhaps a bad PX4 parameter somewhere. Maybe you can wipe everything and start from scratch?

## Reply by John Nomikos 0 · 2023-08-23 22:42:05 UTC (in reply to Eric Katzfey)

@Eric-Katzfey Maybe there's something with my ESC firmware parameters that's causing issues?

I'm going to try to flash an esc config that is used on a modalai drone to see if it's any different

Also, is there an easy way to go to the previous ESC firmware version without manually plugging in? I want to go back to see if this is due to the firmware flash in a time-efficient manner. I'm pretty sure there isn't but I wanted to make absolute sure

Also it is on a custom drone, but we got our drone flying with the exact same parameters on the previous ESC version on 1.0.0. Really is seeming like an ESC firmware issue to me.

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-24 00:07:24 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

Yes i can provide you with old firmware for m0117 (the original firmware you had before). You will need your old ESC params. All this can be done right from voxl2 without unplugging. I will follow up tomorrow morning.

## Reply by John Nomikos 0 · 2023-08-24 00:24:57 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev said in [\(Platform 1\.0\.0\) Bug in the most recent VOXL2 ESC Firmware \(Random motors reverse directions each arm\)](/post/11955):
> Yes i can provide you with old firmware for m0117 (the original firmware you had before). You will need your old ESC params. All this can be done right from voxl2 without unplugging. I will follow up tomorrow morning.

Sounds good. I don't think we ever changed the ESC params on the old firmware version. So they would be whatever the ESC came out of the factory with. I'm assuming there are default parameters available for the old firmware, right?

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-24 00:29:23 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 , yes i will provide the default params that are loaded during production.

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-24 15:35:19 UTC (in reply to Alex Kushleyev)

@John-Nomikos-0 , 

I have uploaded the older firmware that was used during production of M0117-1 ESC : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/firmware/old/modalai_esc_firmware_m0117_1_v0_36_f75f1fdb.bin

The default params that are loaded with that are here : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/params-v1/voxl-esc-params/old/esc_params_modalai_4_in_1_revb.xml (please note that this is not the same as the latest `esc_params_modalai_4_in_1_revb.xml` in dev or master branch.

(you can put the old firmware file into the following location: `/usr/share/modalai/voxl-esc-tools/firmware/`

Note that if you want to perform the ESC downgrade right on VOXL 2, you need to get both of these files on your VOXL2 and run the following commands:

```
cd /usr/share/modalai/voxl-esc-tools/

#disable PX4
voxl-esc enable-bridge

#upload firmware to each ESC ID (you will hear a sad beep after each update, which means the params are invalid - this is ok
python3 voxl-esc-upload-firmware.py --firmware-file firmware/modalai_esc_firmware_m0117_1_v0_36_f75f1fdb.bin --id 0
python3 voxl-esc-upload-firmware.py --firmware-file firmware/modalai_esc_firmware_m0117_1_v0_36_f75f1fdb.bin --id 1
python3 voxl-esc-upload-firmware.py --firmware-file firmware/modalai_esc_firmware_m0117_1_v0_36_f75f1fdb.bin --id 2
python3 voxl-esc-upload-firmware.py --firmware-file firmware/modalai_esc_firmware_m0117_1_v0_36_f75f1fdb.bin --id 3

#upload old params (one command to update params on all 4 ESCs)
python3 voxl-esc-upload-params.py --params-file <path_to_your_params_file>/esc_params_modalai_4_in_1_revb.xml

#detect the ESCs
python3 voxl-esc-scan.py

#re-enable PX4
voxl-esc disable-bridge
```
Your firmware has should now be updated to have the hash `f75f1fdb`, which is the original firmware that you had on the ESC and the old firmware `esc_params_modalai_4_in_1_revb.xml` should have been the firmware that you received installed during production.

Depending on the baud rate that you use in your latest ESC params, you may have to update it (the old baud rate was 250K but it could have been changed to 2Mbit, please double check).

Let me know if you have any issues in this process

Alex

## Reply by John Nomikos 0 · 2023-08-25 16:39:11 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thank you so much for the help. I will try this next week. Have a great weekend!

## Reply by John Nomikos 0 · 2023-08-28 15:51:07 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev said in [\(Platform 1\.0\.0\) Bug in the most recent VOXL2 ESC Firmware \(Random motors reverse directions each arm\)](/post/11975):
> python3 voxl-esc-upload-params.py --params-file

So I successfully flashed the firmware on all 4 ESCs. But uploading params gave me this error

```
voxl2:/usr/share/modalai/voxl-esc-tools$ python3 voxl-esc-upload-params.py --params-file /esc_params_modalai_4_in_1_revb.xml 
Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) 
[GCC 8.4.0]
Found voxl-esc tools bin version: 1.2

INFO: Params file name : /esc_params_modalai_4_in_1_revb.xml 
INFO: Params file size : 6971 bytes

VOXL Platform: M0054
Detected VOXL2 M0054 or M0104!
Found previous connection information in .voxl_esc_cache ..
Prioritizing /dev/slpi-uart-2 @ 2000000
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000
Sending library name request: libslpi_uart_bridge_slpi.so
Received standard error event 2
Sending initialization request
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 250000
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 921600
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 230400
INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 57600
INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 57600
INFO: ESCs detected:
INFO: ---------------------
ID: 0, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
ID: 1, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
ID: 2, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
ID: 3, SW: 36, HW: 34: ModalAi 4-in-1 ESC (M0117-1)
---------------------
ERROR: ESC firmware version 36 is incompatible with params supported by this utility
       Acceptable ESC firmware versions are:  [38]
```

I think voxl-esc-upload-params is checking for the version. I could modify it and try again, unless there is an earlier tool meant for this firmware

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-28 15:53:37 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 , 

Yes, you are right, in order to load older params, you need earlier version of the voxl-esc tools. Please use this version of voxl-esc tools, you can check it out right onto your VOXL2 next to the latest voxl-esc tools (do not overwrite) : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/params-v1

Everything else should work the same with old tools.

Sorry about that, i forgot to mention it :)

Alex

## Reply by John Nomikos 0 · 2023-08-28 16:00:29 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev Thank you. Successfully uploaded params

## Reply by John Nomikos 0 · 2023-08-28 16:28:10 UTC (in reply to John Nomikos 0)

Successfully was able to arm and fly with older esc firmware on default params. Thank you for all the help

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-28 16:56:24 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

wow really? I am glad that it worked for you..

However, are you able to share the modified ESC params that did not work for you? the whole XML file. I think you should be able to attach it here or just paste it? As I mentioned before, there should not be a performance difference in the new ESC firmware and we have been testing it without issues, so I suspect the issue is in the new ESC params that you used..

I would like to figure out the issue, in case this comes up again.. thank you!

Alex

## Reply by John Nomikos 0 · 2023-08-28 17:05:14 UTC (in reply to Alex Kushleyev)

@Alex-Kushleyev 

Sure thing. Here's the entire XML file of params I was using on the new firmware that I could not take off with:

```
<?xml version="1.0" encoding="UTF-8"?>

<!-- Copyright (c) 2020 ModalAI Inc.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission.

4. The Software is used solely in conjunction with devices provided by
   ModalAI Inc.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

For a license to use on non-ModalAI hardware, please contact license@modalai.com -->

<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="2000"/>   <!-- minimum RPM that will be attempted, otherwise capped -->
    <param name="max_rpm"             value="35000"/>  <!-- maximum RPM that will be attempted, otherwise capped -->
    <param name="min_pwm"             value="70"/>     <!-- 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="366.028455487"/>  <!-- this is actually motor_voltage vs rpm curve.. using legacy naming -->
    <param name="pwm_vs_rpm_curve_a1" value="0.267931384448"/> <!-- Emax RS1306 3300KV with tri-blade 3x3x3 -->
    <param name="pwm_vs_rpm_curve_a2" value="5.77024053745e-06"/>
    <param name="kp"                  value="0"/>    <!-- RPM controller proportional gain -->
    <param name="ki"                  value="0"/>     <!-- RPM controller proportional gain -->
    <param name="max_kpe"             value="0"/>    <!-- maximum proportional erorr term (max is 999) -->
    <param name="max_kie"             value="0"/>    <!-- maximum integral error term (max is 999) -->
    <param name="max_rpm_delta"       value="2000"/>    <!-- cap for maximum rpm error used in RPM controller -->
    
    <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
    <param name="spinup_power"        value="130"/>     <!-- power used to during spin-up procedure -->
    <param name="latch_power"         value="70"/>     <!-- 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="3300"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
    <param name="spinup_time_ms"      value="500"/>   <!-- Duration of the sinusoidal spin-up procedure -->
    <param name="spinup_bemf_comp"    value="0"/>      <!-- 0: disable, 1:enable back-emf compensation in sinusoidal spin-up procedure -->
    <param name="motor_kv"            value="2400"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->

    <param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
    <param name="protection_stall_check_rpm" value="700"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor -->

    <param name="brake_to_stop"       value="0"/>             <!-- 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 -->

    <param name="tone_freqs"          value="[100, 115, 225, 250, 0,0,0,0, 0,0,0,0]"/> <!-- 200 is 2000Hz, max 255 -->
    <param name="tone_durations"      value="[30,  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="alignment_time_ns"     value="0"/>           <!-- alignment time before spin-up -->
    <param name="timing_advance"        value="0"/>
    <param name="sense_advance"         value="0"/>

    <param name="demag_timing"          value="0"/>    <!-- unused -->

  </TuneParams>
</EscParameters>
```

## Reply by John Nomikos 0 · 2023-08-28 17:09:11 UTC (in reply to John Nomikos 0)

Apologies, this file is not up to date from when I left off. I changed spinup_bemf_comp to this
<param name="spinup_bemf_comp" value="1"/>

and power back to 80.

Everything else on this file should be the same. Here's updated:

```
<?xml version="1.0" encoding="UTF-8"?>

<!-- Copyright (c) 2020 ModalAI Inc.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission.

4. The Software is used solely in conjunction with devices provided by
   ModalAI Inc.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

For a license to use on non-ModalAI hardware, please contact license@modalai.com -->

<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="2000"/>   <!-- minimum RPM that will be attempted, otherwise capped -->
    <param name="max_rpm"             value="35000"/>  <!-- maximum RPM that will be attempted, otherwise capped -->
    <param name="min_pwm"             value="70"/>     <!-- 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="366.028455487"/>  <!-- this is actually motor_voltage vs rpm curve.. using legacy naming -->
    <param name="pwm_vs_rpm_curve_a1" value="0.267931384448"/> <!-- Emax RS1306 3300KV with tri-blade 3x3x3 -->
    <param name="pwm_vs_rpm_curve_a2" value="5.77024053745e-06"/>
    <param name="kp"                  value="0"/>    <!-- RPM controller proportional gain -->
    <param name="ki"                  value="0"/>     <!-- RPM controller proportional gain -->
    <param name="max_kpe"             value="0"/>    <!-- maximum proportional erorr term (max is 999) -->
    <param name="max_kie"             value="0"/>    <!-- maximum integral error term (max is 999) -->
    <param name="max_rpm_delta"       value="2000"/>    <!-- cap for maximum rpm error used in RPM controller -->
    
    <param name="spinup_type"         value="1"/>      <!-- 0: traditional, 1: sinusoidal -->
    <param name="spinup_power"        value="80"/>     <!-- power used to during spin-up procedure -->
    <param name="latch_power"         value="70"/>     <!-- 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="3300"/>   <!-- Desired RPM at the end of the sinusoidal spin-up procedure -->
    <param name="spinup_time_ms"      value="500"/>   <!-- 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="2400"/>    <!-- kV value of the motor. used in back-emf compensation during spin-up -->

    <param name="min_num_cross_for_closed_loop" value="5"/>  <!-- exit latching mode of fixed power after this number of zero crossings -->
    <param name="protection_stall_check_rpm" value="700"/> <!-- if motor spins below this RPM, stall check will trigger and stop / restart the motor -->

    <param name="brake_to_stop"       value="0"/>             <!-- 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 -->

    <param name="tone_freqs"          value="[100, 115, 225, 250, 0,0,0,0, 0,0,0,0]"/> <!-- 200 is 2000Hz, max 255 -->
    <param name="tone_durations"      value="[30,  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="alignment_time_ns"     value="0"/>           <!-- alignment time before spin-up -->
    <param name="timing_advance"        value="0"/>
    <param name="sense_advance"         value="0"/>

    <param name="demag_timing"          value="0"/>    <!-- unused -->

  </TuneParams>
</EscParameters>
```

## Reply by Alex Kushleyev (ModalAI staff) · 2023-08-28 17:40:34 UTC (in reply to John Nomikos 0)

@John-Nomikos-0 

Thank you. OK, here is the big difference that is most likely the reason for your behavior. In your new params you used `kp`, `ki`, `max_kpe`, `max_kpi` terms set to zero, but old params have nonzero:
```
<param name="kp"                  value="130"/>    <!-- 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="1200"/>    <!-- cap for maximum rpm error used in RPM controller -->

```

Considering that you have not calibrated the ESC for your motor and propeller (meaning that the feed-forward term in the RPM controller is wrong), if you also disable the feedback terms of the RPM controller (`kp`, `ki`) then the behavior of the ESC will be completely off from what is desired. Even with incorrect feed forward term (`pwm_vs_rpm_curve` terms), if feedback terms are enabled, they can compensate, to some degree, but with the feedback terms set to zero, there is no hope for the ESC to turn the motor at the desired speed.

You can keep using the old firmware and params if that works for you, but if you wanted to switch to latest ESC firmware and params, then i suggest trying to use the same non-zero RPM controller params.

Alex