I have read your message until the end lately and have some questions / suggestions.
How are you able to fly your wing in q_loiter mode with the TX elevator stick reversed ? Could it be the normal way for you ?
Your wing seem to be very powerful and responsive but fly pretty well in q_loiter.
You are probably the first one in the world to try an auto take off with a belly sitter. I dont think there is a bug in the code but this is a possibility. But, from what I see with your auto take off attempt, there is not enough dampening, I would try to increase q_a_rat_ptch_d, q_a_rat_rll_d and q_a_rat_yaw_d to 0.01 or 0.02. Another possibility is the integrator is saturated and cause the overshoot, try to halve q_a_rat_ptch_I and q_a_rat_yaw_I.
Hi Marc, yes the limits are set and work when I am in manual mode 
Hi Losawing, your suggestion makes sense, will try it out this afternoon, if the weather stays dry ! thanks for your help!
Claus, I think you should be getting the full range of SERVOn_MIN/MAX in stabilized modes. Here’s a plot of elevon servo outputs from my last flight with the Dart with min/max of 900/2100 and pitch/yaw P gains on the order of .2
Test of hover learning with quad tailsitter: Q_HOVER_LEARN=2
(branch kd0aij/quadTSnew2) Seems to be working well now.
Just a small surge in throttle on switch from stabilize to hover, no apparent throttle change going back to stabilize.
Here is a log of automatic Q_M_THST_HOVER parameter changes:
2018-06-17 12:26:23.79: MODE {TimeUS : 497275110, Mode : 17, ModeNum : 17, Rsn : 1}
2018-06-17 12:26:36.19: PARM {TimeUS : 509673585, Name : Q_M_THST_HOVER, Value : 0.141690045595}
2018-06-17 12:27:58.52: PARM {TimeUS : 592005544, Name : Q_M_THST_HOVER, Value : 0.126243948936}
2018-06-17 12:28:19.28: MODE {TimeUS : 612764520, Mode : 18, ModeNum : 18, Rsn : 1}
2018-06-17 12:29:24.37: MODE {TimeUS : 677856884, Mode : 17, ModeNum : 17, Rsn : 1}
2018-06-17 12:29:41.97: PARM {TimeUS : 695454879, Name : Q_M_THST_HOVER, Value : 0.194112405181}
Video:
With a such low value it is rocket for sure.
Do you want to beat the world record of 0 to 100m altitude ?
https://makezine.com/2016/02/29/a-new-world-record-fastest-ascent-made-by-a-drone/
Our last auto mission attempt was a total surprise for us, because we did already few times take-off the wing in to the air with the auto mission.
Auto mission example #1
Auto mission example #2
That was before the MotorBatteryGroup change, and unfortunately logs are not available…
Finally hat some testing Time yesterday eve.
With the modified parameters I could accieve a maximum of elevon movement and I got a pretty stable hover …only slow sind around .
I climed in q-hover and gave full throttle an then switched to FBWA…
ended in a crash …decided that this was the last one with this setup 
!
Now I will try the vectored version of my Caipirinha2.
If someone with this wing could send me the parametersetup for a first startup ? Just do go over the essential q parameter set 
Thanx in advance …
claus
Hello Claus,
Here in this Forum my Information.
And here my last Params bevore I changed to Version 3.8.3 Beta3.
In the meantime no more Flights because working on a new Project.
Vor wechsel auf 3 8 3 beta3.param (16.1 KB)
My Method to find the Params without Crash Risk
Regards, Otto
Hi all,
I have been having a think about what to do next to improve the code for vectored tail/belly - sitters. not necessarily in any order here are the things i have in mind:
-
Put control surfaces on the plane PID’s at all times, then ask plane controller to match rate asked for by the copter controller, I think this will require zeroing the plane integrator when in copter mode. This should allow faster flight and even gliding when in Q modes, should also remove the current ‘pumping’. This will also allow a sharper tune for hover to not be too aggressive with some forward speed.
-
Move back to airspeed based transition, should be better for thrust vectored aircraft as forward airspeed is not linked to pitch angle as it is with none vectored tailsitters. Should also allow back transitions without gaining large altitudes.
-
Enable Q assist to ‘unlock’ vectored thrust with copter controller for forward flight, should allow very slow high alpha type flying in forward flight modes.
-
Enable auto weather vaning in auto modes, i think this should just work just need to be enabled for thrust vectored tail sitters.
-
Splint angle limits to pitch forward, pitch backward and roll. Might remove the Euler angle issue with using Q_ANGLE_MAX larger than 9000 as only one axis would be larger than 9000 so it wouldn’t get gimbal lock??, otherwise i guess we could go to quaternions, i think this already supported by copter?
-
Look into giving the code information about the tilt angle of the motors and do some maths similar to what is done for the yaw motor on tricopters. Should allow angle boost to work as expected too.
Would be grateful for any comments or ideas,
Thanks
what a great list ! Some points are beyond my knowledge but to begin with easier answer / comments
4.Weather vanning could be an nice improvement for q_loiter mode and would bring some assistance to the pilot. I am wondering if it would be applicable to other vtol modes. Probably the wind direction could be deducted from the lean angle.
2.According to my experience, the problem with back transition is not airspeed but the yaw (plane frame) which is not controlled until the aircraft reach q_tailsit _angle. As long as airframe and motor thrust are well balanced and q_m_thst_hover + q_m_spin_min are high enough this is not a problem. But yes this could be at the expense of altitude gain. however I dont know what is the parameter which control pitch up rate when the back transition is engaged. The forward transition is a total mystery for me, I tried to analyse the log but still dont understand which parameters control throttle and pitch rate.
5. Agree. I have q_angle set to 70° with my aircraft. This is fine for pitch but really dangerous with roll. A 30° limit for roll would be fine. I cant say about the euler angle question, I dont understand what the problem is.
6. cant say if this wouldbe useful or not. My experience is tilt motor is already very efficient.
3. I also have the feeling that tilt motor can be very powerful against stall. Currently, the correction aim at leveling the wing. So what to do ? Just Increase q_tailsit_vfgain when airspeed is low ? This would help to control roll (plane frame) at high alpha.
- I dont understand what you mean exactly. I have spent hours to tune PID in order to achieve a smooth and fast forward flight in q_hover mode and I make progress every weeks. With a max lean angle of 70 to 80° the maximum speed is already impressive but the limit I have found is the wing want to turn level and this is not possible at high speed.
Hi Pete,
Thank you for continuing the work.
The idea to improve the item above is great. Really difficult to find params to avoid the pumping.
I spent 50 Testflights without succes to find a solution with changing params.
Good idea to improve the back transition. Should be selectable by a param for those wings without air-speed sensor.
Another idea:
The param Q_M_THST_HOVER is according to a comment from tridge to set the integrator for Q_Hover and has no effect on Q_Stabilize.
Therefore when changing the Flightmode from Q_Hover to Q_Stabilize the wing falls down or climb up when the required Thrust to hold Alt. for Q_Stabilize is not 50%. This because the stick for Q_Hover to hold Altitude is at 50 % before switching back to Q_Stabilize.
I solved this issue by programming a curve in the TX so that the midstick Pos matches the required thrust for holding altitude in Q_Stablilize.
Perhaps this “curve” could be realized in the Firmware?
The other points I can’t comment.
Greatings, Otto
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 ?