A Very Kerbal Kontroller

[Freshmeat]

10 minutes ago, PeteWasEre said:

I have made a guitar amp that's based on a cake tin before!

 

@Freshmeat I'm tryin'

Would be curious to know what approach you used. I spoke to the KRPC Dev and he has no plans for higher level modes, so I need my own PID to turn altitude hold into a pitch command to give to KRPC's autopilot. I suspect similar issues when I have one PID driving another, and my control theory classes are approaching 20 years ago!

I try to make my own PID controller, but my knowledge is superficial at best. For now, change in elevator angle is proportional to discrepancy in altitude, with some limiters if pitch goes to high or low. I need to make the elevators settle if the plane is at the right altitude, but given that it is not generally zero angle, I am a bit out of ideas. I need to find some reading material to progress instead of just fumbling around. My background is theoretical physics, not engineering, but I guess I have to live with my life choices

[tjsnh]

Pretty much the only thing missing is a navball, or a small LCD with a copy of the "primary" navball display, but that's probably a whole order of magnitude of extra problems trying to make ;-)

[PeteWasEre]

@Freshmeat My initial thinking is to make an AP mode that targets a rate of climb or descent. The PID in my case would give my a delta pitch that i can then modify my target pitch with to give to KRPC. If you are trying to calculate elevator position from the error i can imagine it would likely be unstable. A PID should give you a delta control to apply, which takes away the need to calculate the settling point. It should settle where it settles when your delta goes to 0. 

If I can do that then altitude hold should be a function of target ROC vs delta from altitude. So if I am within 100m, 0, and increasing from there.

Thats the theory anyway.... will let you know how I go!

6 minutes ago, tjsnh said:

Pretty much the only thing missing is a navball, or a small LCD with a copy of the "primary" navball display, but that's probably a whole order of magnitude of extra problems trying to make ;-)

Oh now you have me thinking! In the pics above i have a 3D orbital view... if I can do that, why cant I do a navball! Its just a rotating sphere with some markers on it. Thats going on the backlog... thank you!

Bye bye frame rate though..... thats going to take some calculation!

[Freshmeat]

I use KSPSerialIO where I cannot control aircraft pitch directly, only via the amount of input I send instead of the Joystick Y-axis input. So I am effectively pretty much stuck on changing the elevator position, using Delta Y control = k * Discrepancy in altitude (we need inline TeX for this). My problem is that the approach I use overshoots massively for all values of k I have tried yet, leading to increasing oscillations in pitch. The result looks suspiciously to what happens when you do Eulers method of integration on a F = -k*x spring, as you get a tiny overshoot no matter the dt, which will lead to an increasing amplitude. My next approach is to make some form of dampening mechanism, but I am not certain how I exactly will go about it as I cannot predict equilibrium.

Edited October 7, 2016 by Freshmeat

[PeteWasEre]

1 minute ago, Freshmeat said:

Delta Y control = k * Discrepancy in altitude

Yep, I think you really need a PID approach. In my simple understanding before pulling out the old text book..

Delta Y control = C1 x E + C2 x Integral  E dt + C3 x dE/dt    

where E is the altitude error.

As i understand it, which is not saying much yet , the differential term is what will actively help to stabilise you here as you approach the target altitude. The integral term is what then manages small errors as they build up and the proportional term dominates at first when you are far from your target. 

You do need to do some tuning, but there are known methods. Ziegler–Nichols is a common approach and seems manageable, at least on first reading.

[Freshmeat]

Sounds reasonable that I should include I and D of PID . Part of the fun with KSP is the amount of time you can use on it even when you are not playing.

[tjsnh]

1 hour ago, PeteWasEre said:

@Freshmeat My initial thinking is to make an AP mode that targets a rate of climb or descent. The PID in my case would give my a delta pitch that i can then modify my target pitch with to give to KRPC. If you are trying to calculate elevator position from the error i can imagine it would likely be unstable. A PID should give you a delta control to apply, which takes away the need to calculate the settling point. It should settle where it settles when your delta goes to 0. 

If I can do that then altitude hold should be a function of target ROC vs delta from altitude. So if I am within 100m, 0, and increasing from there.

Thats the theory anyway.... will let you know how I go!

Oh now you have me thinking! In the pics above i have a 3D orbital view... if I can do that, why cant I do a navball! Its just a rotating sphere with some markers on it. Thats going on the backlog... thank you!

Bye bye frame rate though..... thats going to take some calculation!

In regards to the navball, once upon a time I tried to get a spare artificial-horizon instrument (beechcraft cockpit surplus) wired up as a USB device controllable through a driver, but it ended up being entirely too much trouble. I always thought it would have been great for flight sims.