Plane: optional limit to flaperon percentage
On my model full [manual] flaperon extension seems to be very badly affecting the roll behavior. Of course this can be remedied with trick settings on the RC range and/or transmitter, but it seems hacky and would interfere with RC calibration. This PR creates a new parameter which can be used to limit the flaperon mixing amount so that if the RC remote commands 100% flap it can be limited to somewhere sane (as we can't do that with servo throw since that would also be affecting the aileron function).
This also allows a wing with both flaps and aileron to be configured with a shallow flaperon limit not to interfere with the aileron too much, but still have some flap functionality. From my theorycrafting sofa this could be useful to delay wingtip stalls while not going for full flaperon setup.
SITL-tested will report from an actual aircraft.
@Hwurzburg added a wifi entry for this. Please let me know if you'd want it be accompanied by an illustration or whether the text is fine. Also tested in a real aircraft and it seems to do what it is intended to.
I like the intent here, not sure why it hasn't been an issue before. I'm tempted to be happy to merge this as long as we're sanity checking the param but the problem is once we add a param it's harder to remove it in the future. I think there's a better solution that can automatically detect and solve this is automatically without a param.
Entering feature creep zone: All we'd have to do is mix in the flap and see if that exceeds the limit, +/- 4500 in this case. If so, however much we're over we subtract flap so that we're pushing the max aileron authority and sacrificing flap only when we're hitting limits. Basically, prioritize aileron over flap when mixing. In fact, it's easier to think of as adding as much aileron as is demanded and only adding enough flap to max out the aileron limit.
@Hwurzburg added a wifi entry for this. Please let me know if you'd want it be accompanied by an illustration or whether the text is fine. Also tested in a real aircraft and it seems to do what it is intended to.
please link the wiki PR here
My base intent is to have some degree of aileron movement past max flaps as well as being able to tune the max flap angle independent of actual aileron throw without resorting to input mixing on the RC side. I agree that a parameter-less option would be superior, I'll try to carefully think your suggestion through tomorrow, but for now I'll address the suggested sanitation change.
Wiki PR: https://github.com/ArduPilot/ardupilot_wiki/pull/7202
Could also be a scaler of current-flaps-%, rather than a hard limit?
Hmm, that's a good one. I was operating under the assumption that the user might want to fix their FLAP_x_PERCENT, but not that I think of it, that's not even the angle per se, so no real point in keeping it consistent across the flaperon scale setting.
Could also be a scaler of current-flaps-%, rather than a hard limit?
Having an option would be nice, some users may want to drop flaperons together with flap to limit and then drop flaps further for increased drag effect. and others may want linear relation for more consistent change in lift.
This sounds like two completely different logics though. Assuming the limit is 50% and let's say the full throw is 45° with no aileron deflection:
| Commanded flap | Flap surface angle | Flaperon (scaling) | Flaperon (limits) |
|---|---|---|---|
| 50% | 22.5° | 11.25° | 22.5° |
| 100% | 45° | 22.5° | 22.5° |
I can do something like "use strategy A if the value is positive an strategy B if it's negative", but I'm unsure if this won't be too confusing.
In a more general sense I mean here's the difference how I see it:
It's possible to do either or both, but I really don't know what's better here since for myself I'm just solving a very limited problem and don't have a solid aerodynamics rationale except for having aileron range on full flaps.
I guess this makes sense, since I seem to have been too focused on the wrong wing when I thought about it. So instead of limiting the flap part of the movement for the aileron that's supposed to go down we're making the opposite one get higher?
Thinking aloud. So for the full flaps turn to the right we'll have:
| Wing | Current | Limit 50% | never-sacrifice-ailerons |
|---|---|---|---|
| Left | +100% | +100% | +100% |
| Right | 0% | +50% | +100% |
Yes this looks superior, I'll adapt your change and re-push.
I've rearranged the math a little bit. Will deploy on a model and see if it works the intended way. I guess the wiki change no longer applies, but then again the animation would not be up-to-date anymore.
I guess this makes sense, since I seem to have been too focused on the wrong wing when I thought about it. So instead of limiting the flap part of the movement for the aileron that's supposed to go down we're making the opposite one get higher?
Thinking aloud. So for the full flaps turn to the right we'll have:
Wing Current Limit 50% never-sacrifice-ailerons Left +100% +100% +100% Right 0% +50% +100% Yes this looks superior, I'll adapt your change and re-push.
I would be carefully with that as you will be effectively changing flap deflection which will affect lift and pitching moment.
So we ultimately sacrifice either aileron or lift the way I see it. Can someone comment on this from the aerodynamics perspective?
So we ultimately sacrifice either aileron or lift the way I see it. Can someone comment on this from the aerodynamics perspective?
Thats indeed the case. Any time one of paired control surfaces hits a limit you have to sacrifice one of controlled values, the same as for overmixed (sum of input gains >1) V-Tail and elevons.
I would add that you should be careful with large aileron down deflections as you may reach tip stall point and start rapidly turning the wrong way 😅
I fly overmixed v-tail 🫣 But anyway if there's no clear cut fit all strategy, then maybe having a parameter isn't a bad idea? We do have a mixing parameter for v-tail for instance. I'm not arguing for my initial approach here (it was just solving a very local problem), but it just seems at this point there isn't an universal solution that would just work.
I fly overmixed v-tail 🫣 But anyway if there's no clear cut fit all strategy, then maybe having a parameter isn't a bad idea? We do have a mixing parameter for v-tail for instance. I'm not arguing for my initial approach here (it was just solving a very local problem), but it just seems at this point there isn't an universal solution that would just work.
I think replicating V-Tail/Elevon mixing with additional maximum for flap input value would cover all cases. though I would go with independent gains instead of that mess that is in V-TAil/Elevon mixer, much easier to keep the current behaviour as default (mandatory).
-- k_A - aileron gain >0
-- k_F - flap gain >0 (unless only used as spoiler)
-- flap - flap command (0-1)
-- flap_max - maximum flap command for flaperlons (0-1)
-- roll - positive for roll right (-1 -- 1)
-- deflectionX - positive down (increase lift) (-1 -- 1)
deflectionL=k_A*roll+k_F*min(flap,flap_max)
deflectionR=-k_A*roll+k_F*min(flap,flap_max)
Hmm, can this maybe be a topic of the devcall? Because this looks cool, yet it adds not one, but 3 extra params.
Hmm, can this maybe be a topic of the devcall? Because this looks cool, yet it adds not one, but 3 extra params.
Fair pointy, flexibility has its price, this covers everything except deploying ailerons as flaps late (would need another parameter for that).
deploying ailerons as flaps late
Not sure if I understand this point
deploying ailerons as flaps late
Not sure if I understand this point
Flaperlon flap response vs general flap command
I'm still unsure which approach is best, but I rolled out the @magicrub 's code at https://github.com/ArduPilot/ardupilot/pull/30811/commits/19d975550466414e08a95d4d02a44a415ff5e17a over 4.6.3 stable and it does what I expect it do to on a stand. Will hopefully fly-test over the weekend and report.
20° / 10 m/s crosswind landing at low speed, 50% flaps, 1 dedicated flap + 1 flaperon per wing. Roll seems to be under control with this code, even though the gusts caused some sharp aileron movement demand. (Don't mind the oscillations, I need to tune yaw damper)