Hi Pete, glad to hear your ideas on improving tailsitter support.
Re (1), do you mean to use the same gains for both the copter and plane PID controllers? I think we’d need to switch to a single (and more sophisticated) controller to accomplish that, since neither one is currently optimal for both hover and FF modes.
On (2), I think we might have problems with measuring airspeed at high angles of attack; and I also wonder how to account for propwash over the control surfaces. Would the code need to also support vehicles with no airspeed sensors?
On (5), I agree that we need separate pitch and roll limits. And we do have the option of using quaternions for setting limits.
I’m not sure what you mean in (6); doesn’t the code know what motor tilt has been commanded?
I have made some progress on the code, was hoping to go and do some testing this evening but I seem to have got some intermitent fault on the FC.
currently it just outputs a scaled value rather than a angle, if we give the code the maximum and minimum angle we can calculate the angle the motor its tilted at. So far i have just calculated the change in angle due to yaw and so as to increase the thrust proportional to that, so for yaw it vectors the motors and throttles up so the upwards thrust is the same.
I thought this would be very easy but its not obvious where in the code the limits are applied, would be great full for any pointers
i’m not too sure how well this will work I think I will just add a parameter so you can pick airspeed or angle based transitions.
For this first point, I mean to run the control surfaces using the plane gains all the time. I have found for hovering on my aircraft the control surfaces provide little help, It will hover fine with just the vectoring. As airspeed increases the control surfaces then become more effective and cause the oscillation. I was thinking of some complex method of speed scaling the gains for the control surfaces, but in forward flight modes i can get down to slow speeds and still have control and also very high speeds as there is a airspeed based scaling built into the gains. So rather than duplicating the scaling why not just use the plane pids for the control surfaces all the time. This should allow the vectoring pids to be higher, and you can auto tune them and it should smooth the transition somewhat as there is no hand over.
TLDR: the plane mode gains do a good job of control at all speeds where control surfaces are effective and it doesn’t matter if they do a bad job in hover because the control surfaces have little effect compared to the vectoring, so just use them all the time
again just a idea to try out, i’m hopeful though
This must also be a problem for copter, they must have a solution we can use, i guess even some sort of delay on the inputs to give you a chance to move the stick. I have been thinking of something like that for transitions if you fly forward in hover mode before transitioning when you transition the aircraft wants to pitch thru 90 deg if you keep the pitch stick the same, would be better if it just carry on at what ever angle its at until you had a chance to get the stick centered again.
The copter controller is currently called from QuadPlane::multicopter_attitude_rate_update
using a function which takes Euler roll and pitch angles:
attitude_control->input_euler_angle_roll_pitch_euler_rate_yaw
when not in "pure VTOL mode"
But there is also the option to use method
AC_AttitudeControl::input_rate_bf_roll_pitch_yaw_2
which takes rates instead of Euler angles.
You can impose separate roll/pitch limits the way I did it here:
Q_M_THST_HOVER does affect Q_Stabilize mode as it is used to scale the control surface outputs with current throttle level.
If you change Q_M_THST_HOVER your tuning will change. And if Q_M_THST_HOVER is too low, there won’t be enough movement available. Increasing the gains won’t help in this scenario because the scaling happens after the PID output limits are applied.
Hello! I’m putting together a tailsitter build and having a problem related to orientation, I think…
In plane mode (FBWA) everything is fine. The elevons move correctly both by pitch/roll stick movements, and when moving the frame around in FBWA mode. But in Q_HOVER and Q_STABILIZE modes, the elevons move in the opposite direction to what they should.
Additionally Q_HOVER and Q_STABILIZE both seem to be ignoring the attitude of the frame, they only react to instantaneous movement (as if using gyro only). Shouldn’t the elevons be moving in such a way as to auto-level the frame, same as how FBWA does?
In all cases the HUD display in MP looks fine. The horizon switches by 90 degrees as expected when changing between FBWA and the “Q_” modes. When I move the frame around the HUD reacts correctly in all axes for both modes…
I think I have followed all the tips in this thread, but maybe there’s something else I might have missed? I’m running plane3.9.
The only kinda strange thing I have done in this build is that AHRS_ORIENTATION is set to 22 (Roll 270 Yaw 90) due to the way I have mounted the flight controller. Given that the HUD checks out fine, this seems unlikely to be the cause, but I thought I’d mention it since the symptom looks like an orientation issue.
Only thing I can think is the Q_TAILSIT_INPUT parameter changes the control from hovering with multi copter controls (0) or like plane (1), so plane frame roll would be copter mode yaw, I’m not sure this would give the problem your seeing tho. I guess just double check all the control reversals in the transmitter and parameters.
yes that is correct they should. Possibly the gains are not correct, what sort of air-frame are you using? I’m sure some one will have a good set of parameters to get you started, they are abit of a pita to tune currently. Have you tried the test with it armed, this does seem to make a difference for some reason.
I have my FC mounted at orientation 12 (Pitch180), although possibly because this is just a pitch change it may mask a issue, but as you say if it looks correct in on the HUD it should be fine
looking forward to a tail-sitter vid
in vtol modes, nose up and q_tailsit_input=0, if you apply rudder left the left aileron must goes down so your aircraft will turn to the left. This is opposite to the plane logic.
I think what you observe is normal.
Yep ~ same problem I had which I wrote about months ago ~ never was able to fix it. Check to see if all is fine when you change Q_Tailsit_Input ~ that is the case for me. Everything works fine in Q_Tailsit_Input=1 but when I change it to Q_Tailsit_Input=0 the issue you describe shows. Is that the same for you ?
I would guess this is due to a inputs reversal issue, you can mask rudder input being wrong by reversing the outputs as its not used for stabilization, this would have no effect in with Q_Tailsit_Input of 1 as rudder is always rudder. Thing to do is go back and check against the inputs set on the wiki :
‘‘The green bars should move in the same direction as the
transmitter sticks (except for Pitch where the bars move opposite to stick movements - low values are forward, high values are back). If the green bars move in the wrong direction, reverse them using your RC transmitter’s channel-reverse function (see your RC gear’s manual for guidance).’’
I would not use the input reversal parameters they seem to sometimes have no effect on the mission planner output bars, the other thing that may be easier is just to calibrate the radio using Q ground control as it does all the reversing automatically I think
once your inputs are correct then you can go thru and reverse your servos as needed
Isn’t what you said identical with the documentation?
http://ardupilot.org/plane/docs/parameters.html#q-tailsit-input-tailsitter-input-type
I always use Q_TAILSIT_INPUT=0 and it behaves exactly as intended.
@Otto : Thanks for your input 
Now I finished assabling the new vectored hardware - tonight will try to configure it . Are the elevons and the motors moving during q_stabelize and Q- hover ? DId a short test yesterday eve …I was wondering …thought that only the motors were moving in q-flightmodes …you can ghelp me with that …
Greez ,
Claus
@ Claus,
Verry quick the change.
Yes, both are moving if the param MIXING_GAIN = 0.5 .
(0 without Elevons)
Regards, Otto
ahhh… all I had to do was arm. Now everything is going ok.
I had actually tried arming earlier, but that was when I was still using EKF2 and everything went really weird (HUD horizon immediately moved to about 45 degree roll when armed, then returned to level when disarming, this was fixed by using EKF3).
The reasons I didn’t think arming would be necessary to check elevon movement are 1) because for FBWA the elevons move as expected without needing to arm, so I figured arming only affected motor outputs, not servos and 2) because the servos do actually move in response to frame movements when disarmed, just not correctly.
hi all ,
yesterday eve I did my first flight with my Caipirinha 2 - now with vectored Thrust. My whole setup is about 1.5kg - 4S 5000mah - Motors MN3110 780KV -
The q-hover was pretty stable - although It was swinging in the PIT axis . Need to reduce q_a_rate_pit_P
And in roll it felt a bit sluggish. Have to increase the roll value.
Which way I should try the first transition. With my new motor mount I don’t wanna crash it in the field 
If all axis are stable after the next test I would like to try a trasition .
Do I have to fly a special figure to make a save transition ? If someone could give some advice I would appreciate it
Regards ,
Claus
PS: In plane mode the elevons are moving in the right direction - chose the same setup parameter as I used before converting the Caipi to a tailsitter …
PS2: Is there any possibility to tune the Q_a_rate values in flight with an extra channel ? As you can do with plane and copter ??? did not find a valid parameter …
PS: Do not lean backwards (e.g. if there is wind from back to hold position) else it would start to fly in plane mode backwards and roll.
PS2: Yes, possible here:http://ardupilot.org/plane/docs/common-transmitter-tuning.html?highlight=tune_chan
Good luck, Otto
Then that happens (from the eighteenth second):
Good luck, Rolf
Just put this here, amazing work
Hello ,
I finally made some tesing qhover experiments. Now my wing is oscillating in the wind when I lean againt it.
Did not try to switch to fbwa caus of the instability.
maybe someone is able to get some information out of the log …
thanx in advance,
claus
hi Claus,
where are the logs ?
Oscillations are probably due to some Q_a_rat parameters set too high but may also come from something not rigid enough. Check servo linkage and flight controller mount.
pierre
In case you use my Params. This are for an older version of the FW.
I remember, they changed something with proportional Thrust. (Many posts above, Thrust scaling)
And then, David (palm369) reprorted that his params and his calculation system didn’t work anymore.
But this oscilating, when leaning against the wind, this could be also a so called pumping
And this pumping effect seems to be an issue of the control.
I worked weeks to find params to eliminate this pumping with no succes.