airspeed gives better performances for auto, loiter and RTL modes as it allows to keep airspeed accurately set to trim_asrpd_cm value whatever the wind. According to my experience airspeed match correctly gps speed in the range 10-65 m/s. I have the digital sensor on my jetwing but I do not see improvement over the analog one. Strangely the analog is for me a little less noisy, but the analog seems to be limited to 58m/s. Bellow 10m/s I cant say because I have not a lot of experience but it seems difficult to get a good performance as the noise is always in the range 2-4m/s
I have loaded the last binaries in my test wing and found all the parameters you said. That’s clear for me. The weather is very bad this WE so I dont know when I will be able to fly.
I made a review of all q_parameters and found some weird value:
q_throttle_expo is set to 12 as it was 0.5 before
q_acro_pit_rate is set to 0.5
q_acro_rll_rate is set to 12
q_acro_yaw_rate is set to 90
Are q_acro_rates relative to plane frame ?
I’m not sure why we’d get bad values for parameters when flashing a new firmware. I’ll check the source to make sure the default values are correct.
Q_ACRO_RLL/PIT/YAW rates are body-frame max rates which apply in QACRO mode, and default to 360/180/90, respectively. I think 90 is a reasonable default for max yaw rate, but let me know if you disagree.
ACRO_ROLL_RATE and ACRO_PITCH_RATE apply in ACRO mode as before.
Both attenuation method are very fine. For the interpolation method I have had to set speed_min=1 and speed max=12. Transitions are OK, Q_acro with recommended rates is OK.
I tried q_assist_speed=9 with tailsit_gscmsk=2 and 4 but it seems assistance is disabled. What do you mean by bit 0 ?
Q_tailsit_rll_mx is still broken.
Thanks for testing the gainscaling options; glad to hear they’re still working in the updated PR.
TAILSIT_GSCMSK is a bitmask:
setting bit 0 enables BOOST, which boosts gain at low throttle
setting bit 1 enables ATT_THR: attitude/throttle based gain attenuation
setting bit 2 enables INTERP: interpolation between copter and plane controls
so to enable BOOST and ATT_THR, but not INTERP, TAILSIT_GSCMSK = (binary) 011 = 3 (base 10)
to enable only INTERP, the binary value would be 100 = 4 (base 10)
and binary 010=2 would enable only attitude/throttle based gain attenuation
I just confirmed that in SITL; will try to fix it today.
oops, that’s my bad, I just re-applied the previous fix without testing. Although looking at the code in mode_qstabalise.cpp it should be working.
@iampete The problem is a little complicated: rll_mx is working as it should when the nose is vertical (limiting bodyframe yaw), but when you’re pitched down toward the horizon in bodyframe roll mode things get confusing…
@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
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.
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.
@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
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.