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
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
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
FIFO sensors produce data at a well known rate, but samples come in
bunches, so we can't use the system clock to calculate deltaT.
non-FIFO sensors produce data when we sample them, but that rate is
less regular due to timing jitter.
For FIFO sensors this changes makes us use a learned sample rate,
which allows for different clock speeds on sensor and system board.
For non-FIFO sensors we use the system clock to measure deltaT
the overall effect is a fix for sensors that produce samples at other
than the claimed datasheet rate.
Leonard Hall
Randy Mackay
murata
Dr.-Ing. Amilcar Do Carmo Lucas
Michael du Breuil
Andrew Tridgell
Lucas De Marchi
Karthik Desai
Peter Barker
Pierre Kancir