It can indirectly reduce vibration, since the copter is no longer reacting to noise
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.
Log :
https://drive.google.com/file/d/1ko7GiTEjz1ebys36qMwETVG2215_znjL/view?usp=sharing
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.
Is there any good guidance or suggestions as to when and how to tune the PSC values? When to tune POS vs VEL?
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.0If 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)
2 Likes
Awesome! Thanks for that.
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”?
Correct, yes PSC applies to all GPS assisted modes, or any external position source really.
Loiter has some of it’s own params outside of PSC too.
2 Likes
Thanks Dr Andy
INS_HNTCH_REF = hover_thrust * (min_freq / hover_freq)^2
means my rule of thumb is more like
INS_HNTCH_REF = hover_thrust * 0.6
just very roughly.
1 Like
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
1 Like
Thank you @xfacta for all the suggestions.
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.
1 Like
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.
Thank you for the quick answer!
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
One small question, with a small D, the drone will be less reactive, right? So this means that it will have more problems with the wind.
I was checking some logs of crashes that I had, and I found this one of 2 years ago. We saw the oscillations and though that it was because the PID was not good. Can you say that this drone crashed because of the wind and low value of D ?
In that case I cannot lower D value a lot, or I need to stop flying when there is wind?
I would love to know this before starting to check my new configuration
the log : https://drive.google.com/file/d/1ZsmkPZnc2Ce-BHq20vpKdA04_2dCUpRi/view?usp=share_link
In that old log, that is not a D term oscillation. D terms tend to produce small high frequency oscillations that are often not visible to the naked eye. A whining or mechanical noise from the motors and heating is usually evident if D is too high.
This looks like the quad got hit by a disturbance or weight shifted (battery) and two motors are not able to go to low enough output to maintain stability. It looks like everything was at defaults too, so PIDs wouldn’t suit 15" props and low KV motors - reactions were not suitable.
No, quite different and for different reasons
hi @xfacta
On another project, autotune engaged but fails to level, please tune manually again, of course, guided by you previously, the Harmonic Notch filter was applied and vibrations were reduced before Autotune started.
- Can I just focus on the above sets of values to change before I attempt the autotune the second time? for ATC_RAT, you seem suggestions to increase D, and reducing P and I. For ATC_ANG, you seem to suggest increasing them.
- Or I should try the 4.3.0 version?
- Can I just ignore PSC default values changes for now as I am doing Autotune?
1 . You can certainly try those PIDs you listed and see if flight is stable enough.
2 . I would advise using the latest stable firmware version
3 . PSC values can be usually ignored unless there’s a problem. There is reason to adjust a couple after initial hover tests: PSC_ACCZ_P and PSC_ACCZ_I
If you think there’s a position holding problem, possibly affecting Autotune, do these steps in order.
Test by using AltHold and do some hovering and movements, then switch to Loiter and do the same movements - observe if there’s any apparent instability or oscillations in Loiter.
PSC_VELXY_FLTD,5 down to new value of 2.5
Observe and gather log. If that fixes it great - no further action.
If it’s not resolved just change this
PSC_VELXY_FLTE,5 down to new value of 2.5
Observe and gather log. If that fixes it great - no further action.
If there’s still no fix, try these
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
Let us know exactly what helps.
Autotune, I am curious to know, for the same drone, if underwent twice successful complete roll tune for example at the same venue, same environment condition, will the tune results the same or close?