Hello everyone，I build a quadplane which has 4 motor and two front motor can tilt.I follow the quadplane document to setup my aircraft. Now my quadplane work fine in QSTABLIZE and FBWA,but it cause yaw swing when I switch QSTABLIZE to FBWA. I try to open VectoredYaw,but the problem still exist.This problem is bothering me for a long time.Hope someone can help me solve this problem.
A log would be useful but I have a few suggestions as I had a similar looking problem
Are all all the esc calibrated correctly
Check the both front motors are rotating down at the same speed and stop with the props vertical and horizontal
I have been calibrate the motor esc and I try use different throttle in transition.
This aircraft used Kris firmware before, everything is normal, so the mechanical part should be no problem, but when I switch to the official firmware, the transition process will appear swing.
I have uploaded the log in the post.
Hi David Ardis
I did check that the range and behavior of the tilting servos were normal.
I found in the forum that there are several people with similar models to me who have the same problems as me. So I suspect that the official firmware does not support this type of tilting aircraft.
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.
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.
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.
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