(Request) A kOS VTOL auto hover script

[Vaxuality]

Greetings,

I've kind of been wanting to make a VTOL hover script with kOS, but after several hours of attempting, there were no good results.

I'd like to ask if anyone has an already made script that will do the trick, I am not requesting someone to make it feom scratch, just if anyone already has one.

Thanks.

[artwhaley]

I haven't gotten into KOS yet, but have done this with KRPC and might be able to help with the concept.   

I used a PID loop (and I believe that KOS has a generic 'hardware' PID available for you to use?).   To hover, I used a setpoint of 0 and input vertical velocity as my measurement variable, and the output was fed into the throttle.   You could also probably use the altitude you want to hover at as the setpoint and then measure the actual altitude, if you were more worried about that than about vertical velocity.  

[Benjamin Kerman]

Never used KOS, but programming experience says something like this: 

Start
if vertSpeed > 0, decrease throttle by 1
if vertSpeed < 0, increase throttle by 1
if forwardSpeed
...

Kinda like that. 

[artwhaley]

@Benjamin Kerman  - that was my first attempt as well when I was trying to limit dynamic pressure on an ascent script.  I found it over corrected a lot!   Switching even to a proportional control helps, if you're not ready to get into a full PID controller.  A pseudocode example might be = 

kP = .2               # sorta arbitrary value for the proportional gain - tune this until you 
				      # get the balance you want between strong reaction/over correction
  
target_speed = 0      #For a hover - could be not zero for a controlled climb or descent

LOOP INDEFINITELY:
    error = target_speed - vertical_speed        # calculate the error                 
    correction = error * kP                      # multiply error by the gain
    set throttle = throttle + correction         # apply the correction to the throttle value.   

That way we instantly react to the value that we're measuring in a way that is proportional to the error.  If we're a little high, a slight negative correction gets made.  If we're way low, a large positive correction gets made.  And when we cross the correct value, we don't have to wait a few cycles for the value to incrementally return to zero.

 

To improve that to a PI controller, all we have to do is this - 

kP = .2               # sorta arbitrary value for the proportional gain - tune this until you 
				      # get the balance you want between strong reaction/over correction'

I =  0                 # The integral term. A sort of memory for how long we've had an error in the vertical velocity
kI = .1               # gain for the integral.

MaxI = 10              #Max and minimum I values to prevent 'windup.' 
MinI = -10
  
target_speed = 0      #For a hover - could be not zero for a controlled climb or descent

LOOP INDEFINITELY:
    error = target_speed - vertical_speed        # calculate the error
	
	I = I + error                               #Integrate the errors
	if I > MaxI then I = MaxI
	if I < MinI then I = MinI

    correction = (error * kP) + (I * kI)                      # multiply error and integral by gains
    set throttle = throttle + correction         # apply the correction to the throttle value.   

That's 13 lines of code for a fairly adaptable controller routine.  What we added with the I -   we keep a sum of all the errors we've measured... and multiply that times the kI gain.  What this does is pretty intuitive once you think about it...  let's give an example.   

With the code above, say we're 1 m/s too high - as in we're drifting upward at 1 m/s.     In  the first cycle through the loop:

error = -1,

I = 0 + -1

So the correction applied to the throttle will be (-1 * .2) + (-1 * .1)      or  -.3

 

If that isnt' enough to fix it, and we're STILL climbing at 1 m/s in the next cycle, NOW I = -1 + -1.   So this time through the correction is (-1 *.2) + (-2 * .1)   or -.4.

The longer we're wrong, the harder it will 'lean' on the throttle to bring us back into balance.  This way we get small corrections for quick flutters, and stronger corrections when something goes way wonky and stays that way.

Edited August 5, 2017 by artwhaley