Allow global scaling of PD terms in multicopters #26620
Conversation
|
This is a good idea!! Very much in line with the theory Mark Spatz (UAVTech) explains in this video: |
|
Why not also scale I term? If the goal is to make it easier to setup would it be better to have a scale param in the PID object itself so it works for all PID loops? |
@bnsgeyer only wanted PD |
|
@andyp1per the way this is currently implemented. It is multicopter only. I guess you are letting me implement it for heli?
The I term for heli’s is kept at a lower value and is not adjusted to be the same as the feedforward term. The I term is left at a small value to keep from causing roll over while on the ground. |
|
If the goal is to make it easy for users to setup then it probably should scale I term as well. Most users are not flying heli. Its still not 100% clear to me what the goal of this PR is? |
|
@IamPete1 the goal is having the ability to scale based off of some other condition whether it be rotor speed, airspeed, or density altitude. |
From scripting? Scripting can just as easily set two parameters as one. I think the benefit of only having to change one parameter is only really valid if its a user who is changing it manually. |
|
Happy to scale I as well if the current params are multicopter only. |
|
@IamPete1 i think having the hooks in the PID is good to haVe. I am not sure that I would make it a parameter available to users. @andyp1per what you are proposing would affect all vehicles that use the PID. You only added parameters to multicopter. I guess that is what I meant but my comment. But now that I think of it, I probably would not add the parameters. Just want to use the scaling feature in the PID object. I guess we could add another scaling function that did PID rather than just PD. |
| // boost output if required | ||
| P_out *= boost; | ||
| D_out *= boost; | ||
| // scale output if required |
There was a problem hiding this comment.
If this is a user exposed parameter should we consider adding protection against negative values or 0.
|
if this changes P on multicopters and allows for lowering P and doesn't lower I then I think that is extremely dangerous. If you set the scale to 0.5 then you could get massive phase lag from I |
|
I think we would need a thread in discord code_review channel to discuss, given we can't get all the key people on the same call |
|
This PR was motivated by developers wanting to make it easier for people to back off their gains to make an aircraft a little more stable during tuning. The normal approach is:
My position on this has always been that people should be able to do the last step without an additional parameter but I understand that many developers feel that this would make it easier for people to tune this last step with a parameter and also easier for us as developers to support if this was the case. The purpose of the Scale factor that Andy uses here is to allow a dynamic back off of the gains in known phases of flight where we expect to see oscillation or where we are turning a PID loop on in flight (quad plane). I intend to add a backoff for roll, pitch and yaw that will the oscillation on the ground before take-off. For non-feedforward based control like multirotors the scale should do PID. However, I am not sure about heli. Maybe that would be PIDFF, PD, IFF, not sure. To include these parameters that are fundamentally there only to save users from multiplying a couple numbers the consensus between developers needs to be a 100% slam dunk. I am not seeing anything close to that here. |
From discussion with @lthall and @bnsgeyer
This makes it easy to raise or lower gains in a proportional manner.