Control Mixer

I spent some time looking at how curves are handled in various transmitters (albeit mostly from the manuals), and what we can do.

The easiest thing to use would be quadratic splines. Unfortunately, they tend to have a lot of oscillation (local max/min between specified points) and probably aren't appropriate

A cubic spline would be better, but it also likely has more oscillation than we'd want.

A bezier spline could be perfect, but you need to do some math to determine the control points. The easiest way to compute control points is with a geometrical method (something like this: scaledinnovation.com/analytics/splines/aboutSplines.html ), which gives the slope at each point to be equal to that of a line drawn between the 2 adjacent points. However, if you actually try it on the DEVO8, you don't get this result, so the are obviously not using this method. this method also requires a sqrt function which I'd rather not use.
I found an alternate bezier curve implementation which doesn't appear to need any sqrt functions here www.codeproject.com/Articles/31859/Draw-...Set-of-2D-Points-wit but haven't yet experimented with it.
The downside of a bezier curve is that it is non-trivial to evaluate at a given coordinate. a quadratic or cubic function would be much easier.
I need to experiment with the DEVO8 more to get a better feel for what algorithm it may be using.

Is the 'smooth curve' function really necessary? Other radios offer only piecewise-linear and/or equation-based 'smooth' functions. It seems to me we could get most of the gain with a lot less effort if we started with something like simpler.

IMO the expo is not essential for the curves, but it can be very comfortable. Imagine a heli throttle curve in stunt mode. It is "V" shaped to give more thrust for the larger pitch values at both the negative and positive end, where the pitch is the larger. You can make such shape with 3 points: point L at 0%, point M at 50% and point H at 100%.
Now if you waint it to be a curved shape (more like "U" than "V"), because you dont need the throttle to linearly increase with the pitch, then you should use all the 7 points (9 on the DEVO 12) to approximate the exponential curve, while you can set it with one checkbox and three points now.
So it can substitute with curves, but it is tedious...

However it is more important for the midsticks expo in the D/R menu!

I know you would like to handle all the transfer function settings with one curve, but it is easier to play with those few d/r and expo (and/or travel adjust) values to distort the otherwise settled - and difficult to change - curves.

Would it be hard to find these calculations in the fw?
Or we may look how the er9x guys calculate these things...

I looked at er9x and radioclone as part of my investigation. I don't fully understand er9x but as best as I can tell, they use an x^3 equation to model expo. Radioclone is more interesting. They seem to use a 2-layer curve implementation which is applied as part of the mixer. The 1st is applied to the raw data. The 2nd layer is applied during mixing. This allows them to modify an existing curve for D/R. In neither case do I see any evidence of any kind of curve fitting.

I have a 9X transmitter but haven't wired up the programmer to it yet, so I'm getting this mostly by reading the manual and inspecting the source. the er9x/th9x code is a mess, but the radioclone source is more reasonably thought out.

Then IMO we can leave out the curve fitting of the curve points, and use some x^2 or x^3 function for the stick expo.
Am I right, that the order of functions is: stick value -> d/r & expo -> curves -> mixes -> travel adjust -> transmitter?
While I know the travel adjut and the [dual] rate are are completely different things, but they very much do the same, so one of them can be omitted too...
In that way all the curves are limited to the normalized 0..100% range, and the d/r alone would allowed to increase/decrease the range.

I don't know, am I clear enough sometimes? My english is quite bad...

I've been playing with ER9X more, and I'm beginning to see the appeal of how they did things.
The idea behind it is a multiplexer that can add, multiply, or replace different inputs based on events. you can have as many different inputs controlling a channel as you like.

The system is complex, but it should be possible to setup any configuration, multiplexing multiple signals and layering multiple curves.

As an example, a 6ch heli throttle curve might be defined like this:They have predefined CCPM mixing for different swash setups, but you could do it yourself with something like:
The user interface for this is quite cludgey, but it is very flexible. To make it easier for the novice, they have predefined templates that provide inital values.

You can define virtual switches which can be used for the conditionals. The timer functionality seems somewhat limited, but you can basically start the timer on any event.

I'm going to think about if there is a better way to interface with a setup like this that would make it easier to use, but as I've been moving up the learning curve, I'm definitely seeing the appeal.

PhracturedBlue wrote: The idea behind it is a multiplexer that can add, multiply, or replace different inputs based on events. you can have as many different inputs controlling a channel as you like.

The system is complex, but it should be possible to setup any configuration, multiplexing multiple signals and layering multiple curves.

Could you explain it a little more, please?
You mean, like in the code examples, you can configure all the conditions (or even multiple conditions), the "else" branch(es), and the multiple argument expressions assinging the channel value?
You showed nested "if"s in the example. What depth can you configure?

I am having difficulty explaining it you might do better watching some er9x youtube videos or reading the manual. There should be no limit to the number of nested if/else conditions or how curves are applied or what conditions are used. You can effectively define variables (basically these are virtual channels) and rsuse them as needed.

The actual code to do so looks nothing like what I posted. I was trying to show what the capabilities are.
Here's the code for my throttle again:and here is how it is implemented in the tx (ID0/1 is the fmode toggle))
I could, however, configure something like this (though I'm not sure why I'd want to):It should be possible to configure arbitrarily complex expressions. The interface to do so is complicated, so actually applying the above would take some effort, but it is flexible enough to do so.

The ER9x manual on the mixer is here:
9xforums.com/wiki/index.php/Er9x_user_guide#Mixer

You can actually play with it yourself without having a 9x transmitter.
Download EEPE from here:
code.google.com/p/eepe/

And the template library from here:
9xforums.com/wiki/index.php/Er9x_user_guide#Example_Mixes

EEPE is not a direct simulator for the 9x (so you can't really get a feel for the interface on the tx), but it will let you see the capabilkities as well as the concept for how instructions are layered to create complex condition statements. And you can get a good feel for how it works.

THANKS! (Edit: Sorry, I've forgot... )

Sounds a bit too complicated, for sure...
There are not only programmers using transmitters!

I will play with it to see what it is like, and what's really needed...

I fully agree with the idea, that every channel should have a curve, mixes from other channels, and a rate, all that depending of different conditions like switches (especially the fmod sw) or stick/channel value. Basicly that is what they have there...

Well, in order to make progress, I've decided to implement the er9x mixer functionality. I have no idea how we'll present this to the end user, but the underlying principles of how the mixers are applied makes sense to me, and it should be flexible enough to expose nearly any interface to the end-users.

The Curves in ER9x Are applied as a transfer funcytion, so that is what I implemented
Basically there are a bunch of predefined functions to select from, or you can use a user-defined PWL.

We can of course rip this whole thing up and throw it away, but I wanted something to start with, and these guys have already thought out most of the issues.

One of the things I'm not sure about is the trims. Should trims be applied before or after the curves are applied?

I have not implement the delay or slow/fast capabilities, nor did I deal with alarms (I'm not sure the mixer is the right place for that)

I've still got some work to do to tie the code together such that I can actually test the new mixers in the emulator, but I'm pretty far along now.

Ok, I've checked in the mostly functional mixer code.

There is no interface to create mixers yet, so I've hard-coded a few to verify things are working. I've only tested with the emulator because the bar-graph feedback updates the screen too slowly to be useable.

Things that seem to work:
* apply a multiplier and offset to a channel
* PWL curves
* a few other simple transfer functions that I got from er9x
* max limits
* stacking multiple mixers to create complex functions
* predefined CCPM mixers

I haven't dealt with the trim values yet

Because the implementation is based on stacking multiple mixers to create a complex value, it is important that the mixers evaluate in the proper order. This means we need to be careful when creating the mixers to place them in the proper order so that they work.

I think the rule for ordering is that a given MixerA that uses SourceX and SwitchY must be placed after all mixers that have destination X or Y. When we start looking at the user interface, I'll need to make sure these rules are always obeyed.

I also need to think more about memory management. The current system is very inefficient. I'm not sure how to only use the amount of memory needed without a malloc implementation. As newlib doesn't have a decent one, it may be worth implementing something simple that can be used for the model and gui data. It would be a lot more efficient than trying to worst-case the memory usage.

I've been thinking about how to display the Mixer controls, and I decided to use the same templates concept that is in er9x, but to extend it to be more flexible.

Here is the main mixer page. It shows the channel, the primary control, the primary switch (if any) and the template in use.



Clicking on the template will (soon) open a new window where you can control the parameters. So for instance the Simple page will basically allow you to set the input, the curve, and min/max values.
The Dual-Rates page would be similar but with the addition of selecting the relevant switch and the limits of d/r separately (but still using a single curve)
I don't know what the 'complex' configuration will look like, but likely it'll basically expose the raw mixer interface
We can, of course, add as many templates as desired to make configuration easy.
Once finished, the code will convert the configuration into a set of 1 or more internal mixers

The 'simple' mixer interface is almost complete. Some of the simpler widgets are not yet hooked up but most of the hard stuff works:





The hardest part that is left is probably converting the template back into a mixer, but taht isn't needed for the 'simple' template.

I'm finding that there is still some work to do to the widgets. There is no way to use a 'long press' to speed through options, and no way to use buttons to change widget values.

I mean physical buttons on the Tx. The widgets don't react to pressing the Up/Down, Left/Right or Enter buttons. This is useful especially in the field where you may be too fat-fingered to use the touch display.

Ok, I've basically finished with the mixers for now.
I've built GUI interfaces for the following templates:
Simple - supports a curve and scaler
Dual-rates - supports one curve and one switch with 2 scalers
Expo - supports one curve and one switch and one scaler
Complex - you define each mixer for a given channel

I've added the code which should (I think) properly order the mixers such that they execute only after alll dependencies are met

So at this point It should be possible to map Tx inputs to channel outputs as needed for any model type.

Cool!
I have to have a closer look, but first it seems, that the numeric spin buttons intcrement by 5 in the down direction, but by one upwards. I guess the big steps are for the continuously pressed state...