Full house wing (6 Servos)

I’m new here and have read about crow settings, differential spoilers etc., but I haven’t found information about controlling 6-servo wings. The background is a powerd glider which I want to setup for measurement flights in a research environment. The machine we use is equipped with 6 servos in the wing and I haven’t found any information on how to control a machine like this. My transmitter can do this easily, the machine flies well without a flight controller, but it seems hard to transition to ardupilot.
Any information is appreciated.

IMHO you can only control 4 flaps on wings with Arduplane (Differential Spoilers). So you would have to operate two flaps manually.

German is probably no problem for you. For differential spoilers please see here.

This is interesting. My studies of Ardupilot suggested that the mixing layer lacks flexibility. Actually, looking at the source I didn’t find the concept of a seperate layer for mixing at all, but a huge set of parameters trying to get close to a mixing layer. There were several discussions about implementing a mixing layer in ardupilot (e.g. Better mixers for Arduplane, PX4, mavlink etc, A new approach to ArduPlane Mixer Scripting). All seem to have ‘expired’. The question for me is: Why? All modern transmitters have an extensive mixing layer. To my opinion, this mixing layer belongs in the receiver as it is tied to the machine, not to the transmitter. The transmitter should send stuff like ‘roll right’ (Attitude) or ‘mode:landing’ (Status), not ‘Servo 3 up’ (Servo).
To contribute to Ardupilot I think about providing a mixer layer along the a concept close to labview, consisting of functional nodes with inputs and outputs, constructed out of a descriptive file (XML, JSON or some format along the lines of ANTLR), connected to form a consistent process from inputs (attitudes) to outputs (Servos). The main reason is my beloved Multiplex mc4000, the most flexible transmitter I ever owned, even in comparison to my Jeti DS. This concept can span from extremely simple to extremely complex, all types of crafts, low in computational complexity for simple control designs to involved additional control in full house ships, possible support by a gui designer like labview itself. I find setting up planes with all the parameters extremely counterintuitive, error prone and difficult to test. In addition to this I have to do additional mixing in the transmitter if I cannot find parameters to serve my purpose (e.g. a 6 servo wing).
I am involved in a research project about autonomous gliders and might be able to free some resources to start a definition and implementation of such a layer, if -and this is the important part- the developer community of ardupilot is positive about my ideas. There might be good reasons for the momentary design of mixing in ardupilot and I am willing to learn about the advantages.
Still the central point is: I would like to make my ship with 6 servos (possibly 8 servos in the future) in the wing do what it should, directly in ardupilot, adapt to different positions in the plane polar (speed, angle of attac etc.) to start to exploit if ardupilot can lead to plane which can be called ‘efficient’.

I completely agree with your assertion that the mixing belongs on the machine itself and not in the transmitter, which is how ArduPilot is designed (mixing within the autopilot).

I do not have experience with the full house control scheme that ArduPilot supports at present, but I do see that it only supports 4 servos total. While it seems that you’d prefer to control all 6 surfaces independently, it is possible to double outputs such that the two inboard or outboard most surfaces behave identically.

Lua scripting could be an excellent way of achieving more flexible mixing. For example, use the existing full house control scheme for the outboard 2 control surfaces of each wing, and then control the inboard surfaces via Lua, applying some percentage of the middle surface output to them (or using more input parameters to further refine their behavior).

If you wanted to be more elaborate with scripting, you could assign a very simple control scheme with just aileron, elevator, and rudder assigned to unused outputs. You’d then take those outputs as inputs to the script (along with any other pertinent input information such as airspeed or AOA) and have the script act on all six surfaces accordingly. That would provide LOTS of flexibility but also a lot of opportunity for error/crashes.

If that’s an adequate solution, then you could simply leave it that way indefinitely. Alternatively, you could use scripting as a proof of concept for the mixing you desire and then use that logic as the basis for a pull request to include multi-surface mixing as a native feature in the firmware itself.

indeed, using a lua script is the way to go. It gives you a very high degree of flexibility.
The problem with mixing systems like in px4 is the mix can’t depend on the parameters you want it to depend on. You want the mix to scale with factors like airspeed, pressure altitude, flight mode, flight stage (eg. landing), wing angle. A table based mixer can’t do that.
So ArduPilot provides the most common setups, then uses a lua script to do complex things, and allows you to do it precisely how you want it.
To see an example of handling a really complex lua mixer that goes way beyond what tables can do, see this video:


It’s worth noting that you’ll want to use an H743 based autopilot, most likely, such as a Cube Orange, CUAV X7 or Nora, mRo Control Zero, Holybro Durandal, QioTek ZealotH743, MatekH743-series, or Holybro Pixhawk 6-series (at some risk of bleeding edge development with the Pixhawk 6).

In my experience, Lua scripts on such autopilots run at about 100Hz max, which should be adequate for your use.

You can see it that way, but IMHO it is not the case. Especially since with LUA scripts there is a possibility to implement own wishes.

What exactly should your research project be able to do? If you assume a manually flown 6-flap glider, various functionalities are possible (see here as an example). Should all this be implemented autonomously, or where are the premises in your project?

Thank you for some exhaustive answers. I very much appreciate the quick and friendly responses here.
The projekt has several steps. They have in common that we want to use electrified gliders for long-term surveillance (e.g. after extinguishing fires in remote areas etc.). We want to achieve really efficient flight to extend flying times as far as possible. This would include to use measured and optimised plane polars for optimum deflection of all control surfaces.
My conceptual thinking tells me that all mixing should be done the same way. I see no reason in seperating basic mixing from advanced mixing. The mixing layer should receive attitudes from either the controller (stemming from all kinds of input) or from a transmitter and should issue appropriate servo positions as outputs. I can see that using lua is a workaround. This word, according to my experience, always points to more general issues.
I am always open for arguments, but your replies have told me, that my original statement seems to hold.

I disagree that native mixing falls short across the board - it simply falls short for your use case, which is quite specific (and unique).

Perhaps you’d be interested in one of this year’s GSoC projects: Adding Custom Attitude Controller to Copter(ardupilot.org)

However, I disagree that Lua is a workaround. Using the get_output_scaled() bindings from a very basic control scheme, you’d have fairly direct access to the output of the rate controllers in each axis (Tridge might be aware of a better method, but this is how I’d start). I recently wrote a CAN driver for Rover motor controllers using Lua in a very similar manner, and it’s been highly successful thus far.

You might be surprised at the level of control you can achieve within the scripting environment, and the pace of development using scripting vs native code changes would likely be orders of magnitudes faster.

I agree that development will be much faster in Lua. I disagree that I have a quite specific use case. Even with a normal 4 servo wing, the native mixing is far from satisfactory. If you have ever flown a competition in F3B, F3F or F3J you will now, how finely tuned these ships are to get the performance needed out of the airframe. What you get with arducopter is amazing control over the flight path. But you do not get decent performance out of a plane. At least, that is my experience up to now.
Being a programmer myself I find it funny that everybody suggests using lua scripts for mixing. Mixing itself has nothing to do with programming. Not all users of ardupilot are supposed to be programmers. A user centric approach to SW always appealed to me. This would normally include some GUI to set up a plane. A GUI where a non-programmer could set up aplane like an F3F competition ship along the same concepts he or she would set it up on a Multiplex MC-XXXX, a Jeti, Taranis or any other modern transmitter. Am I so far away from the normal use case of ardupilot? Who wants to use ArduSoar if the airframe cannot be tweaked for optimum performance? I would like to be able to -as we used to put it- ride an ants fart to get some height if possible.

I created a request on github about 5 years ago about this exact issue. it would simplify building exotic setups if you could just do custom mixing. I once built a Vtol with 2 flight controllers because arduplane couldnt do what I wanted it to , so the quad tilting lift motors were controlled by openaeroVTOL because it has fully customizable mixing and it was controlled by the outputs of arduplane running on a APM board. the tilt rotors were controlled by the flap output so as far as ardupilot was concerned it had really good flaps.

Interestingly, the answer to this was again, use a script.

I do agree with the sentiment that not every user should be a programmer. ArduPilot does a fantastic job of providing vast flexibility across countless types of vehicles and variants. And I completely understand the tedious, and at times overwhelming nature of setup and configuration. A GUI as you suggest would be nice, but imagine programming that?! I’m not saying it can’t or shouldn’t be done, but crafting and maintaining it would be incredibly time consuming, and it seems that the dev team chooses to use that time refining and adding features under the existing paradigm rather than creating that particular user experience (for better or worse).

Back to the case at hand…when native features fail to produce the results a user desires, the answer is programming. Whether that’s via a feature request for the dev team to solve, user-written custom firmware/pull requests, or user scripts, some measure of programming must be done.

I will also admit that I don’t have much experience with ArduPlane (mostly Rover and ArduCopter), but I have seen some very impressive results that indicate that high levels of performance (maneuverability, speed, range, and/or endurance) are well within reach.

Given your stated background, given goals, and the toolsets at hand today, I really encourage you to give Lua scripting a try. Again, you may well be surprised at the results!

yes you can but you shouldnt have to any modern radio can mix channels together with a basic menu, openaero controller can do it.

It seems that the intent is often to abstract such rudimentary mixing away from the user within the attitude/rate controllers themselves. In very generic terms, the user selects frame and output types, and the autopilot reacts accordingly to coordinate turns, trim the elevator, etc.

For example, your feature request specifically mentioned crow flaps, which I have to assume were not a native feature at the time. You can now specify that control scheme.

All of the mixing parameters carry a warning “for advanced users only” - ostensibly to provide some additional flexibility to the user when the autopilot doesn’t quite achieve desired results (again speaking from a somewhat novice view of ArduPlane).

And when that fails…indeed, the answer is scripting, which I understand isn’t necessarily popular opinion here, but it does account for cases that are not handled by existing features.

If anyone is interested, I’m happy to write a simple mixing example script to satisfy some curiosity on the topic and/or for your use/modification. Disappointingly, I don’t see one in the GitHub examples.

if you look at opentx as an example, it has its inputs mixing and output, essentially we would like to have ardupilot as the input, pitch, roll, transition, flaps etc. then we can make the output puts do what ever combination nessasary. thats basically what I have done with the openaerovtol controller connected to the outputs of ardupilot.

While it is true that scripting has solved a lot of the problems its not quite as user friendly compared to a menu, especially if your not familiar with programming.

There is a quite easy half way house here. We find some mixing definition we like. Maybe we can use a common format with some other system?

Once we have a definition file format defined we can use a lua script to implement that mixing. Then single “universal control surface mixer” lua script can work for all.

The problem with doing this directly on the flight controller is simply one of input data. Where do we put the configuration. It is not a format that fits well with our existing parameter structure. We could load another file, as I propose we do in the script, but then that costs flash for everyone. Scripting is great for supporting unusual behaviors because it is so flexible.

1 Like

The natural first question is: what mixing features are important?

I’m quite familiar with EdgeTX and OpenTX’s mixing, which are incredibly flexible and also incredibly frustrating at times as a result.

At first blush:

  • Scaling (percentage of a source)
  • Offset (by fixed amount relative to source)

And then, what inputs are important? At a minimum, any given servo output or RC input.

Worth entertaining further scaling/manipulation as a function of speed, AOA, etc? Or provide those as additional inputs? I suppose with some file format creativity, any valid Lua binding that provides a numeric return value could be used as such an input.

I’m very willing to put some effort into such a universal script if it isn’t something that @iampete is capable of devoting time toward at the moment (or provide help as desired).

1 Like

Some admittedly brief searching didn’t really turn up any standard files for RC mixing. OpenTX and EdgeTX store all of their data in binary files that aren’t easily parsed.

OpenAeroVTOL implemented an Excel doc as a GUI, which does indeed make the user experience a bit nicer, though I’d hate to pigeon-hole users into requiring Excel in order to configure a mixing script.

I can envision a file format something like this:

SERVO4 = SERVO3 * 0.5
SERVO5 = RCIN1 * airspeed / 100

It might be a bit of a bear to parse within Lua, but I wonder if a Python script could be used to auto-generate a mixing script for ArduPilot based on such a format? At least then we tie the user to readily available, open source software rather than a Microsoft product.

A very motivated soul could even use such a construct as the basis for a Mission Planner plug-in, but I’m afraid I can’t devote the time required for that!

…just a few thoughts with a bit of brainstorming help from @geofrancis

1 Like

The difficulty with the analogy to RC mixing systems (eg. OpenTX) is that those rely on pilot input using switches to change between different phases of flight. The pilot, with their situational awareness of what is happening, will change the config of the surfaces for when they are in takeoff, landing, thermalling, cruising etc. With complex wing setups like a 6 servo wing you won’t usually have a single table mixer, you will have several and switch between them.
The pilot can make that decision to switch based on their knowledge of the vehicle and what the aircraft is currently doing. In ArduPilot we focus on autonomy, so we want to be able to make those flight phase decisions automatically. To do that the tables don’t work as the factors that go into the decision are not typically accessible to the mixer. They are accessible to a lua script.


@tridge, do you see value in the “universal mixing script” concept? Your point regarding table-based mixing is well taken…but if the table included factors like sensor output, could it not be coerced to make those autonomy-based decisions? Or am I making too much an effort to oversimplify the problem at hand?