- Posts: 698
Heli: Summary analysis, problem spots, templates
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.
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:
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:
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
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
Please Log in or Create an account to join the conversation.
08 Sep 2016 11:06 - 08 Sep 2016 11:36 #53628
by Thomas.Heiss
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.
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
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
Please Log in or Create an account to join the conversation.
08 Sep 2016 13:55 - 08 Sep 2016 14:31 #53635
by Thomas.Heiss
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.
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.
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.
Please Log in or Create an account to join the conversation.
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:
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:
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.
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...
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.
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.
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
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
Please Log in or Create an account to join the conversation.
Time to create page: 0.064 seconds
-
Home
-
Forum
-
Development
-
Development
- Heli: Summary analysis, problem spots, templates