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!

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[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