Checks the baro fallback drops the altitude gate rather than the
compensation beyond 20m from the launch point; the previous
AP_GroundEffect reported 0s there.
The baro fallback gates touchdown on height-since-takeoff assuming flat
ground. Beyond 20m from the launch point that assumption may not hold,
but disabling touchdown compensation there left mission landings and
rally-point RTLs on baro-only vehicles with none at all, a regression
from the pre-gate behaviour, while the no-position branch assumed flat
ground everywhere.
Beyond 20m fall back to any gentle descent counting as a landing, as
before the gate existed and as the comment on the constant already
described. Rangefinder, near-launch and no-position paths are
unchanged.
SITL, GNDEFF_ALT=1.0, GUIDED to 3m, land 30m from takeoff:
touchdown_expected 0.0s -> 9.6s (6.9s landing at the takeoff point,
9.8s with GNDEFF_ALT=5).
EKF3's HAGL is not zero on the ground: the EKF substitutes the
rangefinder ground clearance (RNGFNDx_GNDCLR) while the sensor is out
of range low. Gating on absolute HAGL therefore released the takeoff
window before liftoff whenever GNDCLR >= GNDEFF_ALT, and the touchdown
gate could never be met on the same vehicle.
Anchor HAGL alongside the takeoff altitude while on the ground and
gate on the climb since then, matching the relative-to-takeoff
fallback. Without a rangefinder behaviour is unchanged.
SITL, GNDEFF_ALT=0.5 GNDEFF_TMO=0, RNGFND1_TYPE=100 RNGFND1_GNDCLR=0.6:
takeoff_expected 0.0s -> 4.9s, touchdown_expected 0.0s -> 6.9s
(baro-only baseline 5.0s).
Restores the pre-PR latch: takeoff_expected is set while armed and
land_complete and only cleared by the release check, so an altitude
release is not undone by a later dip below GNDEFF_ALT and modes that
disable it (THROW) never see it in the air.
Also clamps GNDEFF_TMO before the unsigned conversion, only trusts the
takeoff XY anchor for the drift gate when it was captured with a valid
horizontal position, and renames the drift define to say it is a NE
distance.
Replaces Copter's built-in ground-effect detection with the
AP_GroundEffect library and wires its AC_PosControl and per-cycle
vehicle state.
A stored GND_EFFECT_COMP=0 is migrated to GNDEFF_ALT=-1; the enabled
default needs no migration.
With the default GNDEFF_ALT of 0.5m touchdown_expected now also
requires the vehicle to be near the ground (within 0.5m of the takeoff
height, and within 20m horizontally of the launch point when no
rangefinder is available), where the old code asserted it for any slow
descent at any height. GNDEFF_ALT=0 restores the old behaviour.
Vehicle-agnostic detector that tells the EKF when to expect baro
disturbance from rotor downwash near the ground, driving AP_AHRS
set_takeoff_expected and set_touchdown_expected. Adds GNDEFF_ALT
(altitude threshold and master enable) and GNDEFF_TMO (takeoff hold
time).
GPS_AUTO_SWITCH used to have a value 3, "use second GPS". That was
replaced by GPS_PRIMARY, and this converted a stored 3 into GPS_PRIMARY=1
with GPS_AUTO_SWITCH=0. Added Nov-2020 and present in the 4.1.0 release,
so anybody moving from 4.3.0 or later has already had it applied.
The conversion only ran while GPS_PRIMARY was unconfigured, but
GPS_PRIMARY arrived in the very same commit as the conversion, so on the
first 4.1-or-later boot of any vehicle carrying a 3 it was unconfigured
and the conversion ran.
A stored 3 which survives is no longer any of NONE, BLEND or
USE_PRIMARY_IF_3D_FIX, so update_primary() falls through to the UseBest
path - the same as any other value this firmware does not know, and the
same as it already does today for anybody who sets 3 by hand after having
configured GPS_PRIMARY. 3 is not offered in the parameter's @Values and
GPSAutoSwitch::USE_SECOND stays commented out in the enum, so the number
is not handed out again.
The last caller went away with the per-vehicle RCn_OPTION conversions.
AUX_FUNC::ARMDISARM_UNUSED and AUX_FUNC::SAVE_TRIM stay in the enum:
those numbers are still spoken for and must not be handed out again.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to ARMDISARM (153),
and Rover's SAVE_TRIM (5) to TRIM_TO_CURRENT_SERVO_RC (155). Both were
added Sep-2021 and are present in Rover-4.2.0, so anybody moving from
Rover-4.4.0 - the oldest release a Rover user can be moving from once the
migration floor is 4.3, as Rover has no 4.3 - has already had them
applied.
A stored 41 or 5 which survives becomes an unhandled auxiliary function
on Rover and does nothing, which is the same outcome as any other option
number this firmware does not know.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to ARMDISARM (153).
Added Sep-2021.
Blimp has no release tags, so unlike the other vehicles there is no
release which can be shown to contain the conversion, and a 4.3 migration
floor says nothing about a build made from master. This removal takes
the floor to mean that a Blimp older than the whole 4.3 cycle is out of
scope for migration, the same as it is for every other vehicle.
A stored 41 which survives becomes an unhandled auxiliary function and
does nothing, which is the same outcome as any other option number this
firmware does not know.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to ARMDISARM (153).
Added Sep-2021, but Sub has no 4.2 to 4.4 releases, so the first release
carrying it is ArduSub-4.5.0. That is also the oldest release a Sub user
can be moving from once the migration floor is 4.3, so everybody in scope
has already had it applied.
A stored 41 which survives becomes an unhandled auxiliary function and
does nothing, which is the same outcome as any other option number this
firmware does not know.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to ARMDISARM (153),
or to ARMDISARM_AIRMODE (154) on a quadplane which had the airmode option
set and no AIRMODE switch. Added Sep-2021 and present in Plane-4.2.0, so
anybody moving from 4.3.0 or later has already had it applied.
A stored 41 which survives becomes an unhandled auxiliary function and
does nothing, which is the same outcome as any other option number this
firmware does not know.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to
ARMDISARM_AIRMODE (154). Added Sep-2021 and present in Copter-4.2.0, so
anybody moving from 4.3.0 or later has already had it applied.
A stored 41 which survives becomes an unhandled auxiliary function and
does nothing, which is the same outcome as any other option number this
firmware does not know.
Rewrote a stored RCn_OPTION of ARMDISARM_UNUSED (41) to ARMDISARM (153).
Added Sep-2021 and present in Tracker-4.5.0, which is the earliest
tracker release there is, so every tracker release a user can be moving
from already applied it.
A stored 41 which survives becomes an unhandled auxiliary function and
does nothing, which is the same outcome as any other option number this
firmware does not know.
Converted EK3_GPS_TYPE, EK3_ALT_SOURCE and EK3_MAG_CAL into the
EK3_SRC1_ parameters. Added Nov-2020 and present in the 4.3.0 release,
so anybody running 4.3.0 or later has already had it applied.
Note that the only call to convert_parameters() was from
InitialiseFilter(), below its
if (_enable == 0 || _imuMask == 0) {
return false;
}
early return, so "present in the release" is not quite the same as "has
run". A user who has had EK3_ENABLE=0 for every release from 4.3
onwards never reached the conversion, and if they enable EKF3 after
moving to 4.8 they get EK3_SRC1_ defaults rather than their old source
selections. That is judged too unlikely - and the parameters too old -
to keep the conversion for.
Converted MNT_ to MNT1_, mount angle limits from centi-degrees to
degrees, and the mount RC input channels to RCx_OPTION. Added Sep-2022
and first shipped in the 4.3.0 release, so anybody running 4.3.0 or
later has already had it applied.
Widened LOG_FILE_BUFSIZE from 8 to 16 bits. Added Nov-2020 and present
in the 4.3.0 release, so anybody running 4.3.0 or later has already had
it applied.
Converted the old COMPASS_PRIMARY into the device-id priority list.
Added Feb-2020 and present in the 4.3.0 release, so anybody running
4.3.0 or later has already had it applied.
Note that the conversion sat inside Compass::init(), below its
if (!_enabled) {
return;
}
early return, so "present in the release" is not quite the same as "has
run". A user who has had COMPASS_ENABLE=0 for every release from 4.3
onwards never reached the conversion, and if they enable the compass
after moving to 4.8 their old COMPASS_PRIMARY selection is not honoured.
That is judged too unlikely - and the parameter too old - to keep the
conversion for.
AP_RollController::convert_pid() and AP_PitchController::convert_pid()
converted the old RLL2SRV_/PTCH2SRV_ gains into the AC_PID form. Added
Apr-2021 and described in the code as "a temporary conversion function
during development"; present in the 4.3.0 release, so anybody running
4.3.0 or later has already had it applied.
Trims conversion_table down to just the TRQ1_ block, which was added
May-2024 and so is still required. Everything above it - battery
(Oct-2013), serial baud (Jan-2015), MOT_THR (Aug-2017), COMPASS_ENABLE
(Apr-2019), WP_RADIUS (May-2019), sailboat (May-2019), ATC_TURN_MAX_G
(May-2021), WP_PIVOT (Dec-2021) and PRX1_ (Aug-2022) - is present in
Rover-4.4.0, the oldest release a Rover user can be moving from once the
migration floor is 4.3, as Rover has no 4.3.
Also removes the WP_SPEED/CRUISE_SPEED conversion (May-2019) and the
attitude control FF/FILT conversion (Jul-2019) on the same grounds.
Converted the old battery failsafe parameters (Mar-2018) and
COMPASS_ENABLE (Apr-2019). Sub has no 4.2, 4.3, 4.4 or 4.6 release, so
the oldest version a user can be moving from once the migration floor is
4.3 is ArduSub-4.5.0, which has already had these applied.
- the conversion_table, which converted the old altitude fence
parameters (Mar-2021)
- the loop converting the old chan params to RCx_OPTION, along with
rc_option_conversion and the RCConversionInfo struct (Mar-2021)
Both are present in the 4.3.0 release, so anybody running 4.3.0 or later
has already had them applied.
Added in 2019 for the Rover-3.4 to 3.5 upgrade, and present in
Rover-4.4.0 - the oldest release a Rover user can be moving from once
the migration floor is 4.3, as Rover has no 4.3.
This moved ATC_RAT_RLL/PIT/YAW_FILT to ATC_RAT_*_FLTE and dates from
2019 - it is present in ArduSub-4.1.2 and ArduSub-4.5.0. Sub has no
4.2, 4.3, 4.4 or 4.6 release, so the oldest version a user can be moving
from once the migration floor is 4.3 is ArduSub-4.5.0, which has already
had this applied.
Sub::convert_old_parameters() is left empty by this, so it goes too.
This was meant to convert VTX_OPTIONS from int8 to int16, and is present
in the 4.3.0 release, so anybody running 4.3.0 or later has already had
it applied.
It should be noted that it never actually did anything. 0658f06030
widened _options from AP_Int8 to AP_Int16 and added the conversion in
the same commit, but passed the new width rather than the old one:
_options.convert_parameter_width(AP_PARAM_INT16);
The argument to convert_parameter_width() is the type the value was
stored as *before* the widening, so this should have been
AP_PARAM_INT8. AP_Param::scan() matches on the type in the parameter
header, so a value written as an int8 is never found by a scan for an
int16 and the conversion always returned false without touching
anything. A user upgrading across the widening lost their VTX_OPTIONS
regardless.
So this removes dead code, and the migration floor is not really what
makes it safe to do so.
This converted SERVOn_FUNCTION from int8 to int16, and is present in the
4.3.0 release (in fact all the way back to 4.0.0). Anybody running
4.3.0 or later has already had it applied.
Rover has no 4.3 release, so the oldest version a user can be moving
from once the migration floor is 4.3 is Rover-4.4. All of these
conversions are present in Rover-4.4.0, so anybody running that or later
has already had them applied:
- the airspeed object out of g2 (Jan-2022)
- the AIS object out of g2 (Mar-2022)
- FENCE_ parameters into the AC_Fence object (Mar-2022)
Also drops the call to SRV_Channels::upgrade_parameters(), which is
being removed.
Sub has no 4.2, 4.3, 4.4 or 4.6 release, so the oldest version a user
can be moving from once the migration floor is 4.3 is Sub-4.5. Both of
these conversions are present in ArduSub-4.5.0, so anybody running that
or later has already had them applied:
- the airspeed object out of g2 (Jan-2022)
- FENCE_ parameters into the AC_Fence object (Mar-2022)
Also drops the call to SRV_Channels::upgrade_parameters(), which is
being removed.
The Q_M_PWM_MIN/Q_M_PWM_MAX conversion was added Oct-2021 and so is
present in the 4.3.0 release, which is enough to retire it under the
4.3 migration floor. It is being removed in a commit of its own
because it was never just a migration:
AP_Param::convert_old_parameters(&mot_pwm_conversion_table[0], ...);
if (!motors->check_mot_pwm_params()) {
AP_Param::convert_old_parameters(&mot_pwm_conversion_table[0], ..., CONVERT_FLAG_FORCE);
}
The second call re-ran on every single boot, not just on the first boot
after an upgrade. Any vehicle whose current Q_M_PWM_MIN/Q_M_PWM_MAX
were invalid had them silently overwritten from the old quadplane
parameter slots, over and over, for as long as they stayed invalid. A
user could be flying on values they never set and have no indication of
it.
That magic goes away here. A vehicle with invalid Q_M_PWM_MIN/MAX is no
longer quietly repaired; it now fails the existing AP_MotorsMulticopter
arming check with "Check Q_M_PWM_MIN and Q_M_PWM_MAX" and the user fixes
the parameters themselves. This is a behaviour change, and it is the
point of the commit rather than a side-effect of the migration-floor
cleanup.
AP_MotorsMulticopter::check_mot_pwm_params() is still used by that
arming check, so it stays.
Randy Mackay
George Zogopoulos
Andrew Tridgell
msli-dev
Andy Piper
Peter Barker