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

John Nomikos 0

@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?

Alex Kushleyev

@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

John Nomikos 0

@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!

Alex Kushleyev

@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 -->

John Nomikos 0

@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 -->

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.

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

Alex Kushleyev

@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

John Nomikos 0

@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.

Alex Kushleyev

@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

John Nomikos 0

@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.

Alex Kushleyev

@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

John Nomikos 0

@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

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

modaltb

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

John Nomikos 0

@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

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

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

Alex Kushleyev

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

Eric Katzfey

@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?

John Nomikos 0

@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.