Yes, I can see the elevons (RCOUT) are often at the limit.
I think you mean in vertical position at Hover (not longitudinal)? Yes, the CG is not in the center of the motors. Difficult to adjust by moving the battery because there is a carbon tube underneath.
I thought the top/bottom motors would be strong enoughe to compensate (compared with a dual mot tailsitter)
I will try frame_type = 0. (At first in the rack to see the efficency)
Yes I think also, the elevons where constant deflected to produce this Rotation. (Not to stop)
Note that the continuous yaw problem went away with tailsit_input=2
And I actually meant the longitudinal CG; it has a large effect on the elevon deflection required to hold pitch attitude when in VTOL modes with some forward airspeed. I’m not sure how critical the vertical CG location is.
BTW, nice landing!
Yes, use Q_TAILSITTER_INPUT = 2 (or 3) for all copter tailsitters.
This is the “bodyframe roll” option: for both options 2 and 3 the yaw stick controls earth-frame yaw and the roll stick controls body-frame roll when flying level (like an airplane, with the nose pointing near the horizon).
But when hovering with option 2, the aircraft responds like a multi-rotor, with the yaw stick controlling earth-frame yaw, and roll stick controlling earth-frame roll.
When hovering with option 3, the aircraft responds like a 3D aircaft, with the yaw stick controlling earth-frame roll (body-frame yaw), and roll stick controlling earth-frame yaw (body-frame roll).
Option 3 is what you would choose for performing aerobatics.
As you decrease the static margin (by moving the CG closer to the neutral point) you should find that hover stability increases since less elevon deflection should be needed to maintain pitch control. Yaw control suffers whenever the elevons saturate, and this is more likely to happen when large deflections are necessary to hold the desired pitch. The downside to reducing static margin, of course, is that you may lose stability in forward flight. It could be that this airframe design and airfoil are just ill-suited for tailsitters.
I thought the upper/lower mots are controlling the pitch as usual for copter. ?
At line 519 starts a uncontrolled Yaw and the elevons are deflected 10° max. only. The Yaw starts after pitching back to vertical by a (elevons) impuls. Ater that, the elevons remain at zero and the wing stops slowly by itself.
I know, bad flight position direction North. Yaw difficult to interpret in Log while moving around 0 - 360 °
When using Frame_Type = 0, will it work with Yaw Torque control in Plus Configuration because Roll/Pitch are controlled also with more/less torque?
In EU, emergency situation, scools, shops, theatre, borders … closed except food and health shops. Corona War.
Right… I was thinking duo-motor tailsitter when I wrote that. Also, your top/bottom motors don’t seem to be maxing out. At least it recovers yaw control eventually, though.
I notice that as you pitch forward and begin to pick up airspeed (3:16 in the video), the elevons go to max deflection calling for left (body-frame) roll. That might be a clue as to what is going wrong; could the CG be off laterally (one wingtip heavy)?
I’ll try to reproduce this in sitl. Maybe I can improve the tailsitter attitude control logic (or find a bug).
The covid-19 situation seems pretty serious. And it’s clear that incompetence over here has increased the risk. Best of luck to everyone.
The wing is balanced in lateral direction. But at this time, I gave also a little bit roll to the left.
I noticed, that in all 3 cases of uncontrolled yaw that Att.Roll climb over Att.DesRoll when before the pitch stick is released. Good to see at line 278000. It begins to roll in backward flight. At Pitch of 26° the elevons flip full deflection to the right elevon down, left up.(2.17 in the video) And continue this roll when vertical, now its yaw. The roll start before the elevons are fully deflected.
To bad, this behavior, the rest would be good. Sometime, flight forward works good, even with more pitch like 3:02 in the vid.
Good qustion.
As this diagram. Seen from top down in Hover Position.
Mot 1,Right Plane mode, SERVO1_FUNCTION =33
Mot 2, Left Plane mode, SERVO2_FUNCTION =34
Mot 3, botom, SERVO3_FUNCTION = 35
Mot 4, top, SERVO4_FUNCTION =36
Elevon left , SERVO5_FUNCTION = 77, reversed 1000 = up
Elevon right, SERVO6_FUNCTION=78 2000 = down
The logs of above Rack-Tests.
For frame type 0, you need this motor layout (only the rotation directions change):
This has the disadvantage in FW flight that your wing motors aren’t counter-rotating, but would normally not be a problem since ailerons/elevons should be able to counter roll torques.
I also believe that you will be the first one to flight test a quad+ copter tailsitter with this frame type. I think @losawing only tested torque-based yaw on quadX tailsitters (frame type 1).
Motor 3 becomes in Plane Mode bottom and Motor 4 becomes top Motor.
Motor 1 is in Plane Mode right Motor, #2 is left.
Would need more time to change all Motors due to the fixed fast Prop mount.
Another Question about the “old” Frame_Type 16 setup:
What would happen if the top/bottom Moter Rotation is wrong? (Discussions long ago)
Because: Roll works perfect as it should. Yaw also, when no pitch is applied. (Landing)
The Yaw issue happened with pitch. May be torque and elevons work against each other. And varying torque (pitch) the control with the elevons is disturbed (strengthened or weakened
Could you test it in SITL? In the best case, even reproduce my issues.
Yes, motor 3 is bottom and 4 is top. 1 is right(starboard) 2 is left (port).
For frame type 16, I assumed motors 3/4 would be counter-rotating.
I’ll check the rotations we have for the Caipirinha copter tailsitter in RF8; so far I haven’t been able to reproduce your yaw behavior in SITL, but if I crank the yaw gains up as high as yours it can go completely unstable and crash.
Interesting that Pierre’s biwing and batwing/jetwing seemed more stable than SITL, but the Caipirinha based models are less stable.
Before modifying the motor/rotation setup, I will go back to the basics with my params in the Frame_Type 16 config.
Tests 1 and 2 with P=0.5 (SITL) and P=0.18 where verry slugish and I went back to the Rack
I had good graphs in the Rack with P=1.6, I=0.8, D=0.02, FF=0.2, Y_MAX=27000, IMAX=0.5.
But at this time, I tried to “crank” up the params until oscillations as recommended for the tuning. And it never started oscilations. . Also the values of @losawing are lower than mine actually as he mentionned earlier. I will repeat the YAW test Serie in the rack, beginning low.
That sounds like a good plan.
Yaw behavior is sluggish in SITL (qhover) for the quad tailsitters, but that works as long as the control error stays reasonable.
Now, I found why I cranked the values up.
As I changed from Q_TAILSIT_INPUT = 0 to 2, the response on Stick Inputs was verry week and Yaw followed retarded DesYaw.
I made a Rack-test with the same parameters. The PIQY Values are verry different. The feeling with Q_TAILSIT_INPUT =0 was better and the reaction similar as Roll und Pitch. And I have now some “experience” in the Rack after 65 Tests.
Here the two graphs:
I thought you were using input=0. My favorite mode is input=3.
Since Tuesday we are not allowed to go outside except for work and food shopping. I don’t know for how long… At least I can fly from my garden, VTOL are perfect for that.
For Fieldtest 1 to 3 I used Input=0. After test 3 with continues yaw I changed to Input = 2 as you recommended. A previous Racktest showed that the respond was week an therefore I increased the P, I and FF Value. In Test 4, the stick reactions were good, except the sudden three-sixty yaw. The suspiction this could be due to the exreme high Values led to the Test 5 with reduce Values.
No sudden Yaw, but with verry carefully stick commands and nearly no wind.
And I feel the effect of the elevons is too week for this model. Sometimes full deflected without large commands. Just good enoughe for one axis in the Rack, but not together with Roll/Pitch in the Field.
Therefore I will try your suggestion with torque based Yaw. (Frame_Type = 0)
In Switzerland they do not want to declare this as regulation with the slogan: “we are a free country”, yet. They still hope a call to all would be enoughe even though the youngster celebrate Corona grill partys.
Groups with more than 5 people would be punished with 100 CHF. Over the near border in Germany South the same as regulation but over 3 persons and punished up to 25 000 €. 95% of the aircrafts are grounded and parked on a unused military airfield. The same as during WW2 was full of damaged allied bombers.
Beginning Fev. we heard from the governement: We ar well prepared, no danger. And now, no masks, no protective clothings, not enoughe desinfection, borders to Italy to long open. Verry critical, be carefully.
Video Test 5:
The difference in yaw performance between Q_TAILSIT_INPUT = 0/1 (multicopter logic) and 2/3 (custom body-frame roll logic) is no doubt due to the more sophisticated control algorithms being applied in method AC_Attitude_Control::attitude_controller_run_quat(). This method is designed specifically for multicopters, and prioritizes roll/pitch control over yaw control. That is probably why there was a catastrophic loss of yaw control in your test 3 with Q_TAILSIT_INPUT=0. And my own experience with the duo-motor Caipirinha tailsitter is what motivated me to eliminate it from the body-frame roll control modes, since these are specific to tailsitters.
And although I haven’t been able to reproduce the exact in-flight behavior of your Caipirinha quad tailsitter in SITL, it does seem that my other quad tailsitter models in RF8 (Stryker and Dart) are much more stable in yaw than the Caipirinha. Given that observation and the great success which Pierre has had with his quad tailsitters, I think it’s likely that the Caipirinha planform and airfoil are just not good choices for copter tailsitter. Hopefully we will one day be able to explain exactly why that is
Once we do have a better understanding of the stability issues, we can try to add back some of the attitude control enhancements from AC_Attitude_Control::attitude_controller_run_quat(), if there seems to be a potential advantage for well-proven airframes.
