Mixer profile to open the posibility for vtol/mixed platform

[shota3527]

I think this mixer_profile approach for VTOL requires the least amount of work for supporting VTOL. switching the PID/nav controllers between MC and FW.

how to setup

https://github.com/shota3527/inav/blob/sh_mixer_profile/docs/MixerProfile.md

known issues

• VTOL plane in multi-rotor mode can trigger false landing detection in RTH landing in a headwind. set nav_disarm_on_landing to OFF might help
• VTOL plane in multi-rotor mode struggles in windy conditions due to its physical limit

updates in 202030725:

https://www.youtube.com/watch?v=6_4D3aLc8G8&t=204s
INAV_7.0.0_cli_20230725_130613.txt

old post:

It is still in development.
real flight on commit id:e0db9ae4c920530d405822f186f3b90f6aaddd2b
https://www.youtube.com/watch?v=9JEAN-SsOKw&t=2s
cli diff
INAV_6.0.0_cli_20221119_095038.txt

It is very experiential and it may cause a crash or flyaway or fly a servo
It should be ok unless mixer_profile other than 1 is used. May break a lot of things when performing a hot switch between profiles. reviews from other developers are appreciated

bench test
https://studio.youtube.com/video/aomNk
diff file used in video:
INAV_6.0.0_cli_20221113_225555.txt

[shota3527]

Can you add the same functionality to the another FC board - Speedybee F405 wing?

@macgyverek
You can find it here by P-I-Engineer
https://github.com/P-I-Engineer/inav-piengr/tree/pi-shotamixer/src/main/target/SPEEDYBEEF405WING

sorry, I will not make target.c for another FC board because everyone prefers different pin mapping, I think It is better to leave the target.c to the manufacturer.

If you are not familiar with the compiling your firmware, i can send you a precompiled one

[P-I-Engineer]

Can you add the same functionality to the another FC board - Speedybee F405 wing?

you can pull this into your build or copy or whatever
https://github.com/P-I-Engineer/inav-piengr/tree/pi-shotamixer/src/main/target/SPEEDYBEEF405WING

[P-I-Engineer]

https://www.youtube.com/watch?v=4X8yEgraxN4

[DzikuVx]

@shota3527 2 comments from my side. Plus, we will have to make some adjustments to Configurator to cope with the changes. And of course the removal of MOTOR_STOP what is good :)

[shota3527]

@DzikuVx
bench tested and sim tested on commit e4984a5
I have implemented the MSP to support the moved motor stop feature
Once configurator made changes on the motor stop feature, This PR should function same as master unless new feature from mixer_profie is used.

    case MSP2_INAV_MIXER:
        sbufWriteU8(dst, mixerConfig()->motorDirectionInverted);
        sbufWriteU8(dst, 0);
        sbufWriteU8(dst, mixerConfig()->motorstopOnLow);
        sbufWriteU8(dst, mixerConfig()->platformType);
        sbufWriteU8(dst, mixerConfig()->hasFlaps);
        sbufWriteU16(dst, mixerConfig()->appliedMixerPreset);
        sbufWriteU8(dst, MAX_SUPPORTED_MOTORS);
        sbufWriteU8(dst, MAX_SUPPORTED_SERVOS);
        break;

[shota3527]

corresponding configurator pull request
iNavFlight/inav-configurator#1829