I would like to introduce the community to a mixer method used to fly complex aircraft in manual, fly-by-wire and autonomous modes.
The main challenges of mixing are:
- Flexibility to do anything you want.
- Easy to use and prevents mistakes
- Fly-by-wire capable.
- Field programmable
- Easily expandable
- Failsafe compatible
Fly by wire needs control inputs from your transmitter. Imagine if your tx mixes together elevator and aileron for a delta wing. If the autopilot looks at a servo channel, it has no idea if you are commanding pitch or roll. This means that the transmitter can’t do any of the mixing. All mixing must be after the autopilot.
You can now choose to have one mixer for AP and one for manual or one combined mixer for both. Maintaining one complex mixer is difficult but two would be asking for problems. With one mixer, the mixer must be placed after the failsafe.
When setting up mixers for a complex aircraft, the number of mixer settings is enormous. For a full wing, there are at least four controls that mix into four channels. Each mix has between three and five mix points with some mixers being conditional on state. That is around 100 parameters for the wing alone. A live connected GUI is needed to make home setup and field tuning possible.
Experimenting with different mixer setups is part of tuning the aircraft for different flight phases. The user may wish to add and remove different mixer functions. The type of mixer function should be easy to change and it must be easy to add different functions to the system. This needs a GUI that automatically adapts to new functions and support for automatic code generation.
For the past year I have been flying a mixer that solves these problems. The toolchain consists of automated code generators and a gui with live mavlink communication. The flexibility has meant that I can accurately tune the settings, certainly beyond the level my radio can. Without the live GUI, the setup time would be far too long and critical field trims impossible.
This implementation is far from perfect. The key problem is that mixer settings are a one-way communication. There is no way to verify what settings are inside the mixer. There is no way to make sure that different versions are synchronized. These are the reasons that this toolchain has not been promoted for general use.
In the long term I would like to see a system that solves these problems. My thoughts are for something like the mavlink parameters discovery. There may be other ways to improve this. I am open to suggestions if anyone is interested.
For an overview of the project, visit the wiki here:
https://code.google.com/p/pyfedit/wiki/HowToEdit
Note that the latest version is mavproxy based compared to the standalone version in the wiki.
Some credit must go to Paul G. One of the key ideas he gave me was how to safely mix manual and autopilot commands to enable smooth autopilot override.
Comments
I didn't even know people were still using the UDB4 anymore. It's good to know it isn't a serious load to the system either, I was figuring the extra calculations and functions would be an issue, but I'm not really familiar with device programing. Most of the work I have done in the past has been high level, like BASH or PERL. Keep up the good work.
"Since all mixing is moved to the Tx"
should read
"Since all mixing is moved to the autopilot"
Thanks for sharing your mixing problems. You seem to have a fairly unique setup there. It is just the kind of problem I created this mixer system to solve.
Since all mixing is moved to the Tx, no mixers are needed on the Tx. I fly a 10 channel aircraft on 6 channels plus mode. I also use exactly the same transmitter setup for all of my aircraft.
There is not thousands of additional functions, only 15. Some of these are obsolete so I only use half of the functions. It uses a few kb of ram for the mixer settings and mavlink communication buffers. There are some lookup tables for the functions plus the default mixer settings, maybe another few kb of flash.
The mixer is implemented on UDB4, not ardupilot. I have not yet checked how much effort it would be to move it to ardupilot. I would not advocate anyone attempting to port to ardupilot when the system needs improvements. If I get enough interest then I will support a group to work on the improvements.
/Matt
No doubt mixing can be complex. I am having trouble setting up mixing on a wing, and it only has 4 servos.
Elevon mixing (Finally added to the APM in manual mode)
Differential Aileron (On a left turn, the left Aileron/flap should travel up further than the right wing goes down)
Differential spoiler (On left rudder, both left control surfaces move opposite directions to create drag, right side does nothing).
Airbrakes (Both wings flaps move opposite aileron to create drag).
Throttle to aileron
Of course each additional parameter you try to mix makes the number of functions grow exponentially with things which can be mixed, like landing gear, multiple rudders (Airbrakes), vtail, elevon, flaperon, helicopter, gyro gain, multirotor, multi engine. Then you can take parameters that are speed/orientation based and also mix these too. It gives me a headache even thinking about it.
The biggest limiting factor I have run into so far is the TX has very limited mixing options. The norm seems to be one basic configuration (Elevon, v-tail, CCPM) with 3 configurable mixing options.
I couldn't even imagine taking a project like this on, especially if you were looking to integrate thousands of additional functions with the hardware limitations of something like the APM2.5 which would be the ideal scenerio since it already intercepts the inputs from the reciever.