MOT_SPIN_MAX for reducing power out in case of vibrations by LUA

I just wonder if this is a safe route to go:

My copter seems to exhibit extreme vibrations stsrting from a certain combination of power and speed. These vibrations are not due to bad FC damping, the copter hovers for instance at 1450 - 1500 uS and 20 A and has Vibes XYZ below 10, but at full throttle and 1950 uS, the current could go as high as 80 A and VibeZ is 100 and clipping is permanent. With 35 A, the Vibves are below 30.

I do not want to reduce the MOT_SPIN_MAX permanently, because the copter may be flown at very high altitudes, where full throttle, i.e. 1950 uS would produce not more than 30…35 A.

The question is: if I implement something like this:
If Vibe Z goes above certain level (about 50), reduce MOT_SPIN_MAX progressively to about 0.85 (1700). Could this be dangerous? Could it destabilize attitude? The Flight Modes where this could occur would most probably be ALT HOLD and ACRO.

I could also be checking for current, so that if the current is already below let us say 35 A, the MOT_SPIN_MAX would not be modified.

I wonder if this could produce potential thrust loss condition and whether this is dangerous. I do not think it is a good idea that instead of MOT_SPIN_MAX to intervene the throttle directly or to limit ANGLE_MAX for ALT HOD Mode?

Yes, that is dangerous and not advisable.

On the other thread I understood that with no wind situations (stationary vehicle, but with props) the vibes are not high. So seams that the vibes do come from turbulent air flow.

Improve the air flow to reduce the turbulence is the way to go, if I correctly understood your other post.

Yes, that the case. It flies extremely well, with extremely low Vibes up to about 70 km/h and 35 A and Vibes at 20. From there, the Vibes really deteriorate very fast, i.e. at 85 km/h at 45 A, the Vibes go from 20 to 100.

I think I have to redo completely the airframe, but I was thinking whether this power reduction is a good way of dealing with the problem.

I do not need a very powerful copter, but I need it to fly at high altitudes, so there will be a lot of variation of the throttle and RCOUT output for the same power.

After considering all aspects, I think I will do the LUA script. And I will comment the process here because some may give input, and it also could be a good exercise at Lua scripting…

Some things to consider. The copter flies really well up to at least 65 km/h, which a reasonable, but not excellent speed, and definitively is almost unflyable at 80 km/h. The copter, at 2200 grams, hovers at about 200 W (5S 11 A x 19.7 V). The vibration issues begin with power settings above 700 W (36… 38 A) and with some horizontal speed above 60 km/h. If I shoot up vertically, I got up to 1200 W without bad vibration. However, I would not be using GPS speed as criteria for decision, because the problems are related to air speed, and this one I do not have.

I ran into first big problem: there seems no way of accessing VIBE values from LUA. If I understand correctly, up-to-date list of available functions are the bindings:

And there is no mention of Vibes.

The other option would be to get IMU.accz values, because they also strongly oscillate when there is a problem, but IMU is not available either…

I found ahrs:get_vibration…
vibe_z=ahrs:get_vibration():z() ???

It seems like a terrible idea because you have identified a correlation but no cause. Not a great first scripting project, IMHO.

1 Like

For the love of science and 500 bucks at stake… I do not know… If it works out, could be great.

I think I got it more or less right:

Tomorrow I start the debugging process in the air…

vibration.lua (3.3 KB)

Basically, what the program should do is to reduce both MOT_SPIN_MAX and ANGLE_MAX slowly (1…2 seconds) to 0.8 and 26 degrees during the time that Vibe_z remains above 60, PROVIDED that the total power is above certain limit (600 W).
if the Vibe_z goes below 30, then original normal values are restored.
In the 30…60 region, the copter would fly with intermediate values of MOT_SPIN and ANGLE_MAX.
And there is a switch button which would unconditionally restore the original values.

function update ()

local power_min=600 – minimum power (W) below which we would not touch anything
local power_max=2000 – max power (W) above which we would not touch anything
local MOT_SPIN_MAX_Minimum=0.8 – we should never go below this.
local MOT_SPIN_MAX_Step=0.005 – step for reducing on each cycle the MOT_SPIN, 20 cycles/sec, so 1 second = 0.1
local ANGLE_MAX_Step=20 – step for reducing MAX ANGLE, value of 20 - 4 deg/sec
local ANGLE_MAX_Minimum=2600 – Minimum angle we could use
local voltage=battery:voltage(0)
local current=battery:current_amps(0)
local vibe_z=ahrs:get_vibration():z()
local power=voltage*current
local panic_switch=rc:get_pwm(11) – panic switch, will restore original values

if not original_angle_max then original_angle_max=param:get(‘ANGLE_MAX’) end – we save the ANGLE_MAX from FC first time we begin executing

if panic_switch>1600 then – restore MOT_SPIN_MAX and ANGLE_MAX
param:set (‘MOT_SPIN_MAX’,0.95)
if not original_angle_max then param:set (‘ANGLE_MAX’,3000) – if somehow we do not have original angle max, we will use a safe 30 deg
else
if (original_angle_max>2000) and (original_angle_max<7000) then – safety check
param:set (‘ANGLE_MAX’,original_angle_max)
else
param:set (‘ANGLE_MAX’,3000)

             end 
    end        
    gcs:send_text(4, 'VIBE PREVENTION CANCELLED') 
    return update, 50  -- exit here

end

if (power>=power_min) and (power<=power_max) then – we are within power where we can do things
if (vibe_z>60) then – this is the limit above which we have to do something

         if not vibration_event then   -- this is first entry to a vibration event
             vibration_event=1
             gcs:send_text(0, 'VIBRATION EVENT') 
             param:set ('MOT_SPIN_MAX',0.9)  -- immediate and fast action required
             MY_MOT_SPIN_MAX=0.9
             MY_ANGLE_MAX=original_angle_max
          else   -- continuous reentry, slowly reduce MOT_SPIN_MAX, and ANGLE_MAX till predefined minimums
             MY_MOT_SPIN_MAX=MY_MOT_SPIN_MAX-MOT_SPIN_MAX_Step
             if  MY_MOT_SPIN_MAX<MOT_SPIN_MAX_Minimum then MY_MOT_SPIN_MAX=MOT_SPIN_MAX_Minimum  end
             param:set ('MOT_SPIN_MAX',MY_MOT_SPIN_MAX)
	 MY_ANGLE_MAX=MY_ANGLE_MAX-ANGLE_MAX_Step
             if  MY_ANGLE_MAX<ANGLE_MAX_Minimum then MY_ANGLE_MAX=ANGLE_MAX_Minimum  end
             param:set ('ANGLE_MAX',MY_ANGLE_MAX)
             gcs:send_text(0, 'Ang:' .. MY_ANGLE_MAX .. ' Max_Spin:'.. MY_MOT_SPIN_MAX)

      end
     end     

end

if (vibe_z<30) and (vibration_event==1) then – this is the end of the vibration event, restore original values
vibration_event=nil
gcs:send_text(0, ‘END OF VIBRATION EVENT’)
param:set (‘MOT_SPIN_MAX’,0.95)
if (original_angle_max>2000) and (original_angle_max<7000) then – safety check
param:set (‘ANGLE_MAX’,original_angle_max)
else
param:set (‘ANGLE_MAX’,3000)
end
end

return update, 50

end

return update()

The cause is the airframe, with about 99 % probability. But determining which part of it, is extremely difficult. It will be a project for several days at least.

I have three hypothesis:

Slender Arms: unlikely, built very sturdy, no twist
Large Body in airflow: unlikely, could generate buffetting, but the z vibration is not buffetting…
Resonating frame: quite possible, very difficult to diagnose.

If it was purely resonance, than the frame would vibrate independently from whether there is airflow or not. That was not the case.

The vibration appears only when motors are turned on, and the vibration is very quick to appear, less than 0.1 seconds after the power increase, but the vibration also needs to have airflow.

I have a very similar frame but with much stronger arms, 30 mm, I could swap the copter to that frame, or I could reduce the arms which are designed for 18" but from what I have seen I will run this copter probably on 13, 14 inch at most (the current airframe is “take two” of the previous project, it has Sunnysky 4008 - 600 kV motors, and runs on 5 S liion)

A simple built-in alternative to consider is:
MOT_BAT_CURR_MAX and MOT_BAT_CURR_TC
From what you say, you could potentially set “CURR_MAX” around 35A or so. Adjust the amps value and time constant to suit, do a few tests.
This is not a hard/immediate limit of current, but the FC will reduce RCout to bring the current under control after “CURR_TC”.

https://ardupilot.org/copter/docs/parameters.html#mot-bat-curr-max-motor-current-max

https://ardupilot.org/copter/docs/parameters.html#mot-bat-curr-tc-motor-current-max-time-constant

I usually set these as a matter of course, after tuning and some tests to confirm my best RTL_SPEED , LOIT_SPEED and WPNAV_SPEED for efficiency or other requirements, and observing the current draw in logs.

EDIT:
Also in your other thread that is extremely similar - it appears your copter could benefit from an aerodynamic canopy of some sort.
Also do the wind compensation procedure, which will enable reporting of the wind speed.

Also in both threads you havent provided a log yet.
Have you considered the flight controller antivibration mount?
Photos.

1 Like

Antivibration mount is absolutely not necessary because the vibrations are very low up to a certain point. And beyond certain point, they are very destructive, which no anitvibration mount would compensate for.

Aerodynamic canopy could be one of the possible solutions, I thought about it and I may try something out temporary out of foam first to see if this is the culprit.

I did not know about the MOT_BAT_CURR_MAX, and it seems it would be doing almost the same as I planned in my script.

Now I am thinking either just about limiting the Max current using this parameter or limiting this parameter only if vibrations increase beyond certain level.

The risk of simply limiting the max current is also that it could lead to potential thrust loss. My current from where a limiting should occur is about 3 times higher than needed for hover, so that is a very safe current, but if you fly hard in acro mode or in alt hold mode, you will reach a limit, and then maybe reduction of ANGLE_MAX is also a good idea.

Anyway thanks a lot for the suggestion of MOT_BAT_CURR_MAX, I definitively will try it out first.

One thing I would definitively change in ARDUPILOT is that MOT_BATT_CURR_MAX should be replaced by MOT_BATT_POWER_MAX. Since I use Liions, there would be a considerable variation of equivalent current, and if one uses different batteries, like 5S or 6S, then it is even more important to rely on POWER and not on CURRENT.

Here is the log file of the last test flight where I was trying to get the vibration behaviour…

https://www.ecoterrenos.cl/vibes.bin

I have tried the parameter, but I did not like too much how it works, it tends to cycle the power up and down, I have set it to 25 A and 2 second TC. So, as an emergency safety net it would work, but as an integrated power reduction tool seems to be too crude.

I think Ardupilot should implement two TC constants for this: one for going down with the current, and the other for going up, and also possibly a rate of increase. If this is not done, than the function is of very limited use…

I have tried out the LUA script as designed, and it works!!!

I tested in Alt Hold Mode and Acro Mode.

I will upload the test flight .bin file shortly.

This is the modified LUA script:

vibration.lua (3.8 KB)

I had to do some modifications, basically, making the angle_max change smooth in both directions, and also I had to reduce the MOT_SPIN_MAX minimum value to 0.75 and most probably it would have to go lower, may be 0.65, because it just eliminates the worst clippings.

I am not sure if MOT_SPIN_MAX could be reduced much faster, as is now, it takes about 1.5 seconds to become actively low. I wonder if I do the change in 500 mS whether this could affect stability during the transition period.

first test with MOT_SPIN_MAX minimum of 0.74
https://www.ecoterrenos.cl/luatest1.bin

In Alt Hold, in all cases, I push the stick forward to the limit, so that the reduction of angle and of power is done by the LUA.

I would make these changes, although they wont change physical vibrations:

ANGLE_MAX,4500
AUTOTUNE_AGGR,0.1
BATT_FS_CRT_ACT,1
INS_FAST_SAMPLE,1
INS_HNTCH_ATT,40
INS_HNTCH_BW,12
INS_HNTCH_FM_RAT,1
INS_HNTCH_FREQ,50
INS_HNTCH_HMNCS,1
INS_HNTCH_MODE,3
INS_HNTCH_OPTS,6
INS_HNTCH_REF,1
INS_LOG_BAT_MASK,1
SERVO_BLH_OTYPE,0
SERVO_DSHOT_RATE,0

I think you’ll find the harmonic notch filter and DSHOT rate changes are beneficial.

With the extreme amount of vibration you have, there must be issues with the frame or motors, or turbulence from the big flat body is blasted directly onto the flight controller.

Thanks for the suggestions, and I will do them, but they will not change the real issue.

My copter has a very big platform because I initially was thinking of using up to two bricks, somthing like 2 x 1.2 kg batteries, but with experience I gained, I am settling for much lighter battery load, may be a max of 1.5 kg, or even less. With 1.0 kg battery and this setup I expect to have flight times of about 65 minutes and 40 km total flight distance, and with 1.5 kg maybe 75 minutes. Increasing battery load will make the crashes just more expensive, but will not really increase the flight times.

So I just may redo completely the airframe.

second test with MOT_SPIN_MAX minimum of 0.65, the clipping of max power is now very clear, the stability seems not to be affected, the current stays within the preset minimum power (500 W)

https://www.ecoterrenos.cl/luatest2.bin

Hi @Michail_Belov,

I haven’t read all of this thread but I just wanted to add that if the vehicle has a current monitor it might be sufficient to add current limiting.

Nice that you’re taking advantage of scripting for custom behaviour!

Unfortunately, I needed not current limiting, but power limiting (because of Liions), and it was also conditionned to the appearance of vibrations.

But the sccript, with some minor modifications works now extremely well. On level flight it allows copter to go up to around 75 km/h, then kicks in.

I also added the Z vibe and power in Watts on display, which also helped a lot to fine tune the parameters for power reduction.

1 Like