QuadPlane( 2 front motor tilt)transition yaw swing

I had a similar issue on my own VTOL of about that size.
With the Quad firmware set up as an “H” frame, it never did this. I had set it to “H” so that the front two props would be spinning the “correct” directions when tilted forward. Has to do with P-factor and whatnot.
However, I was having some frame flex issues, to the point of instability, so I set it to be an X quad.
Once it was set as an X quad, it started having yaw issues similar to what you’re seeing on transition.

I (mostly) got rid of the behavior by lowering the yaw P value and speeding up the q_tilt_rate_down. My theory is that it’s holding on to the quadcopter control logic for too long, and when the motors tilt forward, it tires to correct minor yaw movements with quad logic. Which means spooling up two motors, and slowing down the other two. Unfortunately, when in X quad configuration with motors partially tilted forward, it’s spinning up the wrong one… let me give an example.

-We have an X quad trying to transition.
-It needs to yaw slightly to the left to reach it’s target heading, or maintain it’s current one, etc.
-To yaw to the left, it spins up motors 3 and 4 while slowing down 1 and 2.
-Motors 1 and 3 are partially tilted by this time.
-Look where motor 3 is on an X quad. It’s the front left when viewed from the top.
-Because motors 1 and 3 are partially tilted, spinning up motor 3 while slowing down motor 1 creates a yaw moment to the RIGHT, when it’s trying to yaw left.
-As great as arduplane is, one thing it’s not great at is handling “I told it to go this way but it went the other way instead”
-Thus, yaw oscillations, and failed (or VERY dicey) transitons.

2 Likes

I very much agree with you that the reason for the YAW axis oscillation is that the multi-axis control logic and the control logic after tilting the motor are contradictory. In addition to modifying the code for the tilt motor compensation control in the Arduplane code, there is no better. The way is.

My flight log is invalid, there is no way to find it, I am very sorry.

Is there any update on this? I’m still fighting with it on my birds, I thought I had it tuned out but that appears to be a fluke.

Here’s a log from a series of flights I did yesterday. I tried changing a few parameters around to get improvements, but not much helped.
https://drive.google.com/open?id=1FMLtgkV5hPuj8CNzFsuPTzBUhuHndB6i

Hi James, to check if this is an issue with the multi-rotor torque based yaw control causing issues when tilted can you do a test with the yaw factor zeroed out in the motors matrix?
For X change it here:

for H change it here:

change all the AP_MOTORS_MATRIX_YAW_FACTOR_CW and AP_MOTORS_MATRIX_YAW_FACTOR_CCW values to 0 for the corresponding frame type.
If the issue is the torque based yaw control causing issues at high tilt then this should completely eliminate it. I’ve tested it with an e-flite convergence in RF8 SITL and it flies fine, using just vectored yaw.
If this does work then we could add new frame types that have zero yaw factors, or add some code to scale the yaw factor with tilt.
Cheers, Tridge

2 Likes

Hi Tridge,Thank for your reply!
I will test the new code in these days and get back to you as soon as possible!

I’m working on testing the new code as well, we should have it compiled today and then it’ll be a matter of the mercy of the weather.

The weather gods were indeed merciful, so I was able to get some testing in today on the modified code.
Logs are here, the one marked “Normal Firmware” is from friday while the one marked “Modified Firmware” is of today’s flight. The Normal Firmware log contains two flights, the first one was a tuning flight (as this was done on a freshly built airframe) while the second one was for VTOL transition datalogging.
Points of note:
-The testing in these two logs was done on an airframe with a lower wing loading and a higher power/weight ratio, compared to the airframe that I have had the most issue with. I used this one for safety sake, as it performs better all around.
-The yaw “issue” during transition is less noticeable on this lighter aircraft, but is still present.
-The modified firmware seems to have the desired effect, unexpected yaw during transition has decreased and the remaining amount could likely be chalked up to wind.
-However, I noticed an odd behavior during quad flight. Using Q_Stabilize, control sensitivity felt greatly impaired compared to normal firmware. Especially pitch forward. Not sure what’s up with that. Might be related to the new code, might be something to do with the fixed wing TECS tuning I did on friday.
-Q_loiter was perfectly fine
-Yaw in quad was greatly out of tune, compared to normal firmware. I messed around with the PIDs for a few minutes to get it “good enough” to test, but ideally I’d like the fix to allow for standard (non-vectored) yaw control for quad frames. Aircraft with only a single tilt servo wouldn’t be able to function with what I flew on today.

Ok, I’ve done some more test hovers while playing with params. it appears that my Q_Stabilize pitch control issue was indeed caused by TECS settings. Not sure what the path to solving that would be, though, it’s either “Fly with incorrect TECS settings” or “Fly without adequate Q_Stabilize control”. I’m not sure why TECS is affecting quadcopter modes in the first place?

that is odd, as TECS is not used at all in QSTABILIZE mode
regardless, I think your results are sufficient that we should create a frame type without yaw control in the AP_Motors backend, leaving yaw to the vectoring

2 Likes

Hi Tridge,

I’ve got the same issue that James and Marco: the plane always yaws in transitions when the front servos tilt (H configuration). Are you still planning to add a new frame type without torque yaw control?

Hello everyone,
I was also testing a vtol quad plane with front 2 motors tilting(x config)… I am also facing the same issue of yawing. please let me know if you all were able to find a solution.
Thanks

Having the exact same problem running the same configuration, is there any solution or fix?

Or does the pilot just have to fight it like seen in the video above? We wanted to run an auto mission with ours and the autopilot likely would not be able to handle it.

If anyone can help or any devs have instructions any help would be appreciated. @tridge @Leonardthall

1 Like

hi all (and especially @ianfreemantle who I promised an update to a while ago).
I know it has been quite a while since this issue was raised, but we’re finally getting somewhere. Over the last week I’ve been working with @kris and Brandon MacDougall over in a new quadplane ardupilot discord channel (see https://ardupilot.org/discord ) and in the simulation channel.
There are several efforts happening in parallel:

  • we’re working to create two good quality tilt-rotor quadplane models to allow us to test solutions to this and other issues affecting tilt vectored quadplanes. The first model we’re building is a model of the Arace Griffin https://araceuas.com/ thanks to assistance from Alex and Adrian from Arace.
  • I’m working with @kris to incorporate a number of changes he has made for ArduPilot on tilt-vectored quadplanes. This includes changes to yaw handling in transitions using differential thrust to cope with yaw inbalances. We’re discussing a possible change here: https://github.com/ArduPilot/ardupilot/pull/15960 . That work is on hold until we get good simulation models for testing
  • I’m working with Alex from Arace and @iampete to work on a list of feature priorities for these types of vehicles.
  • I’ve started work with @Leonardthall on a new approach to tilt vectored quadplanes that will use a vectored AP_Motors backend, so knowledge of the vectoring of the motors is build right into the motor mixer, instead of being an add-on in the ArduPlane code. That should allow us to get much smoother transitions under a wider range of conditions. We’re hoping to prototype that code over the next month.

A number of people have offered to test some of the proposed changes. I’d like to hold off on that for a few days at least until we have the simulation models working and the changes tested in simulation. Once that has happened we’ll start looking for people to test the changes.
Sorry this work has taken so long to get started.
Cheers, Tridge

3 Likes

Awesome, thanks for the update and for all the work done on this.
I’d definitely be keen to test the changes once you have the sim models working.

We now have a nice model:


I can already offer some advice based on testing on this model.
If you are flying ArduPilot stable or master releases or then you should keep the Q_TILT_MAX angle small. One of the key differences between the ArduPilot releases and the firmware that @kris has developed is that his firmware can handle large values of Q_TILT_MAX. For example, ARACE normally set this to 73 degrees for the Griffin. If you try to fly ArduPilot 4.0 or current 4.1 with Q_TILT_MAX=73 then we get wild yaw problems and the aircraft crashes in the simulation. If I test the firmware from @kris with the same settings then it flies well.
This will be the focus of my work on tilt quadplanes in master, fixing the code so that yaw is handled well with large tilt angles.
Cheers, Tridge
2 Likes

I’ve now got yaw control during transitions working a lot better. Demo here:


The PR with the changes is here:

After some review and discussion I will be looking for some brave testers of the new code

Hi Tridge/All

Here is the log of my first and second transition. The first was accompanied by a significant left yaw so it could be worth a look…the second not so much, no parameter change. Q TILT Max = 50 QTILT RATE DOWN =80, QTILT RATE UP = 200, these are Parameters from foxtech 4.1.0dev currently running 4.0.7.

Greg Covey identified that my servo auto trim needed changing for safer flight…weird I have just connected my nimbus via mission planner and servo auto trim is set to 1 apparently this was off during flight > to a continued decent and Q Stabilise bail out. My parameter file also has my q-alt-assist as 30 yet my current parameters in MP indicates 0. Just a couple I’ll be sure to check during pre-flight.

Steve
https://1drv.ms/u/s!Auv-5QlGCPQokSjGOuIX2XzBSvNe?e=YnXDAw
Password= Password

If you are willing to be a guinea pig I can build you a test firmware with my new tilt handling code. Note that you would likely be the first person to fly it outside of simulation, so it is not a low risk flight.
Are you interested?
Cheers, Tridge