update

[Rui-Xiaoyu]

Summary by Sourcery

Adjust motor power allocation logic with a configurable chassis power margin and correct quadratic current solver behavior.

Bug Fixes:

• Fix current solver to use the computed solution when the quadratic discriminant is near zero instead of writing to the original current value.

Enhancements:

• Introduce a named chassis power limit margin constant and apply it in available power calculations for omni and swerve outputs.
• Ensure available chassis power for swerve control is non-negative and no longer adjusted by negative motor power contributions.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adjusts chassis power limiting logic by introducing a configurable power margin, fixes a bug in solving motor current from target power, and simplifies available power accounting for omni and swerve control paths.

Class diagram for updated power control and motor power model

classDiagram
  class MotorPowerModel {
    +float CHASSIS_POWER_LIMIT_MARGIN_W
    +float calculate_motor_model_power(float current, float rpm, float kt, float k1, float k2)
    +float solve_current_for_power(float target_power, float rpm, float kt, float k1, float k2, float original_current)
  }

  class PowerControl {
    -float k3_chassis_
    -float sum_error_
    -float sum_error_3508_
    -float sum_error_6020_
    -int motor_count_3508_
    -int motor_count_6020_
    -float motor_power_3508_*
    -float motor_power_6020_*
    -float speed_error_3508_*
    -float speed_error_6020_*
    +void OutputLimitOmni(float max_power)
    +void OutputLimitSwerve(float max_power)
  }

  PowerControl ..> MotorPowerModel : uses

Loading

Flow diagram for updated available power calculation in OutputLimitOmni and swerve path

flowchart TD
  A[Start power limiting] --> B[Input max_power]
  B --> C[Compute available_power = max_power - k3_chassis_ - CHASSIS_POWER_LIMIT_MARGIN_W]
  C --> D[Initialize required_power_3508_sum = 0, sum_error_3508 = 0]
  D --> E[Loop over 3508 motors]
  E --> F[Compute motor_power_3508 at index i via calculate_motor_model_power]
  F --> G{motor_power_3508 at index i > 0}
  G --> H[Accumulate required_power_3508_sum and sum_error_3508]
  G --> I[Do nothing for nonpositive power]
  H --> J[Next motor]
  I --> J[Next motor]
  J --> K[Similar loop for 6020 motors without subtracting negative power]
  K --> L[Use available_power and required sums to limit outputs]
  L --> M[End power limiting]

Loading

File-Level Changes

Change	Details	Files
Fix quadratic-solution logic when solving motor current from a target power to avoid using uninitialized or incorrect root values.	Use final_current instead of original_current for the degenerate (delta ≈ 0) quadratic case so the function’s output is always written through the same variable Defer sqrtf(delta) and root (x1/x2) computation until after confirming delta is non-negligible to avoid unnecessary work and keep scope local to the branch	PowerControl.hpp
Introduce an explicit chassis power limit margin constant and use it consistently in chassis power distribution calculations.	Add CHASSIS_POWER_LIMIT_MARGIN_W constant to define a fixed power headroom in watts for the chassis power limiter Replace hard-coded numeric margin (3.0f) in omni output limiting with CHASSIS_POWER_LIMIT_MARGIN_W Update swerve power limit logic to subtract both static losses and the margin while clamping available power to be non-negative using std::max	PowerControl.hpp
Simplify available power accounting by ignoring negative motor power contributions instead of adding them back into the available budget.	Remove decrements of available_power for motors with negative predicted power in both 3508 and 6020 motor loops, aligning available power with only positive consumption Keep error accumulation and positive power summation unchanged for both motor types	PowerControl.hpp

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• In OutputLimitOmni, available_power can still become negative while OutputLimitSteer explicitly clamps it with std::max(0.0f, ...); consider aligning the behavior between these two paths to avoid inconsistent handling of low power situations.
• Replacing the update of available_power for negative motor power in OutputLimitSteer (removing the else { available_power -= motor_power_XXXX; } blocks) changes the power balance logic; double-check whether you still want negative/regen power to effectively increase available power, and if not, document the new assumption in the power allocation scheme.
• The CHASSIS_POWER_LIMIT_MARGIN_W macro is a compile-time constant used in multiple places; consider converting it to a typed constexpr float to improve type safety and scoping.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `OutputLimitOmni`, `available_power` can still become negative while `OutputLimitSteer` explicitly clamps it with `std::max(0.0f, ...)`; consider aligning the behavior between these two paths to avoid inconsistent handling of low power situations.
- Replacing the update of `available_power` for negative motor power in `OutputLimitSteer` (removing the `else { available_power -= motor_power_XXXX; }` blocks) changes the power balance logic; double-check whether you still want negative/regen power to effectively increase available power, and if not, document the new assumption in the power allocation scheme.
- The `CHASSIS_POWER_LIMIT_MARGIN_W` macro is a compile-time constant used in multiple places; consider converting it to a typed `constexpr float` to improve type safety and scoping.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}