Prior to onshot being added to the system. The -r of the
"rate" command would not invoke the ioctl PWM_SERVO_SET_UPDATE_RATE
when -r was not provided on the command line. This may have been a
feature or a bug.
When onshot was added to the pwm command a bug was intorduced
that precluded the ioctl PWM_SERVO_SET_UPDATE_RATE from being
called on -r 0.
This commit fixes that issue, and preserves the "prio to oneshot"
behavior of the "rate" command when -r is not specified.
sched_note_{suspend|resume} were calling hrt_absolute_time before
it hrt_init is called. This can lead to register access before
clocking is enabled. The result is a hardfault.
- 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.
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
