I have had a mess about with changing the to the plane PIDs, Q assist for vectored tailsitters and giving the code info about servo tilt angles but no improvements so far.
Turns out Auto weather vanning is already enabled for tailsitters, just need to switch it on with the parameters, has anyone tried it?
I have encountered the euler angle issue in realflight, also yaw seems to always be in earth frame, I think it would make more sense to be in body frame. If you yaw in Q modes while at large pitch angles it just sort of skids round rather than doing forward flight orientation roll. I guess this is just because quadplanes donât really get to angles where you can tell the difference. Might be quite tricky to change in the code however as it affects all quadsplanes not just tailsitters.
Most recently i have been playing with transitions I think airspeed based transition is unnecessary, however i think it does make scene to do some sort of airspeed wait before back transition to vtol. ie it would only start transitioning once it has slowed down to some predefined speed. Currently I have it locking pitch and roll to zero and cutting the throttle, then once the speed is below the threshold speed it carrys on as before. This results in the aircraft just flying off straight when the transition switch is flicked. In realflight the aircraft can go quite a distance before it starts transition, so you have no control. This speed parameter allows you to trade off height gain for linear slowing down distance.
anyone have and ideas about other ways of doing it? I might have a look at the landing code its essentially the same problem except instead of doing a flair just before stall it would go in to the transition.Having reverse thrust would be ideal, could just stop on the spot and catch it in vtol,
Hello, I was wondering if I could get some help with a strange issue that I had with a tailsitter. I had been doing some pid tuning the previous day and had it flying okay in qstabilize mode. Today I went out to test qhover and then to maybe try a transition but didnât get very far. If you look at the video you will see it abruotly take off from the ground and then control itself with some pitch forward. I the let go of the pitch and the drone did a backflip twice before crashing into the ground. https://youtu.be/AZsuDBp_Yjc https://drive.google.com/open?id=1BbV02h1ygh58KpPR4oBjRsoUfXBENV-3
In which direction is it pointing then?
For my unvectored it would be best to the keep nose in the wind while loitering, but holding the SIDE into the wind while landing, so it does not have great pitch angle and falls overâŠ
Thanks for your commit to the angles! We now can reduce the roll angle without reducing the pitch angle. This is great!
For the backtransition I cant tell if this makes sense to slow down first. You will need an unpredictable horizontal distance for this.
Also you can do this by mission commands right now by âset speedâ.
Dunno if reverse thrust is fast and symmetric enough to work.
I think your deflection angles for your flaps are too small. Right before it did the first backflip the left flap went to maximum but this was not enough to get it back to position.
Had this issue with my very first tailsitter.
I suggest to have at least ±30 deg, better 45 deg.
If you flash the latest beta there is a parameter called Tailsit_thscmx you should turn it down until your on the ground oscillations go away will probably end up being somewhere between 1 and 1.5.
Great test rig, Lovely flight, great tuning. Above all, thanks for including parameters. Gives me a starting point.
Iâm still here with three tailsitters to test (I like to build) and no time for another 6 weeks.
By then summer will be fading.
Thanks for the feedback mytailsitter was initial gonna be. Non vectored but then decided to be vectored so thats why theyre that long. And the wing ends deflect about an inch in manual mode. The ground oscilations were due to some flex in the body. But i dont get why it flipped in the first place because there was no harsh movement to cause some weird inertia stuff or anything. And it flew well in qstabalize. it was almost as if the pixfalcon was lagging becuase of the abrupt take off but i dont know for sure.
How do you enable weather vanning ? I tried 3 or 4 months ago with arduplane 3.8.3 and came to the conclusion it did not work. I remember correctly I tried q_wvane_gain and q_wvane_minroll parameters without success.
The Euler angle issue you mention is a very important flight limitation. At high pitch angle, It is almost impossible to roll (body frame) the wing. This is what I called a flat turn in a former post. The consequence is a lower maximum speed in a turn.
From my point of view, a minimum airspeed will help for a safer transition but I see no advantage for maximum speed.
Thank you very much for the support you bring. Unfortunately, for the moment I am not able to test them as there are too much people on my beach.
Just had a go in SITL, auto weather veining seems to work fine, you have to be in Qloiter or other position control mode, with q_wvane_gain 0.1 it takes 30 seconds or so to very slowly yaw itself into the wind, with 0.4 its nearer 10 seconds,
Interestingly it seems the loiter controller does a better job with the wind at 90deg rather than facing the wind. I guess this is just due to the controller not expecting lift from the wing. It uses only throttle to control altitude, so it ends up where it cant lean into the wind any further because of the droping throttle to maintain altitude, I guess it needs some sort of extra logic to power up the throttles and lean over further and use angle of attack for height control and throttle for position, i.e fly like a plane at exactly the wind speed.
Although i havenât tuned up the loiter controller, maybe that would help
I have no experience in Planes or Wings.
Has anyone an advice what happens.
I assume it is a sideslip.
As to see in the Rigg, the Yaw is not controlled by the FC. Why not?
Exists Params to enable oder tune this?
The same function works in Hover Mode for Roll perfect. (Same axis)
But as to see, the the wing was rescued by a perfect Backtransition Program. Thanks a lot.
Otto
Looks like it just needs a vertical stabiliser, as you say plane does no yaw control, it is all just pasthrough from the rc contorl in FBWA. For plane it doesnât use motors to stabilise yaw as it does for hover roll as a plane should still be able to fly with the motors off.
You should just add some vertical stabiliser, hard to say how much exactly but initially you cant really have too much.
In one of the FBWA failures it transitions to Qhover but does nothing for 2 seconds this is due to it waiting for the plane controller to reach the transition angle before the hover controller takes over. In this case the plane is not responding so it never reaches the transition angle so it times out after 2 seconds. If you set you Q_TAILSIT_ANGLE angle to zero it will instantly switch to hover logic. This might be better for initial testing.
The tailsitter code does use differential thrust for yaw control in FBWA mode. Parameter RUDD_DT_GAIN controls the amount of differential; your log has it set to 10%.
Thereâs no GPS data in the log, though. Did you have GPS lock and pass the pre-arm checks before taking off?
Do you mean with âvertical stabilizerâ the Rudder or the Winglets, also âmecanical wareâ?
And not the powerful computer with Gyros which makes her job perfect for Roll in Hover Mode.
GPS was not enabled for the first Log but more than 11 Sats and hdop 0.9.
RUDD_DT_GAIN ist 10. But in the Rigg I tested until 50 without any influence for Yaw. Whether to hold
the Direction nor when I moved the wing by hand up and down.
Do I need KFF_RDDRMIX for that?
Otto
I think he is saying that you need a bigger vertical tail plane ( Seitenleitwerk gröĂer, kein servo). After watching the scene for few times I also think this is the reason.
I had same experience with my tailsitter. Problem is that if your motors are not 100% same kV or any reason, they will not produce same amount of thrust and your plane will yaw very fast. (like here: https://youtu.be/wSg2vyiaebg?t=2m26s)
This is also a reason I went for the Multistar 51A BlHeli32 ESCs. Not only they get the signal digital over DSHOT, they also have the ability now to log the RPM, Voltage, Current and Temp.
Yaw control:
RUDD_DT_GAIN -> only works when you control yaw with the remote stick, doesnât do it automatic.
KFF_RDDRMIX -> not suitable for tailsitter, only traditional aircraft.
Not sure, but I think this is what your searching for: YAW2SRV_DAMPhttp://ardupilot.org/plane/docs/parameters.html#yaw2srv-damp-yaw-damping
When your genuine ruder and winglets will be installed, Beware of high I value. I saw on your video that you increased them a lot after your rig test. I have totally destroyed my first tailsitter for that. After a stall test, I think the controller accumulated so much error that I lost control for few seconds and crash.
You tried setting the I_max value? I never messed with it but I think its meant for that case. Though I dunno how to determine the suitable value for it.
BTW anybody knows how you judge if the value for FF is too high/low?
I wrote about the methode for the PID tuning before, but for FF I have no idea
Would know dier how do I configure the elevon outputs and motors for firmeware prior to 3.8?
I want to use 3.7.1 to be able to use the QGroudControl on the Android mission planner.
Would know dier how do I configure the elevon outputs and motors for firmeware prior to 3.8?
I want to use 3.7.1 to be able to use the QGroudControl on the Android mission planner.
I will pay attention. The log shows, that in this strange Roll the Param I was immediatly at I_MAX (3000)
Sometimes in a log the Value PIDR_I is during the whole test Zero, even Roll_I is set to 0.4.
P and D shows the correct values.
If this wrong I Value is then used for control, no wonder about bad results or interpretations.
Here in this Pic the RLL2SRV_I is set to 0.4, RLL2SRV_IMAX to 3000.
