I am a relatively new user.
Pixhawk 2.1, Arduplane, latest firmware, etc…
I am currently flying a QuadPlane conversion of a Radian Pro with good results so far.
I am especially interested in setting the aircraft up for good automatic hover control in windy conditions.
I have started to play around with Q_WVANE functions as well as Q_VFWD_GAIN.
I have also loaded the latest beta firmware and am eager to experiment with Q_AUTOTUNE as soon as the wind cooperates. I will report my results when done.
This is all fine and good, but I’m curious – Why are the conventional control surfaces deactivated for all hovering modes, but it is possible to activate them during “assisted fixed-wing flight”?
One would think that if Q_WVANE functions are being used, then this would enhance hover control in high winds.
Has anyone experimented with this?
Are there any workarounds to enable activation of control surfaces during hover?
I think this is what it does currently, maybe we could use the wind prediction to invert the controls, although its never going to work that well, might be better to just stop outputting controls.
Yup, I fly full scale too – basic taxiing procedure.
Which is why I wrote: “One would think that if Q_WVANE functions are being used, then this would enhance hover control in high winds.”
i.e. as long as the aircraft is pointed into the wind then it will reduce the burden on the quad motors and increase the acceptable wind margin.
iampete:
Interesting thought about inverting the controls based on wind prediction – I hadn’t considered that as a possibility.
In regards to your comment that I should be getting control surface deflections already, I checked my telemetry and all RCOU variables showed tiny control surface moves even though the wind was gusty. (and I witnessed no perceptible movement during any of my flights) – so unless something is wrong, I am not getting control surface outputs in Q_modes.
For this to help, the control surface deflections would have to be large in Q_modes due to relatively small dynamic pressure.
After flying again today, I wonder if I am asking the wrong question.
Maybe the right question is:
Why not add Q_ASSIST functionality to actual Q_modes instead of just for fixed wing modes?
That is, if you can work it the other way with Q_ASSIST helping the aircraft fly below stall speed in FBWA, then why not apply it from the other direction to assist Q_LOITER hold position in high winds?
As long as the autopilot has an estimator for wind speed (or some other metric) then why not have the control surfaces engage at some specified wind speed? You could call it Q_LOITER_ASSIST or something like that. Also, as long as the aircraft has sufficient directional stability, then quad motor yaw commands could be phased out at that point as well.
It would be necessary to use Q_VFWD_GAIN of course.
I suspect it is doing control surfaces just the quad motors are so good at maintaining target rates the error never gets big enough that they move a noticeable amount. Try tipping the aircraft on the ground in Qstabalise with no throttle.
Essentially I think the problem is one of having two separate control loops. You might be looking at it in hover and see that the quad motors are working quite hard to maintain angle against the wind. The control surfaces could easily more a little more and unload the quad motors. So why don’t they? In Q-modes the copter control loop is the master and the plane loop is the slave. Copter controller decides what rates it needs to meet the desired angles and asks both the copter and plane rate controller to meet these angles. However what happens if the plane controller trys to go too fast you will find the copter controller is fighting against the plane to slow down. You could end up in the situation where the plane controller is at full down elevator and the quad controller is at full throttle to counteract. The aircraft is still reaching is targets fine but not very efficiently. To ensure the controllers never fight like this one or the other of them must always have its integrator term zeroed. For Q modes the plane integrator is zeroed and for Q-assist in forward flight the copter integrator is zeroed.
Now i think of it maybe we can improve on this we could for example only zero the slave integrator if it is acting in the opposite direction to that of the master. However you still will find due to the ineffectiveness of the control surfaces while stationary the plane integrator will very quick build up to a high value, once you gain some airspeed and the control surfaces starts working it will be too large causing a large angle error that takes some time to decay beck to the correct value. This can be fixed with a low I_MAX value but then you loose some of the resilance to diffrent CG’s and control surface failures and things. There are some clever anti windup methods for PID controllers but then you add more parameters and more complexity to the tuning process.