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.
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.
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.
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.
RST_SWITCH_CH is documented as "RC channel to use to reset to last flight
mode after geofence takeover", but nothing in Rover reads it. The member it
binds to, reset_switch_chan, has exactly two references in the tree: its
declaration and its GSCALAR. There is no reset-on-geofence-takeover
behaviour in Rover for it to control.
Plane went through this already. It removed its own RST_SWITCH_CH in favour
of the MODE_SWITCH_RESET RC auxiliary function, and carries a conversion for
it in its conversion_table[]. Rover has no MODE_SWITCH_RESET handler, so
there is nothing here to convert to and no behaviour to preserve: the
parameter is simply doing nothing.
Removed in the usual way, leaving a "RST_SWITCH_CH was here" marker and
keeping the k_param_reset_switch_chan key so the enumeration after it does
not shift.
The companion RESET_SWITCH_CHAN_PWM define, the other half of the same
removed feature, goes in #34213.
This drops Rover:RST_SWITCH_CH from the generated parameter metadata and
nothing else, and saves 80 bytes of flash on SITL.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The member has exactly one reference in the tree: its own declaration. It
is not in var_info, so it is bound to no parameter and its value is never
read. Removing it changes no stored parameter, since the old CH7_OPTION
value is located by k_param index through ConversionInfo rather than
through this member.
That k_param key is left in place, with its comment corrected. It reads
"unused", which is true of the parameter but not of the key:
load_parameters() still passes k_param_ch7_option to find_old_parameter()
to carry an old CH7_OPTION setting across to RC7_OPTION. Removing the
enumerator would also renumber every key after it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
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.
The beacon object now lives in AP_Vehicle; remove it from g2 and convert the stored BCN parameters across from the old g2 location.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
when the mode switch was in the "make vehicle safe" position it allowed checks to be skipped. Notably the position checks that mode-guided really wants to be passing
this changes Rover to not set soft_armed false when safety is on,
making Rover match Copter. Instead the new is_armed_and_safety_off()
method is used where we need to know that actuators are active
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Override has_pilot_input_for_override_clear() to use steering (rcmap
roll) and throttle, plus lateral on omni rovers, instead of the
Copter-style roll/pitch/yaw/throttle set.
reject MAV_CMD_DO_REPOSITION destinations that lie outside the
configured fence, with MAV_RESULT_FAILED. Same approach as plane and
copter. Doing this inside set_desired_location() ensures other paths
into GUIDED (e.g. scripting and SET_POSITION_TARGET) are also bounced.
going via the static methods threw away the const-correctness so we need a bunch of non-const equivalents of several const methods
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This removes the need for the pointer to the first mode, and removes the
undefined behavior resulting from indexing past that first mode and
hoping the others follow (though this is unlikely to pose a problem in
practice).
Saves a few bytes of RAM and flash as the pointer is no longer needed
and code is no longer necessary to set it up.
Also fixes the bounds check condition of that array to match its size so
there is no longer the possibility of indexing one past it.
The message is sent with MAV_FRAME_GLOBAL which requires AMSL altitude.
Convert the target location's altitude to AltFrame::ABSOLUTE before
sending, matching the same fix Copter already has.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Randy Mackay
George Zogopoulos
Peter Barker
Henry WurzburgandClaude Opus 5
Stephen Dade
Yuri Rage
Tatsuya Yamaguchi
Hunter McClelland
deepak61296
Andrew Tridgell
Ryan Friedman
Thomas Watson