This is a major issue I’ve had with a couple of prototypes, where the CG required for hover and the CG for forward flight just aren’t really compatible. I’ve tried two different styles of airframe, one with a lot of sweep and one much more of a plank, and the plank was much much easier to balance for both flight modes.
Hello Marius, this is Sergio Tellez, I tried to answer your email but it is returning. Please contact me with another email or fb SERGIO CHECO
Thanks
Sorry, But Checo from F1? 
Hello Sergio,
I send you a MP .
Best Regrds
Hello to everyone! Thanks a lot for that help @tridge
I already have flying the Mini Orca from @Checotp! It’s a great airplane, right now I just need to balance the airplane and upgrade the Telemetry module to start deploying missions with transition.
Here a brief video of Hover flight on QLoiter, I’m using PixRacer R15 and CAN GPS Location ONE from Mrobotics!
https://drive.google.com/file/d/1NMs3SSSoNy_HrMa9OkB_LcwRM42w0dML/view?usp=sharing
@hwurzburg Hi Henry, looks like you have some seriously good knowledge about N-V-tailsitters and params, and hoping you can help me. I built a non-vectored tailsitter from an AR Wing and it is indeed suffering from a “lean” and gets “stuck” exactly as you have explained above. However, the lean is only in one pitch direction - back towards me (i.e. when the vehicle’s top is facing me in a hover). When pitching forward, he can fight as much as he needs to stay in QSTAB, but when I bring him toward me, he “gives up” at about 20 or so degrees. I adjusted Q_Trim_pitch -5 degrees to try to cheat this tendency a little and that made no difference, I also adjusted the Q_max_angle param to 80 degrees (from the default 30) and this works for forward pitch, but again, not for bringing him back towards me. I even went so far as to add 50 grams of balast weight on his belly, hoping that would do it - no good. I believe my elevons are of sufficient size, as again, he behaves beautifully when pitching forward and fighting the wind. The only problem is his pitching back toward me, he can barely handle 15 or 20 degrees and then I know he’s done for (lol). With my quads, I know that raising I-gain fights off external forces like the wind, but does that also apply here? Any suggestions you have would greatly be appreciated. Pictures, logs, and params are included in my posts below. Thanks in advance Henry. Bill
I have very little non vectored tailsitter experience, but even vectored tailsitters can get into this “locked” position…usually my pitch tuning has not been good when this happens…from your graph above, it appears that its not great also, well before the “lockup” happens there is a lot of differences between demanded and actual pitch…and the only way out that I have found is to give it a lot of throttle in QSTAB in this position… its very similar to 3D planes in a hover with a lot of side motion…you can get going fast enough that full rudder will not make it return upright without a bit throttle burst… @marco3dr has a lot more experience with non vectored tailsitters…perhaps he can comment also
Thanks so much Henry! In terms of pitch tuning, what would you suggest? Bumping I-term up??
Been looking at your youtube channel, too, nice work!
first get FF right…that needs a graphical analysis using the logs(bit lengthy to explain…I need to write something up)…it should fly pitch and yaw(poorly) with just FF and 0 D/I/P…then increase D and then P and set I =P…unfortunately there are no tailsitter oriented tuning docs …all QuadPlane tuning docs are for STL and Tilts…might try to write up something when I get a chance…
Thanks Henry @hwurzburg. For Q_Pitch - I am now maxed out at .5 for both P and I, Maxed out on FF at .5 and my D is zero and it flies fine (except for the “backward lean and quit” problem) so my control (i believe) is as “snappy” as I can get it. Again this problem is only in one direction, back toward me. Literally everything else about his attitude and flight characteristics are just great - it’s just this one characteristic that results in a complete loss of control. A couple other things to note (and that I wonder might be problematic) are the fact that 1) I’m using an omnibus f4 pro and not a top of the line pixhawk or even a nice Matek F4 or F7 - so I theorize that possibly my FC can’t keep up with Ardupilot ? @tridge is the Omnibus f4 Pro hurting me here? Secondly, I am doing all this with a GPS only and no compass. Literally everything works great except for this “lean back and quit” problem. It has reared it’s ugly head on 4 consecutive prototypes over the course of a year and it’s driving me nuts! 
@marco3dr I sure would love to hear your thoughts as your vehicle looks as though its performing beautifully! Thanks guys! Bill
You have to waste days to analyze logs and understand where the possible margins for improvement are, it is not easy to write all the steps to be done in a post, sorry! 
The code also still has gaps to fill, especially on the land detector, which with non-vectored tailsitters is disastrous, so better land in QStab for now.
Also the lack of acceleration control at least on roll in translated flight should also be implemented.
We have already reached an excellent compromise but there is still something to refine.
@marco3dr I have a simple guide written for the wiki to do primary rate controller tuning (like that for the STL) as a starting point…feel free to comment on it…Add tailsitter tuning guide by Hwurzburg · Pull Request #4275 · ArduPilot/ardupilot_wiki · GitHub
most of the tuning guides are to get safe, not perfect, tune of the PID loops…but advanced guidance contributions on transition tuning would be welcomed! (personally, I just get them safe and fly…but I fly vectored tailsitters so things are a lot easier to get working)
1 Like
And the OmnibusF4 Pro will work as well as anyother flight controller…the higher end ones have more memory for scripts and functions removed from 1MB boards…and redundant sensors, board heaters, more UARTs,CAN, etc. but as far a flying in general, they offer nothing more in terms of control…this issue is not due to the OminbusF4Pro…I use it on many tailsitters I have
For me your guide is excellent as far as P/I/D and FF is concerned, I also do log analysis but I work mostly with TUNE_PARAM in flight (pot and 3pos switch), because visual feedback also helps a lot, but I don’t think it’s easy to make a guide on that.
Working in this way makes tuning safer since you can push the parameters to the limit without the risk of compromising the initial set-up of the drone, which always saves from possible overtuning.
Of course Q_A_ANG_x and Q_A_ACCEL_x are also very important.
Hello !
Thanks for concentrate all this precisions 
@losawing I’m working on an update to the bodyframe-roll code based on visualizations generated using a web tool called VPython. This is a link to the programs: https://www.glowscript.org/#/user/kd0aij/folder/QuadPlane/
EulerAngles just shows the attitude resulting from Euler Roll/Pitch/Yaw controls, and the effect of gimbal lock when pitch is near 90 degrees.
bodyframe-master shows the behavior of current ArduPlane master for tailsitters with the BodyFrameRoll bit set in Q_TAILSIT_INPUT:
- the “planemode” checkbox sets the PlaneMode bit in Q_TAILSIT_INPUT
- the ORTHOGONAL and PERSPECTIVE radio buttons control the projection to the display canvas
- the TRAIL checkboxes control plotting of trails from the tips of the roll/yaw axis vectors
- the VIEW radio buttons change the camera angle (right-mouse drag is free rotation)
- the RUN radio button controls the simulation clock (must be running to see yaw rate)
- the TEST buttons at the bottom run through some canned R/P/Y control sequences
bodyframe-roll-update is the proposed change in behavior. It’s the same for copter mode input, but different for PlaneMode. The “test Plane Input” and “test2 Plane Input” buttons highlight the major difference, which is to make bodyframe-roll independent of pitch and yaw.
I’m curious as to whether these programs will work for you, and whether the visualizations make any sense at all. Apologies in advance for the overly complicated presentation.
1 Like
hello Mark,
Yes programs work and visualizations make sense. I have tested plane mode. Bodyframe master behave like a real tailsitter (or the other way 
), I mean stick movements to make a coordinated turn at high (> 60°) and low pitch (<60°) angle are very comparable. But in real flight the dependence of bodyframe-roll with pitch and yaw is difficult to see as required bodyframe-roll is hardly above 30°. I have also tested the update and I can see a lot of differences, obviously the bodyframe-roll is now independent, but I need to compare more to make my mind on other effects.
1 Like
Great! Thanks for taking a look at this.
My PR branch is GitHub - kd0aij/ardupilot at pr-bodyframe-roll-update
and a binary for SITL testing is here: pr-bodyframe-roll-update - Google Drive
But IIRC, you aren’t using RealFlight. Level flight feels about the same (to me) in the simulator as the original. I think @hwurzburg will try it out in RealFlight also.
correct, I wanted to say ‘a real plane’
Hopefully I will test the binary next WE. My small non vectored tailsitter is now nicely tuned and fly at every pitch angle, it will be perfect for this task.
1 Like
That would be great. The new version might perform significantly better when flown aggressively, or when pitched backwards (inverted), but I’m afraid my piloting skills are not sufficient to test that even in the simulator. I can’t even tell which stuff is (or should be) backwards when inverted
But I think the new version does “feel” a bit better even in normal flight attitudes near straight & level.