- Fixed V712
- The compiler can optimize this code by creating an infinite loop, or simply deleting it.
- There is need to add a volatile qualifier to the '_ExitFlag' and 'sim_delay' variables.
Add assessment of IMU bias and mag field estimation
Reduce warning false positives by adjusting thresholds and eliminating use of peak value plots for output observer monitoring
Clear each figure after saving to reduce memory usage
Miscellaneous bug fixes and improvements including:
More conservative reporting of velocity and position accuracy when aiding is lost
Separate reporting of accuracy for local and global position
Detection and recovery from badly conditioned accel bias states and covariance values
Logic to prevent high manoeuvre levels causing bad acceleration bias learning
Reduce sensitivity of covariance prediction to timing jitter
Continue reporting of GPS quality until the later of airborne or checks pass
Add ability to perform wind estimation for multi-rotors using a specific force drag model
Ultimate we want this changes that is being backed out herein.
But it is breaking things because it returns the EINVAL
when there is a rate overlap. So the rest of the pwm ioctl
calls then fail and do not set the pulse widths on arming.
As a secondary issue. We sould call up_pwm_servo_init() to
establish the PWM channel allocation early. This then allows
FMU::set_pwm_rate to properly check for improper rate request
not isolate to one group (timer).
The root cause was the replacment of a local variable num_outputs
with the class member _num_outputs.
The effect of a "bad mix" is to return 0 - this clampped the
_num_outputs to 0.
Prior to commit 3b3e2b2 px4fmu: "consolidate usage of output mode"
this would not have been an issue because the local num_outputs
was reset every cycle"
As a secondary issue. We sould call up_pwm_servo_init() to
establish the PWM channel allocation early. This then allows
FMU::set_pwm_rate to properly check for improper rate request
not isolate to one group (timer).
because there is no sense to have different angle scalings into different directions
it would lead to unintuitive piloting experience
acceleration is directly coupled to the tilt angle regardless of possible assymetric multicopter vehicles
because in altitude mode we have a baro available and can therefore check vertical movement
we can not check horizontal movement but I consider the checks for landing still pretty safe
unlike in manual mode we are not allowed to disarm before land detection in altitude mode
This will avoid file system corruptions in cases where px4_shutdown_request
is used. However it will not help obviously when the battery is pulled
directly.
Previously load stats were stored outside of the printloop, but
with the refactoring to save memory state was reset and used in
the first loop before the actual load calculations were valid.
Fixed by moving the summary info to the bottom of the top printout
after everything is computed. Also restructured the callback to
not depend on a line counter and fixed astyle glitches.
Sander Smeets
Phillip Khandeliants
Paul Riseborough
David Sidrane
Andrew C. Smith
Daniel Agar
Matthias Grob
Beat Küng
jwilson
Lucas De Marchi
Nate Weibley
Julian Oes