kanflo
Implement PID controller for power control
As mentioned in #17, a PID controller would be very useful to maintain output power while under load.
Thanks for this project!
This is an essential feature for me, so I'm beginning work on this at https://github.com/BasedOnTechnology/opendps
Hopefully in the coming weeks I can get my DPS running and tune the PID constants.
Out of curiosity, is there either a loop in this code that takes a completely repeatable amount of time, or a timer running somewhere that I can use? PIDs rely on a consistent timestep per cycle.
Great, looking forward to your PR! There is a 1ms systick timer you could use to eg. add an event to the application event queue every X ms.
I found a nice writeup by @dannyf00 about PID controllers the other day if you need inspiration. You could of course be a PID ninja in which case I bow respectfully ;)
@kanflo
Sorry to bother you again. DPS5020 issue was caused by my incompetence.
Voltage PID is in and working:
https://youtu.be/vhyeJkDaF4I
I also added a CC term to the PID to make the CC behavior replicate that of my lab PSUs; that is, decrease voltage when current limit hit:
https://www.youtube.com/watch?v=WdlEo2w7u9c
There's a lot of startup overshoot with the current PID tunings; I've had the overshoot down to about 100 millivolts, but I forgot what tuning parameters caused that :(
Currently, I just have the PID function called from the mainloop; I've tried to add it as an event, but... I can't figure out how. Could you give me a pointer on how that's done?
Secondly (sorry), could you explain how the command_handler function works? I'm hoping to be able to input new PID tuning values through a command...do I need "COMMANDLINE=1" set as a flag? If I set that flag, I get a "missing ui.h" error.
Thanks again!
Cool! For adding a new command, add an entry to commands[]containing the name of the command, the handler function and number of arguments and build with COMMANDLINE=1 which should build again.
@kanflo Huh, I didn't seem to get any response doing that. I tried sending a few of the other commands ("on", "off")with and without newlines and it didn't seem to parse it. Might be something at my end.
@0xDBFB7's branch wouldn't build for me for some weird reason, so I ended up implementing my own basic version of PID control, branched off the 10ae4b2 commit: https://github.com/tzarc/opendps/commits/pid_control
Not sure if it's any help, as I've only implemented it for CV, but perhaps it could be a reference for the proper implementation as well.
@tzarc Really sorry about that, I got super busy and didn't want to make pull request until I had the PID tunings perfect, since overshoot would kill target boards.
My branch has a few specific changes for my setup that probably prevented the build.
No problem; mine was hacked together relatively quickly so having a safer implementation is probably best!
Pushed to the following branch, based on current master: https://github.com/tzarc/opendps/tree/pid_v3
Only handling CV, don't have a way to test CC.
If we're cool with that, I'll make the PR.
Awesome, I was just looking into how best to implement this. How do the two DACs work on the DPS5005 to control voltage and current. Is it possible to set them to two different values and it will automatically switch between CV and CC modes?
EDIT: I've posted my findings here
Thinking about it do we need a voltage PID? There's already a feedback loop in the hardware and with correct calibration in #17 and with a fix for #7 we should be able to say for certain (giving a bit for calibration errors and temperature drift) what the output is.
With the calibration I don't see the mismatch between the output and what's on the display that started the discussion. Excluding the one caused by #7 which is not accounted for by the PID loop anyway. I feel like we may have come full circle here and that Manawyrm's comment was correct to start with