[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Vegemeister]

12 hours ago, Steven Mading said:

Can you specify the exact kOS version?  Because this used to be a bug and then got fixed.

0.18.2, and the current master branch.  I tried it in a debug build, and steeringmanager:moi was showing something like v(60,2e-7,60). That is consistent with my hunch that the moments of inertia are being calculated assuming each part is a point mass, since the rocket is a single-stack with only physicsless parts attached radially (the 3 solar panels).

12 hours ago, Steven Mading said:

Also, if you leave the scene (i.e. go to space center), and then go back to the vessel (click in it in tracking center), does it do it again, or does it stay stable?  I ask because there can be bugs related to the system not realizing which vessel ID is the right one, so it polls information from the wrong craft, confusing the steering, and that sort of bug tends to reset when you force the game to reload the vessel into memory from the file. 

The problem persists when switching to the space center and back.  I first discovered the problem on my ckan installation with tens of mods and several active ships, but subsequent testing has been in a new save file with only kOS installed and only the single craft.

[Redneck]

6 hours ago, Steven Mading said:

We're pretty much stalled on any user interface work until KSP 1.1 comes out.  The news about how the old GUI system is being deprecated in Unity 5 and while it would still work there's no guarantee how much longer it will continue to work for, made us kOS devs decided to put a development freeze on any UI related issues in kOS until we're on Unity5.  We're going to want to redesign the whole UI anyway so there's no point in putting any work into the current system just to then throw that work away.

 

yeah i totally understand the stall. Im in the same boat with my landing gear on my deltaglider. And still no word on a new PartTools. But if you would could you keep this in the back of your mind for later? I think this would be a great addition to KOS in IVA's and a little boost for the immersion factor

Spoiler

http://forum.kerbalspaceprogram.com/index.php?/topic/98801-wip-kospropmonitor-iva-kos-monitor-for-rpm/

 

Edited January 16, 2016 by Redneck

[Rodyle]

Hi mod team!

I have been using your mod with great pleasure. However, I was wondering if you guys could update one error: when you try to copy a file, but cannot, due to lack of memory, it gives a very unhelpful error message.

[Jenyaza]

Try to implement "yet another rover autopilot".

We can use LATLNG(x,y) to specify point on planet surface (GeoPosition). But it not locked to current vessel, particularly to it facing

Otherwise, we can use SHIP:GEOPOSITION. This is point where vessel is now. Still be only point

How i can get the GeoPos point, that is, for example, 100m away from vessel, forward? And 15m right?

Simple scheme

Spoiler

 

Edited January 17, 2016 by Jenyaza

[Drew Kerman]

this sounds at first like you're trying to figure out, based on where the rover is currently looking, what the geopoint is of a spot in the distance - but are you simply just trying to orient the rover towards a point on the surface?

[Dunbaratu]

9 hours ago, Jenyaza said:

Try to implement "yet another rover autopilot".

We can use LATLNG(x,y) to specify point on planet surface (GeoPosition). But it not locked to current vessel, particularly to it facing

Otherwise, we can use SHIP:GEOPOSITION. This is point where vessel is now. Still be only point

How i can get the GeoPos point, that is, for example, 100m away from vessel, forward? And 15m right?

Simple scheme

  Reveal hidden contents

 

 

I assume you want something that is curved around the surface.  In other words, if it was 100000m, you want it to curve around the horizon, not be up in mid-air above the ground like a straight line path that long would be.

So you're interested in a curved line of length D, not a straight one.

Here is a strange unorthodox way to think of doing it:  Get the current position of your rover from the body center.  It will be a long vector calculated like this:

SET myPosFromCore TO ship:position - ship;body:position.

Now to find a spot D distance away around the circumference of a sphere of that radius, find the angle equal to how far you need to rotate to achieve a circumference length of D at that radius:

SET myRadius TO myPosFromCore:MAG.

SET degrees to (D / myRadius) * CONSTANT:RadToDeg.

That's how many degrees to rotate the position vector, but the axis to rotate it around, to get a position directly in front of you is your starboard axis:

SET RotAxis to Ship:facing:starvector.

Now you can rotate the position vector by that much, around that axis:

SET newPosFromCore to ANGLEAXIS(degrees, RotAxis) * myPosFromCore.

Now newPosFromCore is a vector from the body's core to the new position you want.  To turn that into a geo position, just do:

SET newLatLng to ship:body:geopositionof( ship:body:position + newPosFromCore).

 

Warning: I have tested NONE of that.  I could have a step wrong.  Especially the rotation direction of the angleaxis.  You might need to add ":INVERSE" to the end of it if you find it's picking a position behind you instead of in front.

 

What I described there would give you a position directly in the way you're facing.  To deflect the aim of the rotation to your left or your right, do some trig between ship;facing:starvector and ship:facing:forevector with the tangent of the desired angle. to get a rotating vector axis you want.

[Sealed14X]

Looking for a bit of help in my basic function.
Thanks for any help that can be offered.
Here is the function that I am using:

// Pre launch Sequence.  Execute before bottom most Stage
declare function fn_PreLaunch
  {
  parameter b_SAS.
  parameter b_RCS.
  parameter b_Lights.
  parameter f_Throttle.
  parameter b_Gears.
  
  SAS b_SAS.  // I want to set SAS to the variable b_SAS (Boolean: On / Off;  [True or False])  
  RCS b_RCS.
  lights b_Lights.
  lock throttle to f_Throttle. //Throttle is a decimal from 0.0 to 1.0
  gear b_Gears.
  }.

// Here is the function call (changeable as needed per rocket and mission needs):
fn_PreLaunch (On, On, On, 1, On).

Edited January 18, 2016 by Sealed14X
spelling and grammer / function call

[Jenyaza]

 

Maybe, I'll understand it.    Thank you.

*going to hard testing*

[Jenyaza]

Maybe, I'll understand it.    Thank you.

7 hours ago, Gaiiden said:

this sounds at first like you're trying to figure out, based on where the rover is currently looking, what the geopoint is of a spot in the distance - but are you simply just trying to orient the rover towards a point on the surface?

Not orient the rover towards a point, but orient the point towards a rover.

Point is nearby the rover (10..40m, not far), but always should be in front of vessel. It,s "locked" to rover, not target.

I want to make the rover "scan" the surface if front of it.

I get 5 points; first before the rover,  next is some left (from first),   next some right,  more left and the last is more right. And rover position - as starting point.

Now get the PointX:TERRAINHEIGHT in all points, and compare with Rover:TERRAINHEIGHT.

If "more left" point is about 6 meters down, and all other is near zero (from rover height), it "say" to rover - turn right, because we have a crater (or slope) left

 

*going to hard testing*

P.S. fail... how to remove posts?

Edited January 18, 2016 by Jenyaza

[Drew Kerman]

oh, you're looking to do terrain avoidance? Cool.

[pellinor]

43 minutes ago, Jenyaza said:

I want to make the rover "scan" the surface if front of it.

I get 5 points; first before the rover,  next is some left (from first),   next some right,  more left and the last is more right. And rover position - as starting point.

 

Ship:Body:GeoPositionOf( Ship:Position+ X * Ship:Facing:ForeVector ):TerrainHeight

This should give the terrain altitude of the point X meters in front of the rover.

[hvacengi]

On 1/16/2016 at 9:53 AM, Vegemeister said:

0.18.2, and the current master branch.  I tried it in a debug build, and steeringmanager:moi was showing something like v(60,2e-7,60). That is consistent with my hunch that the moments of inertia are being calculated assuming each part is a point mass, since the rocket is a single-stack with only physicsless parts attached radially (the 3 solar panels).

The problem persists when switching to the space center and back.  I first discovered the problem on my ckan installation with tens of mods and several active ships, but subsequent testing has been in a new save file with only kOS installed and only the single craft.

I've kind of become the "steering" guy for the project, since I wrote the new `steeringmanager` code.  Those small MoI values really mess up the math.  I can't quite figure out how unity manages them, but there is some kind of a scale factor applied to keep the values in "reasonable" ranges.  Since I couldn't figure out how to predict that, I wrote an adaptive section of the code that will try and adjust your "available torque" based on the observed angular acceleration.  The problem is, the "epsilon" value used to try and reduce very small fluctuations can also prevent the steering from trying to stop.  I hadn't run into this prior to the last release, but I found it as I was doing some other testing in the last month or so.

I'm working on an update to the steering so that staging/docking events will be tolerated a little better.  And in that branch, this appears to be fixed.  But that fix probably one be in the next update, but rather the one after.  So, since it looks like you're comfortable compiling on your own anyways, here's what you can do to fix it locally: Change the value of EPSILON on line 154 of "SteeringManager.cs" from "0.00001" to "1e-16".  We don't want to ignore the epsilon value entirely, but it can be much smaller and still have good results.  For the ship I was testing, this change fixed the rotation immediately.  Let me know if you end up having to tweak it further, it would be good to have a chance to test out that value before I push it to the public.

Sorry for my delay in response.  I spend a lot more time on github than here, and I ended up having a busy weekend that didn't leave me a lot of time to work on kOS.

Edited January 18, 2016 by hvacengi

[Vegemeister]

1 hour ago, hvacengi said:

I've kind of become the "steering" guy for the project, since I wrote the new `steeringmanager` code.  Those small MoI values really mess up the math.  I can't quite figure out how unity manages them, but there is some kind of a scale factor applied to keep the values in "reasonable" ranges.

Hmm.  If I've read the code right, you're getting the MoI from Vessel.findLocalMOI().  Seeing as Squad wrote that and KSP isn't open source, we don't know how it calculates the MoI.  2e-7 seems unreasonably small to me.

Unity's docs suggest that, for each part, Unity computes the inertia tensor and stores it as the diagonal of the tensor in the principal axes basis, plus the rotation (from? to?) the part's native basis.  IANAPhysicist, but I think the correct way to calculate the vessel's inertia tensor would be to make a Matrix4x4 from each Part.Rigidbody.inertiaTensor and then reverse first the inertiaTensorRotation and then the part's facing, as described by wikipedia, then use the parallel axis theorem to find the inertia tensor relative to the vessel's center of mass, then sum over all the parts on the ship.

If Squad's findLocalMOI() is treating each part as a point mass and not accounting for the MoI of the part itself, that could explain the very small roll MoI on vessels with no massive radially attached parts.  I found someone mentioned this a few months ago on Reddit.

1 hour ago, hvacengi said:

 Since I couldn't figure out how to predict that, I wrote an adaptive section of the code that will try and adjust your "available torque" based on the observed angular acceleration.  The problem is, the "epsilon" value used to try and reduce very small fluctuations can also prevent the steering from trying to stop.  I hadn't run into this prior to the last release, but I found it as I was doing some other testing in the last month or so.

I'm working on an update to the steering so that staging/docking events will be tolerated a little better.  And in that branch, this appears to be fixed.  But that fix probably one be in the next update, but rather the one after.  So, since it looks like you're comfortable compiling on your own anyways, here's what you can do to fix it locally: Change the value of EPSILON on line 154 of "SteeringManager.cs" from "0.00001" to "1e-16".  We don't want to ignore the epsilon value entirely, but it can be much smaller and still have good results.  For the ship I was testing, this change fixed the rotation immediately.  Let me know if you end up having to tweak it further, it would be good to have a chance to test out that value before I push it to the public.

Setting EPSILON to 1e-16 fixed the problem on my 1.25m and 2.5m test rockets, mostly. The spinning and oscillation are gone and the roof is pointed in the correct direction, but the roll steering is less smooth than the pitch and yaw. It turns very quickly, overshoots, then takes a long time to get back to the correct direction.  But that isn't a problem for my use case.

1 hour ago, hvacengi said:

Sorry for my delay in response.  I spend a lot more time on github than here, and I ended up having a busy weekend that didn't leave me a lot of time to work on kOS.

No problem.

[pellinor]

Is there a simple way to get Eta:Apoapsis / Eta:Periapsis for the orbit patch after a maneuver node?

Edit: next question, how do I get the times of transition between orbital patches? An orbit seems not to know when its patch starts or ends.

Edited January 20, 2016 by pellinor

[blnk2007]

On 1/18/2016 at 1:59 AM, Sealed14X said:

Looking for a bit of help in my basic function.
Thanks for any help that can be offered.
Here is the function that I am using:

// Pre launch Sequence.  Execute before bottom most Stage
declare function fn_PreLaunch
  {
  parameter b_SAS.
  parameter b_RCS.
  parameter b_Lights.
  parameter f_Throttle.
  parameter b_Gears.
  
  SAS b_SAS.  // I want to set SAS to the variable b_SAS (Boolean: On / Off;  [True or False])  
  RCS b_RCS.
  lights b_Lights.
  lock throttle to f_Throttle. //Throttle is a decimal from 0.0 to 1.0
  gear b_Gears.
  }.

// Here is the function call (changeable as needed per rocket and mission needs):
fn_PreLaunch (On, On, On, 1, On).

What exactly do you want help with? Is something not working?

[TDW]

On 18/01/2016 at 6:59 AM, Sealed14X said:

Looking for a bit of help in my basic function.
Thanks for any help that can be offered.
Here is the function that I am using:

// Pre launch Sequence.  Execute before bottom most Stage
declare function fn_PreLaunch
  {
  parameter b_SAS.
  parameter b_RCS.
  parameter b_Lights.
  parameter f_Throttle.
  parameter b_Gears.
  
  SAS b_SAS.  // I want to set SAS to the variable b_SAS (Boolean: On / Off;  [True or False])  
  RCS b_RCS.
  lights b_Lights.
  lock throttle to f_Throttle. //Throttle is a decimal from 0.0 to 1.0
  gear b_Gears.
  }.

// Here is the function call (changeable as needed per rocket and mission needs):
fn_PreLaunch (On, On, On, 1, On).

 

In kOS on and off are commands and cant be passed as variables. Try using true and false instead:
 

// Pre launch Sequence.  Execute before bottom most Stage
declare function fn_PreLaunch
  {
  parameter 
   b_SAS,
   b_RCS,
   b_Lights,
   f_Throttle,
   b_Gears.
  
  set SAS to b_SAS.  // I want to set SAS to the variable b_SAS (Boolean: On / Off;  [True or False])  
  set RCS to b_RCS.
  set lights to b_Lights.
  lock throttle to f_Throttle. //Throttle is a decimal from 0.0 to 1.0
  set gear to b_Gears.
  }.

// Here is the function call (changeable as needed per rocket and mission needs):
fn_PreLaunch (true, true, true, 1, true).

also worth noting that if you end the script after calling that function kOS will release the lock on the throttle and it will return to whatever it was before kOS took control. If you want the throttle value to persist try using

set ship:control:pilotmainthrottle to f_Throttle.

instead. However if it is run as a boot script when you first spawn the vessel on the pad that wont work as the throttle starts off at 0 then ksp sets it to 0.5. You need to wait a second or so before setting the throttle value to avoid it being overwritten by ksp.

[ShadowZone]

Been scratching my head lately on a problem...

I found a fascinating bit of PID controller code in a video for a hover script.

now I want to expand on it by adding a position lock to it. The goal is to let a craft hover above a specific set of coordinates.

So far I came up with this crude approximation:

set spot to geoposition.
lock steering to latlng(spot:LAT,spot:LNG):altitudeposition(alt:radar + 90).

This kind of works, but apparently it just makes the craft act like a pendulum around that point that oscillates out of control after a short while. I imagine I would need something like this:

check if "current geoposition" is off "target geoposition".
use pitch/yaw delicately to move above "target geoposition".
if rcs/vernor available, use translation controls to move above "target geoposition".

the crucial part of course is "use pitch/yaw delicately". I would imagine I would have to check constantly how much the craft is off target and then adjust its controls accordingly.
 Obviously I would like to use the PID controller provided in the link above. It does a marvellous job at keeping altitude. And I am way too much of a novice to even try to come up with something like that myself.

Thing is, I do not really have a clue how KSP or kOS at that measures and calculates positional data and how to translate that into steering commands. For the time being I do really simple and stupid trial and error poking around the code stuff. So yeah... any help or nod in the right direction would be much appreciated

 

EDIT: weird observation: as soon as I give control to kOS, the roll controls (Q/E) seem to be inverted, even after I give control back to the pilot. Any idea why that may be?

Edited February 8, 2016 by ShadowZone

[Dunbaratu]

2 hours ago, ShadowZone said:

Been scratching my head lately on a problem...

I found a fascinating bit of PID controller code in a video for a hover script.

 

now I want to expand on it by adding a position lock to it. The goal is to let a craft hover above a specific set of coordinates.

So far I came up with this crude approximation:

set spot to geoposition.
lock steering to latlng(spot:LAT,spot:LNG):altitudeposition(alt:radar + 90).

This kind of works, but apparently it just makes the craft act like a pendulum around that point that oscillates out of control after a short while. I imagine I would need something like this:

check if "current geoposition" is off "target geoposition".
use pitch/yaw delicately to move above "target geoposition".
if rcs/vernor available, use translation controls to move above "target geoposition".

the crucial part of course is "use pitch/yaw delicately". I would imagine I would have to check constantly how much the craft is off target and then adjust its controls accordingly.
 Obviously I would like to use the PID controller provided in the link above. It does a marvellous job at keeping altitude. And I am way too much of a novice to even try to come up with something like that myself.

Thing is, I do not really have a clue how KSP or kOS at that measures and calculates positional data and how to translate that into steering commands. For the time being I do really simple and stupid trial and error poking around the code stuff. So yeah... any help or nod in the right direction would be much appreciated

 

EDIT: weird observation: as soon as I give control to kOS, the roll controls (Q/E) seem to be inverted, even after I give control back to the pilot. Any idea why that may be?

I hate the new forum software.  I typed a long reply with code samples and everything, and hit "submit" and the software refused to take it, and then said mysteriously "this field is required" at the bottom of the page without any indication which field its talking about, and all my work was wiped and I couldn't get it back with backarrow.

 

Here's the short summary of what I typed:  PID on a vector is messy. These PIDs are for scalars.  So use several independent PID's - one for the longitude and one for the latitude, and one for the vertical hover, as they are orthogonal values, then use vector addition with the unit vectors for up, north, and east multiplied by the result of the 3 pids, and use that resulting vector to steer by.

I have no idea about the Q/E thing - I've never seen it.

Also, try searching on the documentation for "PIDloop" - there's now a much faster built-in PIDloop feature you can use in kOS instead of having to spend precious kerboscript cycles on it.

[Drew Kerman]

3 hours ago, Steven Mading said:

I hate the new forum software.  I typed a long reply with code samples and everything, and hit "submit" and the software refused to take it, and then said mysteriously "this field is required" at the bottom of the page without any indication which field its talking about, and all my work was wiped and I couldn't get it back with backarrow.

You also remember to check the footer of the quick reply box and see if there was an auto-save link when you paged back? This forum should be auto-saving replies, but it does a poor job of letting you know it does it.

[ShadowZone]

18 hours ago, Steven Mading said:

I hate the new forum software.  I typed a long reply with code samples and everything, and hit "submit" and the software refused to take it, and then said mysteriously "this field is required" at the bottom of the page without any indication which field its talking about, and all my work was wiped and I couldn't get it back with backarrow.

 

Here's the short summary of what I typed:  PID on a vector is messy. These PIDs are for scalars.  So use several independent PID's - one for the longitude and one for the latitude, and one for the vertical hover, as they are orthogonal values, then use vector addition with the unit vectors for up, north, and east multiplied by the result of the 3 pids, and use that resulting vector to steer by.

I have no idea about the Q/E thing - I've never seen it.

Also, try searching on the documentation for "PIDloop" - there's now a much faster built-in PIDloop feature you can use in kOS instead of having to spend precious kerboscript cycles on it.

As for using PID for the positional data, I wanted to set up multible variables, for instance "hoverLat" and "hoverLon" as well as "latOffset" and "lonOffset". I am not really sure I understand the second bit about vector addition an multiplying.

I would have very much liked to see your code examples

[troyfawkes]

Thought you guys might appreciate this. I was having trouble figuring out how to create a hyper specific Execute Node script using physics instead of constantly checking variables, and I wrote out the solution and my thinking. Some notes:

• Still not polished, it's basically a purely mathematical solution right now.
• It takes into account change in mass through burn.
• It takes into account multiple engines with different Isp.
• It uses vectors to determine when steering is ready.
• It knows on load when your burn starts and ends, no graduated checks along the way.

I'll be doing more of this as it's a really solid way for me to learn how everything works.

[panzerwaffe044]

Noob's question.

I have a problem with LOCK STEERING TO HEADING command on the craft with Stayputnik Probe, no-gimbal engine and 4 control surfaces. I play with FAR and the rocket is aerodynamically stable. The rocket's refusing to pitch. I would like to use kOS in the early career with no RT connection for my early sounding suborbital rockets. As the search tells me, it's a known issue... Any advice?

Of course I could just use a thrust-vectoring engine (it works fine with it), but it's less efficient ASL and I wanted to make my rocket comletely aerodynamically controlled.

 

[kcs123]

14 hours ago, troyfawkes said:

Thought you guys might appreciate this. I was having trouble figuring out how to create a hyper specific Execute Node script using physics instead of constantly checking variables, and I wrote out the solution and my thinking. Some notes:

• Still not polished, it's basically a purely mathematical solution right now.
• It takes into account change in mass through burn.
• It takes into account multiple engines with different Isp.
• It uses vectors to determine when steering is ready.
• It knows on load when your burn starts and ends, no graduated checks along the way.

I'll be doing more of this as it's a really solid way for me to learn how everything works.

I'm not much of rocket scientist nerd, but I have recalled of Scott Manley video (it was recommanded on KSP front page some time ago) where he explained whole ISP mess. IIRC, for Ve equation you have always use earth gravity as constant to get correct velocity. It was used in that way for a reason, to help scientist used for imerialistic measurment standard to not mess up equation with metric measurment system and vice versa.

If you need to calculate gravity acceleration on each celestial body in Kerbal Space Program, kOS provide some nice tools for it.
Check out this kOS documentation page. More specific, take a closer look on BODY:MU. It is standard gravitational parameter.

Now, knowing this, it is much easier to calculate gravity for any celestial body where your craft is influenced at. Thanks to kOS, you don't even top know body name for it.

Instead of just one command for gravity calculation, I will put whole funcion here that I used within my power landing script and hovering script. It might be usefull for other folks around that also still learn how to use kOS like me.

// function to calculate gravity constant and ship weight
function ThrottleLimits {

  set Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2.
  set CraftWeight to SHIP:MASS * Body_g.
  //set CraftMaxThrust to SHIP:MAXTHRUSTAT(SHIP:SENSORS:PRES). // can take in account tail rotor that is set to "0"
  set CraftMaxThrust to SHIP:AVAILABLETHRUST.
  if CraftMaxThrust > 0 // need it to prevent divide by zero
  {
	set MinThrottle to round(((CraftWeight/CraftMaxThrust) - 0.15),2). // throttle for ~0.85 of TWR to prevent too high down velocity - crashing issue
	set MaxThrottle to round(((CraftWeight/CraftMaxThrust) + 0.2),2). // throttle for ~1.2 of TWR to prevent too high up velocity - flipng issue
	
	// in low gravity bodies like Minimus, minimal throttle can be calculated below zero, that should not be possible
	if MinThrottle < 0
	{
		set MinThrottle to 0.
	}.
	
	if MaxThrottle > 1
	{
		set MaxThrottle to 1.
	}.
  }
  else
  {
	set MinThrottle to 0. // throttle for ~0.85 of TWR to prevent too high down velocity - crashing issue
	set MaxThrottle to 1. // throttle for ~1.2 of TWR to prevent too high up velocity - flipng issue
  }
}.

Thing that you might miss in your blog is altitude of ship. You have to take that in account instead of gravity on sea level of celestial body of influence.
Most interesting part for you would be this:

set Body_g to SHIP:BODY:MU / (SHIP:BODY:RADIUS+altitude)^2.

[MinimumSky5]

I'm having a strange issue with my program for a simple sounding rocket. The program is:

CLEARSCREEN.

PRINT "Counting down:".
FROM {local countdown is 10.} UNTIL countdown = 0 STEP {SET countdown to countdown - 1.} DO {
    PRINT "..." + countdown.
    WAIT 1.
}

UNTIL SHIP:MAXTHRUST > 0 {
    WAIT 0.5.
    PRINT "Stage activated.".
    STAGE.
}

WHEN VERTICALSPEED < 5 {
    WAIT 2.
    STAGE.
}

The error message i get is that apparently, the curly brackets after < 5 are actually the Euro sign, which is impossible as that isn't  even an option on my keyboard.

[Dunbaratu]

11 hours ago, panzerwaffe044 said:

Noob's question.

I have a problem with LOCK STEERING TO HEADING command on the craft with Stayputnik Probe, no-gimbal engine and 4 control surfaces. I play with FAR and the rocket is aerodynamically stable. The rocket's refusing to pitch. I would like to use kOS in the early career with no RT connection for my early sounding suborbital rockets. As the search tells me, it's a known issue... Any advice?

Of course I could just use a thrust-vectoring engine (it works fine with it), but it's less efficient ASL and I wanted to make my rocket comletely aerodynamically controlled.

 

http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#tuning-cooked-steering

 

Essentially the problem is that kOS's cooked steering knows nothing of areodynamic-only control like from fins and rudders.  So when it calculates how much torque it *thinks* the ship is capable of outputting, it gets a very small nearly zero number.  Then it gets way too conservative when it is deciding what is the max rotation it should allow itself.  It rotates up to a rotational speed, holds that rotational speed, then slows down as it approaches the set point.  It has an upper cap on how high it will allow that rotational speed to get, and that's based on it guessing how long it THINKS it would take for it to stop its rotation if it had to.  Given that its calculations of how much torque it thinks it has is wrong when the torque is coming from flappy control surfaces and nothing else, it gets the false notion that it would take it an enormous amount of time to stop a rotation, and thus it gets very conservative with its rotations and refuses to allow itself to get much rotation started in the first place.

One fix is to manually add a fudge factor that tells the steering manager that the available torque is a bit higher than it thought it was, to compensate for the fact that it doesn't try to add torque from areo controls to the calculation.  You can do this by setting:

 

steeringmanager:pitchtorqueadjust, steeringmanager:yawtorqueadjust, and steeringmanager:rolltorqueadjust.

 

6 hours ago, MinimumSky5 said:

I'm having a strange issue with my program for a simple sounding rocket. The program is:

CLEARSCREEN.

PRINT "Counting down:".
FROM {local countdown is 10.} UNTIL countdown = 0 STEP {SET countdown to countdown - 1.} DO {
    PRINT "..." + countdown.
    WAIT 1.
}

UNTIL SHIP:MAXTHRUST > 0 {
    WAIT 0.5.
    PRINT "Stage activated.".
    STAGE.
}

WHEN VERTICALSPEED < 5 {
    WAIT 2.
    STAGE.
}

The error message i get is that apparently, the curly brackets after < 5 are actually the Euro sign, which is impossible as that isn't  even an option on my keyboard.

When requires a THEN keyword (I really should remove that.  It's kinda dumb, but it was inherited from the language before I got my hands on it.)

I don't know why it's showing a euro sign in the error message, though.  It doesn't do that for me.