For those new to fields like robotics or aerospace, it can seem at first glance that a problem like moving a robot arm or flying an RC airplane might be simple problems to solve. It turns out, however, that control of systems like these can get complicated quickly; so much so that these types of problems have spawned their own dedicated branch of engineering. As controls engineers delve into this field, one of their initial encounters with a control system is often with the PID controller, and this open source project delivers two of these general-purpose controllers in one box.
The dual-channel PID controller was originally meant as a humidity and temperature controller and was based on existing software for an ATmega328. But after years of tinkering, adding new features, and moving the controller to an ESP32 platform, [knifter] has essentially a brand new piece of software for this controller. Configuring the controller itself is done before the software is compiled, and it includes a GUI since one of the design goals of the project was ease-of-use. He’s used it to control humidity, temperature and CO2 levels in his own work at the University of Amsterdam, but imagines that it could see further use outside of his use cases in things like reflow ovens which need simple on/off control or for motors which can be controlled through an H-bridge.
The PID controller itself seems fairly robust, and includes a number of features that seasoned controls engineers would look for in their PID controllers. There are additionally some other open-source PID controllers to take a look at like this one built for an Arduino, and if you’re still looking for interesting use cases for these types of controllers one of our favorites is this PID controller built into a charcoal grill.
In case anyone is interested in a PID controller with a variable output signal rather than on/off:
https://github.com/LegacyNsfw/AvcsController/blob/master/Code/Controller/Feedback.cpp
There’s also a simple LCD UI for adjusting the gains.
It’s been managing the exhaust valve timing in my Subaru for about 15k miles.
Any OutputDrive, like a DAC, can easily be implemented in output.cpp. internal output is a double value and only in the specific Slow- or FastPWM converted to dutycycle. But I doubt it would currently be suitable for valve timings as the gui takes quite some processing from the same core as the PID loops. That requires more dedicated stuff.
From the look of things the PID loop could also be moved onto its own thread
Yes, indeed. I had already made an issue on the github page. But so far it does not seem necessary. I did have to move the SlowPWM code (which runs on CPU) to an additional thread though as that had too much jitter because of the GUI.
I think it would be usefull to thread it (on another core) when going (far) below 100ms timesteps maybe.
Thanks for the idea!
So, why are you adjusting the exhaust system on your Legacy, and what are the results after 6 years?
[2 Subaru household]
Some context first: My 05 Subaru Legacy came with variable intake valve timing, and a couple model years later they started making the STI with variable exhaust timing as well. And then my fuel pump got weak, the engine ran lean under boost, a ringland cracked, and over the next 1000 miles or so, ALL of the oil snuck out… I never noticed excessive smoke, so the first sign of trouble was a low oil pressure light, and it was time for a new motor.
So long as I was getting a new motor, might as well get them fancy new dual-AVCS heads like the 08 STI… And I was itching to do something more interesting than blinky lights with an Arduino. In theory that should enable a bit of additional power, but in practice I haven’t had it on a dyno to really find out. I just set the exhaust valve timing for what seems reasonable, and left it there while I tuned the other stuff. It runs strong, so I’m happy.
Funny thing is that after I was fully committed to this project (engine built and installed) I learned a lot more about valve timing. Enough to question the wisdom of the whole project. Intake valve timing matters a lot for performance. Exhaust valve timing matters too, but not as much. From a horsepower perspective, it probably wasn’t worth the trouble. But I learned a lot, and it’s kinda neat having an Arduino baked into my car now, so there’s that.
Just a small note: exhaust valve timing is very important in NA cars, as it gives you a good boost in cylinder scavenging when tuned and designed correctly. In turbo cars, it’s a lot less relevant. Even some intake valve parameters, like lift, are not so important. As an example, the modern Civic Type-R only has variable timing in the intake, and VTEC (which is variable lift and duration, more than timing) only in the exhaust, and they say its there to help with boost threshold, not for power (and for marketing, can’t have a honda sportscar without VTEC, even though there is no vtec-kick).
All this timing woes in turbo cars, like you see in many 2.0T german engines, is mainly for improved fuel efficiency at cruise/low load conditions. For power, turbos just shove air by force and don’t care about stuff like pressure pulses and resonances.
can we get a little more on managing your exhaust valve timing… is this just messing with the variable valve timing, and was there a intended improvement?
Ought to sell these, would be a handy benchtop thingie
It is developed for researchers on the University from taxpayers money. I’d like to give it back to the public as open source. I do not permit anyone else to sell this software. I won’t either ;) But thanks!
> I do not permit anyone else to sell this software.
That’s not what the license says
Yea… just casually scrolling through Knifter’s github, I see a dozen different license violations.
Relicensing the fork of humidity_regulator as GPL3.
Relicensing Arduino-PID-Library as GPL3.
Relicensing random vendor or forum code as GPL3 with no attribution.
etc, etc.
Not a very good look.
Sounds like something straight out of a university
If you had a look at the humidity_regulator repos: There is literally not a single line of code copied from them. But the idea itself came from them which I have contributed on several occasions.
I did not use (parts of) Arduino-PID anywhere. Can you elaborate? I use my own FPID repos which is loosely based on MiniPID (stated as well) but also completely build myself.
“Random vendor or forum code” leaves me searching for clues what you referring at.
Please, feel free to notify owners of said code of my mis-usage if you feel I’ve harmed them and Ill gladly sort out their complains with them.
Except that the entire code base was originally forked from a 3 clause BSD licensed project and released under 3 clause BSD until you decided to re-license it 5 months ago.
So any commit before 208E5C are still 3 clause BSD, however I have some doubt’s you contacted Sciunto to re-license his code as GPL3 which probably invalidates the license switch for all commits made after 208E5C.
Maybe I’m missing something but why is this a big deal — Most 3d Printer boards have 2 or 3 PID circuits to control termperature, is this doing something special that I missed. PID controller seems to me to be a quite common implementation on Arduinos and ESP32’s already.
Sorry about above — first time I read the brief it looked like this was something new, not just a very well done implemaentation of something most of us use at some point and frequently.
Am working on how to build a PID with the help of other engineers..
It is not new at all! Just an easy to use implementation with added features and common obtainable hardware and probably can be made without soldering and code modifications for some combinations of sensors/output drivers.