I need help regarding the PID of my drone. I have seen some posts where some people have had problems because their PID were too “aggressive” and that this could be damaging to the motors and lead to crash. I know when my drone is not responsive enough but honestly I do not know how to determine when it is too aggressive to the point of making the drone crash.
Manual tunning of Roll and Pitch
(I decided to do autotune first to then manually set roll and pitch, but now with my payload)
For the input shaping I was happy of how the drone was flying so I didn’t change it
So with this steps I got a PID really responsive and then I wanted to do some tests to see if the drone could fly even in some dangerous environments.
I did some up and down tests at 5m/s. And then (maybe I went too far) I tested the drone at speeds up to 16 m/s.
I want to make sure that the drone is not gonna crash because of the vibration it can have at high speeds or with some winds when it is flying at 100m so this is why I did it.
I want to learn to identify possible causes of future crashes, it would be nice any advise you can have
It is a quadcopter, 15" props with 4006-380KV T-Motor.
You are on the right track with steps 1 to 4.
Hopefully step 5 is not needed, although some prefer to manually tune.
If step 4 Autotune works out OK, don’t change "PID"s for a payload, but just reduce these accel values based on minimum and maximum take off weight
new ATC_ACCEL_P_MAX = ATC_ACCEL_P_MAX x (min_TOW / max_TOW)
new ATC_ACCEL_R_MAX = ATC_ACCEL_R_MAX x (min_TOW / max_TOW)
new ATC_ACCEL_Y_MAX = ATC_ACCEL_Y_MAX x (min_TOW / max_TOW)
You can set
ATC_THR_MIX_MAN,0.5
See if this reduces the oscillations you seem to have in Loiter
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
The HNOTCH setttings look a bit odd for 15" props, probably should be around 60Hz to 80Hz and INS_HNTCH_REF should definitely be 0.19
I imagine you looked at your FFT graphs and chose the frequency of about the highest looking peak. You might find that there’s a small peak at about 57Hz (half of 114), and that would be the primary noise source you need to target.
Leave INS_LOG_BAT_MASK,7 if you have any doubts or until totally finished tuning.
INS_ACCEL_FILTER,10 is low, especially for something this size. Are you sure you need it that low? I’d tend to leave it at default 20 unless you absolutely have to change it.
Usually once the HNOTCH is all correct and working, Autotune sorts out the rest.
It’ll be good if you can get the Z axis vibrations down a little bit.
The real formula for setting INS_HNTCH_REF is
INS_HNTCH_REF = hover_thrust * SQUAREROOT(min_freq / hover_freq)
and in reality it works out close to
INS_HNTCH_REF = hover_thrust * 0.8
You want the harmonic notch filtering to start working from just below hover thrust, don’t wait until hover thrust and everything is already being affected by noise.
Thank you very much for all your answers. Today I have some windy day so tomorrow I will have a look at all the params that I have to change and I will post the log to see if it is better.
@xfacta For INS_ACCEL_FILTER I set it at 10Hz because of the documentation. I also had it at 20, but I am not sure what could be the effect of this so I just did what the documentation says.
Regarding the Z vibrations, it is true that my payload vibrates but I had a little understanding that doing the notch filter could reduce this problems. But I will try my best to reduce it. I already have some tips in the forum so I will try some, but if you have more ideas they are more than welcome.
My UA had the Vibe.y issue, which I reduced by moving and mounting some modules to a more rigid structure and securing wires (preventing bounce) away from FCU.
So, I changed the ref to 0.19 and the frequency for 58Hz for the notch filter. I did then AUOTUNE and then changed my accelerations with formula ATC_ACCEL_P_MAX x (min_TOW / max_TOW).
I feel the drone less aggressive than before but I guess it is Ok because I do not want to burn the motors. In general would you say that this is a nice PID ?
I wanted to test the drone in some missions so I chose one, terrain following 2m lidar at 5m/s, and a second one at 60m and 10m/s.
As you can see the drone follows the line pretty good (not perfect but ok) in both cases. The problem is that when it reaches a WP it continues.
I tried in one of the flights changing the PID correction of PSC. I got a little better but when I switched back to Loiter I had a lot of oscillations so I came back to what @xfacta suggested.
Is there an update that I did not see that can make this happen? I spend the entire day trying to figure out so if you have a hint that could be really helpful.
Have you ever tried to remove the conditional yaw commands from your flight plan only to check if it couldn’t be the cause of the strange behaviour in turnarounds?
The documentation really only means we should change INS_ACCEL_FILTER as low as 10 for larger aircraft, and for where it has become impossible to remove vibrations any further.
It’s one of those things that we’d never normally change until you’ve exhausted other options.
I’ve asked Leonard before and there is bit of a process, some trial and error (or more correctly making changes then rechecking logs)
In relation to the question I asked this was the reply about a specific occurrence of oscillations in Loiter
We are looking at the PSC XY PID loops and we want to take out the 4.5 Hz oscillations.
To determine if this is the fix we can set the D term to zero and half the rest:
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25 ← was set to zero for testing as per advice
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
If this solves the problem then you get to do some PSC tuning.
The PID logging may clearly show that the D term is at fault.
You may solve this by dropping the D term or reducing the filter to 2.5 Hz or
something like that.
Since then I’ve seen the oscillations in loiter a lot lately and so far the catch-all / easy way to sort it out seems to be to just set
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
and it doesn’t seem to compromise the position-holding ability. You could always fine tune it your self.
On a new build recently, I started by setting PSC_VELXY_D,0.3 before the first flight because I knew this X8 would be sensitive. Later, after test flights I just set all those params as above, since Loiter was still a bit shakey, and it’s been fine.
EDIT:
I’m still working out whether to
request some change to default params potentially because the position controller is now more sensitive due to improvements in (many areas of) the code
or there’s some bug in the code causing the sensitivity (much less likey I feel)
Just to clarify, the PSC_ values only affect loiter mode. So if the oscillation isn’t present in alt hold and only appears in loiter then this is a good place to look? Does the PSC tuning apply for all “GPS Modes”?
Set
BRD_BOOT_DELAY,5000
to ensure the CAN GPS device is ready and booted up before Ardupilot
and
ATC_THR_MIX_MAN,0.5
Try different values for GPS_GNSS_MODE and GPS_GNSS_MODE2 using the selection dialog in MissionPlanner to just pick 2 constellations at once. Use whichever gives you the best HDOP in the shortest amount of time from power up.
You can set FENCE_ENABLE,1 to ensure there’s a good 3D Fix and Home can be set before you are allowed to arm.
Check the other Fence params to ensure they suit you.
I would set
INS_LOG_BAT_MASK,7
and do another test flight to verify the HNOTCH/FFT settings. The reason being is there’s still noise and some tiny oscillations or instability in the attitude control. This may have affected the Autotune result too.
ATC_RAT_PIT_D,0.006 and ATC_RAT_RLL_D,0.006 are still relatively high compared to the P and I values.
So you could try two manual things:
lowering them to 0.004625 or as low as 0.0037
increasing ATC_RAT P and I values to about 0.1
Possibly some more work on the HNOTCH would sort out the underlying issues and Autotune would produce a better result.
EDIT:
Also very definitely set these:
BATT_ARM_VOLT,22.10
BATT_CRT_VOLT,21.00
BATT_LOW_VOLT,21.60
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
I had a lot of problems with the position overshoot and the end I just understood that it is just the way it is now.
In the release notes, for the 4.2.0 there is :
d) Waypoint navigation will make use of maximum waypoint radius to maximize speed through corners
Even so, I was having some problems following the path with the PSC params that you suggested so I tried with the default params and then it got slightly better.
So in the end both of the GPS (I think) are working well.
Regarding the battery parameters suggested, our batteries are Li-ion, and the company told us that we can fly up to 3.2V, and with 6S this is 19.2. So we normally stop the flights manually at 19.50V. That is also why we do not have any FS.
I decided to make some test flights at different heights and everything was working pretty good. I decided to set INS_LOG_BAT_MASK to 0 because I didn’t want to charge the Cube (I should have leave it).
Unfortunately I had a little crash today. The drone was twitching after a little mission so I decided to observe and do some hovering. I though it was because of the PID and the influence of the wind, given that the test was in a little mountain. After a few minutes I heard a noise and the drone starts falling. Fortunately there was not big damage but there is the big question of why. I can see in the logs that Motor 1 was the one that stopped worling, but it is a brandnew motor that had never flown before.
I remember for my last crash (Octocopter multiple crash) that @dkemxr told me that I had a bad PID. This time, this is why I wanted to make sure that the PID was working OK.
I do not want to keep crashing drones because of the PID, or at least I would love to just understand why it happens.
PIDs are definitely an issue, the quad gets into oscillations in both AltHold and Loiter
Start by setting INS_ACCEL_FILTER,10 - there was a discussion about it elsewhere, you had it correct earlier.
Cautiously try these with Stabilise and AltHold and see if it is working OK.
These are lower ANG values and typical RAT values
ATC_ANG_PIT_P,6.5
ATC_ANG_RLL_P,6.5
ATC_ANG_YAW_P,4.5
ATC_RAT_PIT_D,0.005
ATC_RAT_PIT_I,0.1
ATC_RAT_PIT_P,0.1
ATC_RAT_RLL_D,0.005
ATC_RAT_RLL_I,0.1
ATC_RAT_RLL_P,0.1
if there’s still oscillations try lowering the RAT P and I values a bit
You might have to concentrate on the manual tuning process
For the LiIon batteries 3.2 is a high low voltage, 2.8 is more typical.
For 3.2v set
BATT_ARM_VOLT,21.50
BATT_CRT_VOLT,20.40
BATT_LOW_VOLT,21.00
MOT_BAT_VOLT_MAX,24.60
MOT_BAT_VOLT_MIN,19.20
for normal LiIon levels set
BATT_ARM_VOLT,19.10
BATT_CRT_VOLT,18.00
BATT_LOW_VOLT,18.60
MOT_BAT_VOLT_MAX,24.60
MOT_BAT_VOLT_MIN,16.80
I’m a firm believer that you should always set
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
since it’s easy to be distracted and miss a low battery voltage - this is what the flight controller is for, checking these sorts of things while the pilot is busy.
Now I am also convinced that it is the PID, precisely the D term. I think that maybe when I had it at 0.006 the motor did not like it and started to be damaged. Then when I passed it to 0.004 it was low but not enough and the damage had been done.
I will pay attention to this parameter and will be back with some results, hopefully better.
And certainly I will set the BATT params this time
