One motor hover would be crazy! 
I am in holidays so I have time to fly my planes.
I made a test I wanted to do for a long time, this is to compare the power needed to fly when propellers rotates the AP direction VS the normal direction. I took my 1m 10 inches prop TVBS blue wing for that.
AP direction, almost no wind
Loiter average airspeed between cursor=14.98m/s
Average current between cursor=6.39A
Average Voltage between cursor = 11.78V
So power = 75.3W
Normal direction, 3m/s wind
Loiter average airspeed between cursor=15.17m/s
Average current between cursor=5.80A
Average Voltage between cursor = 11.96V
So power = 69.4W
This is 8% less !
And the feeling when piloting is a little better so I keep it.
1 Like
you mean as normal option A.
I have opted for this for the maiden flight.
Good news 8% and the feeling. Thanks for the test
yes, normal is A.
I forgot to mention that motors are 53 cm apart so 53% of wing span. The result could have been different with other motors location.
@iampete
I think I had a bug twice this afternoon with 4.1.dev.
It happened during a transition from Q_loiter to FBWA. During the transition the plane got crazy.
C5 and C6 are motors output. Normally right after the transition FW done message both motors have the same output but not this time and the plane made an uncontrollable side slip. I saved the plane by switching to hover (about 2.5 s reaction time, not bad considering the stressful situation) 
It happened twice during that flight. Between the 2 bad transitions I made a Q_hover to FBWA transition which was fine. After landing motors were fine.
Before that flight and since I uploaded 4.1.dev I also made 4 flights with a total 16 transitions from q_hover and q_loiter without problem.
Can you post the log (or DM it to me).
There are only 3 real forward transitions in this log at 471, 554 and 593s. Other where made at ground level holding the plane to check for motors problems.
You will see that after the transition at 593s, there is always a very large difference between attitude pitch and desired attitude pitch, this is something I have never seen before. But Attitude estimation is very close between EKF and AHRS.
Edit: with 4.1 log display only one IMU
This nasty looking pitch spike to - 90 is a artefact of logging. The log happens to fall between when the mode is changed and the Quadplane code updates the transmission state, you get a single time instant with the copter AHRS view rather than plane view. Then goes back to the plane view log until until the Transition VTOL done message. Its annoying but a major PITA to fix, does not effect the flight, logging only.
For the transmission to FBWA your airspeed is quite low,
It is interesting that you were already flying at 45 deg in Qloiter, so it should have more or less transitioned instantly, you can see the throttle jump to hover when your switch modes. I think that is a issue, but I donât think it would have caused the behaviour you saw.
I donât see a clear cause, maybe a stallâŠ?
Thanks for your answer
Transition from FW to Q_hover or Q_loiter is always very fine. This is not the problem.
Airspeed was low but normally the plane accelerate quickly after the transition message. I agree, the low speed means almost no aerodynamic stability and this is why right / left motors thrust must be the same. Please, plot the curves of motors output C5 and C6 and compare bad/good transition and you will see a large difference when transition is bad. Good transition is at 14:50:19
I agree also it is strange that the problem happen when FW transition is triggered from Q_loiter mode at 45°lean angle (wind was blowing). I made hundreds of successful transitions from qhover and lean angle is always 0 in that case.
This differential thrust is FW mode make me think of qassist. Is it possible Q_assist was triggered ? The Q_assist_speed parameter description tell us âzero means no assistance except during transitionâ. I have q_assist_speed=0 and it was a transition !
Edit: before the flight 241 I changed Q_loit_ang_max from 55 to 45. Same value that transition_angle
You can now see the Qassist state in QTUN.Ast log, this shows it was not assisting. This is the two throttle plotted with pilot rudder, looks just to be normal differential thrust.
1 Like
you were right, my FW transition issue was caused by bad tuning. This graph to explain
Every time I have this dead-full spin after the transition message, motors output oscillations can be seen on the log and when transition occur the output difference between left and right motor is frozen during about half a second. I found this duration is equal to throttle_slew rate which default value is 100%/s. When differential thrust is too high for aerodynamic stability the spin occur. This is what we can see on the graph above, a 360° spin in 1s.
The bad tuning was with high gain q_a_rat_yaw and q_a_rat_rll. I found also that motors output is higher during transition with 4.1 vs 4.0.7 so Q_M_thst_hover value was too high for the current tuning hence more speed and more oscillations.
Thanks for your help and happy new year
glad you found it!
Yes, we were directly applying hover throttle to the outputs in 4.0, in 4.1 we apply the same voltage and expo scaling that is used in the copter modes to get the true hover throttle.
This was the patch if your intrested:
Thanks for the link.
I have an other problem for you: from time to time during a flight with a lot of transitions, the neutral position of tilt motors drift upward and the neutral position of control surface drift downward. This is very bad as the plane become unstable in hover. C1 and C4 are control surfaces, C2 and C3 tilt motors.
This is the beginning of the flight, hover mode, wing almost vertical, RCin C2 neutral, control surfaces and tilt motors are close to neutral position (left side before hover is manual mode). Everything is fine.
End of the flight, again Q_hover: between 1263 and 1266s pitch is almost 0 and RCin C2 is neutral, you can see that RCout C1 to C4 drifted a lot and large oscillations show instability.
do you have servo auto trim on? We auto trim the elevons but not tilits so its possible that after some forward flight they are fighting. It does save prams so it should be clear if its changed. The only other thing would be the I term of the PIDs.
I have servo auto trim = 0
But for the I term you might be right, this is the plot of PiQ_P_I the exact moment I said servos neutral where out of trim. So what to do ?
You should be able to use Q_TRIM_PITCH to set the hover angle such that it does not need as much I, of course this might mean that you drift off in QStab and Qhover. It seems just to be that you have different ideal trims for forward flight and hover.
when my TVBS wing hover vertical with RCin C2 neutral, the balance is good and PIQP_I stay around 0.
But from time to time PIQP_I built, balance is broken and instability come. I have reviewed more than 20 logs and found this problem happen only when flying Qhover or qstabilise and only with plane 4.1.
The starting point of I building is always a EKF3 lane switch message. When I look at tilt motors output (C2-C3) this message is always immediately followed by a sudden jump of 100 to 300ms but no (immediate) jump of control surfaces (c1 and c4). The tilt motor shift is kept until a mode change to FW or manual. So control surfaces have to move a lot to balance the new trim C2-C3 position and this is why from time to time my wing becomes out of trim and fly badly. This is something I can see on the logs but also visually observed several time since 4.1.
A couple more tailsitter impromvnets coming soon.
This should fix the slow forward transition from a pitched forward hover. I think it was @losawing that had that issue?
And lots of people have been asking about weather vanning, this adds some Q_OPTIONS to allow to yaw side into the wind.
Happy to do test builds if anyone wants to try it, both are fairly small changes so they should get in to master soon.
Yesterday we ran various fully automatic missions on one of our tailsitter, after having first countless transitions from Cruise to QLoiter and vice versa without any problem.
Unfortunately in my opinion the Ardupilot code on tailsitters has a huge problem in the throttle management during a QRTL, during the transition it puts the THR to zero making the tailsitter lose its trim, which does not happen from Cruise to QLoiter, even maintaining the throttle stick on the tx to a minimum.
Itâs a shame, because thatâs all we need to bring home automatic missions.
I will document everything as soon as possible.
@Iampete, thanks for the implementations.
One question:
I have decided to use one Beitian880 gps&COMPASS in my TS > the compass is HMC5883L.
But Iâm wondering if it will be robust enough for one DM TS, even away from sources of interference.
(EK3 YAW RESET xx error)
Do you suggest any specific compass for one DM Tailsitter?