currently when the vehicle is landed again (not after bootup) the core position controller does not run anymore
therefore the velocity limit ramp in some cases did not get reset correctly
speed limiting in auto takeoff mode only needs to be limited when the user did not take over
adresses:
there were setpoint twitches at the beginning and end of my smooth takeoff routine
it was to slow and not configurable
it was only available for automatic takeoff
auto takeoff was pretty chaotic and bypassed the velocity controller until some magic condition
the goal of this approach is to make the behaviour and smoothness more predictable and reuse the exact same logic for manual takeoff
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).
Matthias Grob