Ive got a 1800mm (motor to motor) quad running 43x14 props. All up weight in flight log and video is just under 33kg. Initial tune parameters were used from mission planner for the 43” props. Accel and compass were both configured. Normally I’d include a screen recording of EKF/Vibe from mission planner but forgot to stop and save the recording so it corrupted. There was no meaningful interference or vibrations.
The video shows the quad taking off and having a weird side to side (roll) rocking. My normal process would be to magfit, magfit, quicktune, magfit, autotune each step increasing the flight aggressiveness but thats on airframes that are steady/level on takeoff.
It looks to me like PID values are off? perhaps too high? Any help would be greatly appreciated.
Video and flight log are available in the following drive folder.
Judging by the oscillation frequency, yes, roll PIDs are most likely too high. 0.1 for ATC_RAT_RLL_{P,I} is what I would test first, while simultaneously dropping D to 0.002.
After that, few necessary or desired actions are:
set LOG_BITMASK to the now-default 180222 so that PID contributions get logged and we can answer these questions with less effort;
non-zero D and zero FLTD is a dangerous combination, you have this for yaw. Set ATC_RAT_YAW_FLTD to the same 10 as you set other filters.
you don’t seem to have any filtering and a post-filtering bump at about 23-35 Hz, whereas your motor RPMs are also at 25 and 30 Hz. You would likely benefit from filtering.
Motors 1 and 2 run at 30 Hz in hover, motors 3 and 4 run at 25 Hz. Judging from the frame type and servo output assignments, it’s the CCW motors which run at 30 Hz, and CW motors at 25 Hz, which means you have a noticeable yaw imbalance, which likely results from motor alignment issues. Fix the mechanics and make your life easier.
Do you have a log of an initial flight with Initial Tune parameters, default Rate PID’s and the vertical controller gains set based on hover thrust (~0.14)? And yea, there is a mechanical Yaw bias.
Really appreciate the feedback. Im going to make these changes tonight and test again.
Both of you called out a yaw bias which at first was confusing to me as I calibrated each arm to a < 1 degree variance from the body out to each motor of each axis but then I remembered that this flight was on my test fit aluminum top and bottom plates and not carbon fiber so there could be a small amount of flex in the plates as there is no structural rigidity to the side to side axis like there is front to back. Im also going to double check again each arm/motor to see if I missed something.
Dave, this was the initial flight with initial tune parameters. If I am missing something here, please let me know.
After that flight set the Vertical Acceleration Controller gains. They are a bit too high now which can cause output oscillation.
I was asking how it first performed on default rate PID’s because they are not now. It’s true you would lower these if output oscillation is seen in the log but it’s also true that large quads often need higher than default PID’s not lower for attitude control authority. But, you have high thrust:weight so it’s not so simple.
I see you raised the Horizontal Velocity D gain for some reason.
So, it’s definitely not just “Initial Tune Parameters”. Or are you using the Methodic Configurator?
Roll changes you suggested @MaxBuzz worked like a charm. First flight log and video in the following drive link are with just those changes.
Second flight log I applied hntch values and it seemed to get more sloppy (still stable). Which I presume means the notch filter is not correct? (sorry no video of it flying with the hntch settings).
I did not use the methodic configurator. I did copy params from another large airframe but then thought I overwrote the PIDs using the “initial tune parameters” feature of mission planner. Perhaps that doesnt change all the parameters like I thought that it did?
Part 1. For the notch, my suggestions are as follows.
Do not change:
INS_HNTCH_ENABLE: obviously leave at 1
INS_HNTCH_ATT: leave at 40 so far, might go down once the machine gets tuned tighter
INS_HNTCH_MODE: leave at 3
INS_HNTCH_REF: leave at 1
INS_HNTCH_HMNCS: as of now, makes sense to leave at 3
INS_HNTCH_FM_RAT: I prefer leaving it at 1 and change the frequency/bandwidth parameters to avoid spreading parameter semantics.
Must change:
INS_HNTCH_OPTS: this must absolutely be changed for ESC-based filtering. The absolute minimum is 2 to select “multi-source”. I tend to also set the next bit, “update at loop rate”, and all my machines fly with the value 6. To the best of my knowledge this is a safe choice these days, but it’s much more important for small machines.
INS_HNTCH_FREQ: when using ESC feedback filtering, this is not your hover frequency, but the minimum frequency you want to be able to filter, which is ideally below any propeller rotation frequency encountered in or around flight. The current is 25, and already in your logs I see some propellers rotate at 18 Hz. With a machine with non-rigid landing legs, I would want to cover the RPMs of the propellers at arming, which is about 8Hz, otherwise you may have PID runaways before leaving the ground. I would set this to 5, lower is safer.
INS_HNTCH_BW : this should be at most half the previous value, and in multi-rotors even less. For my quads I tend to set this to INS_HNTCH_FREQ / 10 as I know that noise peaks are rather sharp. In your case, I would set this to 1/5th, that is 1. Note that this is not the actual filter’s bandwidth, it will scale with ESC feedback to stay at the selected relative width (1/5 of the frequency).
As of now, I tend to disagree with INS_GYRO_FILTER = 10. I feel like this is quite too low even for a machine of this size. I would set it at least to 20, and maybe higher once you dial the notch filters. At this moment, this may be a noticeable contributor to the overall sloppiness.
The PID contributions for pitch and roll in your latest logs are very small, which might also explain some of the sloppiness. This is not a guarantee, however: I have a couple of machines with very quiet frames and a high enough T/W ratio, where e.g. PIDR.P and PIDR.D are pretty much always below 0.03, but they fly considerably well.
Here, if I were responsible for this machine, I would try to raise the PIDs gently, making small flights, likely with increasing aggressiveness, and watching PID{R,P,Y} entries in the logs - so that the system is closer to its final config when running autotune. For the remote advice situation, I would recommend doing a series of flights with a slightly more aggressive profile (judged by the pilot’s feelings to be still safe) to determine whether the current config is safe enough to run autotune, and then continue with autotune if it feels fine enough.
Your current vibration profile is a bit in the grey zone. For the first out of the two latest logs, some of the vibes (on some of the IMUs) go to 20 as you descend and land. I would recommend having an additional look at the mechanics, including both arm mechanics and hanging wires around the flight controller mount that can transmit unwanted vibrations.
You still seem to have some yaw imbalance. It’s kind of flyable, but you know.
Landing legs. Not immensely critical, but I would recommend stiffening them a bit, e.g. by adding and tightening some string to make more triangles for rigidity. Currently they do cause fun effects with yaw at startup.
Above I recommended something like 5/1, just a bit tighter than 4/1, and for the smaller machines with reasonably good motors/propellers and quick enough telemetry I tend to raise this to 10/1, because the system is apparently able to respond quickly enough during RPM changes and the phase lag should be a bit smaller I guess.
Applied the “Must Change” parameters called out by @MaxBuzz and had good results. Airframe looks stable other than on takeoff due to those individual legs that I need to somehow tie together to combat the yaw shake at takeoff.
When viewing the flight log, take note that the first takeoff in the log I had attempted to do a quicktune which failed (violent back to back roll oscilations retured and quicktune didnt downgrade out so I had to cancel the quicktune).
After this I put the airframe into althold and observed the aircraft start driving forward telling me the pitch PIDs now need some work. At this point, should I manually do this and then try to head onto autotune? If the airframe cant do a quicktune, does that even make sense to think I could move onto Autotune?
I also plan to load this airframe up with significant payload (80lbs). Should I do any of this tuning with payload? or will the aircraft adjust accordingly from no payload to then having payload?
You need to fix the Yaw bias and it looks like you still have some leftover parameters from what you copied over from the other craft. It would useful to see some post filter data in the log too, you haven’t enabled that parameter.
Here is the RC output graph that you can produce as you work on the Yaw bias. CCW Motors are commanded higher than the CW motors.
This is a clue that this craft is unstable and not in a state of tune to run Quick Tune or Auto Tune. Be very careful or start over without parameters from another craft.
For the Quiktune - although I have precisely zero experience using it - I believe the culprit is QUIK_OSC_SMAX, which is set to 3 currently, and the logs show that the parameter adjustment stops rising when the actually perceived slew rate reaches 3. The problem is that on this machine the slew rate of 3 is dangerously high. As a result, based on quiktune experience alone, I would not declare the machine to be unstable.
You may probably want to either try it with QUIK_OSC_MAX = 0.5, or to manually test whether the machine can tolerate 20 deg twitches in AltHold and proceed with the real autotune. As a personal opinion, once I have looked at Quiktune’s parameter set, I don’t feel like I trust it a lot…
P.S.: and this yaw imbalance can cause a lot of “fun” when tuning, as a twitch in roll would also kick the machine’s yaw, so you really should invest in fixing it…
With all the yaw imbalance comments I decided to rebuild the drone, this time with the use of new jigs to ensure perfect alignment on each of the arms.
