User's demand for servo balance function

[FrSky-GX]

Some users need to use multiple servos to drive the same side, where the mechanical differences between the servos require similar functions to adjust.

[hrenz]

you can use curves at servos menue for this

[mawzthefinn]

This is a duplicate of #38

@hrenz - With servo telemetry it should be possible to auto-adjust the curve to balance the servos by monitoring current draw to observe binding.

[Nicholas-Luoyi]

Hello everyone. We are here to ask if this kind of function is useful to enhance in ETHOS. Actually, we design to add a new concept called Channel Group. You can add channels which controls one flap into a channel group. You can adjust the curve for these channels at one page. So you don't need to enter & exit from channel to channel in outputs page. At the same time, we will add a new switch to lock the output value of all the channels you add to this group. This will help you to balance all the servos at any angles. You can see the image attached below. Any suggestions are welcomed. Thank you all.

[mawzthefinn]

It's definitely a useful addition, folks have been asking for an easier solution to just adjusting individual channel output curves since the early days.

[RC-SOAR]

Not sure I understand this proposal.

Take a common example of twin flap servos with different geometries. Currently we calibrate each output via its own individual curve, so that the flaps track correctly regardless of mechanical differences. This allows mixer weights to be the same on both left and right sides. This greatly simplifies mixer design.

Can you provide an example of how this proposal would help in this situation?

[rburrow87]

This is great! Very useful feature for larger aircraft.

Can you provide an example of how this proposal would help in this situation?

Maybe it won't help in your situation then. But this is useful for situations like a single aileron with 2+ servos driving it. Or even just balancing left and right elevators throughout the range.

Just because the end points are matched does not mean they will move exactly the same throughout the range unless you have everything mechanically matched absolutely perfectly. Which can be very difficult to achieve.

[mawzthefinn]

@RC-SOAR 's example is no different than yours @rburrow87 , except in how far off the two servo geometries can be (it's possible to have much larger variation on independent surfaces than ganged servos on one surface)

You want the two servos moving in sync in both cases, the question is how is that done via the screen shown.

MY suspicion is that the two servo pages are independent adjustments.

[rburrow87]

Ah I missed where RC-SOAR mentioned using a curve. I had attempted to use a curve on the outputs to match servos, but I found it too tedious for the small amount of correction I needed. This will make it much easier.

[RC-SOAR]

I think I get it now. At least, this is how I think it should work, based on the CAL mode which I offer on my OTX glider templates and which aims to solve the same problem (that of equalising the movement of left/right surfaces).

The goal is to achieve the same deflection on each side, for any given aggregated mixer value.

Comments are in relation to the earlier screenshot. Additional features in italics.

• A group is a pair of related channels, identified as 'servo 1', and 'servo 2'.
• Each channel has its own output curve (nothing new here, it will have been defined in the Outputs menu).
• The active channel is selectable via the 'servo 1/2' field.
• The curve of the active channel may be adjusted via this page.
• Allow the user to hop between points on the active curve, and apply the x-value to both channels simultaneously, overriding all other mixers for those channels.

This is all that is necessary to get a pair of surfaces to track together, regardless of mechanical differences.

Not sure that it's necessary to 'lock' channels, since the curves are adjusted individually, or have I missed something?

[Nicholas-Luoyi]

Locking channels means that you don't need to keep togglling the stick while adjusting the curve point of one servo.

[rburrow87]

That's a nice touch!

[strgaltdel]

since the core function (synchronization of flap deflections) can basically already be performed by the output curves, for me the real "added value" is only given by the "lock mechanism".

What I could imagine / what i do understand: (1) During the adjustment work on a channel group the "lock mechanism" ensures that "actually" no further mixers can make changes on the deflections.

(2) Practice shows that "paired" servos for e.g. flaps are installed mirror-inverted between left and right wing. sometimes weights are set in the outputs to prevent mech. stops or to exhaust servo travels, so the output settings reverse.. limits..must still be considered (actually self-evident)

(3) ideally an input (e.g. throttle) can be defined for synchronization/calibration to "approach" the trim points in order to generate deflection, or you can jump to them via touch, which generates servo deflection, so you can visual proof your curve setting; apart from the trim points, no other intermediate "curve points" for deflection should be reachable during the process (like using an internal staircase curve when using an analog input) the analog "lock input", if supported, is only used during the calibration process

(4) i would propose that all "servo output curves" of a group shares the same x-coordinates, only trimming individual y coordinates should be possible

In sum, this is definitely an enrichment. If it should even be possible to get access via Lua (like to already existing curves), a script could be developed that allows a fully automatic calibration via IMU-measured angles at the flaps and return of the values via telemetry.

[pstasek]

This feature is achievable when a certain procedure is followed using curves in Outputs. However, whenever somebody needs this to be configured in our club, they come to me and I have to make it work for them. Any improvement of this workflow towards being more standard user-friendly is appreciated.

The workflow I'm using is temporarily setting the said surface outputs to a slider, removing all but one servo connection and tweaking the curves manually, checking a hole in a ball link is aligned with the control horn through all of the travel. It's labour labour-intensive workflow but provides great results.

I can see that a temporary assignment of the group to a slider from the Output screen would simplify this procedure and be more intuitive as this is quite hard to explain to less tech-savvy guys.

Workflow based on current draw would need to be automated as it would probably introduce servos to high power loading during extensive amounts of time when done manually and be potentially dangerous. But it would certainly be very cool!

[robertobrazill]

A very useful feature that could be created in conjunction with this is that the curve graph can be moved along with the desired command, which is currently static. In JETTI radios the graph moves, and to make a servo balancer it is a very useful thing. On the X20 you have to do it in the dark, as the graph doesn't move.

[RC-SOAR]

We already have two means of balancing servos:

• min/max/subtrim (acts as a 3-point curve)
• optional output curve

Both of these work together, which can be a little confusing (unless you set min/max/subtrim to their pass through values).

Rather than add a third layer of complexity, what would be nice would be to replace min/max/subtrim and the output curve with a single multi-point calibration curve, with a UI which allows for easy adjustment in pairs, with all mixers disabled.

[robertobrazill]

It would be excellent if this topic was reviewed by the FRSKY team.

[Quimb0]

Hello. It is a great help to achieve that ethos balance of servos by surfaces, it will mean a lot of precision in adjustment and a saving in time by not generating so many manual curves blindly. Do we know if this is in the process of being implemented? Thanks for the work

[andreavi90]

Any news by the developer team? Servo Balance will be a very useful function, and it's already implemented in other systems like Spektrum or Jeti.

[bsongis-frsky]

This function is really needed. But it seems to me the "Channels groups" concept is out of topic. What the users need is a way to balance the servo output at any position of the input.

1) We should work here with a special curve in the channel output which I will name "Balance curve". All points there should be 0 by default

2) But there is a problem: when the user will want to balance 2 servos (let's say CH8 and CH9, the 2 left ailerons for example), he will have to work on CH8, change one point, then CH9, change the same point, then back to CH8, etc. At the end, the user is lost. He will change the wrong channel curve.

Here I would like to propose a tool in a contextual menu: a Dialog will propose to show 2 curves (perhaps more is needed / possible) in the same time, one at the left, the other at the right. Tandem radios have a big LCD, it should be perfect. The curve which is currently modified will have the focus, so that you cannot change the wrong channel by mistake.

[bsongis-frsky]

Some comments are out of topic, but still valid:

1) Current position shown on the curve => #24

2) Locking feature (to allow the user to release the stick) => #24

[hrenz]

Look at this video, there is no need for exact ruder balanzing it balanzing itself, its from Desert Aircraft Australia

[rburrow87]

That works for a pull-pull setup, but not if each servo is directly driving the same surface. Or if you're trying to perfectly match two elevators, or similar.

[bsongis-frsky]

Interesting. Perhaps you will like to balance your 4 ailerons on the glider wing, then 2 may be used as flaps. This will also be true with only 2 ailerons, or 2 airbrakes ...

Here is the work in progress as of today:

[bsongis-frsky]

[robertobrazill]

Nice!

[spoke2570]

This is going to be cool.

[strgaltdel]

Over the weekend, I was thinking about the "Balance Channels" feature.

I know it's actually still too early to discuss it in a broader way since the very first release isn't "public" yet. And please don't take my post as unnecessary criticism before the feature can even be used, but rather as an idea for how it might be further developed.

"My issue" becomes apparent in the image above showing 4 ailerons.

Basic idea: A plane has, for example, 6 or 8 flaps, and the 4 ailerons need to be synchronized. If I now give aileron input, this will only move 2 flaps to a "synchronized position" (e.g., 30% deflection), which can then be balanced. The other two flaps "on the other wing" will deflect in the opposite direction, and so they can't be trimmed for a "30% Ail Up Position" in this state

another point: What unclear is to me: which signal controls the "X position": a) Is it directly from the control input, or b) from the output of the aileron mixer?

If, for example, only 80% aileron weighting and 120% butterfly are configured, in case a) the full range wouldn't be utilized due to weighting and differentiation configured in the mixer. Case b) could be difficult if the neutral point has been shifted by an offset mixer, so even by adding 100% from input, you don't reach the max points.

My idea of a future workflow:

• The user first sets the direction in the channel outputs according to best practices and synchronizes the end points via the limits (min/max).
• Ideally, for "channel balancing," a preferred control input (slider/throttle/pot) could optionally be configured. If a preferred control input is defined by the user, the existing mixers on the respective channels are temporarily deactivated, and only this input generates a signal from -100 to +100% on the corresponding mixer outputs. Now, ALL FOUR configured channels can be moved to the desired positions IN PARALLEL via the slider, and can be adjusted.
• As an additional enhancement for Ethos 2.x: A "snap" function would no longer allow the control input to change the X value linearly; instead, the control value would be discrete and would "jump" directly to the nearest X value, similar to the "auto" function, so that adjustments are made exactly on the "trim coordinate."

Mawz's commented on rcg: "I actually suggested that FrSky develop an FBus Angle sensor a while back for setup use (ideally a set of BT sensors with a BT to FBus dongle you can plug into the receiver"

And now imagine an X24 or "next generation" or whatever transmitter , in some years, could directly process such BT or Wi-Fi sensors, and the transmitter would have a script that automatically performs the manual steps mentioned above and generates the correction curves for 4 flaps fully automatically in just three minutes... (-; how did someone say. "i have a dream".....

[bsongis-frsky]

On a glider which has 2 left ailerons and 2 right ailerons. If you need to balance the left ailerons, you need 2 curves, they will go to the same direction. No problem.

Why would you need to balance the 4 ailerons in the same time? Because you use them as flaps (all in the same direction)? Then you need to balance them using the flaps function:

[bsongis-frsky]

[strgaltdel]

Use cases:

1) Input Ail left 50% should generate same physical deflection upwards then Ail right 50% for example; in case you've a 6 flap glider the outer 4 flaps mostly are used as ailerons with more or less butterfly/camber mixing 2) and yes, usage of Ails for secondary functions like Butterfly and crow.

i'll see how it's implemented, was under the impression that the balance curve should sync the complete available deflection rate.

e.g. Ails:

• some gliders are configured so that butterfly will generate the max deflection upwards, ail maybe 80%, so using butterfly as input would be the input choice to sync deflection upwards, but is not usable to sync downward deflection on ails
• most gliders have more downward deflection on ails then on camber/flap, so using flap as input for synch downward deflection would not take the absolute min position into account.

that's the reason i proposed an additional input to reach the endpoints under all circumstances, without the need for switching between different ones.

probably i've to work with the first published release to give more input, i don't have the "complete picture" yet, Without a doubt, it is a great enhancement. i guess we're talking about the last 10 % optimization potential, if any

[Dsrenger]

One thought, without knowing the exact implementation.

When balancing the ailerons, I usually use the method Mike Shellim uses in his templates.

The issue with balancing ailerons is, that one Aileron moves up and one moves down. This prevents a optical balancing, that is sometimes easier and more accourate then measurements.

Mike implemented in his template, that the ailerons move in the same direction while balancing the curves to allow the optical calibration.

Whould it be possible to incorperate a way to let the ailerons move into the same direction temporalily as well?

I think that a very good method for balancing ailerons.

[strgaltdel]

.. thats what i meant with

"Ideally, for "channel balancing," a preferred control input (slider/throttle/pot) could optionally be configured. If a preferred control input is defined by the user, the existing mixers on the respective channels are temporarily deactivated, and only this input generates a signal from -100 to +100% on the corresponding mixer outputs / channel inputs . Now, ALL FOUR configured channels can be moved to the desired positions IN PARALLEL via the slider, and can be adjusted."

and pstasek wrote a year ago "The workflow I'm using is temporarily setting the said surface outputs to a slider, removing all but one servo connection and tweaking the curves manually,"

but i can feel Bertrands pain, Probably weeks were spent on the existing solution it’s almost finished and works as initially intended. There's rightful pride in this great enhancement. And now we come back at the end with the fundamental statement, 'something's still missing...'

btw @dennis: Helmut just introduced the feature in the forum as a function for synchronizing multiple servos that control one flap

[Dsrenger]

I hope nobody (especially Betrand) gets me wrong.

It is already great as it is. As you you said before. It is just the last 10%.

I really hope Bertrand gets it, as what it is. Constructive thoughts on the showed feature.

[RC-SOAR]

@bsongis-frsky can you explain where the balancing curve sits in the pipeline? Currently we have Min/Max/Subtrim (effectively a 3 point curve) feeding to the (optional) output curve. Presumably the balancing curve is applied last?

[bsongis]

Today the order is: 1) limit the mixValue which has to be applied inside the allowed range 2) apply the direction 3) apply the curve 4) apply the balance curve 5) apply the limits (min / max / center) - it's forbidden to go over the min / max 6) apply the slow 7) apply the PWM center

[RC-SOAR]

Thanks, Bertrand.

In terms of workflow, one would adjust steps 3 and 5, then make ad-hoc corrections with the balancer, is that right?

Also can you clarify: the input to the balance curve would be the output of the output curve - so there is no guarantee that the balancer would see the full +/-100% swing as it would depend on the output curve characteristics. If the swing is small, then presumably only a small selection of points in the equaliser would be active. I'm thinking here of cases where limits are set via the output curve, with min and max left at their default values (+/-100%).

[strgaltdel]

@RC-SOAR imho: It's often the case that there are different ways to achieve a goal (like the previous method of synchronization). For example, restricting the endpoints can also be done through a curve in the outputs.

Sometimes, however, there's only one best practice. Here, it means: The Y-endpoints of the previous "output curves" must always be +/-100%, and limits should ALWAYS be set via min/max.

@bsongis The more I think about it, the more I realize that I’m missing a "link":

Which input signal is used to match the selected curves? a) Is it automatically derived based on the selected channels (e.g., aileron channels automatically use the outputs of the aileron mixers, or even directly the aileron input)? b) Is an "input" manually defined, in addition to the manually selected channels, or c) Is it the standard "sum of all mixer operations" signal (e.g. including flaps, butterfly, offsets to an aileron) ?

If it's c), then "my problem" of synchronizing, for example, 4 aileron flaps simultaneously via pot/slider, would be easy to solve by using a free mixer as the last mixer, which is only used for calibration, controls the entire range +/-100%, and replaces all previous ones.

that would be great

[RC-SOAR]

@strgaltdel

Sometimes, however, there's only one best practice. Here, it means: The Y-endpoints of the previous "output curves" must always be +/-100%, and limits should ALWAYS be set via min/max.

A percentage of users will not have the end points at +/-100% simply because it's not enforced. I agree it's a small percentage of users, but it should be considered a limitation.

(Users of my templates with CAL mode set their limits in the output curve, however they will not need a balancer facility as the balancing is done during calibration.)

[bsongis]

@RC-SOAR The input of the balance curve is the output of the previous step.

You may use the output curve to balance the surfaces, but it won't be the best method any more!

Also I will add another method to balance the surface, which will give the full range [-100%:+100%] as input to the curve (and output), without the need of an extra Mix!

[RC-SOAR]

As described so far, it seems to me that the balancer feature is in essence a way of making ad-hoc corrections, for setups which do not use output curves (that is: setups which set limits via Min/Max).

One potential problem with the current proposal. What happens if, after equalisation, the user decides to define an output curve (for example to define a non-linear response), with the curve shared between all channels in the group? Wouldn't it invalidate the equaliser curves, necessitating a re-equalisation?

[bsongis]

If the curve is shared by many outputs, it cannot be an equalisation curve, it's something else, which is common. Then comes the equalisation curve ...

[RC-SOAR]

To clarify, suppose the user

1. Optimises the equalisation curves via the new UI (step 4 above). So now we have perfectly balanced outputs.
2. Later, he defines an output curve (step 3), and shares it between all the outputs in the group (for example, to define a non-linear response). Doesn't that invalidate the equalisation curves?

[bsongis]

The equalisation curve is applied AFTER the curve

[robertobrazill]

In my opinion, equalization should not necessarily be considered as a curve, for elevator balancing, you do not need to make a curve. I can send a video of how it is done on the Jeti, do you want it?

[bsongis]

I see the use of curves rather when the input is linear and the output is not. Then the result of the output after the curve is theorically right. Plus the balance curve and the output will be really right as it will fix all the mechanics small defects (one curve per channel, not shareable)

[strgaltdel]

i'm with Bertrand

• equalization curves should be used to compensate deflection differences in between a group of flaps, so you'll typically see "alignment values" around the zero-line

• this does not automatically mean that you'll get a linear, or a from users targeted "deflection response". so if the user wants to obtain a specific "response curve" in the channel-group, he must define one and apply this to all of the related outputs

[RC-SOAR]

The equalisation curve is applied AFTER the curve

Got it, thanks.

@strgaltdel Understood. I was under the mistaken impression that altering the output curve would invalidate the subsequent equalisation corrections.

[jasalca]

Ethos Simulator 2024-09-11 17-11-46.zip Bertrand, I was researching this great work that you are doing and I saw this proble perhaps because it is not finished, but I wanted to tell you about it.

When you access to edit a curve through " outputs" menu, everything goes perfectly, but if you try to edit a curve through the "curves" menu , not everything new that you are implementing appears.

I´ll send you a video.

Thanks for this great job

[RC-SOAR]

Would love to try it out but it won't be before next week.

[strgaltdel]

Great work, i love it, congratulations !

As jasalca mentioned: Entering a single curve by "direct edit" you need two clicks / "taps" on screen 1st set focus on the curve (i would propose to set the focus without user intervention) 2nd is needed to activate the Auto-fetch

thanks !! udo