Servers by jDrones

Dual-motor tailsitters

(letpi) #1544

I have loaded and tested the prquadts fw for some days now for a total of 9 flights and dozens of transitions. I have tested all kind of attitude and speed to enter back transition, I also flyed acro and manual as I did before and this time all transitions were perfect. So impossible to reproduce the bad back transition, very good job…

Maybe the only thing to be aware is the back transition need some speed. Because I set Q_tailsit_vfgain=0.1 (almost 0) and because there is no differential thrust from top and bottom motors until the transition angle, the pitch rate rely on flaps efficiency and wing equilibrium.

Now I am going to make an other fast wing non vectored with 2208 2600KV motors on wings and 1808 2600KV top and bottom motors. On 4s and 5*7.5 props it will be around 1500W and a little more than 400Km/h pitch speed. The TP100 airfoil is already printed…first tests within 2 months

(Mark Whitehorn) #1545

That’s good news; there must have been a bugfix applied to master in the meantime. Thanks for the log, I’ll take a look at the transitions to see if I can think of any ways to improve them.

(James Near) #1546

Has anyone come up with a good writeup of steps to follow before the first flight after everything is built. Want to make sure I don’t forget anything.

(Pavel) #1547


We are trying to perform a SITL simulation of a tailsitter model with an AUTO mission. We are not using any flight simulation SW, just bare model.

And we cannot launch the model - due to “Gyros inconsistent” error the arming is failed.
The mission is pretty simple - it consist of 4 WPs only, and we were able to fly it with at least qiadplane sim. model.



The SITL is freshly installed to a Ubuntu 18.04 VM.

(letpi) #1548

This is at least how I proceed. This is surely not complete but a start if someone wants to add his own experience.

CG position :
To fly as fixed wing the CG MUST be somewhere between let’s say 15 to 22 % of the wing mean aerodynamic cord. The link bellow is a tool to calculate the M.A.C. and find CG location as a function of the wing design.
Keep in mind that the small fuselage of a plank wing may change the CG location by 1 or 2%.
CG in the middle of the wing thickness with respect to the Z axis is better. Check both wings are equal weight.
I think the hover is more stable when the CG is at ¼ of the wing cord of the wing section behind the propellers. For most wing design it means you take advantage to set the CG as close as possible to the neutral point of the wing. But beware that bellow 3 % of static margin there are a lot of chance the wing will be totally not flyable as a fixed wing.
Large flaps and ±40 ° throw for a non-vectored tailsitter. Less surface and less throw (±30°) is acceptable for a vectored.
Tilt motor : -45 +80 °
Both motor equal thrust

Q_A_ANGLE_BOOST=0 (for vectored I guess but I am not very sure)
Q_ANGLE_MAX=2000 for first tests then increase step by step.
Q_VELZ=100 for first tests then increase step by step. This low value gives safe back transition (to q_hover) whatever the throttle stick position. Of course it will take a while to land.
Q_transition _ms : I don’t remember what is the default value but 3000 seems to me a good start.
All Q_a_rate default values

Hover flight
Wait for a calm day without wind.
If your wing is vectored and takeoff from belly, remove propellers and switch to q_hover to verify is you get tilt motor oscillations. If yes you can break propellers. I have no solution for that.
Takeoff with q_hover or Q_stabilise mode, control there is almost no flaps or tilt motor oscillations, observe flaps neutral position.
Pull and release the elevator stick and observe, try to increase q_a_rat_pitch_p as much as possible, look for overshoot and oscillations.
Yaw the wing for several 360 turn and observe the EKF compass gauge.
Roll the wing carefully because it can go fast in that direction.
When after takeoff the wing drift in one direction (without wind) and take time to stop you can try to increase the relevant Q_a_rat_xxx_I parameter. But try to understand first why the wing is out of trim.
PID tuning take a lot of time, to save time you can test qautotune available in the last built. There is a dedicated qautotune blog.
When you are happy with your PID, increase Q_max_angle step by step.
If you observe flaps oscillation at high lean angle try to decrease Q_tailsit_thscmx from the defaut value of 5 up to 1.
If you observe throttle pulses while flying q_hover and high lean angle you can try all Q_AZ parameters.

Log analysis
Plot Q_Tune - throut, look at the hover value and use it to set Q_M_THST_HOVER, Set Q_M_SPIN_MIN about 1/2 of hover value and not lower than 0.25. These 2 parameters are critical for transitions.
Plot XKF1 pitch, XKF6 pitch, AHR2 pitch, ATT pitch : curves should be superposed except ATT pitch
Plot XKF3 “IVN, IVE, IVD” “IPN, IPE, IPD” “IMX, IMY, IMZ” refer to the wiki for interpretation
Plot Power VCC and Vservo

From q_hover to FBWA and fbwa to Q_hover: should be OK with above recommendations
It is always better to have the throttle stick centered.
If the wing has not enough speed to complete a smooth back transition, try to increase Q_M_THST_HOVER and Q_M_SPIN_MIN.
If you want the back transition to proceed sooner with less altitude gain try to reduce Q_TAILSIT_ANGLE

FW flight
Wait again for a calm day and proceed autotune as soon as possible.
For the beginning, avoid any back transition from an auto mode flight and do not use Q_loiter.
Q_tailsit_vf_gain is not really useful: a low value of 0.1-0.2 is OK.
Rudd_dt_gain together with kff_rddrmix allow using differential thrust as rudder. That’s very nice but should be increased carefully if you don’t want to make U turn.
Make the same log analysis as above except for the throttle tuning I use Ctune
Look at your flaps position when flying level at different speed and compare them to the neutral position. If your flaps are below (or at) the neutral position it may indicate the CG is after, that’s really dangerous.
good luck

(John V) #1549

Time for the “reveal” of what I have been doing. Up front, thanks for the invaluable resource and community. Just thought y’all might find this interesting, it’s what I’ve been working on. This company provides secure data network to first responders etc. Basically they set up a mesh network bubble with high-speed data and then when someone goes outside the bubble, like smoke jumpers or a sniper team, my drones autonomously fly over and provide high-speed data re-trans. Enjoy

(Mark Whitehorn) #1550

Very cool. Congratulations on your success and thanks for posting.

(Mark Whitehorn) #1551

@losawing @iampete @tridge Here’s my latest version of the quad tailsitter code, getting closer to being ready for master, but still just a PR against my own fork:

It uses servo functions k_motorN (same as multicopters) and Q_FRAME_CLASS=14 for the quad config. Elevons are the same as before.

I’m having trouble with this version pitching dramatically downward on forward transitions though. I’ve seen this problem several times (it’s what destroyed my real Stryker model) but haven’t been able to determine the cause. It doesn’t seem to be correctable using PTCH* or Q_TRANS* parameters.

There are links to video and SITL model/params in the comments on the PR

(letpi) #1552

It looks like the pitching downward on forward transition is a stall. Did you tried to increase q_m_thst_hover about 0.1 above the hover value and may disable hover learn if enabled.

(Mark Whitehorn) #1553

@losawing It turns out that increasing Q_TAILSIT_ANGLE from 45 to 60 degrees and decreasing Q_TRANSITION_MS to 500 msec eliminates the pitch overshoot and forward transition loses only a few meters of altitude.

The hover learning patch hasn’t been applied to this branch, and q_m_thst_hover is set fairly high.

I see that you have Q_TAILSIT_ANGLE set to 40 degrees for your quad flying wing; do you have any advice on how to find the best values for these params?

(letpi) #1554

I do not understand your observation about q_transition_ms . I suppose Q_transition_ms set a pitch rate, so the lower, the higher the pitch rate will be and probably the overshoot too.
If I am correct Q_tailsit_angle is relative to vertical for forward transition (and relative to horizontal for back transition) so increase it allows the wing to accelerate more and this is what we want.
Looking again at your video, the transition occurs without speed. I looked at the log of my quad flying wing to see what is the value of Qtune_throut; it is 0.45 (hover value is 0.42 and q_m_thst_hover=0.45) for both forward and back transition but rcout c5 to C8 are different depending of the transition. Always 1450 steady for back transition and always 1555 average for forward transition. I don’t understand this difference but my conclusion is the fw allow for extra power in order to accelerate. How is it from your side ?

(letpi) #1555

Could you send me your last version fw. I hope to be able to test it next WE, this is the faster solution to see if the bad transition is parameter or fw dependent.

(Pavel) #1556

Perhaps a stupid question, but I have found that YAW control of my model is reversed in hovering, I checked in QStabilize and in QLoiter.
I.e. RC YAW left - plane rotates right, and RC YAW right - plane rotates left.

Is that correct behavior of YAW in hovering?
All RCX_REVERSED are set to 0

(Peter Hall) #1557

Looks right to me, some times hard to get your head round the rotation change.

(Pavel) #1558

We have successfully flew an AUTO mission.


The mission went well, just at the beginning, the plane didn’t follow the mission but recover anyway and landed at the destination WP.


(Mark Whitehorn) #1559

Yes, my parameter values don’t make much sense. I need to understand the code better too.

I put fmuv3 binaries for my latest version of the code here:
along with the SITL params I’m using. Beware that this hasn’t been tested on a real vehicle at all yet. Frame class for a quad tailsitter has changed to 14, as you can see in the .parm file.

UPDATE: I fixed a few potential problems and regenerated the binaries just now. Also note that the servo functions for the motors are now the same as for copter, by default on channels 5-8:

and that the motors to be used in forward flight are specified by a new parameter Q_TAILSIT_MOTMX (thanks to @iampete)
To use just the wing motors in forward flight, set the mask to 3
to use all 4 set it to 15

(letpi) #1560

thanks a lot for the binaries and for this new implementation. I looked at your last PR, I understand only a little, but it seems to me it open a lot of new nice possibilities.
I also made a comparison of fixed wing transition between the sitl data flash log available on your PR and the prquadts log (post 1521)

You can see that top and bottom motors does not behave the same ;
1- much more differential thrust between top and bottom motors with the new code.
2- average value of C5 to C8 output are above hover (by about 100) with prquadts but are equal to hover value with sitll211, thus no speed for transition and stall.
3-qtuntrhout is steady but increase with sitl211, don’t know if matter
4-in both case the transition occur at the right lean angle but the pitch rate is about 200 °/s instead of 40 °/s thus the overshoot. Right before transition top and bottom motor thrust reverse but it is too late.
5- q_transition_ms corresponding to sitl log was 3000ms that is a very good value and does not explain the pitch rate increase.

So, I can not really help, but I think now the overshoot is not only a parameter problem, maybe you already found the solution. Keep going …

(Mark Whitehorn) #1561

Thanks for the analysis. I hadn’t been using apmplanner2 lately, and forgot that it also plotted messages like “transition fw done”. That’s really handy.
Also thanks for pointing out issues with thrust on transition and the top/bot motor behavior; I hadn’t thought about them making the overshoot worse.

(Mark Whitehorn) #1562

I found a bug in the tailsitter forward transition logic. The fix is in master, and I’ll generate a new quad-tailsitter PR against master with major improvements from @iampete tomorrow.

(letpi) #1563

this is hard to believe, they removed the bottom motor ???