I would not recommend using boost motor unless your flying on latest. There is a bug in stable and beta where it can be left with some throttle when disarmed. Currently boost is only active in hover modes. I have a PR that fixes that.
No Rudder Servo
Everything works accept my rudder servo… I’ve calibrated the radio and is registers full rudder deflections. I needed to reverse the rudder for correct direction.
When I check servos in calibration, everything moves (including motors) but rudder doesn’t.… rudder will arm as well… I’ve tried multiple servos in that same slot (#4) and tried assigning a different function to #4 (ie. Elevator etc) but still no movement. Changing slot #1 (ailerons) to 21-rudder disables the slot but will work again when I switch it back.
Thoughts?
UPDATE… I switched Servo#4 to RCin4 and rudder works… still not sure way #21rudder won’t work? Am I missing a setting?
Tim
What is your setting for Q_TAILSIT_INPUT?
If it’s 0 or 2, rudder should respond to roll stick input, if it’s 1 or 3, rudder should respond to yaw stick input.
This is assuming you have Q_FRAME_CLASS = 1
and Q_TAILSIT_MOTMX not zero.
Hi Mark
Hi Mark
CLASS was 1
Q_TAILSIT_INPUT was set to 0… I would like Yaw to be controlled by the rudders in the down wash of the tail hover motors. (pic attached)
Q_TAILSIT_MOTMX is 0, but I don’t see the options for other than 0
Try Q_TAILSIT_MOTMX =15
That should enable tailsitter behavior, including aileron, elevator and rudder control surfaces,
and all motors active in forward flight.
Rudder now works as 21, but lost my ailerons (roll) for stick inputs (elevator stick still works)… QStabilize still controls the roll if I move the board.
QStabilize - yaw is corrected by ailerons and roll is corrected by rudder.
T
with input = 0 you have an helicopter like aircraft where aileron stick control swashplate. So it is normal your roll stick control rudder control surface because this is the one that will roll your aircraft in the earth frame.
with input = 1 or 3 you are piloting a 3D plane
This is a verry good, clear explication, much better than in the Wiki. Now its also understood by me.
This is the wiki page which describes the tailsitter input options:
https://ardupilot.org/plane/docs/guide-tailsitter.html#tailsitter-input
I thought it did a good job of explaining things, but suggestions for improvement are very welcome.
Sorry, it was not a criticism, explained why I understood finally.
Today another test with the copter Tailsitter after rack tuning.
First section not bad, then with uncontrollable, continuously Yaw after stop forward hover.
Video: https://youtu.be/TC7fX7JMCSA
Log: https://drive.google.com/open?id=1uUOV2MpxTPU4CTHWjXYJt8pPdMSXMZGa
Param: https://drive.google.com/open?id=1UOH33FK02TFryYb7G3gmHVKJQg2zQvzE
Landing rotating in a rough plowed field. Uper motor carrier broken, needs to be printed again. 
I use still ArduPlane V4.1.0dev(1d8c0c49) as recommended to get the possibility to use Q_FRAME_TYPE=16 (I read It disables torque-based yaw control, which causes instability in the plus-frame quadcopter tailsitter.) Has this to do with this rotating effect?
Thats an interesting one, just looks like it needs more gains to overcome the yaw once it has started. Increasing the yaw I max value would give it a chance to get out if it happens again but most likely you just need higher gains over all.
But Att.DesYaw wants to make this rotation. (Desired) or do I misunderstand this Param?
The desired is following the actual so the error does not get too large. So it is always trying to slow the rotation. If the actual stayed still if would try and slow for 180 deg and then try and accelerate for the next 180 deg. Looking at PIQY shows the desired rate is opposite to the actual.
There could be some funny interaction between roll, pitch and yaw going on also. The yaw causes some roll and pitch error, to correct this it throttles up some motors that make the yaw worse. Essentially it did what we would expect in such a case, keep roll and pitch good at the expense yaw, as it would on a hex with a motor out for example.
I see you still have Q_TAILSIT_INPUT=0
If you change that to 2, your roll and yaw sticks will behave the same as before, but you should get better yaw behavior (input types 2 and 3 use tailsitter-specific control algorithms, but types 0 and 1 use the standard multicopter logic).
I don’t think much tailsitter flight testing has been done with Q_TAILSIT_INPUT=0
@iampete,@kd0aij
Thanks for analyzing. In the video is an error with the gauge elevons. The left elevon is set as “reverse” and I did this not implement. Therefore during rotation the left elevon shows up instead down.
I will replace the video as soon as possible.
During the last two tests, I recognized the same sudden Yaw while stopping forward hover-fligth. But it finished after half turn.
Yes, for the next trial I will follow your recommendation with Q_TAILSIT_INPUT=2.
I thougt, 0 is standard and 2 or 3 are options.
Edit: Video replaced, new link here: https://youtu.be/TC7fX7JMCSA
Now changed Q_TAILSIT_INPUT to 2. Seems to be nescessary to increase the Params.
Actually:
Q_A_RAT_YAW_P = 3.0
Q_A_RAT_YAW_I = 1.0
Q_A_RAT_YAW_D = 0.06
Q_A_RAT_YAW_FF = 1.0
Q_A_RAT_YAW_Y_MAX = 1.5
Q_A_ACCELY_MAX = 150 000
But I wonder, why Att.Yaw reacts so sluggish, even the stability is good. (Rack Test)
Is there another Param which limit this?
I am wondering why do you have such high yaw_P and yaw_ff ? I tested only value less than 1.
In your list q_a_rat_yaw_flte is missing. Could you test 0,10, 20 ?
Yes me too. I started with P=0.5 for Test 1, similar to the Values working good in SITL. After seeing the stagger in forward hover, reduced for Test 2 to 0.18 as it was default meaning this is Oscillating. But even worse contiuend testing in the Rack. With 0.18 and 0.5 it was verry slugish and better with 1.6 or 2.5.
After changing to Q_TAILSIT_INPUT =2, it followed even slower Att.DesYaw, therefore increased P and FF. And with this hight values it did not oscillate as it should when the Params are to hight.
Here Test 4, with this hight values. Perfect start, good reaction on Roll and Pitch but again sudden Yaw. Fortunately not continously.
Video: https://youtu.be/ZEb4xg5YeKM
Log: https://drive.google.com/open?id=1hmBTp55Ph93YMX3aEF4hGZS77Zx5c1J3
Param: https://drive.google.com/open?id=1YQRvoLB5lcqhl9ebqc0P3wd2_inm5rxi
By the way: The elevons are 30% larger than original.
It looks like the first yaw departure occurred when desired pitch went from 10 to 30 degrees in about half a second. This was followed by a 30 degree roll error and loss of yaw lock. The AETR.Aileron ouput is saturated at this point, indicating insufficient control surface authority.
If the elevons are not effective enough, changing to frame_type 0 to add torque-based yaw might help. I believe @letpi has had good luck with this (motor rotations must match the copter quad-plus layout).
The CG might also be critical to this behavior. Have you experimented with it yet?
I agree, insufficient control surface authority is the root cause of yaw instability. However I believe it does not explain continuous yaw. My test wing when converted to quad plus had bigger motors and bigger propeller on wings in order to increase airflow on control surfaces.
Maybe a crazy assumption, I measured the yaw frequency of the continuous yaw, it is around 0.5Hz (180°/s), is there any possible interaction with q_a_rat_yaw_flte=5Hz