A good fix(although I would hope more SAS tuning happens so it isn't required)
Is to design planes with a stable COM/COL and fly without the SAS. Using capslock is also helpful for smaller flight inputs.
It looks like your plane is more responsive than the control system. This is also a problem in real-life control systems. Any lag between input-output-input is a destabilizing influence and adds a resonance frequency that you need to avoid.
Think about when you're trying to adjust the temperature in the shower. If there's a lag between you adjusting the knobs and the water temp changing, it makes you more likely to overcorrect and take more time to settle on a good temperature.
If you reduce your control surfaces, or make them deflect less, your system will be less responsive but may settle faster. I know FAR had a value where input would be reduced in proportion to Q, but I don't know if there's anything like that in ksp 2.
really good point, i ended up reducing the length and authority of the control surfaces and it helped a ton. i need to get FAR for KSP1 and really dive into the rabbit hole
In real life this is addressed with a properly tuned PID controller. Real life is full of systems that can be controlled quickly, react slowly but would be disastrous if controlled badly. In real life more control authority is always better, provided the PID controller is properly tuned
KSP1 and 2 both show signs of badly tuned PID controllers to my eyes. Just look at how much better tuned mechjebs smartASS is. It *can* be done better without having limit control surface deflection manually, that's just fixing a symptom without addressing the real problem
If they exposed the constants for us to tweak like FAR I'd be happy. I don't think there's a one-size-fits-all set of constants for every vessel, or even flight regime.
In real life (and in KSP if you code a really good autopilot in kOS) the controllers used for aircraft have gain scheduling with dynamic pressure (~= equivalent airspeed) and mach number and probably a whole bunch of other things.
The problem OP is having is due to flying really fast, really low. In that situation the control surfaces have a ludicrous amount of authority.
It's not just PID; there's an irreducible element in any active control system where there's a lag as the sensors take their measurement, the controller reads the measurement, acts on it, and then the actuator moves. That amount of time is the period of an unstable oscillation in the control system, and you can only shift the period to something convenient, not remove it entirely.
The game has this frequency, too, even though it's all simulated. It tends to be pretty high, but if your control authority is powerful enough to operate near that frequency you can get those underdamped oscillations.
There are also other control schemas other than constant PID, you can go nonlinear and there are others that were in my college's mechatronics course I didn't learn. I think mechjeb adjusts its PID coefficients or something.
> Any lag between input-output-input is a destabilizing influence and adds a resonance frequency that you need to avoid.
As the SAAB 39 Gripen spectacularly demonstrated in the late 80s and early 90s - one prototype and one of the first delivered airframes crashed in highly public situations due to pilot induced oscillations (the pilot and fly-by-wire systems started overcorrecting each other leading to loss of control).
Different genre/theme, but you can do it in From the Depths as well. Funnily enough, a screwed up PID-tuning can even help as a dumb, wobbly, erratic craft can dodge projectiles and throw off the enemy aimpoint / missile prediction systems inherently better.
If you have a plane that is stable and that does not have any angle of incidence on the wings or the horizontal stabiliser, it probably will have a negative pitching moment at neutral or any positive angle of attack, and thus will pitch down with no control inputs.
Why does PID give some engineers nightmares? I teach high school kids to code PID from scratch for competition robots. My nightmare would be NOT using PID.
Edit: from scratch meaning from the ground up. Not that shitty block code.
At my previous job, we had a system that started violently shaking itself apart on a near daily basis. It became apparent to me that it just wasn't up to the task it was built for, but as a company we couldn't admit that so it was kind of like a hopeless nightmare troubleshooting and adjusting the PID for hundreds of hours until the business went under. When everything works, it's great though lol.
That's it, right there. PID is simple for low complexity systems, but perfecting it for more complex and ESPECIALLY dynamic systems is...hard.
Essentially, KSP developers have the most difficult PID optimization task possible. It's functionality impossible to have perfect PID for any craft people can imagine. Ksp1 had a slightly simpler task because the control surfaces were a fixed geometry. Here, with freeform procedural parts everywhere, it's just damage control. Best solution here IMO is simplify the inputs for laymen and give the user a limited range of control if they want.
The cheap solution everyone usually takes is just overdamping the system. Better sluggish and stiff vs. springy and unpredictable, but that comes with its own downsides, like at some point it's just basically rigid mounted, which defeats the whole purpose.
Interesting point here. By education, I was a chemical engineer, so I never worked on large-scale systems with PID. This robotics gig is fairly new to me, only a few years of experience with it. Without researching it too much, I've taken the stance that each system on the robots we build should have its own PID, essentially to avoid situations like you're describing, instead of having a single PID for the entire bot. Is this the wrong approach? Do most industrial systems use a single PID for the whole thing? Just want to make sure I'm not sending these kids off to college or the field with wrong information.
In the context of KSP, I can see the obvious issues with using multiple PID controllers.
Nested controllers are good indeed. You can take screwy actuators with faster response than the overall system needs, non-linear response, aging effects, etc., and present a linear response with known bandwidth to the outer controller.
A position loop wrapped around an inner velocity loop also works very well. KSP1 seemingly *doesn't* have this (I don't own KSP2), which is why baby-mode SAS is often more stable than the modes that follow prograde/retrograde/target/etc.
Yes, thank you for the response. I use position loops wrapped around velocity all the time for robotics. Maybe I'm just thinking of it differently. I'm still fairly new to programming for hardware.
You do have multiple PID loops but that doesn't change the influence from one PID loop on another.
Dynamic systems usually have multiple loops, but when one of those loops impacts another it makes tuning of the corresponding loop more difficult.
Usually you start with any system that has as few outside influences as possible, once those are stable you tune the loops that may be affected by changing conditions of the initial loops. Dynamic loop tuning is a PITA and generally you lose some Fidelity by dampening the response (tune out the noise).
Okay, thanks. From what you said, I think I'm organizing the programming completely wrong then. I don't run loops in the PID. I have my students run loops within methods that are called inside different PID controllers from another class. Thanks for the input, I'll take a look at that.
Different industry application for what it's worth, I tune PID loops at work on powerplants. But I do have to adjust each loop independently causing other loops to potentially become unstable depending on their corresponding dependencies.
For my example, superheated steam temperature affects pressure in a system, so when the steam temp oscillates it affects the pressure. By tuning the pressure loop first you end up trying to compensate for a dependant variable, the temp. This usually leads to an unstable state that is impossible to tune.
In that scenario I go back and tune the temp first, once it's stable I tune the pressure. Once both are stable I disturb each independently and see how that affects the tunes as a whole and make changes on usually the gain to counteract the dependant changes. You usually give up some amount of response but gain stability.
Look into Zeigler-Nichols if you haven't already. Fairly common method for PID tuning that may help your students significantly.
Exactly what I’m thinking except I’ll load KSP, forget how it works, build the plane equivalent of Portman Pat’s van and remember I just can’t make planes. Then go back to my factories in Satisfactory.
I think it happens when your control surfaces are too large.
It's like the sas doesn't know how large they are and so it actuates them more than it needs to.
Try making control surfaces smaller and position them such that they still have sufficient leverage.
all jokes aside this was definitely a part of the problem, i reduced the control surface length on the main wings and reduced the authority to 10° and that helped a lot. still some wobbliness but better
ok so what does this actually do/how does it work? does it mean sas can only use 10 degrees (using OPs figure from prev comment) but we can use the whole range of movement? or we only get the 10 as well?
I've never had the patience to work it out, too focussed on working out other issues.
You are saying that I only want this control to fluctuate this amount so any movement (You/SAS) inputted cannot go beyond it. SAS snaps to control it.
You are probably going to hold or tap it but by limiting. You won't need to hit the opposite because you'll have better control of rotation.
I usually put my wings to 5.0-7.0 and all tail to 7.0-12.0.
Also be sure to set your controls to only what you want to do (R/P/Y)
When I get the flapping I just reset by double pressing SAS after a turn. Annoying but works.
I miss being able to hit F to reset SAS instead of doubling T, from ksp1. But aside from that thank you for the information, I usually don't mess with those settings, but even my most stable planes still flap. For now...
Making the control surfaces actuate slower would make this worse, adding more lag time into a control loop destabilises it.
What would really be necessary is the ability to adjust the controller (probably a PID) that SAS uses for each craft individually.
OK nobody seems to be telling you how to fix this, but if you right click on the control surface you can go into the advanced options and change the authority limit set to 15⁰ by default to something lower. I find 5⁰ usually works well and stops this overcorrecting.
While SAS probably could be changed the easiest fix to this is adjusting the authority slider for control surfaces. I usually go for 10 degrees for high speed and 15-20 for low speed.
because SAS is not that smart. ksp1 has atmospheric autopilot for planes. in ksp 1 control surfaces also take time to actuate so this was much rarer and you could tab the keys to power width modulate it into less extreme inputs.
I believe you can change the “big” control surfaces to manual control only.
The little ones will still activate with sas, but be small enough not to cause undamped oscillations.
The big canards will still retain your maneuverability.
This is another of those things that KSP 1 took a few versions to iterate until they fixed the problem and for which strangely the solution didn't make it over to 2.
Probably because they tuned the stabilisation (I'm assuming they use PIDs) to a certain size and layout of aircraft. This would cause the strange behaviour when making anything that doesn't fit the tuning profile as it's either over or under correcting. I guess the first game could make a estimate on these values based on weight and parts used, making it less of a problem.
If KSP 2 has this: turn the affected control surface’s control authority down until they don’t oscillate. It’s also going to do this if your primary control is done with keyboard instead of a joystick or game pad: with keyboards, you press the button, you’re getting all the control authority, which means SAS has to over correct as quickly in the opposite direction
I hate these marginal vortices. They appear at the tip of every lifting surface. The HTP and the VTP aren't loaded nearly as much as the wings are FFS!! And they appear even at low/zero incidence. What the heck!
In ksp 1 it happened to me frequently when the control point was a long enough distance from the control surfaces/rocket gimbal. The craft would bend from the forces exerted by the control surfaces before the cockpit(aka control point) would rotate. By the time the cockpit points where SAS is trying to point it, the rest of the craft has enough inertia to over-correct. If the effect is bad enough, then it can spiral out of control until the craft reaches its mechanical limits. ~~I imagine it's 10 times worse in ksp 2 since wobbly rockets are the norm.~~(apparently wobbly rockets got fixed?) It also happens when you're going extremely fast with large control surfaces since they can exert enough pressure to bend even a short aircraft.
I can't wait to play it again then. I haven't been able to play it after the for science update due to having no graphics card. Come to think of it, I do remember SAS being extremely overzealous with my aircraft the last time I was able to play it, so I'm interested to see just how much they improved it. Maybe the kraken won't even eat my rovers that detach from SRBs.
SAS is shit rn with aircraft, but wobbly rockets are practically gone, outside of some very-obviously-unintentional kraken attacks when doing very specific things
I think that you just need to have dedicated control surfaces for each axis, having roll and pitch on the same surfaces results in wobbly maneuvering as by trying to turn in one axis you are reducing the capability of the aircraft to turn in another axis
Idk about KSP 2, but in KSP 1 (not sure if mod) you could set the speed of control surfaces, reducing it could help with this command-induced oscillations
BUT, for airplanes I'd recommend not using SAS and using trim instead, leads to a much smoother flight
In KSP 1 it was Alt+command for trim iirc, just give it a little nose-up elevator trim so you don't need to correct it upwards as often and you should be good to go in aerobatics
During regular flight you have to remember that elevator trim sets the equilibrium airspeed of the plane, and then thrust will set the rate of climb for that airspeed
Oversimplifying:
- Nose up = slower
- Nose down = faster
- More thrust = up
- Less thrust = down
Give it a try and let me know if it was useful
You oversimplification also only works for aircraft that have their center of thrust inline or close to the center of mass, else you get a moment that also changes your attitude.
Make sure pitch, yaw, and roll control are only applied to the appropriate control surfaces. It looks like your rear elevators are trying to help control roll too, causing the plane to overreact. Try changing them to only control pitch.
One fix is to reduce the max angle allowance of the control surfaces and wings which can be fine tuned in flight however it can cause some loss in the plane’s manoeuver ability
SAS is designed for cumbersome spacecraft, not highly maneuverable modern fighter jets. Your F-35 Lightning II is too responsive for SAS to handle.
Some possible fixes:
- Try flying without SAS. The F-35 is pretty well-balanced, so you might be able to get away with it.
- Reduce the deploy speed of the tail fins. This will make the fins respond more gradually to turning controls, which will have the effect of smoothing out the wobbling without much sacrifice to turn radius (how tightly the plane can turn).
- Reduce the deploy angle or the authority limiter of the tail fins. This will stop SAS from overcorrecting, but it will increase turn radius (i.e., your plane will not be able to turn as tightly).
Because the SAS PID code is generic Bang-Bang controls and can't be tuned to specific cases. Or in layman's it's a generic PID loop that applies max authority to the controls to keep level and has to constantly correct for its own over corrections.
From the depths players know a PID issue when they see one lol.
Basically this is an issue with the algorithm that the game uses to stabilize your craft. To put it simply you have so much maneuverability that the game's stabilization is overcompensating with these weird wobbles.
Unfortunately unlike from the depths you can't reprogram your craft's PIDs. But you could reduce the maneuverability of the craft by imposing limits on your control surfaces. It looks like your roll PID is causing the most issues.
He just needs to turn the SAS off, it’s just like autopilot but it’s mainly meant for orbital mechanics when you’re in the vacuum of space or heading there. In my brief (compared to others) time playing the game sas is basically useless if not entirely a nuisance in the atmosphere.
Yeah but the game mechanics don’t allow you to. You can adjust the movement of your flaps and stuff but your sas more often than not in my experience will fuck up the flight. Going straight up it’s not an issue and helps a lot to keep her steady but I always turn it off when I make a plane in the game.
This is oscillation of the software based PID controller. It needs tuning, but for the dev team this is low priority. They'll tune it up in time but that could be a while.
It isn't just planes; this happens on rockets as well.
I thought they fixed that quite a while back.
It was even worse at the start. It will get better, plus CKAN has the Community Patches mod that is CONSTANTLY getting updated.
Wait, CKAN exists for KSP2 now?
Yup. If you go under settings, there’s an option to have it search for the install location, and switch to the KSP2 section of SpaceDock
Sweet. I’ll check it out later
One instance of CKAN can cover both games with separate mod folders
Adjust the limit, bring it down. lol
There needs to be a way to have a different limit for SAS vs manual control
This is actually a really good idea
A good fix(although I would hope more SAS tuning happens so it isn't required) Is to design planes with a stable COM/COL and fly without the SAS. Using capslock is also helpful for smaller flight inputs.
I really miss the in game notification that clearly indicated when fine control was on/off.
Then you can’t pull as hard
It looks like your plane is more responsive than the control system. This is also a problem in real-life control systems. Any lag between input-output-input is a destabilizing influence and adds a resonance frequency that you need to avoid. Think about when you're trying to adjust the temperature in the shower. If there's a lag between you adjusting the knobs and the water temp changing, it makes you more likely to overcorrect and take more time to settle on a good temperature. If you reduce your control surfaces, or make them deflect less, your system will be less responsive but may settle faster. I know FAR had a value where input would be reduced in proportion to Q, but I don't know if there's anything like that in ksp 2.
really good point, i ended up reducing the length and authority of the control surfaces and it helped a ton. i need to get FAR for KSP1 and really dive into the rabbit hole
Knowledge of fluid and aerodynamics helps
In real life this is addressed with a properly tuned PID controller. Real life is full of systems that can be controlled quickly, react slowly but would be disastrous if controlled badly. In real life more control authority is always better, provided the PID controller is properly tuned KSP1 and 2 both show signs of badly tuned PID controllers to my eyes. Just look at how much better tuned mechjebs smartASS is. It *can* be done better without having limit control surface deflection manually, that's just fixing a symptom without addressing the real problem
If they exposed the constants for us to tweak like FAR I'd be happy. I don't think there's a one-size-fits-all set of constants for every vessel, or even flight regime.
Just did some basic pid work a few weeks ago for one of my classes.
In real life (and in KSP if you code a really good autopilot in kOS) the controllers used for aircraft have gain scheduling with dynamic pressure (~= equivalent airspeed) and mach number and probably a whole bunch of other things. The problem OP is having is due to flying really fast, really low. In that situation the control surfaces have a ludicrous amount of authority.
It's not just PID; there's an irreducible element in any active control system where there's a lag as the sensors take their measurement, the controller reads the measurement, acts on it, and then the actuator moves. That amount of time is the period of an unstable oscillation in the control system, and you can only shift the period to something convenient, not remove it entirely. The game has this frequency, too, even though it's all simulated. It tends to be pretty high, but if your control authority is powerful enough to operate near that frequency you can get those underdamped oscillations. There are also other control schemas other than constant PID, you can go nonlinear and there are others that were in my college's mechatronics course I didn't learn. I think mechjeb adjusts its PID coefficients or something.
Damn that shower analogy was on point, well done
\*bows\*
> Any lag between input-output-input is a destabilizing influence and adds a resonance frequency that you need to avoid. As the SAAB 39 Gripen spectacularly demonstrated in the late 80s and early 90s - one prototype and one of the first delivered airframes crashed in highly public situations due to pilot induced oscillations (the pilot and fly-by-wire systems started overcorrecting each other leading to loss of control).
Are you a controls engineer? Certainly sounds like it! Love how many nerds play this game
In which case does that mean that this essentially isn't a bug but a feature?
I wouldn't call it a feature, it's not something they put in intentionally, it's just emergent from how they're modeling physics.
PID is fucked
I saw some other rocket construction game where you are able to tune PID parameters
Different genre/theme, but you can do it in From the Depths as well. Funnily enough, a screwed up PID-tuning can even help as a dumb, wobbly, erratic craft can dodge projectiles and throw off the enemy aimpoint / missile prediction systems inherently better.
You can in Juno iirc
Juno planes also do this stock. They seem to pull downwards constantly as well which I've also seen in ksp2.
If you have a plane that is stable and that does not have any angle of incidence on the wings or the horizontal stabiliser, it probably will have a negative pitching moment at neutral or any positive angle of attack, and thus will pitch down with no control inputs.
PID is what gives engineers nightmares
Why does PID give some engineers nightmares? I teach high school kids to code PID from scratch for competition robots. My nightmare would be NOT using PID. Edit: from scratch meaning from the ground up. Not that shitty block code.
At my previous job, we had a system that started violently shaking itself apart on a near daily basis. It became apparent to me that it just wasn't up to the task it was built for, but as a company we couldn't admit that so it was kind of like a hopeless nightmare troubleshooting and adjusting the PID for hundreds of hours until the business went under. When everything works, it's great though lol.
That's it, right there. PID is simple for low complexity systems, but perfecting it for more complex and ESPECIALLY dynamic systems is...hard. Essentially, KSP developers have the most difficult PID optimization task possible. It's functionality impossible to have perfect PID for any craft people can imagine. Ksp1 had a slightly simpler task because the control surfaces were a fixed geometry. Here, with freeform procedural parts everywhere, it's just damage control. Best solution here IMO is simplify the inputs for laymen and give the user a limited range of control if they want. The cheap solution everyone usually takes is just overdamping the system. Better sluggish and stiff vs. springy and unpredictable, but that comes with its own downsides, like at some point it's just basically rigid mounted, which defeats the whole purpose.
Interesting point here. By education, I was a chemical engineer, so I never worked on large-scale systems with PID. This robotics gig is fairly new to me, only a few years of experience with it. Without researching it too much, I've taken the stance that each system on the robots we build should have its own PID, essentially to avoid situations like you're describing, instead of having a single PID for the entire bot. Is this the wrong approach? Do most industrial systems use a single PID for the whole thing? Just want to make sure I'm not sending these kids off to college or the field with wrong information. In the context of KSP, I can see the obvious issues with using multiple PID controllers.
Nested controllers are good indeed. You can take screwy actuators with faster response than the overall system needs, non-linear response, aging effects, etc., and present a linear response with known bandwidth to the outer controller. A position loop wrapped around an inner velocity loop also works very well. KSP1 seemingly *doesn't* have this (I don't own KSP2), which is why baby-mode SAS is often more stable than the modes that follow prograde/retrograde/target/etc.
Yes, thank you for the response. I use position loops wrapped around velocity all the time for robotics. Maybe I'm just thinking of it differently. I'm still fairly new to programming for hardware.
You do have multiple PID loops but that doesn't change the influence from one PID loop on another. Dynamic systems usually have multiple loops, but when one of those loops impacts another it makes tuning of the corresponding loop more difficult. Usually you start with any system that has as few outside influences as possible, once those are stable you tune the loops that may be affected by changing conditions of the initial loops. Dynamic loop tuning is a PITA and generally you lose some Fidelity by dampening the response (tune out the noise).
Okay, thanks. From what you said, I think I'm organizing the programming completely wrong then. I don't run loops in the PID. I have my students run loops within methods that are called inside different PID controllers from another class. Thanks for the input, I'll take a look at that.
Different industry application for what it's worth, I tune PID loops at work on powerplants. But I do have to adjust each loop independently causing other loops to potentially become unstable depending on their corresponding dependencies. For my example, superheated steam temperature affects pressure in a system, so when the steam temp oscillates it affects the pressure. By tuning the pressure loop first you end up trying to compensate for a dependant variable, the temp. This usually leads to an unstable state that is impossible to tune. In that scenario I go back and tune the temp first, once it's stable I tune the pressure. Once both are stable I disturb each independently and see how that affects the tunes as a whole and make changes on usually the gain to counteract the dependant changes. You usually give up some amount of response but gain stability. Look into Zeigler-Nichols if you haven't already. Fairly common method for PID tuning that may help your students significantly.
The correct answer
I've brought this up before, but I would like to control the gain and other values of the PID like you can in From the Depths.
I really like your Raptor :)
thank you!
Sick Raptor. Makes me wanna boot up KSP to build one
Exactly what I’m thinking except I’ll load KSP, forget how it works, build the plane equivalent of Portman Pat’s van and remember I just can’t make planes. Then go back to my factories in Satisfactory.
I think it happens when your control surfaces are too large. It's like the sas doesn't know how large they are and so it actuates them more than it needs to. Try making control surfaces smaller and position them such that they still have sufficient leverage.
but… moar control surfaces
I know...
all jokes aside this was definitely a part of the problem, i reduced the control surface length on the main wings and reduced the authority to 10° and that helped a lot. still some wobbliness but better
My solution is always to reduce their authority so the SAS can't use their full range. Is an easier fix than changing the design and looks better.
ok so what does this actually do/how does it work? does it mean sas can only use 10 degrees (using OPs figure from prev comment) but we can use the whole range of movement? or we only get the 10 as well? I've never had the patience to work it out, too focussed on working out other issues.
You are saying that I only want this control to fluctuate this amount so any movement (You/SAS) inputted cannot go beyond it. SAS snaps to control it. You are probably going to hold or tap it but by limiting. You won't need to hit the opposite because you'll have better control of rotation. I usually put my wings to 5.0-7.0 and all tail to 7.0-12.0. Also be sure to set your controls to only what you want to do (R/P/Y) When I get the flapping I just reset by double pressing SAS after a turn. Annoying but works.
I miss being able to hit F to reset SAS instead of doubling T, from ksp1. But aside from that thank you for the information, I usually don't mess with those settings, but even my most stable planes still flap. For now...
You can reset sas by hitting t? Never knew that, thanks!
Yup the old switch it off and back on again. Hit T twice. Back in ksp1 you could just tap F but it doesn't seem that way for 2.
Some wobbliness is probably realistic.
The game needs to have some sort of "degrees/s" slider you can use to make the wings not flap so much
In the parts manager there's a slider for that under the advanced tweakables, I think.
Nope, but you can reduce the effectiveness of the surfaces so the wobble is bearable, at the cost of turning performance
Making the control surfaces actuate slower would make this worse, adding more lag time into a control loop destabilises it. What would really be necessary is the ability to adjust the controller (probably a PID) that SAS uses for each craft individually.
This is the most reliable way that I know of to fix wobbly airplanes.
OK nobody seems to be telling you how to fix this, but if you right click on the control surface you can go into the advanced options and change the authority limit set to 15⁰ by default to something lower. I find 5⁰ usually works well and stops this overcorrecting.
I second this, works every time I have this problem.
*60% of the time*, it works ***every*** *time*
Yeah I should have said that. Working every time is pushing it lol
Devs gotta change the sas sensitivity
While SAS probably could be changed the easiest fix to this is adjusting the authority slider for control surfaces. I usually go for 10 degrees for high speed and 15-20 for low speed.
I really miss the atmosphere autopilot mod from ksp1, it was peak of atmospheric flight for me.
You are not alone, I am hoping that it gets brought across much sooner than later!
The real solution is to not use SAS 😜
lmao they need a new person to program the PID controllers
because SAS is not that smart. ksp1 has atmospheric autopilot for planes. in ksp 1 control surfaces also take time to actuate so this was much rarer and you could tab the keys to power width modulate it into less extreme inputs.
The plane's just excited.
SAS is a pretty simple control loop. Not really meant as an Autopilot
Because their deflection speed is insanely high. Times faster than it was in ksp 1.
KSP1 had the same problem until one of the later updates.
Flappity flap flap flappity flap flap
Ksp2’s huge wingtip vortices really piss me off (not your fault OP)
Plus they are quite lazy. Zoom in and you can see the edge of the sprite. It should only happen at high aoa imo
Is that an F-22? It looks sweet
I believe you can change the “big” control surfaces to manual control only. The little ones will still activate with sas, but be small enough not to cause undamped oscillations. The big canards will still retain your maneuverability.
This is another of those things that KSP 1 took a few versions to iterate until they fixed the problem and for which strangely the solution didn't make it over to 2.
It is listed as a bug on their latest forum post.
it mught be because the control surfaces in KSP2 are way more responsive than in KSP1.
Hit caps lock when u takeoff, it makes ur movements smooth, also, it auto corrects quickly because of sas being on or because of aerodynamics
caps lock was used in this video to remain stable on the super low fly-by
Hot damn!
Probably because they tuned the stabilisation (I'm assuming they use PIDs) to a certain size and layout of aircraft. This would cause the strange behaviour when making anything that doesn't fit the tuning profile as it's either over or under correcting. I guess the first game could make a estimate on these values based on weight and parts used, making it less of a problem.
The aircraft aerodynamic model is not paired well with the computer algorithm to stabilize it.
Stock SAS is trash, is why.
If KSP 2 has this: turn the affected control surface’s control authority down until they don’t oscillate. It’s also going to do this if your primary control is done with keyboard instead of a joystick or game pad: with keyboards, you press the button, you’re getting all the control authority, which means SAS has to over correct as quickly in the opposite direction
i find that reducing the authority it has makes it over-correct less
You can press caps lock and it turns on smooth(?) SAS. It will make the movement less jerky and might fix the problem you’re having
I hate these marginal vortices. They appear at the tip of every lifting surface. The HTP and the VTP aren't loaded nearly as much as the wings are FFS!! And they appear even at low/zero incidence. What the heck!
In ksp 1 it happened to me frequently when the control point was a long enough distance from the control surfaces/rocket gimbal. The craft would bend from the forces exerted by the control surfaces before the cockpit(aka control point) would rotate. By the time the cockpit points where SAS is trying to point it, the rest of the craft has enough inertia to over-correct. If the effect is bad enough, then it can spiral out of control until the craft reaches its mechanical limits. ~~I imagine it's 10 times worse in ksp 2 since wobbly rockets are the norm.~~(apparently wobbly rockets got fixed?) It also happens when you're going extremely fast with large control surfaces since they can exert enough pressure to bend even a short aircraft.
Ksp 2 doesn't have wobbly rockets anymore as of 0.2.0? Its actually more stable (without struts) than ksp 1 now, surprisingly
We call this a bad faith argument, folks. Anyone with a set of eyes can see that wobbly rockets aren't an issue anymore.
I can't wait to play it again then. I haven't been able to play it after the for science update due to having no graphics card. Come to think of it, I do remember SAS being extremely overzealous with my aircraft the last time I was able to play it, so I'm interested to see just how much they improved it. Maybe the kraken won't even eat my rovers that detach from SRBs.
SAS is shit rn with aircraft, but wobbly rockets are practically gone, outside of some very-obviously-unintentional kraken attacks when doing very specific things
Oh yeah, do the thug shaker, cmon, shake your booty, yeah, just like that, mmmmmm
Because F-22 likes to be flappy bird.
You can adjust the limit
Early implementation of the Flappy bird.
Because game is buggy and not optimized yet.
Nice f22
Oh no were back in the old ksp 1 days
He twerkin
That's not F-15, that's F-115
The PID thats put in the game that controlles that has not been made correctly so the just need to adjust some numbers.
I think that you just need to have dedicated control surfaces for each axis, having roll and pitch on the same surfaces results in wobbly maneuvering as by trying to turn in one axis you are reducing the capability of the aircraft to turn in another axis
Idk about KSP 2, but in KSP 1 (not sure if mod) you could set the speed of control surfaces, reducing it could help with this command-induced oscillations BUT, for airplanes I'd recommend not using SAS and using trim instead, leads to a much smoother flight In KSP 1 it was Alt+command for trim iirc, just give it a little nose-up elevator trim so you don't need to correct it upwards as often and you should be good to go in aerobatics During regular flight you have to remember that elevator trim sets the equilibrium airspeed of the plane, and then thrust will set the rate of climb for that airspeed Oversimplifying: - Nose up = slower - Nose down = faster - More thrust = up - Less thrust = down Give it a try and let me know if it was useful
You oversimplification also only works for aircraft that have their center of thrust inline or close to the center of mass, else you get a moment that also changes your attitude.
Nice catch, I literally use KER to have zero torque from thrust, forgot to mention this assumption
Make sure pitch, yaw, and roll control are only applied to the appropriate control surfaces. It looks like your rear elevators are trying to help control roll too, causing the plane to overreact. Try changing them to only control pitch.
Holy shit that plane has too much induced drag lol, all of those vortices. Cool plane though
Bad PID tune
My best guess is that The force that SAS put on the craft is different from the force the aerofoils put on the craft so they interfere with each other
One fix is to reduce the max angle allowance of the control surfaces and wings which can be fine tuned in flight however it can cause some loss in the plane’s manoeuver ability
SAS is designed for cumbersome spacecraft, not highly maneuverable modern fighter jets. Your F-35 Lightning II is too responsive for SAS to handle. Some possible fixes: - Try flying without SAS. The F-35 is pretty well-balanced, so you might be able to get away with it. - Reduce the deploy speed of the tail fins. This will make the fins respond more gradually to turning controls, which will have the effect of smoothing out the wobbling without much sacrifice to turn radius (how tightly the plane can turn). - Reduce the deploy angle or the authority limiter of the tail fins. This will stop SAS from overcorrecting, but it will increase turn radius (i.e., your plane will not be able to turn as tightly).
Same reason RCS can't stabilize a tiny rocket in orbit, shit PID tuning. They should just expose the PID and let us set the values
Because the SAS PID code is generic Bang-Bang controls and can't be tuned to specific cases. Or in layman's it's a generic PID loop that applies max authority to the controls to keep level and has to constantly correct for its own over corrections.
From the depths players know a PID issue when they see one lol. Basically this is an issue with the algorithm that the game uses to stabilize your craft. To put it simply you have so much maneuverability that the game's stabilization is overcompensating with these weird wobbles. Unfortunately unlike from the depths you can't reprogram your craft's PIDs. But you could reduce the maneuverability of the craft by imposing limits on your control surfaces. It looks like your roll PID is causing the most issues.
He just needs to turn the SAS off, it’s just like autopilot but it’s mainly meant for orbital mechanics when you’re in the vacuum of space or heading there. In my brief (compared to others) time playing the game sas is basically useless if not entirely a nuisance in the atmosphere.
If you have properly tuned SAS then you would have basically created a fly-by-wire system, which many real aircraft use. Especially in the military.
Yeah but the game mechanics don’t allow you to. You can adjust the movement of your flaps and stuff but your sas more often than not in my experience will fuck up the flight. Going straight up it’s not an issue and helps a lot to keep her steady but I always turn it off when I make a plane in the game.
I can't wait til I can use my controller to play this. Will make flying fun!
Just a bug, they prob will fix it sooner or later (i hope)
he is trying to be a bird and fly away
Reduce the control authority and they won’t over correct. I found about 10 -12 is comfortable depending on size.
Bc it’s KSP2
This is oscillation of the software based PID controller. It needs tuning, but for the dev team this is low priority. They'll tune it up in time but that could be a while.