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 => No cursor displaying when creating any Custom Curve. #24

2. Locking feature (to allow the user to release the stick) => No cursor displaying when creating any Custom Curve. #24

[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

[Dsrenger]

As far as I can test on the simulator (without real model) this looks so fuc.... good

[MikePhillyFlyers]

Hi Bertrand,

Just wanted to pass this by you, in case this would help in your design of the balance function (and even other servo setup funcs as well), I've been a user of Graupner radios for years now (MZ32), they have a very nice balance function similar to what you are designing now. (see the video below, balance starts at about 2:00 in)

https://www.youtube.com/watch?v=ALxShjOS73A

Notice they also have a setup that allows many points on the graph, and you can add more as you wish... if you ever need me to run any functions on my MZ32 or capture some vids for you, I'd be glad to help.

Also, notice the other menus especially their servo limits, endpoints, etc and how they set it all up in the GUIs, etc..

[robertobrazill]

Hi Bertrand,

Just wanted to pass this by you, in case this would help in your design of the balance function (and even other servo setup funcs as well), I've been a user of Graupner radios for years now (MZ32), they have a very nice balance function similar to what you are designing now. (see the video below, balance starts at about 2:00 in)

https://www.youtube.com/watch?v=ALxShjOS73A

Notice they also have a setup that allows many points on the graph, and you can add more as you wish... if you ever need me to run any functions on my MZ32 or capture some vids for you, I'd be glad to help.

Also, notice the other menus especially their servo limits, endpoints, etc and how they set it all up in the GUIs, etc

Awesome!

[jasalca]

I see that the main idea is going very very well. I would like if it is possible for you value for visibility issues on the flying filed in full sun, that the position bar of the stick instead of being white is highlight colour. What it looks like in the "mixer menu"

[jasalca]

I send you an example of visibility

In the second photo you can see that depending on the position of the stick, being of another color , is better seen according to situations

[jasalca]

With the lastest update of the simulator an hour ago, it is doing very strange things. If I try to raise the engine stick it does not correspond to the output of the channel and in the graph what is supposed to be the stick changes color orange- white- orange.
Ethos Simulator 2024-09-16 19-58-39.zip

[jasalca]

I have checked other channels ( elevator, aileron, rudder, ) and the outputs graphics are also malfunctioning

[bsongis-frsky]

The new simulator has a fix for that, it's coming soon

[robertobrazill]

Can you send me the link to the simulator?

[bsongis-frsky]

Available in 1.5.16 nightlies

[bsongis-frsky]

Latest screenshots

[robertobrazill]

@bsongis

As an update suggestion, it would be interesting if the point we blocked (locked) could be included as a new curve point, just like in Jeti.
I don't know if I managed to make myself understood.