FPV 4 in 1 esc calibration from Flight core v2

Jetson Nano

Hey @Alex-Kushleyev @Eric-Katzfey
I am using FPV racing 4in 1 esc , i would like to claibrate it.
My connection is VOXL 2->Flight core v2 -> ESC.
I tried to directly calibrate it , did not work.

Jetson Nano

@Alex-Kushleyev @Vinny @Eric-Katzfey @tom
Hi guys,
If anyone could help me with the issue I am facing it would be great.

I am using VOXL 2 -> FC V2 -> VOXL FPV 4 in 1 ESC , how to calibrate the ESC.

Also my motors are making sound and getting smoked up, When try to arm or run them through QGC. I felt it might be a calibration issue. The motors are only smoking when they in a CF frame, but when they are out of the frame , they are working fine. On other non modalai ESC and FC the motors are working fine.

what could be causing this kind of behaviour.

Jetson Nano

I was able to solve the issue of smoking and sound by using another configuration file for ESC, but after that when i try to connect to FC the ESC is not detected, i don't know why this is happening, i changed the baud rate and checked still the same behaviour.

Could you help why the ESC is not starting after the configuration file change, i tried to start from mavlink console, the ESC was not getting started, but from voxl2, the motors are rotating.

Also the ESC is no longer making the motor initialising sound while powered.

This is the file i am using

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<!--  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  -->
<!--  Sample parameters for 6s lipo Xing2 2207 1855kv motors with 5.1x4.1x3" tri-blade HQ propellers  -->
<EscParameters>
<IdParams>
<param name="id" value="127"/>
<!--  0-7 .. 127 means use hardware ID pins to read ID -->
<param name="dir" value="3"/>
<!--  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="22000"/>
<!--  used for sanity checking and limiting of voltage-dependent funcions  -->
<param name="num_cycles_per_rev" value="7"/>
<!--  number of pole pairs in the motor. used for converting electrical frequency to mechanical rpm  -->
<param name="min_rpm" value="3000"/>
<!--  minimum RPM that will be attempted, otherwise capped  -->
<param name="max_rpm" value="25000"/>
<!--  maximum RPM that will be attempted, otherwise capped  -->
<param name="min_pwm" value="75"/>
<!--  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="-161.08261993195703"/>
<!--  this is actually motor_voltage vs rpm curve.. using legacy naming  -->
<param name="pwm_vs_rpm_curve_a1" value="0.47042836521926995"/>
<!--    -->
<param name="pwm_vs_rpm_curve_a2" value="1.0493408741732317e-05"/>
<param name="kp" value="0"/>
<!--  RPM controller proportional gain  -->
<param name="ki" value="0"/>
<!--  RPM controller proportional gain  -->
<param name="max_kpe" value="100"/>
<!--  maximum proportional erorr term (max is 999)  -->
<param name="max_kie" value="50"/>
<!--  maximum integral error term (max is 999)  -->
<param name="max_rpm_delta" value="6000"/>
<!--  cap for maximum rpm error used in RPM controller  -->
<param name="spinup_type" value="1"/>
<!--  0: traditional, 1: sinusoidal  -->
<param name="spinup_power" value="90"/>
<!--  power used to during spin-up procedure  -->
<param name="latch_power" value="90"/>
<!--  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="3500"/>
<!--  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="1855"/>
<!--  kV value of the motor. used in back-emf compensation during spin-up  -->
<param name="min_num_cross_for_closed_loop" value="10"/>
<!--  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="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  -->
<!-- silent -->
<param name="tone_freqs" value="[0, 0,0,0, 0,0,0,0, 0,0,0,0]"/>
<!--  200 is 2000Hz, max 255  -->
<param name="tone_durations" value="[0, 0,0,0, 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="[0, 0,0,0, 0,0,0,0, 0,0,0,0]"/>
<!--  max is 255  -->
<param name="dt_threshold_ns" value="100000"/>
<!--  during start up, ignore inter-commutation times less than this val, probably noise  -->
<param name="max_dt_ns" value="3500000"/>
<!--  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="2500000"/>
<!--  filter bootstrap value for commutation dt during start up  -->
<param name="spinup_stall_dt_ns" value="8000000"/>
<!--  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="20"/>
<param name="sense_advance" value="15"/>
<param name="demag_timing" value="0"/>
<!--  unused  -->
</TuneParams>
</EscParameters>

Jetson Nano

@Jetson-Nano It was solved, i reduced the baudrate to 250000, and the tune was due to the deafult value , i noticed it later.

I wanted to know that this change in baudrate will not affect the drone, also if i want further tune the esc , what are the procedure.

I am using TMOTOR F60 1950 KV motors.

Alex Kushleyev

@Jetson-Nano ,

I am glad you were able to resolve this issue.

Regarding high baud rates (921K, 2M, etc), The ESC is perfectly fine with that, but you should double check that your Flight Core V2 (STM32) is configured to use DMA on the UART TX and RX. When using Flight Core V1, we noticed long time ago that default was DMA disabled and we would loose relemetry packets from the ESC due to interupt-based UART RX. The outgoing TX packets were still fine, but all these interrupts would add unnecessary MCU overhead anyway. You should be able to see the DMA mapping in the BSP config for the Flight Core V2, but I do not have an exact link right now.

If you would like to perform tuning, i highly recommend that you do that with the ESC connected to a linux PC. You can start with the following ESC param file, which is a similar motor, Xing2 1855kV, 6S, tuned with a 5x4.1x3 propeller : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-params/FPV_RevB/m0138_xing2_1855_5x4x3.xml?ref_type=heads

Follow the ESC tuning guide : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md

Alex

Jetson Nano

@Alex-Kushleyev Thank you for reverting back and the support. I will follow the steps you mentioned to tune the ESC.

Jetson Nano

@Alex-Kushleyev
While testing, I got one capacitor burnt, could verify, whether this affect the performance of the ESC, I was able to do bench test perfectly, but before I carry ahead with flight test I would like to verify with you guys.
I am attaching the photos with you , could please check it out and help me with this.

PCB does not look damaged, only the capacitor looks like burnt, I do not know what caused it, a spark was observed during bench testing, but the motors were working after the spark , i later observed this damage.

What is the capacitor used for here, what is the capacitance.

Vinny

HI @Jetson-Nano
That is one of the several dozens of decaps for VBAT. It is possible if the board was subjected to a strong jolt/shock/impact/bending, it can create a micro defect in the cap, resulting in the cap shorting and then burning up. It is not common, but it can happen with the right (or wrong depending on how you view it) angle and strength of impact. This is a common failure mode of MLCC caps of that size and capacitance density. There are several white papers out there to explain this, here is one such doc:
https://www.mdpi.com/2079-9292/12/6/1297

Just make sure you do not see any VBAT to GND shorts across any of the other large caps right next to it before reconnecting your VBAT. Otherwise you can cause an issue with your battery driving a short.
If you still see a short, try removing that cap, but you need a LOT of HEAT with big tips, but then that stresses the other nearby caps, possibly inducing another failure mode.
If this is just not in your comfort level, we can likely RMA that unit if it was bought recently and not in an obvious crash. It looks pretty clean to me.

For note:
Our team is aware of this vulnerability and we always transport and store our ESCs in padded ESC carriers to prevent them bumping into each other during pre-assembly stages.
If you experience any severe crashes, or accidentally knocked your HW off the table, I'd recommend a quick DMM check for VBAT to GND shorts as part of your check-out routine before your next battery. Could save you a fire!!

Jetson Nano

@Vinny Thank you for reverting back and the information, I will be more careful , and will check your recommended procedure.
From what I externally see there is no any other visible damages to any other components.
What was the capacitance of the component?

I did not notice the damage and had powered the system and it was working fine, now i have replaced the ESC, but i would like to know whether it will be ok if i get the capacitor replaced.

Vinny

Hi @Jetson-Nano
I'm not exactly sure how much of an impact one cap will be, the system will still function near 100%.
It is a 22uF cap, 35V rated 1206 package
We have ~50 of these on the design, so missing 1 is not a big deal in my opinion, especially if it is bench testing or software development purposes.
Hope this helps!

Jetson Nano

@Vinny Thank you for your valuable feedback.

I’ll keep the points you mentioned in mind while doing the bench testing.