@losawing @iampete I just updated the pr-feature-tailsitter-gainscaling binaries with a fix for the bodyframe roll limit. Also updated the associated PR.
Tests OK in SITL with the quad Stryker.
Hello mark,
Every thing is fine and safe except some angle related troubles, definitively these angle questions seems to be very complicated.
q_tailsit_rll_mx is working again with the last binaries but it appears this parameter limits also the roll rate (plane frame) in q_hover mode (q_yaw_rate_max is disabled), so when q_tailsit_rll_mx is set to 20 the roll is very sluggish.
Also I found q_acro_rll_rate and q_acro_yaw_rate are reversed, rll_rate control yaw rate (plane frame) and yaw_rate control roll rate. I think this inversion is not new as I found the roll to be very sluggish with default parameters since (at least) binaries from post 1759 but I did not understood why and thought it was the airframe.
Thanks for the bug report. You’re right about the roll rate limit; I must have screwed up when testing the bodyframe roll/yaw control fix. I’ll let you know when I’ve figured out how to fix it.
The reversal of roll and yaw between plane and multicopter frames is difficult to deal with; right now the acro rate parameters are taken to apply to the multicopter frame so they are swapped relative to the tailsitter body frame. I’ll see if I can find a way to hide that reversal by making the code even more confusing 
The code work just fine. I would just adapt the parameter description.
@losawing It looked like the Q_ACRO_RLL_RATE and Q_ACRO_YAW_RATE parameters were accidentally swapped for the tailsitter case, so that was an easy fix.
I think the roll and yaw rates for QHOVER and QSTABILIZE modes are also correct now for both bodyframe roll modes (TAILSITTER_INPUT_BF_ROLL_M and TAILSITTER_INPUT_BF_ROLL_P).
I updated the binaries at pr-feature-tailsitter-gainscaling
1 Like
This binaries seems to be the perfect one. Nothing to complain: acro rates, roll limit, transitions, gains attenuation… it works perfect.
A video taken early this morning while my flying field was empty. First 30s is qhover to show roll limit and yaw rate, the rest is qacro. A little crash at the end because I was not fast enough to correct elevator.
2 Likes
Thanks Pierre, very impressive demo of QACRO mode and the gain attenuation feature. I assume you had Q_TAILSIT_GSCMSK=2 (ATT_THR)?
yes, you are right plus max attenuation =0.17 and tailsit_input=3
This morning I have loaded the last binaries in my batwing so non vectored dual motor and configured it as a copter tailsitter with q_tailsit_gscmsk=2 and max attenuation=0.2. I flown it with qacro mode and the result is absolutely amazing. The airframe is far better balanced than my test wing and the code run smoothly without oscillations at any speed and attitude, congratulation for that.
1 Like
@losawing,@kd0aij
I followed your project in the back. This is a good example of a perfect development teamwork.
Congratulation.
But sometimes the altitude of the ground is higher than the wing 
Otto
1 Like
Fantastic! Sounds like that gainscaling feature is about ready to go into master.
Thanks @losawing and @lorbass. Highly skilled builders and pilots are an absolute necessity for making progress in these areas.
Flying Qacro is a mix of heli and 3D plane, this is fun and a good training. A question: the roll of my batwing feel a little sluggish and I cannot increase q_acro_ roll rate over 200°/s if I don’t want the wing to roll past the point the stick is released. I don’t think this rate is an air-frame limitation because the wing roll is more responsive in manual (but not really flyable). Is there a solution to increased the roll rate. Increase q_a_rat_yaw ?
looks like Amazon are catching onto copter tail-sitters,
Fairly sure we could fly this with a copy and paste of a hex motor mix to copter tailsitters mixer.
1 Like
Do you have ACRO_LOCKING set to 1?
I’m not noticing any overshoot in roll in SITL with that on, but without it, attitude control is pretty sloppy.
For SITL testing, I have these settings:
Q_ACRO_PIT_RATE 180.000000
Q_ACRO_RLL_RATE 360.000000
Q_ACRO_YAW_RATE 90.000000
Q_A_RAT_PIT_D 0.003000
Q_A_RAT_PIT_FF 0.100000
Q_A_RAT_PIT_FILT 10.000000
Q_A_RAT_PIT_I 0.100000
Q_A_RAT_PIT_IMAX 0.500000
Q_A_RAT_PIT_P 0.100000
Q_A_RAT_RLL_D 0.005000
Q_A_RAT_RLL_FF 0.000000
Q_A_RAT_RLL_FILT 10.000000
Q_A_RAT_RLL_I 0.250000
Q_A_RAT_RLL_IMAX 0.500000
Q_A_RAT_RLL_P 0.100000
Q_A_RAT_YAW_D 0.000000
Q_A_RAT_YAW_FF 0.200000
Q_A_RAT_YAW_FILT 10.000000
Q_A_RAT_YAW_I 0.100000
Q_A_RAT_YAW_IMAX 0.500000
Q_A_RAT_YAW_P 0.100000
and roll response looks like this:
Could you post a log showing the overshoot?
Interesting wing design. Looks a bit like a “box wing” design, though I doubt that there’s much of an efficiency gain in their flight regimes. Must be a significant weight penalty too.
No, acro_locking=0 and attitude control is very strong.
Thanks for the parameters, I have some large differences with FF parameters and q_a_rat_yaw_filt (set to 1). I will try and let you know. I think I can find the log but not now it is too late.
@kd0aij @iampete, This is almost the same concept than the black fly opener. This is an interesting idea. The box wing is not mandatory, could be replaced by a more efficient wing design.
I had forgotten about the BlackFly, thanks for the reminder.
The yaw filter parameter may have been the problem. 1 Hz is probably going to add a lot of latency.
I think I found the guilty, it was not the yaw filter parameter but Q_a_accel_y_max which was set to around 25000. When set to 50000 the latency is very acceptable even with roll rate =300.
Both 1Hz and 25000 was the result of the q_autotune I did a long time ago. The autotune was pretty good for hovering.
Could you check with the SITL the back transition from Qacro to q_hover. I have had a bad transition, the wing yawing badly. I have not the log because I forgot to insert the SD card and I am a little afraid to test it again.