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.
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.
Moves off the Vector3f-returning wind_estimate() method. Blimp uses
the success of airspeed_vector_TAS() to decide whether it has a usable
wind estimate; that is left alone here, so no functional change.
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 flight mode, and
removes the undefined behavior resulting from indexing past that first
flight 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 PID_SEND enum values (1-8) were being passed directly as the
MAVLink axis field, conflicting with both the defined PID_TUNING_AXIS
range (1-6) and Rover's use of values 7-11.
Map each internal PID_SEND index to its proper wire value:
- VELX/VELY → PID_TUNING_VEL_NORTH/EAST (10-11)
- VELZ → PID_TUNING_VEL_DOWN (12)
- VELYAW → PID_TUNING_YAW (3), consistent with other vehicles
- POSX/POSY → PID_TUNING_POS_NORTH/EAST (13-14)
- POSZ → PID_TUNING_POS_DOWN (15)
- POSYAW → PID_TUNING_YAW_ANGLE (16)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
WIND.speed field specifies "Wind speed in ground plane" (horizontal
component only). Use wind.xy().length() instead of wind.length() to
exclude the vertical component. Same fix applied to high_latency_wind_speed().
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
GroundControl now uses these names directly through MAVLink
AVAILABLE_MODES. Update them to match the other vehicles.
QGC does not have a hardcoded list so we just make them nicer for users
rather than matching that list.
They are also used in other status messages so those messages will
change slightly too.
This lowers the effort required to turn off just one arming check.
Previously, a user had to disable the ALL bit and enable every check
except the undesired one. Now they can just disable that one directly.
Hopefully this will result in less vehicles with no arming checks
whatsoever, presuming only one check is giving the user grief.
This, as a side effect, removes the difference between the ALL bit set
and all non-ALL bits set (e.g. the latter disables IMU heater checks).
It also ensures the user will get any new arming checks even if they
have skipped one.
People who need to disable all current and future checks for e.g. bench
testing can still do this efficiently by setting the parameter to `-1`,
leveraging that this sets all bits in 2s complement arithmetic.
A parameter conversion is included that skips no checks if the old ALL
bit is set; otherwise it migrates the user's selected checks. If no
checks were enabled, it disables all current and future checks.
Copter and Sub were already using it.
This changes the default timeout for Blimp from 500ms to 1000ms like
other vehicle types using this parameter.
The definition for FS_RADIO_TIMEOUT_MS in Blimp/config.h was removed
because it was its only usage in the codebase.
various changes to avoid use of the Location .alt field, which should be private.
Introduces several new helper functions on Location to help with this
not so much that we want the system to be initialised inasmuch that if we run the rest of the prearms when not initialised the system is likely to fall over
Peter BarkerandClaude Opus 5
Iampete1
Michelle Rossouw
Thomas Watson
Hunter McClelland
Randy Mackay
Marek S. Łukasiewicz
Bob Long
muramura
Henry Wurzburg
co63oc