These four @Param blocks sit on their own after the var_info tables,
attached to nothing. Their own preamble says they were put there so beta
Mission Planner could pick up descriptions from master, and that they could
be removed "once Rover-3.6-beta testing begins".
All four describe parameters that no longer exist:
CH7_OPTION replaced by RC7_OPTION in Rover-3.5
AUX_CH gone with the same rework
PIVOT_TURN_ANGLE converted to WP_PIVOT_ANGLE
PIVOT_TURN_RATE converted to WP_PIVOT_RATE
The last two still have their entries in conversion_table[], which is what
actually carries an old stored value across, and is untouched.
These are not merely dead comments. param_parse.py harvests them, so the
generated metadata has been advertising four parameters the firmware does
not have. Regenerating Rover metadata before and after removes exactly
Rover:CH7_OPTION, Rover:AUX_CH, Rover:PIVOT_TURN_ANGLE and
Rover:PIVOT_TURN_RATE, and changes nothing else.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rover's SYSID_THISMAV moved out of the vehicle var_info and into the GCS
library as MAV_SYSID, leaving the "// SYSID_THISMAV was here" tombstone in
Parameters.cpp. That took the last consumer of this define with it, and
MAV_SYSTEM_ID has not been expanded anywhere since.
Note this define is dead in the same way in the other vehicle directories
and in AP_Periph, where it is likewise defined and never used. Only the
Rover copy is touched here to keep this PR to one vehicle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neither RESET_SWITCH_CHAN_PWM nor the RESET_SWITCH_CH it describes appears
anywhere else in the tree. The define and the comment explaining the feature
are all that is left of it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The CH7_OPTION parameter was replaced by RC7_OPTION for the Rover-3.4 to
3.5 upgrade and the define has had no consumer since. It cannot have had
one: it expands to CH7_SAVE_WP, which is not defined anywhere in the tree,
so any use of it would have failed to compile.
The "FrSky telemetry support" banner immediately above it goes too. Whatever
it once introduced is long gone, leaving it labelling the CH7_OPTION block
by accident.
The k_param_ch7_option key in Parameters.h is deliberately left alone. It
looks unused and is marked as such, but load_parameters() still uses it to
find the old stored value for the RC7_OPTION conversion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rover has not used the L1 controller since 95c69811cb ("Rover: integrate
position controller", 2021-11-19), which removed both the NAVL1_ parameter
group and the last consumer of this macro:
L1_controller.set_default_period(NAVL1_PERIOD);
Rover does not build AP_L1_Control at all any more; navigation is handled
by AR_WPNav and the position controller. The define was left behind and
nothing in Rover has referenced it since. Its guard is misspelled relative
to the macro it protects, so a NAVL1 defined elsewhere would not have
suppressed it in any case, and NAVL1 is defined nowhere in the tree.
This is the compile time macro only. The Plane NAVL1_PERIOD parameter in
AP_L1_Control is a separate thing and is untouched.
No functional change: the ardurover SITL binary is byte identical before
and after.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit initializes the variable `yaw_deltat` in the file
`libraries/AP_AHRS/AP_AHRS_DCM.cpp` as 0, so those compiling the project
no longer get the "uninitialized variable" error which stops
compilation.
Co-Authored-By: Gemini <200291788+gemini-code-assist@users.noreply.github.com>
The test flies with SIM_ACC*_BIAS_X of 1m/s/s - which is exactly
LAND_DETECTOR_ACCEL_MAX. With AHRS_EKF_TYPE 10 nothing corrects the
bias out of get_accel_ef(), so on the ground the land detector's
filtered acceleration sits precisely at its threshold and whether
landing is ever detected - and thus whether we ever disarm - hinges
on noise. Incidental timing shifts (such as announcing ourselves to
the vehicle on reconnect, which changes how much simulated time the
post-reboot setup consumes) flip it from always-passing to
always-failing on a given machine.
The bias has done its job by the time we land - the test's assertion
is that precision loiter holds position despite it - so zero it
before entering LAND.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The ARMDISARM_UNUSED to ARMDISARM rewrite of stored RCn_OPTION values had
no annotation: it calls set_and_save() directly rather than going through
an AP_Param::convert_* helper, so an audit anchored on those helpers did
not see it.
Blimp has no release tags, so the release cannot be established by
content the way it is for the other vehicles. The annotation names the
cycle it was added in instead: Sep-2021, which is 4.2. No functional
change.
The ARMDISARM_UNUSED to ARMDISARM rewrite of stored RCn_OPTION values had
no annotation: it calls set_and_save() directly rather than going through
an AP_Param::convert_* helper, so an audit anchored on those helpers did
not see it.
Established by content rather than by date: Tracker-4.5.0 is the earliest
tracker release tag and it already contains the conversion. No
functional change.
convert_options() rewrites stored RCn_OPTION values from an old auxiliary
function number to a new one. It is a parameter conversion, but it does
not go through any of the AP_Param::convert_* helpers - it calls
set_and_save() directly - so it carried no annotation and did not show up
in an audit anchored on those helpers.
Established by content rather than by date: convert_options() is absent
from Copter-4.1.0 and present in Copter-4.2.0. The per-vehicle calls are
annotated in their own commits, each naming that vehicle's own release.
No functional change.
One annotation named a bare "4.7" and the other described an upgrade
span, "4.6->4.7". These are shared library files, so they take the cycle
number.
Established by content rather than by date: convert_min_max_params(), and
the convert_params() loop which is now nothing but a call to it, are
absent from Copter-4.6.0 and present in Copter-4.7.0. The older
RangeFinder::convert_params() body present in Copter-4.1.0 was a
different, since-retired conversion. No functional change.
Two annotations named a bare "4.6" rather than the release. This is a
shared library file, so it takes the cycle number.
Also annotates the conversion of the old GPS_AUTO_SWITCH == 3 encoding
into GPS_PRIMARY = 1 with GPS_AUTO_SWITCH = 0. It had no annotation at
all: it calls set_and_save() directly rather than going through an
AP_Param::convert_* helper, and it sits below an already-annotated
conversion in the same function, so it hid from both an audit anchored on
those helpers and one asking only whether a function mentions
PARAMETER_CONVERSION anywhere.
Established by content rather than by date: the GPS1_GNSS_MODE table and
the moving-baseline convert_class() call are both absent from
Copter-4.5.0 and present in Copter-4.6.0; the GPS_AUTO_SWITCH conversion
is absent from Copter-4.0.0 and present in Copter-4.1.0. No functional
change.
The RunCam annotation had text in front of the PARAMETER_CONVERSION
token, so a grep anchored at the start of the comment did not find it.
Both annotations also described the release in prose rather than in the
standard form.
The RunCam date was wrong as well. It read Nov-2024, but the conversion
arrived in 399f9f6f98 "AP_Camera: RunCam camera backend", which was
authored Apr-2024 and merged Dec-2024 - the annotations on this branch
use the date the conversion landed in master, so it is Dec-2024.
Established by content rather than by date: convert_runcam_params() is
absent from Copter-4.6.0 and present in Copter-4.7.0; the CAM_TRIGG_TYPE
to CAM1_TYPE conversion is absent from Copter-4.3.0 and present in
Copter-4.4.0. No functional change.
All three annotations named a bare "4.7" rather than the release. These
are shared library files, so they take the cycle number.
Established by content rather than by date: AC_Circle's CIRCLE_RADIUS_M
conversion, AC_Loiter's _brake_jerk_max_msss conversion and AC_WPNav's
_wp_speed_ms conversion are all absent from Copter-4.6.0 and present in
Copter-4.7.0. No functional change.
Both annotations named a bare "4.7" rather than the release. These are
shared library files, so they take the cycle number.
Established by content rather than by date: the ATC_RATE_WPY_MAX
conversion and AC_PosControl's _pid_accel_d_m conversion are both absent
from Copter-4.6.0 and present in Copter-4.7.0. No functional change.
The LAND_PITCH_CD to LAND_PITCH_DEG conversion carried its date in prose
("added January 2024") rather than in the standard form, so a grep for
conversion vintages missed it.
Plane::load_parameters() carries a dozen conversions and several were
missing their annotation, which is easy to miss because the function has
plenty of other annotated conversions in it:
- TERRAIN_FOLLOW parameter width (Mar-2021)
- USE_REV_THRUST parameter width (Jun-2021)
- INS_HNTC2 from the old fixed notch (Apr-2022)
These are now "PARAMETER_CONVERSION - Added: <Mon>-<Year>", so a grep for conversion vintages finds them and can parse the date. No functional change.
Also names the release the conversion was for, which is the part that
actually matters when deciding whether a conversion can be retired. The
date alone is ambiguous here: 0658f06030 was authored Dec-2021 but did
not reach master until Sep-2022, and the conversion is absent from
4.2.0 and present in 4.3.0. Dating it from when it was written would
point at the wrong release.
These are now "PARAMETER_CONVERSION - Added: <Mon>-<Year> for <Release>",
so a grep for conversion vintages finds them and can parse the date.
Established by content rather than by date: the ANG_MAX conversion is
absent from Copter-4.6.0 and present in Copter-4.7.0. No functional
change.
AP_Mount::convert_params() carried its date in prose ("below conversions
added Sep 2022 ahead of 4.3 release") rather than in the standard form,
so a grep for conversion vintages missed it.
The release is named in the standard form as well. Established by
content: the MNT_TYPE to MNT1_TYPE conversion is absent from Copter-4.2.0
and present in Copter-4.3.0.
AP_SerialManager::convert_parameters() widens SERIALn_OPTIONS and
carried no annotation; added Jun-2025.
The pre-arm check's annotation read "Added May 2028", which is in the
future. That conversion was authored 2025-06-02 and landed in master
2025-06-03, so Jun-2025 is correct. Both are now in the standard form.
NavEKF3::convert_parameters() converts EK3_GPS_TYPE and EK3_ALT_SOURCE
into the EK3_SRC1_ parameters. Added Nov-2020; it carried no
PARAMETER_CONVERSION annotation.
The ARMING_CHECK to ARMING_SKIPCHK conversion was marked
"PARAM_CONVERSION", which no grep for PARAMETER_CONVERSION finds, and it
carried no date. Added Dec-2025 for ArduPilot-4.7.
AP_RollController::convert_pid() and AP_PitchController::convert_pid()
convert the old RLL2SRV_/PTCH2SRV_ gains into the AC_PID form. Added
Apr-2021; they carried no PARAMETER_CONVERSION annotation.
Rover's conversion_table spans eleven years, so it gets an annotation
per block rather than one for the table: battery (Oct-2013), serial baud
(Jan-2015), MOT_THR (Aug-2017), COMPASS_ENABLE (Apr-2019), WP_RADIUS
(May-2019), WP_PIVOT (Dec-2021), sailboat (May-2019), ATC_TURN_MAX_G
(May-2021), PRX1_ (Aug-2022) and TRQ1_ (May-2024).
Also annotates the CH7_OPTION to RC7_OPTION conversion (Jan-2019), the
WP_SPEED/CRUISE_SPEED conversion (May-2019) and the FF/FILT conversion
(Jul-2019). Remaining changes are date format corrections. No
functional change.
Also annotates the RCn_OPTION conversions - ARMDISARM_UNUSED to
ARMDISARM, and Rover's SAVE_TRIM to TRIM_TO_CURRENT_SERVO_RC - which call
set_and_save() directly rather than an AP_Param::convert_* helper and so
were missed by an audit anchored on those helpers. Established by
content: absent from Rover-4.1.5, present in Rover-4.2.0.
Adds the missing PARAMETER_CONVERSION annotation to the conversion_table
(battery failsafe parameters, Mar-2018, and COMPASS_ENABLE, Apr-2019)
and to the attitude control _FILT to FLTE conversion (Jul-2019).
Remaining changes are date format corrections. No functional change.
Also annotates the ARMDISARM_UNUSED to ARMDISARM rewrite of stored
RCn_OPTION values, which calls set_and_save() directly rather than going
through an AP_Param::convert_* helper and so was missed by an audit
anchored on those helpers. It went in during Sep-2021, but Sub has no
4.2 to 4.4 releases, so established by content it first shipped in
ArduSub-4.5.0.
Adds the missing PARAMETER_CONVERSION annotation to:
- the conversion_table, which converts the old altitude fence
parameters (Mar-2021)
- the loop converting the old chan params to RCx_OPTION (Mar-2021)
- the tailsitter (Jul-2021) and tiltrotor (Sep-2021) blocks of
q_conversion_table
The quadplane centi-conversions already carried a date in prose
("centi-conversions added January 2024"); that is now in the standard
form. Remaining changes are date format corrections. No functional
change.
Also replaces the "CONVERSION: Added for upgrade to ArduPlane 4.2, Sep
2021" comment on the RCn_OPTION conversion with the standard annotation.
That conversion calls set_and_save() directly rather than an
AP_Param::convert_* helper, so an audit anchored on those helpers did not
see it. Established by content: absent from Plane-4.1.7, present in
Plane-4.2.0.
These are all "PARAMETER_CONVERSION - Added: <Mon>-<Year> for <Release>"
now, so that a grep for conversion vintages finds them and can parse the
date.
Also annotates the ARMDISARM_UNUSED to ARMDISARM_AIRMODE rewrite of
stored RCn_OPTION values, which had no annotation at all: it calls
set_and_save() directly rather than going through an AP_Param::convert_*
helper, so an audit anchored on those helpers did not see it.
Established by content rather than by date: absent from Copter-4.1.0 and
present in Copter-4.2.0. No functional change.
The @Description gave OA_MARGIN_MAX the meaning of OA_BR_LOOKAHEAD,
saying object avoidance "will ignore objects more than this many meters
from vehicle". It is the opposite: it is the clearance the vehicle tries
to keep.
BendyRuler compares the candidate path's computed margin against it and
only accepts a path when the clearance exceeds it (AP_OABendyRuler.cpp
lines 177, 202, 281 and 303), and Dijkstra passes it to
set_fence_margin(). OA_BR_LOOKAHEAD is the parameter that limits how far
ahead obstacles are considered.
Users have hit this: ArduPilot/ardupilot_wiki#3099 asks which of the two
meanings is right, because the wiki correctly documents it as the
stand-off distance while the parameter description says the reverse.
Also update the two _margin_max member comments, which repeated the same
incorrect wording.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
FENCE_ALT_MIN and FENCE_ALT_MAX each carry their own reference frame,
but pre_arm_check() compared their raw values. Those values are
measured from different datums whenever the frames differ, so the
comparison is between unlike quantities: a floor 20m above home, held
as an absolute 604.09, read as being above a 100m ceiling which is also
20m above the floor, and the vehicle refused to arm with
PreArm: FENCE_ALT_MAX < FENCE_ALT_MIN
The FENCE_MARGIN check immediately below subtracts the same two values
and had the same problem.
Convert the minimum into the maximum's frame before comparing. Where
the frames already match nothing is converted, so a comparison which
used to work without home, an origin or terrain data still does. Where
the conversion is not possible - an above-terrain limit with no terrain
height, or above-home with no home - the check reports that rather than
comparing regardless.
Found by an autotest: ArduCopter's MinAltFence sets an absolute floor
in its first sub-case and takes off again in the second, and whether it
failed depended on the fence still being enabled at that moment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
FENCE_ALT_MIN and FENCE_ALT_MAX each carry their own reference frame,
but pre_arm_check() compared their raw values. Those values are
measured from different datums whenever the frames differ, so the
comparison is between unlike quantities: a floor 20m above home, held
as an absolute 604.09, read as being above a 100m ceiling which is also
20m above the floor, and the vehicle refused to arm with
PreArm: FENCE_ALT_MAX < FENCE_ALT_MIN
The FENCE_MARGIN check immediately below subtracts the same two values
and had the same problem.
Add get_alt_limits_in_common_frame_m(), which converts the minimum into
the maximum's frame and hands back both values and the frame they are
now in. Where the frames already match it converts nothing, so a
comparison which used to work without home, an origin or terrain data
still does. Where the conversion is not possible - an above-terrain
limit with no terrain height, or above-home with no home - the check
reports that rather than comparing regardless.
Found by an autotest: ArduCopter's MinAltFence sets an absolute floor
in its first sub-case and takes off again in the second, and whether it
failed depended on the fence still being enabled at that moment.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Henry WurzburgandClaude Opus 5
robotsnhandGemini
Peter BarkerandClaude Fable 5
“Jim
Randy Mackay
Leonard Hall
Andrew Tridgell