possible regression in quadplane attitude controller?

[tridge]

I've had some strange and quite severe oscillations with a GriffinPro tilt quadplane recently when running master. The oscillations are bad enough that I am at risk of losing the aircraft. The odd thing is that running the same parameters on 4.5.7 I have not been able to reproduce the issue.
There are some complicating factors, so it isn't absolutely certain this is a regression, but I think it is worth looking into.
This is what happens on master:

notice the increasing amplitude of oscillation in QLOITER. Changing to QHOVER did allow it to slowly recover, but still huge overshoots.
This is the same parameters on 4.5.7:

there is still some overshoot, but not dangerous.
the complicating factors are:

• the tune is pretty bad. I don't know quite how I ended up with this tune, it is clearly a manual tune as it has round numbers for the gains. My past logs showed I changed to these gains sometime last year, but I can't remember why. Maybe some experiments I was doing at the time? The rate PID gains are clearly too low for the angle P gain of 10. I could retune it easily and make it fly a lot better, but my concern isn't getting a good tune, it is explaining why master seems much worse than 4.5.7 in case this impacts other users
• I recently increased the payload a bit, adding a RPi4 and a 4G radio, which I suspect is why it is worse now than it has been on previous flights, but as a percentage of total weight the extra payload is small (maybe 250g out of 10kg or so?)
• the ESCs are blheli32/dshot, but are going via a L431 DroneCAN adapter, so changes in the CAN code need to be considered as well as high level quadplane and attitude controller

Some things I've looked at:

• given the number of filtering changes in master compared to 4.5.7 I looked at the unfiltered vs filtered gyro data and I don't see any filter induced lag in the logs
• I'm intrigued by the flat bottom on the RATE.RDes graph above for master. That is probably the 75 deg/s limit from Q_A_RATE_R_MAX, but I don't see an equivalent flat bottom on the tests with 4.5.7. Some change in the rate limiting? Or just the different way of triggering the oscillation (I had to use the sticks to start the movement in 4.5.7 whereas with master it spontaneously oscillates when descending).
• i looked at the RPM feedback from the ESCs versus the demand in RCOU and I don't see any higher lag in master than in 4.5.7.

I haven't tested the 4.6.0 beta. To do that safely I think I'll need to retune first to get a safe set of gains, then use a script to switch to these gains to see if 4.6.0 is affected.

Logs are here:
http://uav.tridgell.net/tmp/GriffinProOscillation/

[tridge]

I chatted to @andyp1per and he thought this change is a possible cause?
7047e11

[lthall]

I chatted to @andyp1per and he thought this change is a possible cause? 7047e11

This is only used in copter guided so I can't see how this could be a factor.

Have I missed something?

[tridge]

Have I missed something?

I doubt you've missed anything, Andy and I only had a very quick look, sorry

[lthall]

Ok, so the difference in green desired rate lines where the top appears to be experiancing limiting but the lower isn't is due to the source of the rate command. In the first graph the rate command is coming from the attitude error and that is limited. In the second it comes from the commanded attitude and is not limited.

[lthall]

This is also a combination of roll and yaw:

It looks like the tune was on the edge and got into a corner of the flight evelope that was properly unstable with some cross compling between roll and yaw.

[timtuxworth]

I maybe have seen a similar problem today with my VTBird tilt rotor. As with yours I haven't flown it for a long time, and it had a "not great" (but flyable) tune on it, but I put a new build based on master on it for some other testing I'm I'm doing and just tried to do a basic hover a couple of meters off the ground. It was scary.
Then I put 4.5.7 Official on, the only change was to disable scripting and a minor tweak to one of the tilt rotor trims. Then I put it in the air (just a couple of meters in QLoiter) and it was much better.

Log of 4.7.0 (+ my "interlock" code) - https://www.dropbox.com/scl/fi/tvyeji5xwl80f6gxwz5bd/log_164_2025-1-15-11-35-08.bin?rlkey=o3nbav6p6t11h5gaeqr0lorf9&st=4oz9hglz&dl=0
Here's a video of part of that flight: https://youtu.be/aYb0AAqVtn0

Log of 4.5.7 (official from MP) - https://www.dropbox.com/scl/fi/amj418e15qbac4lgk5sib/log_166_2025-1-15-11-59-10.bin?rlkey=lp2mm44hwhc7jdmlk6ayj3y0t&st=8nz0lxat&dl=0
Here's a video of the much more stable flight: https://youtu.be/EGJ1jaxr5Ko

There is a slow oscillation on the yaw tune, which I've never been able to break on this plane.

[lthall]

I maybe have seen a similar problem today with my VTBird tilt rotor. As with yours I haven't flown it for a long time, and it had a "not great" (but flyable) tune on it, but I put a new build based on master on it for some other testing I'm I'm doing and just tried to do a basic hover a couple of meters off the ground. It was scary. Then I put 4.5.7 Official on, the only change was to disable scripting and a minor tweak to one of the tilt rotor trims. Then I put it in the air (just a couple of meters in QLoiter) and it was much better.

I have went over these logs too and it does look like the output is messier. It isn't night and day but the old code looks like it is generally softer in it's response.

It would be good to compare the Alt_Hold performance to seperate attitude control from position control.

Looking through the code changes there is a reasonably significant number of changes but I can't find anything that should cause a performance change:

Attitude controller is primarily naming but with a one loop movement of the update_attitude_target(); This should not do anything.
Position controller has a lot of offset work, some sysID work, but I can't see anything that should change the controller.
AC_Loiter looks fine.
I don't see anything in the quadplane.cpp code but I am moving out of my depth now.
Nothing in tiltrotor.cpp
There is a fair amount of work in servo.cpp

I got nothing, other than trying to break this down and comparing Alt_hold and Loiter to see if this is more closly related to attitude or position control would be interesting.

[timtuxworth]

The weather is looking nasty for the next week at least. I'll try to fly it in QHover/AltHold as soon as I can.

[timtuxworth]

There is a fair amount of work in servo.cpp

Given it's a tilt-rotor, this might be important.