- Added failsafe flightmode and rc control box.
To make failsafe procedure a separate flight mode and make it possible
to trigger failsafe with an AUX switch.
- Failsafe mode is activated when failsafe is active.
RC link lost is simulated with the failsafe AUX switch.
When NOT armed: failsafe switch to failsafe mode is shown in GUI (mode
tab).
- Activate failsafe mode with AUX switch.
- Prevent arming when failsafe via AUX switch is active (safety issue).
- Make failsafe disarm if motors armed and throttle was LOW (2D & 3D)
for `failsafe_throttle_low_delay` time (__JustDisarmEvent__).
Applied code changes to effectively add pull request: Make failsafe
disarm if motors armed and throttle low #717.
- Use failsafeIsMonitoring() to actually start monitoring.
- Added `failsafe_kill_switch` to code.
When set to 1 (0 is default), the failsafe switch will instantly disarm
(__KillswitchEvent__) instead of executing the landings procedure.
Arming is NOT locked after
this, so the craft could be re-armed if needed.
This is intended for racing quads where damage and danger must be
minimized in case of a pilot error.
- Added `failsafe_throttle_low_delay`, adapted documentation.
Used to adjust the time throttle level must have been LOW
to _only disarm_ instead of _full failsafe procedure_
(__JustDisarmEvent__).
- Updated the failsafe documentation.
- Re-enable arming at end of failsafe procedure.
At the end of a handled failsafe event, that means: auto-landing,
__JustDisarmEvent__ or __KillswitchEvent__, the RX link is monitored for
valid data.
Monitoring is a part of the failsafe handling, which means the craft is
still in failsafe mode while this is done.
Arming is re-enabled (allowed) when there is a valid RX link for more
then XX seconds, where XX depends on the handled event like this:
1. XX = 30 seconds after auto landing.
2. XX = 3 seconds after __JustDisarmEvent__.
3. XX = 0 seconds after __KillswitchEvent__.
NOTE: When armed via an AUX switch, you will have to switch to the
disarmed position at the very end to be able to re-arm.
The failsafe mode will not end until you do.
- __KillswitchEvent__ has now priority over __JustDisarmEvent__
- Apply rxfail values instantly when failsafe switch is ON
- Added missing cases to display.c
Show M when failsafe is monitoring for RX recovery (AND disarming when
armed with a switch).
===
Reworked the code from counter-based to time-based.
- AUX failsafe switch now has identical behavior to RX loss.
- Added RX failure and RX recovery timing.
- __KillswitchEvent__ skips RX failure detection delay (direct disarm).
===
[UNIT TESTS]
Adapted failsafe related unittests from counter-based to time-based
- Added failsafeOnValidDataFailed() to some tests
- Removed duplicate test setup from rc_controls_unittest.cc
- Removed magic numbers from rx_ranges_unittest.cc and rx_rx_unittest.cc
- Reworked all test-cases for flight_failsafe_unittest.cc
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.
Previously it was possible to set roll/pitch rate > 1.0 using MSP, but
not using the CLI. Roll/pitch rate > 1.0 is meaningless.
TPA is also limited to 1.0.
# The first commit's message is:
Previously, at minimum throttle, the quad would do absolutely no self-leveling
and simply run the motors at constant minthrottle. This allowed the chance
for the quad to lose control during flight if the throttle was set to minimum,
say, to drop from a high altitude to a lower one.
With this edit, the quad will still self-level at minimum throttle when armed,
allowing for safe decents from altitude. To prevent motors spinning when
arming/disarming, the yaw input is ignored if the throttle is at minimum and
we're using the sticks to arm/disarm.
Conflicts:
src/main/flight/mixer.c
# This is the 2nd commit message:
added cli command disable_pid_at_min_throttle
applied. The existing modes are 'step'. A new mode is 'select'.
The other unit tests need fixing up so that appropriate code is compiled
as C and not C++ code.
adjustment ranges to adjustment slots when channel is within range.
example:
```
adjrange 0 0 0 900 1700 0 2
adjrange 1 0 0 1700 2100 1 2
```
explained:
* configure adjrange 0 to use adjustment slot 1 (0) so that when aux1
(0) in the range 900-1700 then do nothing when aux 3 (2) is in any
position.
* configure adjrange 1 to use adjustment slot 1 (0) so that when aux1
(0) in the range 1700-2100 then do use adjustment 1 (rc rate) when aux 3
(2) is in the appropriate position.
Without the entire range of aux1 being defined there is nothing that
would stop aux 3 adjusting the rc rate once aux 1 wasn't in the higher
range.
There are 4 adjustment slots and 12 adjustment ranges.
Adjustment slots and adjustment ranges can use the same aux channel.
e.g.
`adjrange 2 1 0 900 2100 1 3`
* configure adjrange 2 to use adjustment slot 2 (1) so that when aux4
(3) in the range 900-2100 then use adjustment 1 (rc rate) when aux 4 (3)
is in the appropriate position.
e.g. `adjrange 0 0 1700 2100 1 2`
set adjustment range 0, which applies to aux channel 0 (aux1) when range
is between 1700 and 2100 then apply function 1 (rc rate) to aux channel
2 (aux3)
rcRate is decreased when low, increased when HIGH and no change when the
switch is in the middle.
The rcRate ticks up/down at 0.01 every 500ms if the switch is left on.
If using a momentary switch and if you can toggle the switch between
middle and low or middle and high more frequently than 500ms then the
rate will be increased accordingly. Similar to how a keyboard repeat
behaves.
Fixed tabs, kept old references to VARIO. Made SONAR mode a new option so that aux settings could be preserved.
Conflicts:
src/main/config/runtime_config.h
src/main/flight/altitudehold.h
src/main/flight/imu.c
src/main/io/rc_controls.h
src/main/mw.c
src/main/sensors/initialisation.c
both attempted to be enabled at the same time. Angle mode now takes
precedence over horizon mode.
Fix using aux settings that are not applicable to in-use aux channels -
prior to this it was possible to configure aux4 and then switch to
RX_SERIAL using a 7 channel system (3 aux channels) and aux4 would still
have been processed.
The MSP is changed in a way that might provide some backwards
compatibility. The first 4 channels are sent/read as before followed by
the next 4 channels.
If I client ignores extra data received it should be backwards
compatible.
Clients can looks for the new capability bit which indicates the MSP
protocol supports AUX 1-8.