Heli: Summary analysis, problem spots, templates

More
05 Sep 2016 20:52 - 06 Sep 2016 09:57 #53524 by Thomas.Heiss
Hello all developers,

I wanted to give some summary of the known heli code analysis by Hexfet and me and others ("known heli issues"), especially found different "new" problem code parts which work together and it's side effects.

Mantis Bugtracker:
#637: www.deviationtx.com/mantisbt/view.php?id=637
#624: www.deviationtx.com/mantisbt/view.php?id=624

PullRequests:
#90 Fix standard GUI heli template: bitbucket.org/deviationtx/deviation/pull...rd-gui-heli-template
BitBucket template commit b9edc4c: bitbucket.org/deviationtx/deviation/comm...7d1632207bd2c60519d3
#76 Fix channel mapping error when selecting protocol: bitbucket.org/deviationtx/deviation/pull...error-when-selecting
#75 Correct channel assignments when loading templates: bitbucket.org/deviationtx/deviation/pull...gnments-when-loading
Last edit: 06 Sep 2016 09:57 by Thomas.Heiss. Reason: topic

Please Log in or Create an account to join the conversation.

More
05 Sep 2016 20:54 #53525 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Sum code analysis, problem parts, templates
Main (important) heli threads:
Are Cyclic1/2 reversed on standard GUI CCPM120 swash: www.deviationtx.com/forum/3-feedback-que...andard-gui-120-swash
New v4.0.1-ef0d76d: www.deviationtx.com/forum/3-feedback-que...d?limitstart=0#36466

Deviation 5.0 has been released: www.deviationtx.com/forum/6-general-disc...-been-released#47639
Deviation 5.0 release requirements: www.deviationtx.com/forum/6-general-disc...ments?start=20#46348

Cyclic1/2/3 Mixer Template Documentation?: www.deviationtx.com/forum/3-feedback-que...mplate-documentation
HOWTO Setup FBL helis on custom firmware: www.deviationtx.com/forum/how-to/1226-ho...s-on-custom-firmware

Please Log in or Create an account to join the conversation.

More
05 Sep 2016 20:56 #53526 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Sum code analysis, problem parts, templates
Main (important) heli threads - part II:
Can't figure out CCPM settings for flybar: www.deviationtx.com/forum/6-general-disc...-settings-for-flybar
Standard or Advanced GUI that is the question: www.deviationtx.com/forum/3-feedback-que...that-is-the-question
Flybarless template needed: www.deviationtx.com/forum/3-feedback-que...less-template-needed
How do I set the CCPM type for single servo: www.deviationtx.com/forum/3-feedback-que...ype-for-single-servo
CCPM: www.deviationtx.com/forum/6-general-discussions/1537-ccpm

Please Log in or Create an account to join the conversation.

More
05 Sep 2016 20:57 #53527 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Sum code analysis, problem parts, templates
Last new heli threads (excerpt) - part I:
I gave up: www.deviationtx.com/forum/6-general-discussions/6308-i-gave-up
Anyone find V5.0.0 for d7e mistake AIL and ELE: www.deviationtx.com/forum/3-feedback-que...-mistake-ail-and-ele
Deviation 5.0 - can't change channels: www.deviationtx.com/forum/6-general-disc...an-t-change-channels
Help with 7e and T-Rex, mixing standard GUI: www.deviationtx.com/forum/6-general-disc...-mixing-standard-gui

Please Log in or Create an account to join the conversation.

More
05 Sep 2016 20:59 #53528 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Sum code analysis, problem parts, templates
Last new heli threads (excerpt) - part II:
New Firmware V5.0 something wrong of Devo6S: www.deviationtx.com/forum/3-feedback-que...hing-wrong-of-devo6s
Mixer channel order: www.deviationtx.com/forum/3-feedback-que...-mixer-channel-order
Help needed CCPM for Blade CP: www.deviationtx.com/forum/3-feedback-que...e-cp-with-ar6100e-rx
....

Please Log in or Create an account to join the conversation.

More
05 Sep 2016 21:12 - 08 Sep 2016 14:29 #53529 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary code analysis, problems, templates
I did invest on Friday and Saturday 02./03 September some further time to try to understand what is really going on / wrong with the old vs new heli templates.ini and CCPM 120 vs FBL/NONE settings and model.ini settings once written to file system or what happens on GUI model setup / swashplate changes.

This includes 4.0.1-nightly builds before (I am on fcd0669) and after Hexfet's template changes of PullRequest #90 / b9edc4c and included Deviation release 5.0 templates and how my Blade 4503D Flybar heli (CCPM120 with front elevator cyclic servo) and Walkera V120D02s (FBL: Spektrumized/Tarot ZYX) work(ed) with my own Deviation model.ini's (before).

Somehow we also seem to have lost file history BitBucket->Github source repository for the templates and pre master/default/trunk and branches?!?


As explained by Hexfet previously
- pointing to the mixer.c MIXER_CreateCyclicOutput code
- and undoing his previous 4.0.1-nightly-build mixer.c code changes

we still must consider for heli templates + standard mixer (heli) GUI actually swapping cyclic2 with cyclic1 as the CCPM (120) workaround if not going for NONE/1 Servo/FBL.

This can ONLY BE DONE right now in the advanced mixer GUI or manually by editing model.ini - once the (standard) heli GUI screen setup is finished and does not get changed anymore (e.g Swashplate CCPM, protocol, etc.).
If you do editing before or you auto-load (popup mixer heli dialog) any default heli template, it will get overwritten by the current C code.

Otherwise you guys would have to re-write mixer.c - and leaving all previous Deviation 4.01, 4.01-nightly-build and 5.0 release heli model.ini's non-compatible, as explained by Hexfet in coordination with PhracturedBlue about future template versioning.
Even for the old heli templates (all Deviation versions) we would have no 100% working workaround, especially standard mixer GUI (and clicking thru screens).



I) IMHO we need to split heli templates into two for each type - I already have written / tested with basic 4-5 heli templates:

- advanced mixer GUI: CCPM120&others + CCPM NONE [+a real 3rd FBL heli template]: that will of course work without having to manually swapping cyclic2/cyclic1 by user as all variations can be supplied
- standard mixer GUI: CCPM120&others + CCPM NONE (FBL)


II) 4.0.1-nightly-builds heli templates (before b9edc4c) where compatible with CCPM NONE (FBL) only

-> manual swapping cyclic2<->cyclic1 for ELEV/AIL by user in (advanced) mixer GUI for CCPM120 is required and confuses new Deviation users: heli threads popup every ~1-4 weeks


III) new committed release 5.0 heli templates changed by Hexfet (after b9edc4c) are IMHO not compatible with CCPM NONE (FBL) and standard port and standard channel mappings anymore per manual 11.4 swash mixing definitions

Confirmed for III) FBL re-test. on September 08: www.deviationtx.com/forum/7-development/...pots-templates#53635

-> 6ch_heli.ini: cyclic1/cyclic2 ELEV/AIL swapping for e.g CCPM 120 is already done in template, but normal cyclic2/cyclic1 ELEV/AIL mapping is missing (I guess there will be much more FBL helis stand flybar CCPM mixing helis?)
-> alternative 3rd heli FBL template is missing (6ch_heli.ini could be used previously for NONE/FBL too!)
-> heli_std.ini (see V): if there is any fixed AIL/ELEV receiver port/channel order (e.g NanoCPX, XK K110 FBL heli, T-Rex 150 etc.) - where you might not be able to switch ELEV<->AIL ports on the receiver??!??)


IIII) Hardcoded mixer_standard.c does not set the template for protocol e.g EATR vs TAER re-mappings (or automap) as read before in 2 given heli_xxx.ini templates for previous mapped channel:
It does not yet use "MIXER_GetTemplate(previous channel)", so no way to set cyclic1/cyclic2 in any specific two file templates and changing the protocol laters in the GUI.
Template settings are ignored, C code is hardcoded overwriting.
void STDMIXER_SetChannelOrderByProtocol()
{
...
mixer_standard.c:       MIXER_SetTemplate(mapped_std_channels.aile, MIXERTEMPLATE_CYC1);
mixer_standard.c:       MIXER_SetTemplate(mapped_std_channels.elev, MIXERTEMPLATE_CYC2);

Instead of using hardcoded mappings like my try in V) which also takes consideration of swashplate 1S/FBL vs CCPM mixing how could we just read the previous output channel ELEV/AIL and given cyclic2 (NONE) vs cyclic1 (CCPM) template mappings?

Do we have access to the previous loaded template channel values?


V) new committed heli templates do not work in the standard mixer GUI as there is mixer_standard.c code which overwrites (hardcoded) templates.ini cyclic1/2 mappings to it's ELEV->Cyclic2, AIL->Cyclic1 defaults (as before b9edc4c)
-> only playing around with heli_std.ini is NOT enough for working heli setups!

For my internal standard mixer GUI test I partially extended (successfully) this code to:
void STDMIXER_SetChannelOrderByProtocol()
{
    // AIL<->Cyclic1, ELEV<->Cyclic2 and Virt1<->AIL input, Virt2<->ELEV source input mappings only work for SwashType NONE=FBL settings
    if (Model.swash_type == SWASH_TYPE_NONE) {
       // standard template cyclic settings as before: required for FBL (direct 1:1 channel <-> Cyclic <-> source requirements)
       MIXER_SetTemplate(mapped_std_channels.aile, MIXERTEMPLATE_CYC1);
       MIXER_SetTemplate(mapped_std_channels.elev, MIXERTEMPLATE_CYC2);
    } else {
       // mixer.c requires model.ini swapped cyclic templates for working AIL+ELEV CCPM mixing
       // need: output AIL: template Cyclic2, output ELEV=Cyclic1
       // model.ini Virt1<->AIL source, Virt2<->ELEV source.
       MIXER_SetTemplate(mapped_std_channels.aile, MIXERTEMPLATE_CYC2); // std_heli_CCPM.ini template is setup like that
       MIXER_SetTemplate(mapped_std_channels.elev, MIXERTEMPLATE_CYC1); // std_heli_CCPM.ini template is setup like that
    }

This code however does NOT work with the mixer GUI advanced to standard screen and popup dialog and heli_std.ini template loading.


VI) new heli_std.ini template with changed Virt1<->ELEV / Virt1<->AIL inputs (before: Virt1<->AIL / Virt2<->ELEV inputs) do not work for CCPM120 and front elevator for me (I can see this in channel monitor):
- AIL (roll) stick is mixing wrong ELEV+PIT channels instead of AIL+PIT channels, because of the change of the Virt1/Virt2 switched source inputs
- AIL (roll) stick is mixing only correctly AIL+PIT channels: when Virt1/Virt2 restore to old AIL/ELE (before b9edc4c) source input behavior!
-> mixer_standard.c code overwrites the given (adjusted/switched) template cyclic1/cyclic2 ELEV/AIL mapping to previous cyclic2/cyclic1 ELEV/AIL template mapping

-> manual 11.4 swash mixing diagram clearly states that ELEV port is the front/back elevator servo and AIL+PIT ports are to be used for the roll servos, nothing different: www.deviationtx.com/manuals/html-devo10/...ex.html#swash-mixing

-> even for FBL (CCPM NONE) helis in standard mixer GUI:
* output ELEV channel is therefore assigned to AIL source input (template.ini cyclic1 is ignored and changed back to cyclic2)
* output AIL channel is assigned to ELEV source input (template.ini cyclic2 is ignored and changed back to cyclic1)


VII) In the Model setup / mixer advanced->standard selection and popup window there is the "default standard heli template" read:
pages/common/_dialogs.c:    static const char * const STANDARD_TEMPLATE = "heli_std.ini";

static void invalid_stdmixer_cb(u8 state, void *guiObj)
{
...
 CONFIG_ReadTemplate(STANDARD_TEMPLATE); // load template
...
}

The standard GUI mixer popup window
1) does not yet care about Swashplate NONE vs CCPM settings
2) and does not make any template loading choices
3) and would have to be extended with a 2nd popup or a message that a user should actually use the "load/template" button functionality instead of switching to "standard mixer GUI" at the bottom in model setup screen.

heli_std.ini as a template and the constant should be removed!

It looks illogical to me that a user should use "model setup" screen / item "heli" / press button on heli to show "swashplate configuration" popup to either choose NONE (default) or CCPM 120 and then afterwards would have to click in model setup screen below at the the "mixer GUI" item button and choose standard to load one of the two correct heli templates?!?

The normal use of the standard heli GUI probably is that a user chooses advanced vs standard and does the swash settings (NONE vs CCPM 120) within the real standard swash menu configuration (after the template is loaded).

I already tested what happens if I delete the heli_std.ini template (to decouple a little bit the heli logic from the dialog).
Of course no standard heli template can be found by _dialog.c and therefore it would not switch to standard gui anymore.
So there has to stay "some heli logic" with the model setup / mixer GUI standard popup _dialog.c.


VIII) _dialogs.c: Maybe it would be better to drop support for auto standard heli template.ini loading for any Non-Swashplate specific settings with the popup window?
Spreading CCPM NONE vs CCPM 120/120x/140/90 template dialog loading
vs
STDMIXER_SetChannelOrderByProtocol() channel to cyclic1/cyclic2 template mappings
vs
Swashplate NONE->CCPM120/120x/140/90 event fire

Multiple C places with some business logic.


VIIII) Standard mixer GUI and loading a NONE template does not do any event fire when Swashplate NONE->120 is changed within the model setup [probably also for standard GUI Swash menu?!], once the heli template is loaded.
STDMIXER_SetChannelOrderByProtocol() is not called, my model.ini is not re-written for cyclic1/cylic2 (but stays cyclic2/cyclic1).
This means that Swashplate NONE cyclic2/cyclic1 template mappings are not switched for Swashplate 120 to cyclic1/cyclic2 output channel template mappings!!!

How could we easily add Swash change monitoring / event fire and calling our cyclic mapping business logic (or reading from previous template.ini output channel mappings)?


X) There are multiple places where STDMIXER_SetChannelOrderByProtocol() is called, if you really care to integrate any swash business logic as with my test in IV)


XI) Can cyclic1/cyclic2 template to output channel ELEV/AIL mapping be also applied to 120X/140/90 swashplate configuration or is 120X e.g one exception?
I have to read in more detail the 11.4 manual about swash mixing possibilities and play around with the 3 cyclic channel mixing in monitor.
I can only live-test 120 front elevator with my Blade 4503D and so far I do fully understand the channel monitor with only this setting. So far I checked my two models for the channel monitor and tried to replicate for the new templates or code change tests.


Doing all my basic tests with all these variations I do now understand more and more why there are more and more Deviation users who do not get any working heli configuration/templates and mappings anymore :-)
One thing is always missing / wrong...

#1 successful standard mixer GUI test (with no manual model.ini editing): Heli cyclic mixing worked for me in channel monitor either for NONE/FBL or CCPM120 if done correctly in the right order (manual heli template loading, protocol initation, protocol change, etc.).

Personally I would only suggest to go the "4.0.1/5.0 template / model ini" heli compatible workaround route in upcoming nightly-build / 5.x.x if further heli / screen mixer code changes (existing multiple blocks / files) do not get too overwhelming.


Hope to hear from you guys.


Thomas
Last edit: 08 Sep 2016 14:29 by Thomas.Heiss.

Please Log in or Create an account to join the conversation.

More
07 Sep 2016 21:27 #53606 by victzh
Thomas, thanks for your great systematizing work.

Personally I'm not an expert in the mixer code and principles, so I will need time to digest it. If anyone looking here with more experience would look into it I also be grateful.

But this kind of work is necessary to advance Deviation further.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 11:06 - 08 Sep 2016 11:36 #53628 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary code analysis, problems, templates

hexfet wrote: The root error in the code is in the switch statement in MIXER_CreateCyclicOutput(() in mixer.c. For SWASH_TYPE_NONE the assignments to cyc[0..2] are correct. For all the other swash types the cyc[0..2] assignment statements need to have all the elevator and aileron variables swapped. One of those threads Thomas referenced has some links to references on ccpm mixing equations with supporting information.



Mixer.c code cyclic changes in V5.x.x VS bigger (workaround) code changes in multiple blocks/files for compatible heli templates V4.0.1/4.0.1-nightly-build/5.0 releases:

Anyways, to me code (mixer) changes would have been somehow a little bit more logical for a new Deviation 5.x release, as I for example already run into one "PIT channel reversing" heli issue while changing between V4.0.1-nightly-builds to fcd0669?!?

So I also had to do it (PIT channel N<->R) once.
World was not going down because of that! :-)

The fcd0669 code (while using advanced mixer GUI) did not care if I would have to adjust my heli in the new Deviation release where the swash config was SUDDENLY completely going wrong (CCPM120 front elevator mixing setup).

My previous heli CCPM120 model.ini (working, multiple times test flown) was NOT compatible between Deviation releases, dunno why!


Advanced mixer GUI: Cyclic1<->cyclic2 (only???) have only to be swapped by RC pilots manually back according to new release CHANGELOG / announcement within the mixer channel dialog.

For standard GUI: Well, the RC pilots would actually have to manually edit their (workaround) model.ini according to CHANGELOG/announcement

OR

do changing two protocols back and forth within "model setup" as this seems to trigger STDMIXER_SetChannelOrderByProtocol() which overwrites (hardcoded) previous template default (old) ELEV/AIL cyclic2/cyclic1 mappings.

tcaudill01 wrote:

hexfet wrote: Other fixes are possible for specific use cases, but as far as I can tell any fix will break existing model files. For this reason PB did not want to change the mixing equations until support for versioning model.ini files is added


Totally agree with this. ANY edits made to the base code WILL break other layouts, no way around that.

hexfet wrote: Other fixes are possible for specific use cases, but as far as I can tell any fix will break existing model files. For this reason PB did not want to change the mixing equations until support for versioning model.ini files is added



For the moment probably I have to disagree to both above statements :-)

Question: Why do we have to care so much about 100% compatible model.ini / template.ini heli settings across all Deviation releases?

We will not break "other layouts" or (final) working model.ini/template.ini settings, we probably only break CCPM120 (!=NONE) previous made model "workaround solutions".


Examples:
III + VI): For standard heli GUI we seem to have e.g a breaking heli_std.ini file with swapped ELEV<->AIL inputs.
My channel monitor tests where not that successful.

I will re-test Hexfet's 6ch_heli.ini (advanced mixer GUI) with swapped cyclic1/cyclic2 and standard Virt1 AIL / Virt2 ELE source inputs once again for "normal" FBL (NONE) settings.
I can remember that In my previous test this scenario seemed to have failed. Therefore I wrote the points down.
But I'll re-test once again, promised.


I have the feeling that as all the code is written (including dialogs, standard mixer GUI, template loading, hardcoded cyclic mappings, etc.) spread over multiple files we may have not gained that much value only changing the two 6ch_heli.ini and heli_std.ini templates but bringing up new (not seen before) non-working heli scenarios :-(
Last edit: 08 Sep 2016 11:36 by Thomas.Heiss.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 12:09 - 08 Sep 2016 12:14 #53630 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary code analysis, problems, templates
www.deviationtx.com/forum/3-feedback-que...swash?start=20#44406

tcaudill01 wrote: We may end up having to do separate builds for either front ELE or rear ELE until it can be resolved.

The ideal solution is to create a third 120.INI that would rotate the servos in one of the existing INI layouts 120 degrees clockwise. I have tried to accomplish this and can get the AIL and ELE servos rotated but then PIT will not work at all.
It seems as if the code is written towards an EATR layout and we need the option for an AETR.

Also, really wish someone with a forward mounted ELE could try my edits with the Standard GUI and either the 120 or 120X and let me know how (or if) it works.


Yes, EATR template.ini channel order was confirmed by Hexfet once.
I can confirm this, it's the DEVO protocol layout - default pre-selected.

Therefore: Channel1 template.ini is elevator, channel2 template.ini is aileron.
You can also check the sources for "no protocol mapping" (automap is not set in heli_std.ini!) and falling back to default EATR channel map.


However, I have to disagree again to the statement about special releases for front<->back elevator cyclic servo or changing any ail<->elevator standard_mixer.c source places multiple times, as you tried to go thru.

Once I swap cyclic2<->cyclic1 manually in model.ini (after loading manually heli template and be done with all GUI edits) my Blade 4503D with front elevator servo just works.

Roll is only changing AIL+PIT channel monitor bars, nick or collective is changing successfully all ELEV+AIL+PIT channels.

This also applies to the standard mixer GUI in my tests, if you let not overwrite cyclic1<->cyclic2 mappings either by:
- dialog heli window (preset standard values) / loading heli_std.ini template
- changing protocols
- 1st default protocol / channel mapping (done once by mixer_standard.c) which overwrites your custom settings by hardcoded cyclic2/cyclic1 mappings

The side dependencies you are hitting are the real problem.

Alternative is by applying the cyclic mapping code from V) which also checks swashplate configuration (but you do have to change protocol).


I will post a CCPM120 front elevator setup with standard GUI later to re-create / re-test within channel monitor.
Last edit: 08 Sep 2016 12:14 by Thomas.Heiss.

Please Log in or Create an account to join the conversation.

More
08 Sep 2016 13:55 - 08 Sep 2016 14:31 #53635 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary analysis, problem spots, templates

Thomas.Heiss wrote: III) New committed release 5.0 heli templates changed by Hexfet (after b9edc4c) are IMHO not compatible with CCPM NONE (FBL) and standard port and standard channel mappings anymore per manual 11.4 swash mixing definitions

-> 6ch_heli.ini: cyclic1/cyclic2 ELEV/AIL swapping for e.g CCPM 120 is already done in template, but normal cyclic2/cyclic1 ELEV/AIL mapping is missing

I guess there will be much more FBL helis than flybar CCPM mixing helis?



Doing all my basic tests with all these variations I do now understand more and more why there are more and more Deviation users who do not get any working heli configuration/templates and mappings anymore :-)
One thing is always missing / wrong...

Thomas.Heiss wrote: I will re-test Hexfet's 6ch_heli.ini (advanced mixer GUI) with swapped cyclic1/cyclic2 and standard Virt1 AIL / Virt2 ELE source inputs once again for "normal" FBL (NONE) settings.
I can remember that In my previous test this scenario seemed to have failed. Therefore I wrote the points down.
But I'll re-test once again, promised.

I have the feeling that as all the code is written (including dialogs, standard mixer GUI, template loading, hardcoded cyclic mappings, etc.) spread over multiple files we may have not gained that much value only changing the two 6ch_heli.ini and heli_std.ini templates but bringing up new (not seen before) non-working heli scenarios :-(



Confirmed for III) FBL re-test. on September 08.

Result as already described above.

6ch_heli.ini advanced mixer GUI with swapped Cyclic1/Cyclic2 is only compatible for CCPM120&others, but not CCPM NONE/FBL setting anymore. We would have to fallback to previous Cyclic2/Cyclic1.

Moving nick/elevator stick does not move CH1 (Devo = ELEV) but CH2.
Moving roll/aileron stick does not move CH2 (Devo = AIL) but CH1.

This is because swapped Cyclic2 <-> Cyclic1 settings which are not correct for NONE (FBL) setting.
mixer.c:
s32 MIXER_CreateCyclicOutput(volatile s32 *raw, unsigned cycnum)
{
    s32 cyc[3];
    if (! Model.swash_type) {
        return raw[NUM_INPUTS + NUM_OUT_CHANNELS + cycnum];
    }
    s32 aileron    = raw[NUM_INPUTS + NUM_OUT_CHANNELS + 1];
    s32 elevator   = raw[NUM_INPUTS + NUM_OUT_CHANNELS + 2];
    s32 collective = raw[NUM_INPUTS + NUM_OUT_CHANNELS + 3];
    const int normalize = 100;

    if (Model.swash_invert & SWASH_INV_ELEVATOR_MASK)   elevator   = -elevator;
    if (Model.swash_invert & SWASH_INV_AILERON_MASK)    aileron    = -aileron;
    if (Model.swash_invert & SWASH_INV_COLLECTIVE_MASK) collective = -collective;

    switch(Model.swash_type) {
    case SWASH_TYPE_NONE:
    case SWASH_TYPE_LAST:
        cyc[0] = aileron;
        cyc[1] = elevator;
        cyc[2] = collective;
        break;


Luckily that is not a real problem.
We just have to follow my suggestion point I) in supplying multiple heli templates instead of only "one" 6ch_heli.ini.
Attachments:
Last edit: 08 Sep 2016 14:31 by Thomas.Heiss.

Please Log in or Create an account to join the conversation.

More
22 Sep 2016 18:42 #54131 by greeffbf
Thank you so much for help.
Mine works 100% on build v5.0.0.0 with these mods
I used the heli_std.ini and modified as per lines stating with
;OLD CODE
So at
virtchan1 I replaced ELE with AIL
virtchan2 I replaced AIL with ELE

[virtchan1] template=expo_dr
;[mixer] src=ELE dest=Virt1 curvetype=expo points=0,0
;[mixer] src=ELE dest=Virt1 switch=FMODE1 curvetype=expo points=0,0
;[mixer] src=ELE dest=Virt1 switch=FMODE2 curvetype=expo points=0,0
[mixer] src=AIL dest=Virt1 curvetype=expo points=0,0
[mixer] src=AIL dest=Virt1 switch=FMODE1 curvetype=expo points=0,0
[mixer] src=AIL dest=Virt1 switch=FMODE2 curvetype=expo points=0,0

[virtchan2] template=expo_dr
;[mixer] src=AIL dest=Virt2 curvetype=expo points=0,0
;[mixer] src=AIL dest=Virt2 switch=FMODE1 curvetype=expo points=0,0
;[mixer] src=AIL dest=Virt2 switch=FMODE2 curvetype=expo points=0,0
[mixer] src=ELE dest=Virt2 curvetype=expo points=0,0
[mixer] src=ELE dest=Virt2 switch=FMODE1 curvetype=expo points=0,0
[mixer] src=ELE dest=Virt2 switch=FMODE2 curvetype=expo points=0,0
Attachments:

Please Log in or Create an account to join the conversation.

More
23 Sep 2016 10:52 - 23 Sep 2016 10:54 #54160 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary analysis, problem spots, templates
Mantis Bugtracker:
#677: www.deviationtx.com/mantisbt/view.php?id=677 (added, same issues for NONE/FBL/standard GUI as #637)
#637: www.deviationtx.com/mantisbt/view.php?id=637
#624: www.deviationtx.com/mantisbt/view.php?id=624


@Admin
I can not add #677 to reference list to first post www.deviationtx.com/forum/7-development/...pots-templates#53524 .
Error message too many links, as there are 6 links already listed.
May it be possible to turn off this link checking in text on submit for "well-known users" with several hundreds of posts?
Last edit: 23 Sep 2016 10:54 by Thomas.Heiss. Reason: added Mantis bug id #677 (same as #637)

Please Log in or Create an account to join the conversation.

More
23 Sep 2016 16:01 #54176 by greeffbf
You may close #637 opened by myself. Somehow I just can't log into bug tracker anymore.

Please Log in or Create an account to join the conversation.

More
23 Sep 2016 20:58 #54186 by victzh
Thomas, I'll try to summarize your summary for myself, correct me if I'm wrong.

Standard mixer works neither before hexfet patch nor after - one of the cases CCPM 120 or CCPM NONE is always broken.
Currently the only way to fix it is to switch to Advanced mixer which is undesirable for novices.

Please Log in or Create an account to join the conversation.

More
24 Sep 2016 06:40 - 24 Sep 2016 07:11 #54198 by Thomas.Heiss
Replied by Thomas.Heiss on topic Heli: Summary analysis, problem spots, templates
Short version:

victzh wrote: Thomas, I'll try to summarize your summary for myself, correct me if I'm wrong.

Standard mixer works neither before hexfet patch nor after - one of the cases CCPM 120 or CCPM NONE is always broken.
Currently the only way to fix it is to switch to Advanced mixer which is undesirable for novices.


Standard mixer GUI:
Was IMHO working good for CCPM NONE/FBL before b9edc4c template patch (my tests).
CCPM120 neither worked before patch or after really fine, so broken, yes.
Only bug ids + forum complains were for CCPM120.

Two manual CCPM120 workarounds for user: Changing finished standard mixer heli setup to Advanced GUI + fixing cyclic1/2 mappings or editing model.ini and swapping cyclic2/1 with cyclic1/2, after protocol change (overwrites any manual edits).
So NO: Switching to Advanced mixer GUI is NOT the only way to (temporarily) fix CCPM120 within model.ini.
You can't really finish channel servo N/R + CCPM mixer +- AIL/ROLL/COL setup in standard GUI if the 3 cyclics do not travel correctly.


Long version:

victzh wrote: Thomas, I'll try to summarize your summary for myself, correct me if I'm wrong.


I know Hexfet invested much time into this heli stuff, he actually found the (real) mixer.c CCPM120 calculation bug and is also able to test some cases / code and template changes with his helis.
This will be the FINAL solution when CCPM120/120x/140/90 calculates ELEV and put it into cyclic2 instead of cyclic1 :)
I very much appreciate that he took the route and jumped onto the train.

Testing might need to follow a bigger test concept were all different usage possibilities are covered in. Not that very easy to do that.
I am not even sure how CCPM 120X/140/ would work with the cyclic1/2 swapping....

Since some days I have upgraded to release 5.0.0 - can re-test - but no heli C code changes so far since fcd0669.

victzh wrote: Standard mixer works neither before hexfet patch .... - one of the cases .....or CCPM NONE (FBL) is always broken.


With Hextet's heli_std.ini patch swapping Virt1/Virt2 AIL<->ELE on b9edc4c (BitBucket) - after undoing mixer.c code changes - it seems that now also NONE/FBL does not work anymore, which has been working before with the old mixer.c + mixer_standard.c code, true.

But it WAS working before template patch with non-switched normal ELE/AIL channel mappings (had it working with my Spektrumized/ZYX V120D02s).
Now both channels are switched to different stick inputs - this is why there are growing threads on 5.0.0 release for helis (most pilots probably using FBL).

I believe Hexfet expects that one heli FBL pilot just swaps ELE<->AIL ports on the receiver. But why? Not all helis support that (BNF stuff).
In corresponding threads and Mantis Bugtracker Hexfet wrote about a model.c parser bug which he expects to be found and so he needed to swap Virt1/2 input sources AIL<->ELE.
I am sure that he tested it for some special heli scenario.

I am almost convinced that the model c template parsing bug Hexfet believed he found was (maybe) one of the mixer_standard.c overwrite bugs??? Probably...I am just guessing...

Maybe I can help Hexfet and others to re-test his special heli scenario where it was working for him or have some chat / skype about open issues or unknown stuff...

victzh wrote: Standard mixer works neither before hexfet patch ....- one of the cases CCPM 120 ....is always broken.


CCPM120 never worked with standard GUI and heli_std.ini - neither before template patch nor after (at least in my tests).

The additional cyclic2/1 <-> cyclic1/2 channel assignment patch Hexfet made for CCPM120 is not taken care and overwritten by standard GUI code, too bad.
Ignored both before and after patch by mixer_standard.c.

The template change is only good as an user manual copy&paste "template draft" -> model.ini, but not to use the heli_std.ini by Deviation in a natural / automatic configuration way.

You can NOT just use the GUI and configure correctly the heli with the patched template. The C code does not support that.

So yes, you are right. CCPM120 will not be working in standard mixer GUI in the way we have it - without manually adjusting model.ini.

victzh wrote: Standard mixer works neither .... hexfet patch nor after - one of the cases CCPM 120 .... is always broken.


Swapping Virt1/Virt2 AIL<->ELE input sources in Hexfet's heli_std.ini patch even made the CCPM120 worse for me (front elevator setup) because now even the wrong two roll channels are mixed up.
That roll mixing worked before Hexfet's Virt1/Virt2 patch, when using standard front/back elevator cyclic servo port mappings.
I changed my heli template back (as before) and now this CCPM120 roll cyclic mixing is back in working mode:

The additional cyclic2/1 <-> cyclic1/2 channel assignment patch Hexfet made especially for CCPM120 is not taken care and overwritten by standard GUI code, too bad.
Ignored both before and after patch by mixer_standard.c.
The template change is only good as an user manual copy&paste "template draft" -> model.ini, but not to use the heli_std.ini by Deviation in a natural / automatic configuration way.

You can NOT just use the GUI and configure correctly the heli with the patched template. The C code does not support that.
So yes, you are right. CCPM120 will not be working, even in release 5.0.0, in standard mixer GUI in the way we have it - without manually adjusting model.ini.

victzh wrote: Currently the only way to fix it is to switch to Advanced mixer which is undesirable for novices.


Well, this is IMHO not 100% correct.
You can manually edit your standard mixer GUI model.ini and swap cyclic2/1 by cyclic1/2 for channel 1 and 2.
Then it will be working too. I had tested this, followed by other pilots on those heli problem threads.

This is (to my understanding) probably what the heli_std.ini b9edc4c template by Hexfet written for CCPM120 initially stands for: A draft for a user how to manually edit his model.ini without having to hit the forum.

Not sure what the reason about the Virt1/2 AIL<->ELE swaps were and what special heli scenario / model.ini tests have been passed on Hexfet's side.
Maybe I can re-test his heli scenarios on my new 5.0.0 release (makes IMHO no difference to fcd0669 according to new 5.0.0 heli threads)?


Advanced GUI: Will work with two separate heli templates for NONE/FBL + CCPM120 & others - as we have full control.

I already made some additional adjustments for 3rd (real) 6ch_heli_FBL.ini template (without Virt1/2, cyclic1-3) which I posted before, e.g channel 6 pitch complex mixer and fmode0-2 assignments. Will upload laters...

Most of the heli forum questions about advanced mixer GUI seem to be: Help! How do I add a gyro gain channel to a complex mixer :)

So I will be adding a gyro gain channel CH5 (DSM2/x), CH7 (Devo) mixer - so maybe two FBL templates - as well as to this 3rd advanced mixer GUI FBL template (I have some working Blade4503D + V120D02s spectrumized model.inis with working gyro gain).
Template 6ch_heli.ini does not provide it.


Thomas
Last edit: 24 Sep 2016 07:11 by Thomas.Heiss.

Please Log in or Create an account to join the conversation.

More
03 Sep 2017 04:51 #64138 by kmewes
@Thomas
I know this is from almost a year ago, but I like to add my observations. I tested the DSM2 protocol with my Devo 8S and firmware v.5.0.0-2017-08-01 with a Blade SR (also Huey). I switched cyclic2 on channel 2(Ail) to cyclic1 and did the opposite on channel3 (Ele) in the advanced GUI. Before that I selected CCPM 120 (called 3Servo 120 in the SwashType selector box) in the standard GUI and tried to set the mix according to the user manual for the Blade SR. When I did this a played around with the mix settings and noticed that the settings labels, ELE Mix and AIL Mix seem to be reversed. I noticed this when I changed the levels that the servos were moving for the other channel instead. So I swapped the values assuming the labels were swapped. btw in the spektrum DX6i that I also own, the label order for the swash mix is AILE, ELEV and PITCH which makes sense since the channel order is AILE ch2 before ELEV ch3 and Pitch ch6. Then I switched to the advanced gui. I could get the pitch movement and the Aile movement working correctly, but the Elev, which requires the front servo (ELEV) and the rear two servos AILE (rear right) and PITCH (rear left) to move opposite to each other, ELEV moving down and AILE/PITCH moving up and vice versa. What I saw was PITCH servo doing the right thing but the AILE servo not moving at all with right stick (Mode 2) moved back and forth. The AILE stick movements, left-right, worked properly. However there was always a slight movement of the ELEV servo associated with it. I never noticed this before in other helis like the Walkera Master CP or the 4F200 controlled by the WK2801 protocol, both of course FBL with 1Servo swash. Perhaps that's why. At any rate I think that there is perhaps still something wrong with the DSM2 3Servo 120 protocol which perhaps, IMHO, needs fixing. Can anyone confirm my observations and findings with the current DSM2 protocol and a flybar-based heli such as the BSR with CCPM 120 swash configuration?
Thanks.

Please Log in or Create an account to join the conversation.

Time to create page: 0.066 seconds
Powered by Kunena Forum