Skip to content

Auto-tuning: automatically find optimal PID parameters #13

@darioalessandro

Description

@darioalessandro

Problem

Tuning PID parameters (Kp, Ki, Kd) is the hardest part of using a PID controller. Users must manually adjust gains through trial and error, which is time-consuming and requires control theory expertise. Poorly tuned controllers lead to oscillation, slow response, or instability.

Pidgeon should be able to tune itself.

Proposal

Add an auto-tuning module to pidgeon that can automatically determine near-optimal PID parameters for a given system.

Phase 1: Relay Feedback Auto-Tuning (Classical)

The most proven and widely-used approach in industrial controllers (Siemens, Omron, ABB):

  1. Run a relay test — the controller forces controlled oscillations in the system
  2. Measure the ultimate gain and oscillation period from the response
  3. Apply Ziegler-Nichols or Cohen-Coon formulas to compute Kp, Ki, Kd

This is deterministic, well-understood, and works without a system model. It would fit naturally as a pure function:

pub fn auto_tune(oscillation_data: &[RelayTestSample]) -> Result<ControllerConfig, PidError>

Phase 2: Optimization-Based Tuning

Use optimization algorithms to search for gains that minimize a cost function (e.g., ISE, ITAE):

  • Particle Swarm Optimization (PSO) — simple, parallelizable, no gradients needed
  • Genetic Algorithms — evolutionary search over parameter space

These require a simulation loop or real system interaction, so the API would take a user-provided evaluation function:

pub fn optimize_gains<F>(evaluate: F, bounds: GainBounds) -> Result<ControllerConfig, PidError>
where F: Fn(&ControllerConfig) -> f64  // returns cost

Phase 3 (Future): Learning-Based Tuning

  • Reinforcement learning (e.g., PPO) to learn tuning policies across operating conditions
  • Gain scheduling — automatically switch between pre-tuned parameter sets based on system state
  • Neural network-based prediction of optimal gains from system characteristics

Design Considerations

  • Phase 1 should be no_std-compatible (pure math, no allocations needed)
  • Phases 2+ will require std (iterative optimization, closures)
  • Auto-tuning should produce a standard ControllerConfig — no special controller type needed
  • Should integrate with the existing debugging feature for telemetry during tuning runs

References

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions