braincore / pid-rs Goto Github PK

Currently it panics if we don't use update_setpoint. Maybe it's easier, and semantically clearer if we just pass it to the construcor, just like kp,ki,kd. We can still change it later if we want.

I'm currently learning about control systems and wanted to implement a PID system as a starting project and found it was already done here. I used this project as a way to start to reimplement a new version of pid-rs privately to learn and figured that the API might as well be improved upstream to make it worthwhile :)

How interested would this project be with an API rewrite, looking something like this currently:

use pid::Controller;

let mut controller: Controller<f64> = Controller::basic(100.0).p(10.0, 2.5).i(666.0, None);
println!("Current controller: {:?}", controller);

loop {
    let output = controller.calc(2.75);
    println!("Output: {:?}", output);
}

Hi,

it would be great if you could add the category "no-std" (and maybe also "embedded") to the Cargo.toml file of your crate. Adding these categories would make it a lot easier to find for embedded developers on crates.io using filter by category. Right now, your crate is excluded from the filtered results despite being compatible.

It would look like this:

[package]
categories = ["no-std", "embedded"]

The current one is quite low-quality and doesn't work too well with GitHub dark mode:

In the library, the derivative term is computed that way in order to mitigate the derivative kick:

        // Mitigate derivative kick: Use the derivative of the measurement
        // rather than the derivative of the error.
        let d_unbounded = -match self.prev_measurement.as_ref() {
            Some(prev_measurement) => measurement - *prev_measurement,
            None => T::zero(),
        } * self.kd;
        self.prev_measurement = Some(measurement);
        let d = apply_limit(self.d_limit, d_unbounded);

Shouldn't you also divide by the period?

I'm new to control, so I could be wrong. ^_^
Here's my math to explain where this question is coming from.

Version 2.2 shares the major version number (2) with the previous version, 2.1. That means, as far as Cargo (which follows semantic versioning) is concerned, this is a compatible release that will be picked automatically on every cargo update, or for new builds where no Cargo.lock is present (even if Cargo.toml explicitly specifies pid = "2.1.0").

However, 2.2 is not a compatible release. The new argument to Pid::new is a breaking change, and I think this change will break every user of pid. This is not a problem for me personally, as I just use pid in an application that has a lock file checked into the repository and thus have full control over when I update. I wanted to make you aware of the problem though.

Thanks for your work on pid-rs!

Hello,

I've recently been using this library for some motor control. Thanks for your work!

For my own purposes, I added a simple linear feedforward term to the controller.

I also fixed a small bug with the term and output limits: giving a negative limit causes the term or output to be clamped to the limit value.

Would you be interested in pull requests for one or both of these items?

I'm just learning about PIDs and the implementations, as I might want to use it to control the temperature of my coffee machine. In that scenario a PWM signal would control the heater. So a negative output wouldn't be that useful here. I also imagine this would be true for many other applications. So isn't it quite limiting to have the limits always equidistant around 0? Of cause one can map the PID output from the "-limit to limit"-rang to the actual one but that doesn't seams that convenient.

I get the it is quiet intuitive to have positive output from increasing the input and negative for lowering it, but this seams also quite the special property for a system.

Is there some other reasoning for having the limits this way I missed?