modified debug output (currently disabled)
To solve problem as indicated here:
https://github.com/cleanflight/cleanflight/issues/1266#issuecomment-135640133
and here:
https://github.com/cleanflight/cleanflight/pull/1340
and here:
https://github.com/cleanflight/cleanflight/pull/1342
Tested on FrSKY X4RSB with latest CPPM firmware (non-EU version).
Firmware filename: X4R-X4RSB_cppm_non-EU_150630
In both SBUS and CPPM mode.
---
Added delay to rxfail detection
All channels are monitored for bad (out of valid range) pulses.
On bad pulses channel data will HOLD the last value for a period of
MAX_INVALID_PULS_TIME (300ms) before starting rxfail substitution.
This should prevent a too aggressive reaction to small dropouts.
---
Init ARM switch rc channel to OFF for safety
Initialize ARM switch to OFF position when arming via switch is defined.
To prevent arming during init when RX is disconnected and/or when RX is
connected but TX is still off.
---
Modified rx_rx_unittest.cc
Adapted because rxInit() parameters changed.
Added tests for ARM switch initialization.
No further tests added.
---
Move smoothing of rcData to rcCommand
Commit from @borisbstyle pr #1418
rc_smoothing function has changed to leave rcData unchanged in #1418
hardware failures by counting the number of long flashes.
Fix up sensor read API so that code that uses sensors can detect
malfunctions.
If a failure mode occurs in a debug mode the code reboots the system
rather than rebooting to the bootloader.
- 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.
G++ supports a more limited version of designated initialisers.
Reorder fields to be in the right order. Make nested initialisers
explicit.
Signed-off-by: Michael Hope <mlhx@google.com>
Remove duplicate consts.
Pull in the include files where functions and variables are declared.
Mark file local but duplicated variables as static.
Mark some variable declarations as extern.
Remove duplicated variable definition.
Signed-off-by: Michael Hope <mlhx@google.com>
This also ensures that the PWM mapping does not use the sonar pins when
sonar is enabled in a board agnostic way.
Conflicts:
src/main/config/config.c
src/main/drivers/pwm_mapping.h
src/main/main.c
src/main/target/CC3D/target.h
...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.
