I am tuning a multicopter that I built, and it oscillates up and down in loiter mode after sharp altitude changes.
According to the logs (especially noticeable in the attached log, 339s - 340s), the CTUN.Alt keeps increasing while CTUN.CRt is negative. My understanding is that there is approximately a 1-second delay in CTUN.Alt that causes oscillations during rapid altitude changes. Please help me figure out what may be the issue.
From the wiki: “Acceleration (vertical) controller P ( and I) gain. Converts the difference between desired vertical acceleration and actual acceleration into a motor output.” Based on your other values those were too high and may be causing the issue. Typically they are set based on the hover thrust values.
There is too much filtering. You want as little filtering as possible to get the job done. This drone is already pretty clean so it doesn’t need a lot. Basic dynamic notch filter driven by dshot data will do the trick. The web tool was giving me some grief otherwise I’d suggest some values.
As far as I can see the problem is that the vertical position is delayed by roughly 1 second, vertical acceleration is following target relatively close, so it shouldn’t be the issue.
There maybe some excessive filtering but I don’t see how it can cause a full one second delay between CTUN.CRt and CTUN.Alt graphs… If I understand correctly CTUN.CRt should be a derivative of CTUN.Alt.
There is a lot of filtering because this is an experimental frame design and it is not very rigid.
The PSC parameters I mentioned are off by a pretty significant factor based on standard tuning guidelines. Also the relation between those two values is usually x2. The settings you’re flying with is almost x4. Try adjusting those before you go too far down other paths. It’s an easy thing that might solve your troubles. If it works, great. If it doesn’t, let’s try something else.
The vibration levels don’t look bad, especially if you say the frame isn’t very rigid. Again, as little filtering as possible.
I do appreciate the answers, but with all due respect, I still believe that filtering is not the problem here, as:
The acceleration graph (PIDA.Act) follows the target relatively well and with a reasonable delay of 0.05 seconds. At this point, I am happy with how the acceleration controller behaves.
The vertical velocity graph (CTUN.CRt) follows the target relatively well and with a reasonable delay of 0.2 seconds. At this point, I am happy with how the velocity controller behaves.
If anyone could explain why CTUN.Alt graph is increasing while CTUN.CRt is negative, and why there is a 1-second lag between them, I would greatly appreciate it!
Looks to me like it’s going negative because the altitude controller is over shooting the desired height and trying to correct. Try the P & I values I suggested before.
Yes, it is overshooting and trying to correct itself, but my question is:
Why CTUN.Alt is increasing while CTUN.CRt (derivative of CTUN.Alt) is negative?
Negative CTUN.CRt (climb rate) means that the drone is going down. Thus CTUN.Alt (altitude) should be decreasing, but it keeps increasing for about another second.
Also, if you look at the Baro and GPS data, you can see that CTUN.Alt does lag behind them as well.
Since CTUN.CRt follows CTUN.DCRt closely, there are no issues with filtering, acceleration PIDs, or velocity PIDs.
My bad. I see what you’re asking now. Sorry for the confusion.
My comments about filtering were simply something I noticed to help improve the performance of your drone overall. Not about the alt performance. Also, they aren’t configured correctly.
I still stand by my comments on the PSC values, because I feel those too will improve the performance and overshoot you’re seeing in the alt controller.
As for your original question, I don’t have a solid answer. The CTUN.Alt is very clean compared to the baro data, so I suspect it is an output from the EKF. Just as there’s positive alt change with negative CRt, there is also positive CRT with no Alt change. As such there may be a delay in the logging. That’s a guess. I’ll back off and see if anyone closer to the code has a better answer.
I changed some of the settings as you recommended, and it probably helped with overall flight performance, but it didn’t help with my issue.
I finally figured out what was the problem - It was the NewBeeDrone RemoteID module. It does not support GPS autoconfid and sends the GPS data to the flight controller with nearly a 1-second delay. After disconnecting it and installing a regular non-RemoteID GPS module, the problem was solved.
