Changes in limits algorithm

[GoogleCodeExporter]

I would like to open discussion about changes in limits algorithm. Right now 
your latest version has algorithm for limits - cutoff. It means if you have 
limit 50% for the channel, servo will turn 50% of max way and stop with the 
stick in half way and the rest of the stick travel will be dead-band. That is 
fine, but not for all cases. I propose to add optionally also second algorithm 
- scaling. In our example, when stick will be in the max deviation, servo will 
turn 50% of max way. It means you proportionally (linear in simple case, if 
mixer has no exp function ) scale stick way to servo way. For second algorithm 
you don't have dead-band for the sticks.

It is not defect. Modification.

Original issue reported on code.google.com by vlad...@yahoo.com on 22 Sep 2010 at 5:08

[GoogleCodeExporter]

ok, i understand but ..

The dead-band problem arises in several other ways.
- If you have mixer-lines with more than 100%
- If you have more than one mixer line that adds to more than 100%
In total we would have to regard the whole calculation sequence.
Dualrate weight, mixer weights, subtrim .. limits.
The whole scenario can be complex and i dont see a simple way to remove any 
deadband by scaling in the right way.

Is it commmon usage to change the limits?

Isn't it very easy to reduce the mixer weight when the limits are reduced?

Your simple scaling-solution would be an additional multiplication, but this 
should be no problem, we could do it this way.

Are there any other opinions?

Original comment by th...@t-online.de on 23 Sep 2010 at 7:44

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

According your data-flow diagram, limits are in the last step in calculation 
procedure. It means "dead-band" task for the limits can be solved here with 
scaling in general case and as I wrote, the ideal is set up it as options : 
cutoff or scaling.

Original comment by vlad...@yahoo.com on 23 Sep 2010 at 6:30

[GoogleCodeExporter]

This is right, limits are the last step in calculation.
Do we need the cutoff option for positive and negative limits seperatly?
What happens when the limits are assymetric? Then the sensitivity gets 
assymetric too.

For the implementation of this feature we need two extra bits per channel.
Could we reduce the resolution of the limits to get one free bit per limit?
Proposal 1: 0 2 4 6,8,10 .. 124 126                          steps:2
proposal 2: 0 1 ..  9 10 12 14 .. 66 68 70 74 78 .. 142 146  steps:1,2,4
proposal 3: 0 1 .. 19 20 22 24 .. 58 60 65 70 75 .. 145 150  steps:1,2,5

Original comment by th...@t-online.de on 23 Sep 2010 at 8:39

[GoogleCodeExporter]

>Do we need the cutoff option for positive and negative limits separately?
I think no. For the both direction we can choose only cutoff or scaling.
>What happens when the limits are asymmetric? Then the sensitivity gets 
asymmetric too.
Yes, it is logically from my point.
>Could we reduce the resolution of the limits to get one free bit per limit?
Not sure I understand why we need 2 extra bits for the scaling operation, but I 
think to reduce limits resolution according your proposal 1 is not problem at 
all.

Original comment by vlad...@yahoo.com on 24 Sep 2010 at 6:43

[GoogleCodeExporter]

Original comment by th...@t-online.de on 7 Dec 2010 at 10:28

• Changed state: Done

[GoogleCodeExporter]

Can you please explain what final solution was implemented to the release ?

Original comment by vlad...@yahoo.com on 27 Jan 2011 at 9:06

[GoogleCodeExporter]

in the Limits menu you find a new Column Scale (scl).
If you change this column to an asterix (*) then the positive and negative 
values are scaled in a way that 100% mixer output leads to the given 
Limit-value.

The limit values are as follows:
0 1 2 3 4 5 6 7 8 9 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 
50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 135 140 145
This scaling is done not only to save one Bit of storage but also to speed up 
the setup times.

Original comment by th...@t-online.de on 27 Jan 2011 at 9:43

[GoogleCodeExporter]

@vlad: why would limits be symetrical ? I can hardly think of any application 
where they would be. When you press the lever on the servo, you generally 
notice it is not exactly perpendicular to the servo. So even when the airoplane 
was perfectly designed around this servo, limits would always be a-symetrical 
right ?? Limits where introduced to prevent servo movement do harm to the 
plane/helicopter (or vice versa).
I do like the idea of the scaling, it helps you skip a step in the general 
setup of a plane (normally you would set cut off limits, and then adapt mixer 
gain to prevent dead band), but simply going symetrical for limits may be 
cutting one corner too much. 

Original comment by harm.del...@echostar.com on 28 Jan 2011 at 1:56