Allow yaw to have negative expo

[MrD-RC]

User description

See iNavFlight/inav#11098

---

PR Type

Enhancement

---

Description

• Allow yaw expo parameters to support negative values

• Change yaw expo data parsing from unsigned to signed integers

• Update slider ranges to support negative expo values (-100 to 100)

• Update canvas validation to accept negative expo values

---

Diagram Walkthrough

flowchart LR
  A["Yaw Expo Parameters"] --> B["Parse as Int8<br/>instead of UInt8"]
  B --> C["RC_YAW_EXPO"]
  B --> D["manual_RC_YAW_EXPO"]
  C --> E["Slider Range<br/>-100 to 100"]
  D --> F["Slider Range<br/>-100 to 100"]
  E --> G["Canvas Validation<br/>-1 to 1"]
  F --> G

Loading

File Walkthrough

Relevant files

Enhancement

MSPHelper.js Parse yaw expo as signed integers                                                js/msp/MSPHelper.js Changed RC_YAW_EXPO parsing from getUint8() to getInt8() to support negative values Changed manual_RC_YAW_EXPO parsing from getUint8() to getInt8() to support negative values +2/-2      pid_tuning.js Support negative values in UI sliders and canvas                  tabs/pid_tuning.js Updated drawExpoCanvas() validation to accept negative values (range -1 to 1) Changed yaw expo slider range from 0-100 to -100-100 for stabilized mode Changed manual yaw expo slider range from 0-100 to -100-100 for manual mode +3/-3

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No audit logs: The new parsing of signed yaw expo values adds no logging of critical actions, but given this is UI parsing logic, audit logging may not be applicable here. Referred Code // stabilized FC.RC_tuning.RC_EXPO = parseFloat((data.getUint8(offset++) / 100).toFixed(2)); FC.RC_tuning.RC_YAW_EXPO = parseFloat((data.getInt8(offset++) / 100).toFixed(2)); FC.RC_tuning.roll_rate = data.getUint8(offset++) * 10; FC.RC_tuning.pitch_rate = data.getUint8(offset++) * 10; FC.RC_tuning.yaw_rate = data.getUint8(offset++) * 10; // manual FC.RC_tuning.manual_RC_EXPO = parseFloat((data.getUint8(offset++) / 100).toFixed(2)); FC.RC_tuning.manual_RC_YAW_EXPO = parseFloat((data.getInt8(offset++) / 100).toFixed(2));
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Range handling: The canvas draw function now validates [-1,1] and returns early out-of-range without feedback; confirm upstream ensures values are normalized and UI communicates invalid input. Referred Code function drawExpoCanvas(value, $element, color, width, height, clear) { let context = $element.getContext("2d"); if (value < -1 || value > 1) { return; }
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Slider bounds: Sliders now allow -100 to 100 and canvas checks [-1,1]; verify value scaling and clamping are consistently applied to prevent invalid states from user input. Referred Code GUI.sliderize($('#rate_rollpitch_expo'), FC.RC_tuning.RC_EXPO * 100, 0, 100); GUI.sliderize($('#rate_yaw_expo'), FC.RC_tuning.RC_YAW_EXPO * 100, -100, 100); GUI.sliderize($('#rate_manual_roll'), FC.RC_tuning.manual_roll_rate, 0, 100); GUI.sliderize($('#rate_manual_pitch'), FC.RC_tuning.manual_pitch_rate, 0, 100); GUI.sliderize($('#rate_manual_yaw'), FC.RC_tuning.manual_yaw_rate, 0, 100); GUI.sliderize($('#manual_rollpitch_expo'), FC.RC_tuning.manual_RC_EXPO * 100, 0, 100); GUI.sliderize($('#manual_yaw_expo'), FC.RC_tuning.manual_RC_YAW_EXPO * 100, -100, 100);
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Fix incorrect expo curve visualization Correct the expo curve visualization formula in drawExpoCanvas to accurately represent both positive and negative expo values. The current implementation inverts the curve's shape. tabs/pid_tuning.js [63] -context.quadraticCurveTo(width / 2, height - ((height / 2) * (1 - value)), width, 0); +context.quadraticCurveTo(width / 2, height / 2 - (height / 2) * value, width, 0); [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies that the existing formula for drawing the expo curve inverts the visualization, showing an upward bow for positive expo and a downward bow for negative expo, which is the opposite of the intended stick response. Applying the suggested fix is critical for providing an accurate visual representation to the user, which is crucial in a tuning interface.	High
Update