to allow descending by stick for reliable land detection.
Issue:
Stick smoothing gets completely reset to state when not taken off
-> downwards velocity setpoint is gone when not taken off
-> in_descend flag of land detection is never true when not taken off
-> when landing but falling out of landing it landing detection fails
bafore taking off and landing again
Having a 2nd order low-pass filter in the derivative loop reduces
stability at low cutoff values as too much phase is lost through
the filter. Using a 1st order filter avoids this issue because its
maximum phase loss is 90 degrees instead of 180 degrees for a 2nd order
lpf.
This fixes the case where we sometimes switch to altitude control
instead of position control when RC is regained.
What happens is that we detect that the pilot wants to take over control
right when RC comes back. This means that we try to go in position
control in main_state_transition, however, we are already in position
control because we come back from the failsafe state. The result of
main_state_transition is then TRANSITION_NOT_CHANGED, and therefore we
"fall back" to altitude control even though being already in position
control would have been fine.
This fix checks the return result of main_state_transition correctly and
only reacts to TRANSITION_CHANGED and TRANSITION_DENIED but ignores
TRANSITION_NOT_CHANGED.
By default we would leave the LAND failsafe as soon as a link comes
back. With this change, we switch to the LAND failsafe like a proper
mode change, immediately disabling the failsafe as such.
This is as the same that is done for RTL in fact.
This is not optimal but a workaround for the problem where we switch out
of failsafe right on landing and then discover takeoff again and start
looping through it again and again without ever disarming.
I think it was not the best idea to use errno as a global variable to
keep track of the error code. I saw the errno change from where it was
set to where it was actually used, maybe because part of it is called in
the receive thread and part in the regular update/send() thread.
To be safe, I just created a class variable instead.
- initial frequency peak tracking SNR increased from 10->15 db
- after initial detection the threshold decreases to SNR 5db
- gyro_fft large method refactored into smaller pieces
- sensors/vehicle_angular_velocity: dynamic notch FFT make sample rate
check a percentage and relax lower bound safety threshold
- no longer start sercon or mavlink usb by default
- on USB connection (VBUS) monitor serial USB at low rate and start Mavlink if there's a HEARTBEAT or nshterm on 3 consecutive carriage returns
- the mavlink USB instance is automatically stopped and serdis executed if USB is disconnected
- skipping Mavlink USB (and sercon) saves a considerable amount of memory on older boards
SDLOG_ALGORITHM for selecting the crypto algorithm
SDLOG_KEY for selecting the key in keystore to use with the algorithm.
for symmetric algorithms which are currently supported, this is just a free
slot to be used, the key is generated at logging start
SDLOG_EXCH_KEY for selecting an RSA2048 key for encrypting the SDLOG_KEY
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
- Generate a symmetric encryption key and a nonce value
- Use a public key in keystore to encrypt the symmteric key
- Write the encrypted key and the nonce value to disk into .ulgk, name matching with the encrypted log file
- use quick stream encryption to crypt the .ulg file contents
Signed-off-by: Jukka Laitinen <jukkax@ssrc.tii.ae>
By adding the sequence number we can avoid double triggering due to
command retransmissions. This is according to the mavlink spec for
MAV_CMD_IMAGE_START_CAPTURE.
VTOL planes are getting lift from the wing when flying in MC mode at
high speed. They (and some other drones) also get extra drag when
climbing and descending at high speed, corrupting the hover thrust
estimate.
To avoid this, two speed thresholds (vertical and horizontal) are defined
above which the sensitivity of the estimator is decreased by linearly
increasing the observation noise.
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
