[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Qigon]

1 hour ago, kcs123 said:

 

Have you tried navball orientation library from community examples ? Try provided library with example, it is simple to use and understand.

If you realy need -1 you can always use 360 miunus pointing value.

I've heard about it but never really knew what it was about, I'm gonna try when playing next time. It really doesn't matter if -1 or359 since I'll deal about targeting a desired heading. 

Another thing that occurred to me is having a Geo point at North Pole and using point:bearing, Although it's not as good because I'd like multiple ships loaded at a time. 

[Dunbaratu]

3 hours ago, Qigon said:

I've heard about it but never really knew what it was about, I'm gonna try when playing next time. It really doesn't matter if -1 or359 since I'll deal about targeting a desired heading. 

Another thing that occurred to me is having a Geo point at North Pole and using point:bearing, Although it's not as good because I'd like multiple ships loaded at a time. 

Specifically, in this code: https://github.com/KSP-KOS/KSLib/blob/master/library/lib_navball.ks

You can use the function compass_for(ship) to get a number from 0 to 359 for what you're looking for.

 

[Qigon]

Thanks guys, it worked like a charm. 

Now I'm looking for predictions, I'd like to know what will my altitude look like within a few seconds. Problem is, I can't find a way to call predictAt and convert its format (vector) into anything that can compute  either altitude, alt:radar or terrain height, like geocoordinates do.

For this problems sake I don't feel like cheating since it's totally reasonable to have GPS maps pre stored for any planet. 

[Dunbaratu]

4 hours ago, Qigon said:

Thanks guys, it worked like a charm. 

Now I'm looking for predictions, I'd like to know what will my altitude look like within a few seconds. Problem is, I can't find a way to call predictAt and convert its format (vector) into anything that can compute  either altitude, alt:radar or terrain height, like geocoordinates do.

For this problems sake I don't feel like cheating since it's totally reasonable to have GPS maps pre stored for any planet. 

You can get the position of the center of the body (with something like ship:body:position, or kerbin:position) in the same XYZ reference frame as the predictAt vector.

So you can do vector subtraction between the two to get a vector from the future position to the body center.  The magnitude (:MAG) of that is the distance from that position to the body's center.  (The effective radius for gravity calculations.

Once you have that, if you want to know the altitude above sea level, subtract the body's radius.  (body:radius is the sea-level radius of the body).

If you want to know the altitude above ground level, you can do  (body here):geopositionof( (xyz vector here) ):terrainheight + (body here):radius   to get the actual terrain's distance from the body center and do the same thing as suggested above for sea level height.

Be aware that when it comes to predicting terrain height, once you get there the actual terrain can be as much as 3 to 4 meters off from the geoposition:terrainheight prediction (at most).  The prediction is based on the ideal smooth curve functions defined in the game's terrain generator formula, and the actual ground when you get there is a digitized approximation of that created by drawing polygons between sampled vertex points of that function.  The amount by which it can be off varies depending on your graphics load settings (how fine-grain your terrain polygons are).  (This was behind one of the bugs in KSP's early access days.  You'd change your graphics settings, then go back in and reload your game, go back to a saved landed ship on the mun, and it would clip right through the ground and fall forever into the Mun's hollow interior.  This happened because the terrain approximation polygons were now in a slightly different location than they were when you saved the game and the vessel's position happened to be slightly under the ground polygons rather than slightly above them.  If you notice it takes a second or two to reset your vessel's position a bit and it seems to jump up a bit to a new spot when you load a vessel from the map view now, that's due to squad's fix to this bug.  They now, upon loading, move the ship up or down a bit as necessary to match the new location of the terrain polygons.)

 

[kcs123]

I'm trying to create Pilot assistance program, rather than full autopilot. So, I created script that influence SHIP:CONTROL:PITCHTRIM and SHIP:CONTROL:ROLLTRIM using PID controler and info from navball.

set myRoll to PID_seek( RollPID, seekRoll, roll_for(ship) ).
set myPitch to PID_seek( PitchPID, seekPitch, pitch_for(ship) ).
set SHIP:CONTROL:ROLLTRIM to myRoll.
set SHIP:CONTROL:PITCHTRIM to myPitch.

When I read data to print on terminal, it shows that SHIP:CONTROL:PITCHTRIM and SHIP:CONTROL:ROLLTRIM have different values, however it seems that have very little influence, or don't have any influence at all on stabilization.

HUD controlstick position on down left side of screen does not change pitch/roll like it change with ALT + (w,s) and ALT + (a,d)

Is that a bug or intended ? My idea is that kOS adjust trims for desired pitch/angle while pilot still offset it when need trough regular controls.

[Dunbaratu]

7 hours ago, kcs123 said:

 

set myRoll to PID_seek( RollPID, seekRoll, roll_for(ship) ).
set myPitch to PID_seek( PitchPID, seekPitch, pitch_for(ship) ).
set SHIP:CONTROL:ROLLTRIM to myRoll.
set SHIP:CONTROL:PITCHTRIM to myPitch.

 

To me this looks like you're trying to set the trim values to values proportional to an error measured in entire degrees.  (if pitch is off by merely 1 degree, then set the trim to its max of 1.0).  Not sure if this helps the problem or not, but that's going to make for some very violent overcorrection once it does work.

I'll pass this on to our steering expert and ask how the controls lockout works.

[kcs123]

I didin't posted whole code, desired seekRoll and seekPitch were set elsewhere. This part goes trough infinite loop and PID controler array is adjusted so there should not be overshoot, if plane start to wooble it is possible to adjust PID controler trough other values.

When reading settings that should go from -1 to +1, roll ant pitch trim gradualy increases, so there is no violent jump in controlos.
But problem is that I don't see effect of those in flight.

Similar thing I have done with throttle/vertical velocity PID controler, that work just fine. Important part of code is one page back and whole script and craft file is available to download from my link in signature.

I have even created nice script for powered landing that gives just enough throttle for gentle landing on any celestial body, on same throttle/vertical speed PID principle. That works like a charm, kind of pround on myself, since those are my very first skiripts in kOS.

I wold like to enhance that hovering script for Heli, so not only that makes stable vertical speed, but also to stabilize pitch/roll, but for some reason pitch/roll trims didn't worked.

Thanks for investigating this.

Edited January 9, 2016 by kcs123

[Qigon]

18 hours ago, Steven Mading said:

You can get the position of the center of the body (with something like ship:body:position, or kerbin:position) in the same XYZ reference frame as the predictAt vector.

So you can do vector subtraction between the two to get a vector from the future position to the body center.  The magnitude (:MAG) of that is the distance from that position to the body's center.  (The effective radius for gravity calculations.

Once you have that, if you want to know the altitude above sea level, subtract the body's radius.  (body:radius is the sea-level radius of the body).

If you want to know the altitude above ground level, you can do  (body here):geopositionof( (xyz vector here) ):terrainheight + (body here):radius   to get the actual terrain's distance from the body center and do the same thing as suggested above for sea level height.

Be aware that when it comes to predicting terrain height, once you get there the actual terrain can be as much as 3 to 4 meters off from the geoposition:terrainheight prediction (at most).  The prediction is based on the ideal smooth curve functions defined in the game's terrain generator formula, and the actual ground when you get there is a digitized approximation of that created by drawing polygons between sampled vertex points of that function.  The amount by which it can be off varies depending on your graphics load settings (how fine-grain your terrain polygons are).  (This was behind one of the bugs in KSP's early access days.  You'd change your graphics settings, then go back in and reload your game, go back to a saved landed ship on the mun, and it would clip right through the ground and fall forever into the Mun's hollow interior.  This happened because the terrain approximation polygons were now in a slightly different location than they were when you saved the game and the vessel's position happened to be slightly under the ground polygons rather than slightly above them.  If you notice it takes a second or two to reset your vessel's position a bit and it seems to jump up a bit to a new spot when you load a vessel from the map view now, that's due to squad's fix to this bug.  They now, upon loading, move the ship up or down a bit as necessary to match the new location of the terrain polygons.)

 

Very cool, never though of looking into body properties.

 

I'll be honest, although I've been over this for quite some time I couldn't get more than 60 seconds without at least one person nagging me about something, so my mind couldn't possibly be more foggy. I can do the math for the present time and get altitude ok, but whenever I use the same formula for positionAt I get weird things. Shold I expect big displacements in bodt:position? Becaus e I can't get reasonable numbers.

local dB to positionAt(ship:body,TIME+10) - ship:body:position.
print db:mag.

 

 

[Dunbaratu]

7 hours ago, Qigon said:

local dB to positionAt(ship:body,TIME+10) - ship:body:position.
print db:mag.

Doesn't it make more sense to do positionAt(ship,time:seconds+10) rather than positionAt(ship:BODY,time:seconds+10) ?  You're comparing the body's position to the body's position and making a vector of that.

Edited January 10, 2016 by Steven Mading

[Dunbaratu]

17 hours ago, kcs123 said:

 

set SHIP:CONTROL:ROLLTRIM to myRoll.
set SHIP:CONTROL:PITCHTRIM to myPitch.

 

I did a little bit of testing on my own and I think the trim feature is bugged.  I made an issue about it here: 

https://github.com/KSP-KOS/KOS/issues/1362

I'm not normally the one who touches the steering code so I'm leaving it for someone else to pick up and notice it, but if nobody looks into it I might go have a look myself in a few days.

Edited January 10, 2016 by Steven Mading

[kcs123]

1 hour ago, Steven Mading said:

I did a little bit of testing on my own and I think the trim feature is bugged.  I made an issue about it here: 

https://github.com/KSP-KOS/KOS/issues/1362

I'm not normally the one who touches the steering code so I'm leaving it for someone else to pick up and notice it, but if nobody looks into it I might go have a look myself in a few days.

No problem, take your time, I just started to use kOS, so I'm not familiar with things in kOS, what is normal and what not.
 

[pellinor]

Is there a way to get the latest builds from your build automation? So far I only found the official releases on Github.

[Dunbaratu]

4 hours ago, pellinor said:

Is there a way to get the latest builds from your build automation? So far I only found the official releases on Github.

We don't publish automated builds.  We have them, but for developer use only because they often break working features.  It's a good idea but it doesn't exist right now.  at the moment the only way is to actually have a development environment yourself and build from source.

[kcs123]

Don't know if anyone reported, but I found another small bug. I have turned off power on kOS CPU part, to save electricity until I need it. Bringed craft on journey to Mun and while I need to wait for node execution time, I went back to space center.

After switching back to craft, power on kOS CPU is enabled while I left craft with power off. Checked again with quicksave / quickload game, again disabled power become enabled after loading game. It will be also nice to have indicator of power state of CPU. Currently we only have toggle button without actual knowlage is it turned On or Off. You always need to extra check terminal to see actual power state.

[Vegemeister]

I'm encountering a problem with the cooked steering, where it fails to control the roll, and even sets my rocket spinning wildly along its long axis.

Here's a rocket that has the problem, and my super-basic ascent script that seems to reliably cause it:

set steeringmanager:showfacingvectors to true.

stage.
lock throttle to 1.
lock steering to heading(90,85).
wait until ship:velocity:surface:mag > 100.
lock steering to srfprograde.
wait until apoapsis > 75000.
lock throttle to 0.
wait until altitude > 55000.
lock steering to heading(90,0).
wait until eta:apoapsis < 13.
lock throttle to 1.
wait until periapsis > 70000.
lock throttle to 0.
set ship:control:pilotmainthrottle to 0.

At the beginning of the ascent, the rocket yaws over to 5° off vertical as it should, but never rolls to point the roof at the sky.  Shortly before MECO 1, kOS applies a large roll input and sets the rocket spinning.  When it aligns for the circularization burn at 55km, it seems to try to damp away the spinning, but then it starts oscillating. Once it's in orbit, I can lock steering anywhere I like in the terminal and it never stops spinning.

Edited January 14, 2016 by Vegemeister
grammar

[kcs123]

Have you tried to lock roll ?

It seems to me that your rocket start to spin due to outside atmosphear forces. It never stops spining because it is not dealed at all trough script, only pitch and heading and that works as it should.

[Vegemeister]

Heading() returns a rotation, which specifies roll.  I did consider that possibility, though, and tried using lookdirup(heading(90,85):vector, up:vector) instead, in order to make absolutely sure that roll was specified.  That didn't fix it.  AFAIK, lock steering should always produce a fixed roll orientation even if it is not specified, such as by giving it a vector instead of a rotation. 

In previous versions, I had to use lookdirup(some_vector, ship:facing:topvector) to explicitly steer with no regard for roll.  That prevented the "steering through some large sweeping arc to make a roll correction" problem.  The documentation says the new steering system corrects pitch/yaw first to avoid the same issue.

[kcs123]

That might be a bug then. If I understand you properly, heading properly directs rocket, roll is stable at first. But at some point craft start to rotate and it never become stable again.
It seems to me that kOS stabilize roll only first time after heading in right direction, but it never correct again when some other outside forces kicks in.

Issue might be in kOS, but also might be that PID controler is not properly set to react fast enough for disturbance when comes to roll. Might be due to craft design too. If you get too much aerodynamic forces in some of stages, you might try to lower throttle when craft is in problematic area (going too fast on too low altitude). Most likely problematic area is below 10km with speeds above 350 m/s.

You might try to lock throttle only to 0.7 or less on first stage to avoid roll disturbance, so kOS PID controler not become "confused" on later stages.

If you can't get it work with that, you might want to try to use raw controls instead of cooked controls. Slightly more complicated, but more rewarding too on problematic craft designs.

[Vegemeister]

1 hour ago, kcs123 said:

That might be a bug then. If I understand you properly, heading properly directs rocket, roll is stable at first. But at some point craft start to rotate and it never become stable again.
It seems to me that kOS stabilize roll only first time after heading in right direction, but it never correct again when some other outside forces kicks in.

No. The nose is pointed in the right direction, but the steering is never correct.  Although there is no spinning when the script starts, it never rolls the rocket into a roof-up attitude.  It remains in a roof-east attitude until the spinning starts.  With my test script, you can see this by the fact that the vector triplets don't align.

1 hour ago, kcs123 said:

Issue might be in kOS, but also might be that PID controler is not properly set to react fast enough for disturbance when comes to roll.

 As I said, the issue occurs even when typing steering commands into the terminal once the vessel is in orbit. Disturbances are not the problem.

1 hour ago, kcs123 said:

Might be due to craft design too. If you get too much aerodynamic forces in some of stages, you might try to lower throttle when craft is in problematic area (going too fast on too low altitude). Most likely problematic area is below 10km with speeds above 350 m/s.

You might try to lock throttle only to 0.7 or less on first stage to avoid roll disturbance, so kOS PID controler not become "confused" on later stages.

Did you load up the .craft file and try it for yourself?  It is a fully symmetrical, single-stage, single-stack rocket.  The only thing remotely interesting about it is that it's roll moment of inertia is considerably less than in pitch or yaw, but that would be true of any rocket that is shaped like rockets are shaped.  (Could that be the cause? Is the steering code's self-tuning assuming each part is a point mass?  If so, the only thing radially attached is 3 solar panels.)

1 hour ago, kcs123 said:

If you can't get it work with that, you might want to try to use raw controls instead of cooked controls. Slightly more complicated, but more rewarding too on problematic craft designs.

I could do that, but it would need tuning for every vessel and would impose a hard real-time requirement on the rest of the script. I've done it before, and I found that smooth and robust behavior required running the control cycle in every physics tick.

[kcs123]

Sorry, didn't have time to load your craft and try. I was having similar issues as yours, but my crafts were in atmosphere and I use FAR, so stock kOS controls were not suitable to my crafts.
Most of problems I encontered were due to things I described, disturbances due to atmosphear forces, I didn't catched the fact that your craft spins in orbit not in atmosphere.

I hoped that some of those tricks might help you, but it seems that you have to wait for answer from someone that is more experienced with kOS.

[ColKlonk]

Would it be possible to get a breakdown of kRISC('assembler') instructions per 'script' instruction.

I would like to determine how many instructions I can insert into a 'Tick' on average.

Thanks

[Dunbaratu]

On 1/15/2016 at 6:39 PM, Vegemeister said:

Although there is no spinning when the script starts, it never rolls the rocket into a roof-up attitude.

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

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. 

[Dunbaratu]

5 hours ago, ColKlonk said:

Would it be possible to get a breakdown of kRISC('assembler') instructions per 'script' instruction.

I would like to determine how many instructions I can insert into a 'Tick' on average.

Thanks

The difficulty with that is that it changes from version to version.  Once such information is published, it starts to look like a promise and that ties our hands.  The actual means of doing it is in the C# code in a file called src/kOS.Safe/Compilation/KS/Compiler.cs - but it will be really messy to follow.  Basically looking at all the places where it says "AddOpcode(.....)" will show you the opcodes it builds.

It might be a lot quicker to try this special trick:  Compile the DLL from sources on github, so you can get the developer version.  The developer version has a flag enabled that causes it to dump the FULL program to the output log whenever there's a runtime exception.  Add a line near the top of your program that does something like SET X TO 1/0, to force a runtime divide by zero error.  When you run it it will dump the whole program (as a list of krisc opcodes) to the log.

[Redneck]

Can you guys help me with this or run it and tell me if it works or not so I dont think I am crazy? Can you guys help me get this to work? I cant get a response from the creator or in IRC chat. http://forum.kerbalspaceprogram.com/index.php?/topic/98801-wip-kospropmonitor-iva-kos-monitor-for-rpm/

[Dunbaratu]

4 hours ago, Redneck said:

Can you guys help me with this or run it and tell me if it works or not so I dont think I am crazy? Can you guys help me get this to work? I cant get a response from the creator or in IRC chat. http://forum.kerbalspaceprogram.com/index.php?/topic/98801-wip-kospropmonitor-iva-kos-monitor-for-rpm/

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.