Dual-motor tailsitters

The recommendation is: Change to vectored as I did it with the same frame.
Already after the third crash.

And it works perfect:

The age is not a negativ criteria, I’m 77.

Thanks for your answer ! From reading this big document I already felt that non vectored tailsitter are not so windresistant that a vectored one. It it secessary to have a fully 180 degree angle or may it be enough to have 120° ? I am not sure I could realize a 180° total tilt angle…
Greez ;
acdc1

If you look some postes above, JUSTASON seems to work with less.

I use this servos:
https://www.hoelleinshop.com/Sender-Servos-etc-/Servos/Servo-HS-5070-MH-Hochvolt-Miniservo-Metallgetriebe-Multiplex-HiTEC-113070.htm?shop=hoellein&SessionId=&a=article&ProdNr=M113070&t=182&c=187&p=187

If you buy the programmer they can be changed to 180°
The same supplier can also it program for you with 180° angle if asked.
Otto

There are 2 things
The first one is to get the control surface moving in the right direction when you move tour TX sticks. I can see in your video this is not the case for elevator.
The second is to verify in FBWA that the control surfaces move the correct way to return to level flight For this control, hold the aircraft in your hands, pitch and roll the plane.
If your plane is able to hover I think the second item is OK. So you may just reverse elevator with your TX and make both test again.
I think the first video crash is an other problem.

±60° is plenty
+90 allow to land on the belly

Many thanks for your input ! before I convert my VTOL to a vectored one I will give it a last try …Therefore I would like to extend the ailerons throw …The q_Pitch_P value is not the right parameter …Does anyone have an idea which parameter to increase to get the foll throw of the servo ? I saw on the log that ist barely hits the ±40 degree value - although 60 are available …

q_a_rat_ptch_p is the parameter which converts pitch speed error to servo throw.
I think this is the parameter you are looking for.
There is also mixing_gain that you can raise up to 1.5 but the elevon mixer may saturate.
mixing_offset is a parameter to configure the aileron response vs the elevator response. If I understand correctly, a negative value will give more throw to elevator at the expenses of aileron. I never tried it.

Hi Claus, have you checked whether parameters SERVOn_MIN/MAX are limiting your elevon throw?

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 :+1::sunglasses:

Hi Losawing, your suggestion makes sense, will try it out this afternoon, if the weather stays dry ! thanks for your help!
:+1:

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 :grimacing:!
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 :smile:
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:

  1. 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.

  2. 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.

  3. 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.

  4. Enable auto weather vaning in auto modes, i think this should just work just need to be enabled for thrust vectored tail sitters.

  5. 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?

  6. 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.

  1. 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