I am using SUNNYSKY X3520 KV720 for 4s. For testing, propellers 13x5.5 mm were installed. I plan to use 15x8 propellers, which should fit from day to day, then the flight time will be known…
1 Like
@Leonardthall @tridge @priseborough Trying to fine tune my Z84 TVBS above…it has a constant, steady 1hz oscillation in roll in FW modes…Tridge and Pete Hall have been helping me try things: zero i, increase i, zero the new slew limit RLL2SRV_SRMAX=0, zero out Q_VFWGAIN …I have rewired to make sure cables are loose…nothing affects it…its not aliasing, since it happens in zero throttle glides…I have bench tested throttle slowly ramping with no effect on horizon or mag/x/y/z…I have never run into this before on planes…about to conclude its a defective y gyro and replace the autopilot… here is today’s log after zeroing SRMAX and retuning…this constant slow sinusoidal wing rock really messes up video
Is there any slop at all in the control linkages? This can be caused by zeroing problems in your servo or movement in your control linkages or the hinge of the flap. The symptom to look for is does the flap return to the exactly the same position from full deflection in both directions?
no the elevons are tight and driven by digital ball bearing servos…its not control surface slop…
the tilt mechs are tight also, and are not involved in FW attitude since VFWGAIN is zero
Dutch roll is the result of severe coupling between the yaw and roll axes. If a model has a large dihedral (or swept wing) and a little damped drift, a disturbance to generate a yaw oscillation which then induces a roll and vice versa. The vicious circle then begins a mutually maintained oscillation.
thanks… but 1. what is the solution? 2. I have flown this model as a normal single motor wing in many other builds using ArduPlane (and many , many others have also) and never had any issues with this behaviour, why now? could YAW2SRV_RLL or RUDD_DT_GAIN be causing this?..they are at the defaults
however, the only way those could be affecting anything is via the motors, and you will note that while there is a 10us (1 step) variation , in sync, with the sign of the the delta between desired and actual roll, which is probably a rounding effect in the left/right throttle code, that the roll oscillation is present at the same degree in glides where the motors are below idle value and not providing thrust… so this does not seem plausible
I dont think this is a parameter problem, you already made a lot of tests to tune them. So, If we suppose oscillations are frame dependent, you can try two things
The first is to increase ailerons differential throw. It will reduce adverse yaw and hopefully reduce the coupling.
The second is to increase yaw stability by displacing vertical surfaces toward wing tips (and backward). Or maybe put them behind motors like the fx79 above.
no…it does not do that
As they have same airfoil and vertical stabilizer, it doesn’t seem to be frame dependent IMO
My FliteTest Bee is flying as a tailsitter. Transitions from hover to wing are very crisp. Transitions from wing to hover are less confident. They appear to take several “attempts” and there is a lot of elevator wag. Here’s a log and a video of one set of transitions. Please excuse telephone-quality video.
1 Like
One question,
I was thinking to place the GPS & Compass at a 45º. So when tailsitter is sitting looking up, you don’t need to place the tailsitter horizontally to receive satellites. And in plane mode it will continue to receive satellites.
But I have not read about this orientation.
What do you think about this option?
If you get enough satellites for reliable operation in hover mode with the GPS in normal “plane” (level) orientation, you might be better off keeping it level. Assuming that most of your flight time will be in fixed-wing modes…
I need help tuning pitch and yaw axes on my DMT. I successfully QAutotuned the roll axis [1], but I’m having less success with pitch [2] and yaw [4]. I posted a video a couple of posts ago that shows transitions from FBWB to QLOITER and back. You can see pitch oscillations that accompany the transition. I wonder If I need to reduce Q_A_RAT_PIT_P to reduce these oscillations.
[1] https://github.com/arikrupnik/ardupilot-config/raw/master/logs/FIXED_WING/3/2020-09-05%2011-15-49-qautotune-in-qloiter.bin
[2] https://github.com/arikrupnik/ardupilot-config/raw/master/logs/FIXED_WING/3/2020-09-09%2010-07-00-autotune-axis-2.bin
[4] https://github.com/arikrupnik/ardupilot-config/raw/master/logs/FIXED_WING/3/2020-09-09%2010-46-21-autotune-axis-4.bin
Edit: here’s another video with transitions that shows pitch oscillations in hover. This is before I tuned horizontal flight parameters; ignore the aileron wobble in FBWA.
Try transitioning from FW to QHOVER and QSTABILIZE to see if the problem is just with the loiter nav controller. Get those transitions tuned properly before attempting to go straight to qloiter.
1 Like
Thank you, @kd0aij. I will try that as soon as it stops raining.
I’m using QLOITER because it seems that the slightest breeze blows the aircraft downwind. It never has enough time to autotuned before it’s out of field boundaries. And then I have the hardest time navigating it back to the safe area without transitioning to horizontal flight (e.g., FBWA). My understanding is that if I do, QUATOTUNE has to start from the beginning again.
I don’t know if it’s the navigation controller, but it appears that elevator deflection reaches maximum several times in the logs. I can increase the throws, but it’s unclear tom me how much difference that would make. Is it possible that this is simply as far as this airframe can go? What if I configure ailerons as elevons to help with pitch control? They are closer to the prop wash.
Ari.
First, wait for a calm day then manually tune transitions from FBWA to QSTABILIZE and FBWA to QHOVER, in that order. I’m sure there’s advice earlier in this (huge) thread on how to do that. I myself have never even tried a transition straight to qloiter, but perhaps someone else here can give advice on tuning that.
I have configured AHRS_ORINTATION = 2 to rotate the F765 90º clockwise.
With Q_FRAME CLASS = 10 >> I see the HUD as if the tailsitter was nose down.
If I change Q_FRAME CLASS to a value other than 10 >> I see the horizon correctly
I don’t understand this behavior.
if your a tailsitter the HUD changes depending on if your in a plane mode or a Q mode