as a lua script to simplify things for users, yes, that is a nice idea. It would need some examples with plenty of comments
Probably … Please have a look at post #7 again. There is a link to rc-soar.com with a 6-flap example which is often used. But this is only one example, the use of mixers for 6-flap wings are far from homogeneous … I don’t think this should be implemented, because not required for autonomous flying.
(I often support users to equip their motorglider with a FC for RTH. In manual mode, the mixer logic of the transmitter is always activated and for RTH just that of the FC. The claim of the OP is somewhat different, but also rather an isolated case).
@geofrancis (advanced servi mixing): I had read your post before and thought: Yes, I am not the only one.
Can you provide specific examples of the mixes you use and elaborate a bit more regarding your expectations of how ArduPilot can help achieve your goals?
I genuinely do want to help arrive at a solution that’s workable for you.
We can continue the universal script idea in a separate conversation if the concept is unpalatable to you.
To put it short: My vision is to create something like KXStudio : Applications : Catia for ardupilot.
I don’t mind if this is implemented via a universal script, by dynamic object creation and linking through startup, whatever works is fine for me. The goal is to make mixing easy and reliable.
I come from programming in a medical environment (quite some time back). It’s always about obtaining the goals in an intuitive and safe way, as simple a UI as possible for the user. Visual UI’s always proved to be superior to everything else like setting parameter values etc. pp., which is error prone and tedious. Please allow me some time to put together a proposal of a concept to make everything clear and to be used as a discussion base.
I do not think that we are all too far apart in thinking and especially in the goal to make autonomous flying strong and easy.
1 Like
Thanks for putting some time and thought into it - I look forward to hearing more.
I think a building block approach is likely best. If we can settle on a basic implementation via parameter settings/configuration files, it can be translated to a GUI at some point in the future.
I’m afraid I will likely not be able to dedicate the time required to develop and maintain a full UI.
100% ack. The nice thing of this approach is the possibility to start with a rudimentary implementation, (simple mixing, expo, switches, …), describe them (XML, JSON whatever is suitable) and then decide if this is parsed and compiled to lua, c++ objects or thomething else. A first version could even set ardupilot parameters in an aoutomatic way. It can all be made working without a GUI which could follow once the approach proved to be a successful one. I might be able to attach research resources to part of the problem. It won’t be much, but I guess every hour is helpful.
As I said, I will stich something together as a proposal.
1 Like
@Reinhard: Is there a reason why certain things are not necessary for autonomous flying? Is efficiency no part of autonomous flying?
In my opinion there is a lot of promising possibilities for improvements in flight efficiency especially in autonomous flying.
Actually it’s funny to be pointed to Mike. Back in my days in Wales I used to fly F3F there e.g. Welsh open. He used to be there, a very approachable guy.
When I look at how people with 6-flap airplanes fly them, I can’t imagine that this makes sense autonomously. In addition to the mixer logic, some kind of “flight logic” would have to be added to make a plane fly autonomously like a human. And every human also flies differently …
As I said, I occasionally help people to equip their aircraft with an FC for RTH. In the beginning I often wished that things like butterfly, snap-flag and everything that is included in Mike’s templates, for example, would also be covered by Arduplane. Only here it is finally so that flier with RTH is to come back simply. Any special mixer configurations are superfluous.
Now I don’t know your exact application, it may be that more features make sense here. But features that mainly affect the rudder? Efficiency is certainly important and can be measured. But I am skeptical about things like rudder optimization for speed and thermals in autonomous aircraft.
But the initial question was actually whether Arduplane supports 6 flaps and it currently does not.
1 Like
I made a rough sketch of what I would describe as my ‘concept’.
First a standard electrified glider. The only ‘advanced’ element is the thrust compensation to the elevator, just to see how I would describe a mixer.
The corresponding XML-definition would be:
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<vehicle>
<input id="0" name="Yaw">
<scale>1.0</scale>
<offset>0.0</offset>
<port type="out">out</port>
</input>
<input id="1" name="Pitch">
<scale>1.0</scale>
<offset>0.0</offset>
<port type="out">out</port>
</input>
<input id="2" name="Roll">
<scale>1.0</scale>
<offset>0.0</offset>
<port type="out">out</port>
</input>
<input id="3" name="Thrust">
<scale>1.0</scale>
<offset>0.0</offset>
<port type="out">out</port>
</input>
<output id="4" name="Rudder" type="pwm" number="1">
<min unit="ms">1</min>
<center unit="ms">1.5</center>
<max unit="ms">2</max>
<port type="in">in</port>
</output>
<output id="5" name="Elevator" type="pwm" number="2">
<min unit="ms">1</min>
<center unit="ms">1.5</center>
<max unit="ms">2</max>
<port type="in">in</port>
</output>
<output id="6" name="Aileron R" type="pwm" number="3">
<min unit="ms">2</min>
<center unit="ms">1.7</center>
<max unit="ms">1</max>
<port type="in">in</port>
</output>
<output id="7" name="Aileron l" type="pwm" number="4">
<min unit="ms">1</min>
<center unit="ms">1.3</center>
<max unit="ms">2</max>
<port type="in">in</port>
</output>
<output id="8" name="Thrust" type="pwm" number="5">
<min unit="ms">1</min>
<center unit="ms">1.5</center>
<max unit="ms">2</max>
<port type="in">in</port>
</output>
<mixer id="9" name="ElevatorMix">
<line id="9.1">
<point x="-1" y="-0.1"/>
<point x="1" y="0.1"/>
</line>
<port type="in">in1</port>
<port type="in">in2</port>
<port type="out">out</port>
<map in="in1" out="out" func="9.1"/>
<map in="in2" out="out" />
</mixer>
<signal id="10">
<from>0:out</from>
<to>4:in</to>
</signal>
<signal id="11">
<from>1:out</from>
<to>9:in1</to>
</signal>
<signal id="12">
<from>2:out</from>
<to>6:in</to>
</signal>
<signal id="13">
<from>2:out</from>
<to>7:in</to>
</signal>
<signal id="14">
<from>3:out</from>
<to>8:in</to>
</signal>
<from>3:out</from>
<to>9:in2</to>
<signal id="15">
<from>9:out</from>
<to>5:in</to>
</signal>
</vehicle>
Somebody comfortable with XML should easily understand my approach.
A definition of inputs is followed by a definition of outputs an a mixer, that mixes thrust by 10% to the elevaterinput which is routed through directly. The last definitions describe the routing ‘wires’ through the system. Obviously I did not care about limits etc., but I neither do with my personal mixing at home as maximum deflection just means maximum deflection no matter if it is just maximum or highly over. This is a rare case and I normally just expect full deflection.
To illustrate something more complex, I’ll add my concept (not complete yet) for a 6-servo-wing ship:
I want to point out some details here:
- Some Inputs are not taken directly, but put through some expo. This, clearly, is a concept of manual flight but needs to be included anyway, as manual flying is part of ardupilot.
- Cascading mixers: As pitch can be used for snapflap is makes sense to mix it to the flaps before the flap mixing is split ino the movement of the associated control surfaces. This allows for complex mixing with a small number of parameters. This is much superior to mixing snapflap into each surface individually for comfort and safety.
- Output curves: As the flaps for butterfly work in a highly non-linear way it makes sense to differenciate between normal flap operation as camber control and aileron. There, control needs to be fine and precise without compromising the ability of the surfaces for full down (and possibly up) movement.
Id did not add the XML here as it would become quite large. But imagine describing seomething like this by parameters of plain table mixing to get the perspective right.
I still cannot understand why flight efficiency should be a matter of special use cases for ardupilot. OK, copters are never energy-efficient. But even there longer battery times could be of advantage. As soon as we talk about ardu-soar, efficiency is at the core. Even with a good soaring algorithm a bad plane would perform much worse than a good and well-trimmed one. It can easily be the difference between staying up a long time or being grounded with no chance.
Onother question in this context: I thought Lua is considered to be used for non-safety use as it is sandboxed and can be stopped and restarted by ardupilot. When I do complex mixing with lua I expect my machine to fall out of the sky when the sandbox is killed.
So now: Please amuse yourselves by tearing me up to pieces.
@hauseru, thanks much for taking the time to describe your vision and putting into easily digestible terms.
Some food for thought, and a basic first impression:
I think we must be careful conflating our concept of traditional RC mixing with the type of input that a complex autopilot system needs for effective (and yes, efficient) control. For example, pitch compensation for thrust should be sensed and automated without the need to specifically define it in a mixing file. I’m not attacking your specific use of it as an example, but rather the idea that such rudimentary things should be user defined.
The warnings regarding Lua and flight safety are somewhat dated. There is a Copter frame (6DoF, mentioned earlier here) whose entire control scheme is Lua driven. Indeed, scripting engine failures could result in flight failures, but that is the case for any software or hardware component, is it not?
Thanks @Yuri_Rage. Actually I hoped to get the critisim for my case of elevator compensation. That was intended as, clearly, this kind of mixing should be unneccessary because the pitch controller should cover for moments due to thrust (A good builder would cover by building a proper plane anyway 
). On the other hand, even such a mixer could improve the performance of the pitch controller. That is just looked at from another point of view.
For Lua: Lua allocates RAM as it likes and collects the garbage as it likes. Programmers in high risk environments generally do not like this. Once objects are created they should either stay alive or should be destroyed in a deterministic way. At least that is my (possibly old) point of view. So if you want to avoid memory leakage, create all objects while setting up and then leave them as they are. Dynamic memory should be left for less critical parts of the SW unless it is completely unavoidable.
So, i give you the credits for “SW is always prone to failures” but there are many measures you can take to minimise risks. I prefer to take as many measures into that direction as I possibly can. That might be my medical background, but loosing some kEuros plus sensor prototypes due to memory leakage is not my cup of tea.
Your basic mix can be done using the KFF_THR2PTCH parameter for throttle to elevator mixing.
In general expo function are not a good idea, because it introduces no-linearity and thus the roll/pitch controllers have a harder time.
The output from ardupilot should be as linear, then if the pilot wants expo on the sticks they can use the MAN_EXPO_ROLL / MAN_EXPO_PITCH / MAN_EXPO_RUDDER parameters. That is to say the expo should be done between the pilot input and AP rather than between AP and the servos outputs.
Re-scripting. A scripting crash will not crash the vehicle, except of course if you decide to put scripting in charge of key functionality. If its in charge of key functionality then it just needs a appropriate amount of testing. There are some things we can do, for example using protected calls in to recover from errors. As scripting is getting more widely adopted it is increasingly becoming used for flight critical stuff.
I started a similar reply but figured this could be addressed within any mixing scheme by applying expo only to pilot input prior to executing any other control logic, and it could be done onboard rather than within the transmitter, which seems to be the collective desire in the topic. Perhaps the existing parameters alone are enough to accomplish that.
@iampete. I am quite aware, that my first example is a standard case for an ardupilot setup. This setup was posted to transfer the concept of a mixing layer described earlier in this thread, support the logic image and the matching XML as a discussion base.
100%ack for expo between pilot and ardupilot. A multiplexer between an expo output and autopilot intent output, switched by the flight mode would suffice. Easy in XML.
If I want to control let’s say 4 of my 6 servos in the wing by Lua and they get stuck in unsuitable positions due to scripting failures, the plane will very likely crash. It simply becomes uncontrollable. But trust might build up through usage.
As a start, can we make an effort to get you flying?
How do you envision your craft being set up?
Seems like normal rudder/elevator outputs could be used but we need quite a bit of magic to get the ailerons to function. Can at least the outboard surfaces be set up using existing control schemes?
@Yuri_Rage, I’d love to. Normally with 4 servos I do a fine balance between flap, snap flap, aileron and butterfly movement. I guess, just to get aloft, I can treat the inner flaps and the ailerons like in a normal 4 servo full house ship using the given parameters. The middle outer flaps I would like to mainly use as aileron ‘enforcement’, but put them slightly down with the flaps and fully down for butterfly. For agility I like to influence at least the middle flap to support the ailerons when butterfly is fully applied. I do this normally with the inner flap to maintain agility in bumpy approaches like at the wrecker in Wales where lee rotor can become a problem. For a first try in calm air I won’t care to much.
To sum it up. The middle flap should mimic the inner one for butterfly, the aileron in normal mode but with more flap being mixed in in comparison to the aileron itself.
I’ll take that up as an excercise in Lua. It may take some days as I still have to prepare some hardware stuff.
Thanks for your support.
@hauseru, here is an EXTREMELY simple example for butterfly mode as you describe it in your brief summary sentence.
Of course, this script in and of itself is unnecessary, as you could just set both the inner and the middle servos to duplicates of functions 86 and 87 if the only intent was to mimic inner surface behavior.
But if you want to change that behavior at any point (as in mixing flaps into the middle surface), then the butterfly() function becomes a necessary evil.
In a more fully featured script, it may be best to assert a pre-arm check failure in the event that any parameters are not found rather than simply displaying a warning to the user.
And, of course, we’d want to flesh out more fully featured mixing functions that act on the scaled output values rather than simply regurgitating them as I do here. Again, I’m after a methodical building block approach, and I’d like your feedback on this simple example before proceeding farther.
mix-example.lua (1.0 KB)
I tested in SITL with a disarmed, grounded default Plane model (because we don’t have a full house wing as an available model, much less one with 6 wing servos). The theoretical surfaces responded as intended, and you could test this live on a disarmed vehicle in the same way.
I have a few ideas about how to make this read a little more like a mixing table rather than a raw example of Lua scripting, which I will provide as either an edit or further response.
Here’s another example with a mixing table that uses operators to act on input values.
In this case, we exactly mirror the inner surface until flaps are actuated. In flap position 1, we subtract 15% of full travel, and in position 2, 30% (while retaining some degree of aileron mixing, so long as travel is available).
mix-tbl-example.lua (3.0 KB)
If we choose to use a script generator based on some common file format, we can reduce the number of code readability “hacks” in favor of one-off generated functions/tables. I thought the attached example was somewhat clever, but clever isn’t always best practice.
I’ll offer some further opinion that we probably shouldn’t parse a mixing file onboard. The existing scripting engine isn’t capable of loading modules/libraries, so we’d have to write a parser into a single script, which would likely add quite a bit of memory overhead and surely contribute to code legibility/maintenance issues in the long run. That’s my pitch for using a script generator written in Python or another easily accessible language.
1 Like
I set one of the lab assistants to the task to develop a lua script for a 6-servo wing. Looking forward to the results.
1 Like