* stop motors after 90 degrees of rotation and with max rate
* handle no accelerometer data
* improve check for acc, although seems to be OK without it
* disable all attenuation if rate is set to zero
* refactoring thanks Karate
* use sensors.h
* remove unnecessary arming check
* exit crashFlip immediately switch is reverted if throttle is zero
* add Crashflip Rate to OSD
* Revert unnecessary changes in crashflip core.c code
and clarify comments about crashflip switch
* update / minimise comments, thanks Karate
* ensure all names say `crashflip` consistently
* Undo quick re-arm because motrors were not reversed
* fix issue with reversed motors, we must disarm
* ignore yaw rotation and set gyro limit to 1900 deg/s
* default attenuation to off (crashflip_rate = 0)
* refactoring, increase rate limit to allow stronger inhibition
* enable in race_pro mode
* don't attenuate on attitude until a significant change occurs
* no attenuation for small changes
* Updates from review by PL
* remove whitespace
* refactor motorOutput, update comments, renaming variables
thanks PL
* changes from review PL
* only permit fast re-arm if crashflip rate set and crashflip was successful
* properly exit turtle mode
* add crashFlipSuccessful to unit test extern c
* small updates from review
* improved crashflip switch handling
* remove unnecessary motors normal check
* RX task update rate to 22Hz, to improve 25Hz link stability
* modified Rx code
* add LQ to debug
* use max of frameAge or FrameDelta
* Require a dropouit of 200ms, not 100ms, before RXLOSS
* remove FrameAge, use 150ms timeout 50ms checks
* fix tests and tidy up the comments
* Handle NULL input as before, log frame time
* possible solutions to review comment about names
* Remove rxFrameTimeUs
- prepare for direct use of lastRcFrameTimeUs
- refactor rx_spi callback
* remove global currentRxRateHz
* simplify updateRcRefreshRate
* re-name to recheck interval, return frame time debug
* Calculate RxRate only once
* use rxReceivingSignal for consistency
* use signalReceived not rxDataReceived for consistency
* suggestions from review PL
* move defines, thanks K
* fixes from review, thanks MH
* review changes, undo task interval change
rename bool rxIsReceivingSignal to isRxReceivingSignal
thanks Steve for resolving that tasks changes are not needed
thanks PL for your feedback also
---------
Co-authored-by: Petr Ledvina <ledvinap@hp124.ekotip.cz>
single minimum GPS satellite setting
single required GPS satellite setting
CLI Baro vs GPS trust user interface
GPS trust refactoring
allow arming with GPS_FIX even if not enough sats
required sats must be present to arm
set required sat count to 8
add blackbox headers
convert pressure to altitude early
remove median filter
PT2 filtering upsampled to altitude function in position.c - thanks KarateBrot
baro task synced to position task - thanks Steve
PT2 implementation - thanks KarateBrot
ground altitude from filtered altitude
baro cali by average of calibration samples over cal period
adjust vario and smoothing defaults
don't say haveBaroAlt until cal is complete
reduce PIDs since Baro is faster
add baro smoothing values to blackbox header
Co-Authored-By: Jan Post <post@stud.tu-darmstadt.de>
Co-Authored-By: Steve Evans <SteveCEvans@users.noreply.github.com>
Previously the task was always enabled and there's no reason for it to be running if there are no boxID associations.
Saves a few cycles by not running. But has a bigger effect on the scheduler by minimizing the number of active tasks when possible.
Analyze the rc modes activation conditions and only process configured entries. Previously the entire possible list was processed even though typically only a handful are configured.
Reduces the RX task processing time by about 25% (~44us to ~33us) with an average setup of 3 modes configured (F405, SBUS). Processing time savings will diminish as the user configures more modes. But typically far fewer than the maximum of 20 will be configured.
Having the iterm resetting happening in the rx loop causes a sawtooth PID/motor effect while idling since the PID loop is running at a much higher rate and iterm is allowed to grow during this, and then only reset at a much lower rate in the rx loop. This can potentially lead to some oscillation and/or resonance while idling before takeoff as the sawtooth signal can make it through to the motor outputs.
The OSD stats provide no meaningful information and are just an annoyance when exiting these special states.
For Launch Control the stats will be displayed if the launch is triggered and normal flight occurrred.
The vtx code doesn't have a lot of test coverage, so this adds a basic unit test that asserts vtx pit mode behavior
_Legal disclaimer: I am making my contributions/submissions to this project solely in my personal capacity and am not conveying any rights to any intellectual property of any third parties._
