Repository navigation
Conversation
Decode MAV_PARAM_TYPE_EXTENDED PARAM_VALUE (the value carried in the extended_type/extended_data extension fields for values not exactly representable as a float) and remember the logical int type. On C-cast vehicles (ArduPilot) 'param set' upgrades int32 parameters to the extended encoding when the value needs it and the vehicle advertises MAV_PROTOCOL_CAPABILITY_PARAM_EXTENDED (learned by requesting AUTOPILOT_VERSION); otherwise the existing float path is unchanged, and PX4-style byte-wise handling is untouched. The FTP parameter download now records int32 logical types, direct MAVParmDict.mavset callers (param load, scripts) inherit the extended support via the new pymavlink attributes, and the parameter editor routes sets through the param module so it benefits too.
Replace extended int32 writes and FTP log entries with raw float-field bytes. Advertise receive support before writes, decode signed and unsigned 64-bit extensions exactly, and retain integer precision when checking acknowledgements.
Preserve extended value bytes when validating acknowledgements and keep progress notifications out of download accounting. Matching progress extends the pending write timeout, while a targeted PARAM_ERROR terminates it.
|
Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting. Reviewed at head Thanks. This looks good with the companion pymavlink (all 8 new tests pass there), but it needs dependency handling before it can merge. Blocking: with a released pymavlink (2.4.49, which setup.py still allows and CI pins), a vehicle advertising capability bit 2097152 sends every INT32 set down the BYTEWISE_INT32 path (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR427, https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR842). That path calls the missing mavutil.param_integer_value (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR139). The AttributeError isn't caught, the entry never expires, and every later param set for that vehicle is silently never sent (moddebug=0 hides it). Please gate the new paths on the helpers existing and drop the literal-bit fallback, or raise the pymavlink minimum. Blocking: CI is red. Six of the eight new tests fail on pymavlink 2.4.49 (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-113f8f47ea330661441519e80b1eaed22f5f676d592b224fb569ad4b6ca69494R54), which python-cleanliness.yml pins. These need feature-aware skips, or a pymavlink release plus a matching workflow and packaging bump. Non-blocking: The param editor treats IN_PROGRESS (type 14) PARAM_VALUEs as completed writes (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-0ab83ea322003df1a970173025fa9b450bf0b84cb54dbcba7253dfcafc81162bR182). FTP int32 params are now logged to the tlog as raw bytewise values, which MAVExplorer paramchange misreads (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR498). ParamSet.handle_PARAM_VALUE needs an extended_data-is-not-None guard (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR223). Plain UINT32 announcements aren't recorded as a logical type, unlike INT32 (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR377). Two comments still say int32 uses the 'extended encoding' (https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-68655e9162d7f0884145944097120f52a93e1768f77ad8ada2a26badcf2b262fR572, https://github.com/ArduPilot/MAVProxy/pull/1764/files#diff-0ab83ea322003df1a970173025fa9b450bf0b84cb54dbcba7253dfcafc81162bR364). Reviewed at 6be3bfe; SITL and the wx GUI were not run. |
This branch has not been deployed
2 participants
Preserve full-width parameter values when reading, editing and writing them. For example, setting
16777217through a float32 conversion currently loses a bit; the negotiated bytewise path sends the exact integer and verifies the returned value.Negotiate receive support before bytewise writes, retain logical parameter types from messages and FTP downloads, and use raw bytes for signed/unsigned 32-bit values. Support typed INT64, UINT64, REAL64 and 128-byte CUSTOM values, including exact extended acknowledgements and explicit
hex:custom input. Matching IN_PROGRESS replies extend pending write timeouts without changing cached values or download accounting; targeted PARAM_ERROR replies terminate the operation. Legacy C-cast and PX4 bytewise handling remain available.Depends on pymavlink #1291 and the matching MAVLink definitions #523.
Validation:
Related: RFC #31, upstream MAVLink #2624, ArduPilot #34519, and the 32-bit parameter project.
AI assistance: Codex implemented and revised code and tests, performed local validation, and prepared this description under the author's design direction.