disarmed.
Ensure that servo mixes that use calculated throttle output (motor 0)
adhere to the armed/disarmed state, this is achieved by ensuring that
motor outputs, including the effects of MOTOR_STOP are calculated BEFORE
using motor 0 as an input source for the servo mixer.
Baseflight code made both surfaces respond in the SAME direction when
using pitch OR roll.
Behaviour should be:
apply pitch causes the control surfaces move in the SAME direction.
apply roll causes the control surfaces should move in the OPPOSITE
direction.
* optimize for code size.
* consolidate error message handling.
* replace similar error messages with identical ones.
* shorten all strings where possible.
* made less verbose.
This was required for the CC3D OPBL build.
Main rule logic and MSP commands ported from baseflight.
Gimbal mixer updated to use rules. This allows us to remove more
conditional logic. Operation of gimbal servos is now different.
...and apply them after a soft reset (which also required an additional
write to flash), it is now such that features and settings are modified
and stored in flash as before.
After initialisation completes, the active features are latched and are
not to be modified until the next startup. This guarantees that all
saved modifications are persistent even when power is switched of
(without a reset in between).
When a soft reset is required, the active features and the currently
configured features are used to detect if the oneshot feature has
changed state, in which case motor PWM outputs are stopped and soft
reset is done after a 1.5 second delay.
During normal operation the active features will not change and all
changes to features ordered via MSP commands or the CLI are applied to
the configuration that gets saved to flash.
The required effect of modifying features without changing the actions
in the running mainloop is achieved. The user needs to be aware that
changes to features are not applied immidiatly.
Maximum value of 500 is now removing the limit (same as for
yaw_jump_prevention_limit)
Moving defines for PID controllers to headerfiles.
Some general code cleanup.
Documentation update
Pull request #802 has by default disabled yaw jump. That is fine on the
most of the configurations, but one of my multirotors had an angled
motor due to crash and this was causing weird behaviour.
It is also possible to configure very low values, which can even cause a
craft to not be able to stop after yaw and I am talking about the values
below 100 like 1.
Anyway this fix provides only valid configurable values what can't cause
any danger. Also default parameter is not unlimited anymore and is
configured to 200, which is a safe value to anybody who does the
upgrade.
cli.md is also edited
configurations
The hardcoded limit in the mixer and PID controllers 3-5 would be
removed
by default and will be configurable by CLI variables:
yaw_jump_prevention_limit, global setting (original fixed value was 100)
yaw_p_limit, per profile setting (fixed value was 300)
