../../libraries/AP_InertialSensor/AP_InertialSensor_config.h:20:2: error: #error "INS_AUX_INSTANCES must be zero if INS_MAX_INSTANCES is less than 3"
20 | #error "INS_AUX_INSTANCES must be zero if INS_MAX_INSTANCES is less than 3"
| ^~~~~
when we have aux battery information we had assumed the CAN device
would provide the battery remaining percentage. We should obey the "do
not use CAN SoC" with or without an AUX message
This fixes CAN battery monitors with a cell monitor
this allows a lot more drivers to use the GPS_DRV_OPTION but to use
ellisoid height. Particularly useful for DroneCAN GPS modules
using ellisoid height instead of AMSL is useful in some specialised
application
these undocumented bits in register 0x4d control the "adaptive full
scale range" mode of the ICM42688. The feature is enabled by default
but has a bug where it gives "stuck" gyro values for short periods
(between 1ms and 2ms):, leading to a significant gyro bias at longer
time scales, enough to in some cases cause a vehicle to crash if it is
unable to switch to an alternative IMU
this fixes https://github.com/ArduPilot/ardupilot/issues/25025
an incorrectly configured ESC telemetry source can lead to a notch
running at very low frequencies. A simple example is a lua script like
this:
function update()
esc_telem:update_rpm(12, 0, 0)
return update, 10
end
return update()
where motor 12 is unused.
with that script in place we get a 1.0078 Hz filter which leads to
massive phase lag and a crashed aircraft
this is a safety protection. We should also try to find out why the
INS_HNTCH_FREQ lower limit is not working
users with busy CAN bus often get significiantly lower GPS rates on a
moving baseline rover, preventing arming. This PR relaxes the required
frame rate as the EKF is quite happy with 3Hz yaw and the yaw is the
only data consumed from a moving baseline rover
the bad value is -32768 not 0xffff (which is -1)
-32768 badly corrupts the low-pass filter, and is what we see in logs
(a large negative spike on all 3 axes)
update to bug fix from:
https://github.com/ArduPilot/ardupilot/pull/23033
update_pitch_throttle can be called when update_50hz hasn't run in a very long time, or ever. This requires a main loop rate >50Hz, and for the mode change to occur in the same loop that update_50Hz doesn't run but update_pitch_throttle does.
this fixes a state where we either cannot climb or descend in an
uncontrolled manner in a TECS controlled mode
the conditions under which this happened were:
- _use_synthetic_airspeed_once was true due to quadplane takeoff
- we left _thr_clip_status as MAX from previous use of synthetic airspeed
- then run without airspeed
note that this can also impact users with an airspeed sensor if they
disable it or it fails in flight, particularly during a climb
