PID Tuning Guide!! - Stormworks
ฝัง
- เผยแพร่เมื่อ 25 ส.ค. 2024
- Join MrNJersey in this video where he looks at showing you how to tune a PID here in Stormworks!!!
Workshop Download Link: steamcommunity...
-----------------------------------------------------------------------------------
MrNJersey Gaming Offical Discord Server: / discord
MrNJersey Gaming Merch Store: teespring.com/...
MrNJersey Twitter: / mrnjersey
MrNJersey Patreon Page: / mrnjersey
Join this channel to get access to perks:
/ @mrnjersey
-----------------------------------------------------------------------------------
Workstation & Gaming PC: www.amazon.co....
Audio Setup: www.amazon.co....
Please note that links above are affiliate links -- clicking them earns me a small commission if you make a purchase and helps support my TH-cam channel. Thank you!
-----------------------------------------------------------------------------------
Video Audio: TH-cam Audio Library
#MrNJersey #Stormworks #Tutorial
Sorry, NJ. But there's a lot of inaccuracies in this video. Brace for the text wall:
5:10 - You shouldn't clamp the value while you're tuning the PID. Clamping is something you'd do after you're done, in order to mitigate unwanted effects, such as (for instance) the engine turning off when throttling down quickly. Clamping before tuning the PID will just make your tuning inaccurate, as the output will change for every situation that you tested before. In most cases you will NOT need a clamp to get the PID working the way you want it.
6:55 - You can actually just calculate the base P value beforehand by doing simple maths... (desired maximum output divided by the maximum difference between set point and variable). There's no need to guess the rough number, that just bad practice and a huge waste of time. And once you get your base number figured out in, you can fine-tune by decreasing or increasing the number. Starting with 0.1 is just bad advice, since that number depends on three variables above, these are >different for each application
Thank you
Estimating neutral stability point in proportional part of a PID is a part of few tuning procedures.
This control system has quite strong internal dampening due to insane drag in stormworks. which means you can have quite forceful response to small deviation in amplitude with no meaningful oscilations.
Give the Neerdery a rest will you.... this is a tutorial for beginners at this game. You have some valuable points but this is not science class. Relax.
@@EyeDentify Making tutorial means you are responsible for teaching people, especially if it is targeted at beginers. Here MrNJersey completely wrecks quite decent proportional controller by using PID wrong, poorly explains fragments of ZN method and makes some factual mistakes regarding controllers.
MrNJersey is considered Stormworks guru and should be held to very high standards regarding quality and factual correctness of his tutorials as well as other content he produces.
@@tymoteuszkazubski2755 you have a good point sir. But beginners are not Easily chew up that wall of text. That’s what I am getting. Just gonna confuse even more people. But it’s good info he is geeking out about.
My thoughts when i first saw the vid: "great now i have to tune my engines not just in real life but now in a game to" lol
You have to tune engine irl?
@@warrenhepburn9285if your a mechanic, yes if not then most likely no need
Correct title: "How to break perfectly fine proportional controller".
Most of overshooting in your control system could have been avoided if you used cascade controller, as in your current setu you are controlling second derivative of your control variable which means that when you have large errors the integrator winds up and can keep output saturated even after error crosses 0.
The best way to compensate for helicopters pitch and roll is to divide the collective by sin of value of vertical tilt sensor converted to radians. This lets the controller control vertical component of thrust.
A better way of controlling altitude would be to use PID+ (feed forward) to control vertical velocity and simple clamped proportional controller for altitude driving vertical velocity component. Feed forward is optional but can make PID's work easier.
Ok, now that but in detail please
@@crashstudi0s Essentially your collective doesnt control your altitude if you are tilted sideways. So you take the sin of your tilt, multiply that by your collective, and use that as the control variable input of your pid, so if you are tilted sideways it cans till keep you level.
The rest I dont quiet understand, as Im not familiar with pid tuning.
I heard you struggling to pronounce derivative, try it like this "der" "iv" "it" "iv" just pronounce those seperately and see if you can start putting some together. hope you see this
Edit: thanks for the like, all of them help NJ see it
This is amazing! This is exactly what I need to get my creations going. This will be especially useful for me in tuning engines for constant rpm and for self leveling on boats.
I guess I got the notification 31 minutes late
Thank you by the way pids are a struggle for me
Linking the microcontroller on the workshop would be helpful.
Yeah I was just about to say the same
It did on his video about the modular engine car tutorial
This would be an awesome add to engine rooms on ships and other vehicles. Awesome video, thanks for the work.
ships dont have an altitude requirement as they cant fly lol
@@adamtaz6 not with that attidude!
Im new to stormworks and all your tutorial's have been really useful thankyou :)
Best game ever, thanks a ton for your videos.
Great video and a great tool to tune PIDs. One thing: The I-Term is not used to make the system react quicker, it is there to remove steady state errors. Imagine a jet engine controlled by a PID. With P-term alone it would never reach its set RPS, because the throttle output would be 0 if the RPS reach the setpoint. The I-term integrates (adds up) the error for each calculation cycle, so it gets bigger and bigger as long as there is a remaining error. Once the RPS reaches the setpoint, the I-term stays at its value. Or if RPS overshoot the setpoint, it gets smaller again. The I-term in Stormworks is difficult to use, because there is no I-term limit implemented. This has destroyed systems in real life. In Stormworks it may lead to unwanted behaviour, if the PID is active before there is something to control. The I-term will wind up and make it impossible for the PID controller to work.
Your comment just saved PIDs for me. That's what I was missing. Up until now I decided to only use P-controllers for my creations, and thanks to you I got an idea on how to fix the I-controller.
I know that this video is quite old, but I found it just now and maybe someone would benefit from my comment later:
Basically, I would make a custom controller with 2 or 3 PIDs (for PI and PID controllers) and use a separate PID-block for each part.
First PID-block will have only P coef., and I/D will be set to 0 and so on.
You can than limit the I-controller value in two ways.
Set the Setpoint on the PID-block itself to 0. The process variable of the PID-block will be its regulator.
To get the base value you should substract the actual setpoint from actual process variable, thus inputting the actual error in the PID-block.
The first limiting factor will be to clamp the error to a certain range, so the actual I coefficient can be high enough for the PID to be responsive at low errors (2-4% around the setpoint), yet it won't reach it's max value right away, when the error is high (50-80% of the setpoint) and most of the work is done by P-controller anyway. Now we have limited how fast the I-controller can be saturated.
The second limiting factor will deal with the max and min values for the PID-block output. The way I achived this is by making 3 different clamps for the Process variable. Let's say we limited it to "20" in the first method.Then the clamps would be: (20, -20) (0, -20) and (20,0).
When the PID is within its limits, the regular (20, -20) clamp is used for fine-tuning the output. When the PID-block's value reached the limit value, the "greater than" block will trigger a switchbox to change the clamp to (20, 0). Thus the I-controller will not increase its output when the error stays below 0, but once the error has changed its value above 0, it will not be clamped and I-controller will begin to work again.
@@64nvm
You found a clever way to do it with standard parts.
For me it was easier to write a PID controller in Lua. I tried to include every feature I could think of, like feedforward, seperate min/max limits for the I-term, Kpid, output clamp and selectable base/weighting for the D term (error, PV).
I think I would explain it slightly differently.
Yes, you start with the P term. In your case, it seems that the P term was doing all right pretty early. It simply says how to respond to differences between set point and measurement.
In your example you had a throttle of range 0-1 that was to control an altitude. Let's for argument sake say that a 0.15 thrust was required for steady hover. The thing is that with a P term of 0.1, you would need to stay 1.5 meter below the desired altitude in order for the P term to yield the required 0.15 thrust.
That may sound totally acceptable. But then let's consider a winching operation where a 0.8 thrust was required in order to maintain an altitude (or moving the helicopter forward). In order to make a yield of 0.8 to happen with a P term of 0.1, you'd need to stay 8 meters below the desired altitude. That is obviously not desirable.
Think of the P term as a RUBBER BAND. It is useful, yes, but insufficient.
The 1.5 meters and 8 meters mentioned above are called steady state errors. In order to eliminate these, we have the I term. This term will consider your measurement error over time and apply a correction. Let us consider the P term of 0.1 and set point of 45 meters and the helicopter altitude at 43.5. The P term would be yielding 0.15 thrust, which would make the helicopter hover in place, but still below the desired altitude. Now let us consider an I term of 0.01. This would take the 1.5 meter correction and decide to add a 0.015 correction. Let's for simplicity sake say that this didn't affect the helicopter at all, but at the the next "tick" it will add ANOTHER 0.015, increasing it to 0.030. This will continue happening as long as the helicopter stays under the set point. If the helicopter comes above 45, it will subtract a small amount. This will go on and on until the helicopter rests at the 45 meters. The error will be zero, causing the P term to yield 0, but the I term will stay steady at 0.15, not subtracting or adding anything.
This sounds perfect, but there is a problem. If you are at ground level and set an altitude of 45, then the P term at 0.1 will yield 4.5 (which is more than max throttle). The I term at 0.01 will every single tick add 0.45, quickly accummulating up well above 20, especially if it is a heavy helicopter, and this will will not start to drop until the helicopter is above 45 meters. We have an "Integral wind up" causing an overshoot.
It would be even worse if the "hold altitude" was active but the engine switched off. The I term can accummulate into the thousands rendering the controller totally useless until it has spent sufficient time above the set altitude to "bleed out" the accumulated value. Therefore it is important that the controller is only active when there is a connection between the PID output (throttle) and the process variable (altitude). More advanced controllers have clamps on the accummulator to avoid this effect.
But for a normal scenario, a helicopter starting at ground level with a desired altitude of 45 meters will start heading for it very fast. The P value is contributing and the I value is accummulating and growing bigger and bigger since the I accummulator is increasing and increasing. The final ingredient is the D term. This is the brake. It your altitude was 15 meters and the next tick is measured at 15.2, then this says that the current rate of change is 0.2 meters for every tick. This is pretty fast. So the D term set to 0.01 will decide to reduce the throttle by 0.002 just because you are rising.
All these effects adding together: P (the rubber band) + I (the running accountancy of all previous errors) + D (the rate-of-change brake) will hopefully yield a sensible value of 0-1 for throttle.
This machine helped me alot. Its way easier and faster to stabilize a pid. I wouldnt get my vehicle to fly today if it wasnt for this.
Ahem.
P is for causing a reaction based on the error.
D is for dampening the overshoots: if you are already going in the direction that reduces the error, you need to react less than if you are going the other way.
I is to remove residual errors. Imagine your helicopter is set to 250m height. Your heli goes to 230m, the error of 20m does not give enough via P to get to 250m, it is just enough for 230m ... With I the residual error accumulates. As you go -20, -20, -20, -20, -20, these errors add up and I increases, pushing the helicopter to reach 250m... and it will keep it around there, even if you take on more load or drop the same.
Sooo this guide is best bcs it helps me to tune pid in my irl 3d printer
Very helpful. I’m still a baby at things like heli because of this thing. I like the RD but sometimes I just don’t have time to understand it fully. Thanks for the visual representation and explanation
For giving the heli more power when moving forward, you could set up some logic that automatically changes the max for the pid while it is moving forward
Man, that's what i searched for 2 years! You're good!
very useful. I love things like this.
can we have the link for the LUA screen and microcontroller
yh
In the description :)
@@MrNJersey thaaaaaaaanks :)
I don't even own the game yet but these videos are great!
your tutorials are so helpful to me.
I don't follow them, and most of the time the thing I am trying to do isn't even the thing in the tutorial I have playing, but somehow just having ur videos playing as background noise makes me better at figuring out how to achieve something within microcontrollers.
IDK if its a placebo effect or smt but if it works, it works, and I won't complain
I wish I had learned PIDs when I was much newer in the game. I STILL haven't used one I didn't download but this video gives me such a better understanding I'll have a go at it
Oooh man!
Thank you so much!
This would be very helpful to get from the workshop
The nature of a PID is, that when setpoint and input-value are the same (for a long time) the output is zero. That's not what the collective of the helicopter should be to hold the altitude. So you cannot reach the exact altitude with this kind of pid-construction. For the altitude autopilot of a helicopter it's not the problem, because the error is only a couple of cm but for other systems this wouldn't work this way.
This controller/display setup is perfect for a PID I'm trying to get working right for a diesel-electric engine manager (which adjusts throttle based on battery charge decay rate.) Looking forward to tinkering with it!
I was trying to do diesel electric as well, but it's been hard for me to get higher efficiency than I would just diesel. Are you seeing the same issue?
@@orrinbare I've only done a few tests with awful PID numbers so it hasn't really been a good indication. I'm using a large engine with a large generator and electric motor, so I dunno how the math works out for that setup.
@@orrinbareit’s impossible to get higher efficiency with two transformations of energy instead of one.
How is using a bigger engine at reduced pitch authority a better solution than tuning the PID better? Also, quite sure that the explanation for the integral is not right. As i understand it, the I part of the controller looks at the error between the setpoint and the variable and accumulates it in order to get it to zero. This can go very wrong very quickly, as any jump in the setpoint or in the variable will run up the I result. That is why we usually have very low factors for I, otherwise it will screw things up. Most creations should be ok without any I factor, as long as a small constant error (like a slightly incorrect altitude) does not matter.
"The goal of tuning the integral value, is to achieve an adequate controller response or reaction time (after the initial response from the proportional is set)."
@@MrNJersey "An integral term increases action in relation not only to the error but also the time for which it has persisted. So, if the applied force is not enough to bring the error to zero, this force will be increased as time passes. A pure "I" controller could bring the error to zero, but it would be both slow reacting at the start (because the action would be small at the beginning, needing time to get significant) and brutal (the action increases as long as the error is positive, even if the error has started to approach zero). "
Think of the PID values more as the actual mathematical value that they represent, rather than what they do when you adjust them. The proportional number represents a multiplier of the "current" (present) distance between the setpoint and variable. The integral number reperesents a multiplier of the "past" error, since integrals in mathematics are accumulator functions. The derivative number is a number that multiplies the value of the derivative of the current error, or where the error will be in the "future". These three values are then added together, resulting in the output of the PID.
I agree that the explanation of `I`/Integral is incorrect, or at least not explained propperly
To my knowledge of Integral, it's very good at getting from being always slightly off from the setpoint, to being at the setpoint
It increases or decreases slowly, it may be faster or slower depending how large the error is
I could be wrong, but that is my understanding, though note that I have reimplemented a PID in Lua as I am working on my own tools for tuning
As an extra note, I don't use `I` often due to Integral windup which can be a big issue when it takes a long time to get to the setpoint, like a slow rising heli
THE D VALUE
Jet Engine: BRRRRRRRRRRRRR .........BRRRRRRRRRRRRRRRRR..... BRRRRRRRRRRRRRRRRRRR
Def need this. Thanks!
i don't use PIDs anymore, the one big reason for that is that you can't give them min or max limits. sure you could clamp the output, but if you had a long drive with your boat on full power and want to stop, the pid has to come down from a huge value and instead of stopping you continue 5 more minutes with full throttle...
instead i use functions that feed themselfs back, if you want a pid in a function block and the function can be clamped. since i switched to function, i use one and the same rps controller for jets, engines and motors on all rps ranges without configuring one single value.
This is called integral windup, also known as saturation. It's a common issue with PIDs not just in Stormworks, but also in the real world. You can prevent this by setting the integral number to zero when the system starts "saturating" using an advanced PID and some clever logic to switch the integral value to zero if it goes beyond a certain number.
If you want a function like that I always just use a function block and subtract the actual reading from the requested reading. It works great!
@@themystic6604 i don't know how they did it, but i never experienced an integral windup in the game From The Depth. I think there is a solution, even if we both don't know it.
@@Adesterr I am unsure about what exactly FTD does, but my guess would be that it limits the integral value, or some other change to how the `I` in PID works
It is not that uncommon for these changes, but you'd need to reimplement a PID in Lua for them
Another thing for FTD is that the setpoint does not change much usually and so integral windup can be much less noticable
And I wud love if it wud be on the worship!
Connect the clamp to a tilt sensor if it’s above a servers degree increase max clamp
I basically made a PID without knowing it. I made a cruise control system on my vehicle and it behaves very similar to a PID.
please post to the workshop. This is soo helpful (Just like all these tutorial/guide videos of yours)! Thanks for the great content!
Big Brain math moment.
Nice video! 👌
Mr. NJ you legend (:
YEEEEEES!
This graph is actually a life saver. Is it on the workshop?
Description
i have the variable hooked up to a tilt sensor and the graph isn't showing anything, the blue line is just flat
That's the best in Stormworks.. its more than just a game...
I think you might have I and D mixed up. I might be mixed up.
D-E-R-I-V-A-T-I-V-E
Hey!
What changes should I make to the system if I have a linear track based sliding weight in the bottom of my big ship?
That doesn't work the same as a helicopter...
im trying to use a pid on my modular engine to set my throttle setting to the rps i want but i cant get it to work
THANK YOU SO MUCH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
hi
Cool.
How you do tune it for ballast where the setpoint is to be zero at all time???
How to click more than one time on 'like' ? ;-)
Finaly
Will please make an updated (1.0+) medium ship gyro configuration tutorial? 🙏 Please. I can't sent u my problem ship if need
Thats cool and all but this tells me nothing of how to tune it for a ship. I understand how it works technically, but it still makes no sense to me at all and it just pure guessing. The pid seems to just do what it wants relative to the inputs I give it. I've built plenty of ships with the a pid and rail stabilizer that are very steady from setting them 10-0-10000, hull design and randomly changing the amount of weight. I've come to about my 7th ship and it will not for the life of me sit still.
yay ^v^
my alt hold and hdg hold and att hold is made with tilt and compass and altimeter sensors then set point, the amount of difference with the set point is the source for controlling the potential direction. i would never trust a pid controller doing that.
So you have a P controller?
@@advorak8529 matheatic ones , difference of the set number is 12 or -5 then divide by 10 or more example then you have a rock solid p. Altough alt hold needs some offset. How heavyer how larger the error. But it more stable than the ingame pid
@@stefanie_m466 So ... basically, you have read one of the rough guidances for how to set P and think it is the one True Way.
(Not "p", btw, that is probability, as in p < 0.05.)
Altitude hold does not need an offset, it needs I --- this is the residual error I is *meant* to correct. And it will adapt even if you change the load on the fly.
@@advorak8529 i have been reading nothing, my game is own-made. own solutions with what I know. because I solve my problems alone.
@@stefanie_m466 If it is a single player game, you cannot do worse than cheat yourself out of fun. Play however you have fun!
reeeeeeee
3d
First time
Wud
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDD
I got banned for your server, can you unban me?
Low point in NJ's vids. Remember, man can't pronounce 'DER-IV-AT-IV' man can't explain PIDs worth a crap.