Copter-3.5 testing resulted in a significant number of users reporting various issues like poshold and autotune were not functioning because their RC inputs were straying out of the deadzones
Increase Roll, Pitch and Yaw IMAX from 0.444 or 0.222 to 0.5
Decrease Yaw Filter from 5hz to 2.5hz based on the results of autotunes on many vehicles which always seems to produce values between 2 and 3hz
getting to 60 was taking far too long (15 minutes or so). 45 is more
achievable.
This is a result of the fix to the invensense temperature detection
code
only reset position on pitch or roll input
also increases the max angle error for twitching in autotune. When a
vehicle is not well tuned the limit can prevent twitching
We are setting a termination handler for some signals which are of not
interest. Just ignore them. Ignoring SIGWINCH allows for example to
run on a screen and change the window size later without killing
ardupilot.
RPI-based boards that use RCInput_RPI need more stack space otherwise we
end up with stack corruption. This leads to crash particularly when also
using GPIO_RPI since it may change what that driver is poking on memory.
This increases stack size to 1M which is overkill for most of other
boards with a more controllable stack usage. However this exposes that
on multiple different HWs a single point for stack size decision may not
be the best. This can be improved in future.
Cache beacon positions to speed-up distance calculations
Only pass data to EKF after both hedgehog and beacon positions are known
Add license and credit Marvelmind
Re-order code around to minimize diff with upstream marvelmind code
Integrated review requests
It was possible for a board with no safety switch attached to get stuck waiting for the user to press the non-existance switch. Rebooting now resolves the problem because the ESC_CAL parameter is reset to zero regardless of whether the calibration completes or not.
This ensures that old yaw targets are not used in the short interval before they are initialised in advance_wp_target_along_track or advance_spline_along_track
On an invensense IMU with fast sampling we need to lower the slave
sample rate for slave sensors such as the built-in AK8963 compass on a
MPU9250.
The slave rate is set as a multiple of the main rate, so it needs to be
much lower for fast sampling. If we leave it high then it greatly
impacts on IMU sample rate.
Without this change a MPU9250 with fast sampling and a compass enabled
will give a gyro rate of around 7200Hz. With this change it gets 7760Hz