Timeline for Using a PID to control rotation
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S May 4, 2020 at 8:03 | history | suggested | Rodrigo de Azevedo |
Added tags.
|
|
| May 4, 2020 at 3:20 | review | Suggested edits | |||
| S May 4, 2020 at 8:03 | |||||
| S Mar 1, 2017 at 2:14 | history | suggested | DiaperHands | CC BY-SA 3.0 |
Update Hyperlinks
|
| Feb 28, 2017 at 19:36 | review | Suggested edits | |||
| S Mar 1, 2017 at 2:14 | |||||
| Feb 28, 2017 at 0:47 | vote | accept | Joel Graff | ||
| Feb 28, 2017 at 0:41 | comment | added | Joel Graff | I had initially assumed that, but I checked the original code and that's how the authors programmed it. I noticed they divided the output of their velocity PIDs by the acceleration due to gravity, but the angle PID computes the error using the euler angle as the current value. So it seems to me the intent was to take an angle for input and output an acceleration. | |
| Feb 27, 2017 at 20:50 | answer | added | pshlady | timeline score: 2 | |
| Feb 27, 2017 at 12:17 | comment | added | SF. | Note, if your input to PID is angle, your output will be target angular velocity, not target torque / angular acceleration. If you drive the torque with the output, you're doing DPD' (differential-proportional-differential 2nd degree) controller, not PID (proportional, integral, differential). To get the torque needed, you'll need to get the differential of your output, or pass it through another PID. | |
| Feb 26, 2017 at 22:18 | comment | added | joojaa | A PD controller behaves like a spring damper, which can be tuned not to overshoot. In this case it has to be atleast a PD controller or it will oscillate. However due to the nature of this problem i dont think a PID is at all apropriate some model based controller would be much better. | |
| Feb 26, 2017 at 22:01 | history | edited | Joel Graff | CC BY-SA 3.0 |
deleted 98 characters in body
|
| Feb 26, 2017 at 21:51 | comment | added | nibot | Does your d gain have the right sign? | |
| Feb 26, 2017 at 21:50 | comment | added | nibot | Could you embed the gif? I can't see it. | |
| Feb 26, 2017 at 21:35 | comment | added | Joel Graff | Anyway, as I've said, I'm pretty sure this isn't a tuning issue. A simple 1.0 P controller results in the behavior in the gif link I shared. Adding any I or D causes it to oscillate out of control. Adjusting the P up or down makes it oscillate faster or slower, but no more or less. I could be wrong, but this looks like a physics problem, not a PID tuning problem. | |
| Feb 26, 2017 at 21:34 | comment | added | Joel Graff | I updated to add a link to a gif that shows the drone oscillating, FWIW. (had to mutilate it a bit b/c I hit my 2-link limit), | |
| Feb 26, 2017 at 21:34 | history | edited | Joel Graff | CC BY-SA 3.0 |
added 124 characters in body
|
| Feb 26, 2017 at 21:32 | comment | added | Joel Graff | Using a genetic algorithm. I'm pretty sure it's not a tuning problem. The very nature of the PID is what's working against me. That is, so long as the PID hasn't reached it's set point, it continues to apply angular acceleration (in this case). So by the time it's reached it, it has applied way to much to be bale to correct quickly. In other words, it needs to reverse and start decreasing angular acceleration way before it reaches the set point. Much like trying to pilot a spaceship in a vaccuum. | |
| Feb 26, 2017 at 21:10 | comment | added | Gürkan Çetin | Apparently, You need to tune the control gains. I would Start with p, then d and finally I gains. There are wonderful answers at robotics stack exchange site, which also include external links to web sites for theoretical background. | |
| Feb 26, 2017 at 19:01 | comment | added | ericksonla | It sounds like it could very likely just be a tuning problem. How did you determine your constants? | |
| Feb 26, 2017 at 18:40 | review | First posts | |||
| Feb 27, 2017 at 6:58 | |||||
| Feb 26, 2017 at 18:36 | history | asked | Joel Graff | CC BY-SA 3.0 |