baloan

The kOS toolkit is available here: http://kos.wikia.com/wiki/Mission_toolkit_v2. Caveat: the scripts are full of Newtonian math. I will publish an extended version soon and submit an entry in the automated mission challenge. After that the next item on the roadmap is start setting up my Python development environment and start migrating. After migration I should be able to publish the mission toolkit for Python. The mission toolkit contains scripts for: 1. Kerbin ascent 2. orbit adjustments 3. Hohmann transfer from Kerbin to Mun 4. land on Mun 5. take off into low orbit 6. leave Mun SOI and 7. land on Kerbin. Currently everything is pretty 2D but with Python I'd like to use vector math and support stuff like inclination changes and targeting landing zones on arbitrary coordinates. Sounds like lots of fun.

Maybe you fell victim to the changing frame of reference that happens in 100km altitude above Kerbin where KSP switches the origin from local ship reference frame to Earth reference frame. Below exactly 100km the moon reverses direction. Sigh. // display ship & mun coordinates // note change in mun dv when ship is in kerbin orbit < 100km clearscreen. set trgt to Mun. until 0 { set pm0 to trgt:position - body:position. set ps0 to V(0,0,0) - body:position. wait 1. set pm to trgt:position - body:position. set ps to V(0,0,0) - body:position. set vm to pm - pm0. // print "Mun: " + pm. set pmu to (1/pm:mag)*pm. print trgt:name at (0,25). print " P(" + round(pm:x/1000,4) + "," + round(pm:y/1000,4) + "," + round(pm:z/1000,4) + ")" at (0,26). print "|p|: " + round(sqrt(pm:x^2+pm:y^2+pm:z^2)/1000) at (30,26). print "Pbar(" + round(pmu:x,4) + "," + round(pmu:y,4) + "," + round(pmu:z,4) + ")" at (0,27). print " v(" + round(vm:x,4) + "," + round(vm:y,4) + "," + round(vm:z,4) + ")" at (0,28). print "|v|: " + round(vm:mag) at (30,28). set ma to arctan(pmu:x/pmu:z). if pmu:z < 0 { set ma to ma + 180. } print "omg: " + round(ma,3) at (30,27). set vs to ps - ps0. // print "Ship: " + ps. set psu to (1/ps:mag)*ps. set sa to arctan2(psu:x,psu:z). if psu:z < 0 { set sa to sa + 180. } print "Ship" at (0,31). print " P(" + round(ps:x/1000,4) + "," + round(ps:y/1000,4) + "," + round(ps:z/1000,4) + ")" at (0,32). print "|p|: " + round(ps:mag/1000) at (30,32). print "Pbar(" + round(psu:x,4) + "," + round(psu:y,4) + "," + round(psu:z,4) + ")" at (0,33). print " v(" + round(vs:x,4) + "," + round(vs:y,4) + "," + round(vs:z,4) + ")" at (0,34). print "|v|: " + round(vs:mag) at (30,34). set sa to arctan(psu:x/psu:z). if psu:z < 0 { set sa to sa + 180. } print "omg: " + round(sa,3) at (30,33). }

Using kRPC/Python puts whatever language and development environment you use right into the spacecraft (without time delay). This is very comfortable and productive for development though defeats the idea of an "Apollo"-like restricted environment. For me as an avid user of "switch to 0." when running kOS it does not make much of a difference - but for others who play with remote tech or similar it will be a con that the restriction features are not readily available (and maybe difficult to implement). I like the idea of using readily available packages with Python like vector math packages, Lambert solvers which allow for more consistent treatment of vector arithmetic and easier handling of a 3D approach to orbital mechanics. I am still fighting with the concept of pitch, yaw and roll and the continuously changing frames of reference in KSP/kOS.

Does it make sense to separate the language from the variables and command interface like kRPC is doing? Many advantages pop up in my mind: 1. ability to use my favourite development environment and language. 2. access to all variables and actions through a generic protocol. Fix one bug in the interface and it fixes it for all available languages. Decouples language and access layer. 3. Immediate availability of stable programming languages. Avoids Steven and Chris reinventing the wheel. Don't get me wrong: I like your contribution to kOS, your effort and enthusiasm! Great job done. But with a home-grown language and parser there are just a lot of language related bugs to fix - I'd like you rather spend your time to implement cool things like thruster control and docking. Maybe (just thinking loud) it is an option to extract the kOS language and interface it with kRPC - and make kRPC support thruster control and docking become available in Python and kOS (sounds more like a dream). Keep on the great work. I'll be back with a new entry to the kOS automation challenge soon!

Any idea why I can't use Kerbin as a target: set target to "Kerbin". does not work. My ship is in Mun orbit. But I also can't set it as a target from the map view. KSP restriction? Land safely, baloan

I am coming from kOS and this add-on looks cool for several reasons: 1. Python provides a full fledged basis for writing any code - and extension to other languages is easily possible. 2. All variables from here are exposed and available. I will have a look and try to migrate my kOS mission toolkit for launch, circular orbit, Hohman transfer to Mun and Mun soft landing to kRPC/Python. Regards, Andreas

I am looking for documentation on: 1. how to use thrusters? For a Kerbin Minmus transfer I need to align inclination. The challenge is to find the right point in Kerbin orbit where to do inclination change. When setting a target the inclination and the axis where orbital planes cross is visible in the UI. 2. Which variables in kOS show the two points in my ship's orbit where ship and target orbital planes cross? My guess would be something like: TARGET:OBRIT:INCLINATION TARGET:ORBIT:ASCENDING:ETA TARGET:ORBIT:DESCENDING:ETA I checked the Orbit and Node descriptions in the git KOS/Docs directory which was helpful but not conclusive. Thanks, baloan

There is a time difference between the UT time display in the left upper corner and the time variable in kOS. UT: Y1, D02, 4:30:54 kOS time: Y1, D01, 10:29:53 Difference by about 18 hours (assuming Kerbin day has 24 hours). Does this have to do with game time and saved game time?

I am having a hard time aligning the different clocks in the system. Missiontime: self-explanatory. Time: I though I knew what it is. UT time display: Hm, what the heck...? Anyone knows how UT and kos:time relate?

The behaviour for stage:liquidfuel has changed. Formerly stage fuel was 0 when empty. Now it has some residual value: Easy to fix but not consistent. Breaks my ascent script. Not mentioned in any of the release notes. Btw: I lost throttle control after aborting the script. Shift and Control didn't work.

I reinstalled and it works now. Some feedback: 1. When a script stops with an error message I miss a "script stopped" message. If I remember correctly the previous version would say something like: "script aborted in line <n>". Works for syntax errors but not for errors like the below "suffix not found". 2. body has to be changed to body:name (not a big deal) 3. Node semantics have been changed set nd to nextnode. print nd:apoapsis. Suffix APOAPSIS not found on object. How to migrate apoapsis for nodes?

Hi, I've installed https://github.com/KSP-KOS/KOS/releases/download/v12.0/kOS.zip on KSP 0.23.5 (a.k.a. ARM) to check for regressions on my original scripts. Only when I want to bring up the terminal to run programs I see a grey area instead. The terminal window is not working. Bug, feature or am I missing something?

Oops. Thread died? Any pointers to where erendrake's KOS is discussed? I mean this one.

I don't understand the discussion about the code being Open Source and free software or not. Fact 1: kOS is published under the GNU GPL licence. Fact 2: From here: So - and tell me if I am wrong here - according to my understanding anyone (according to freedom 3) may fork kOS, change it, and publish it; as long as it comes with a GPL.

Yes, right. I don't see the discrepancy between two models in KSP (patched conics, Kepler orbits) as a problem but as a feature. That's why it is really hard for me to follow your reasoning. The problem does not go away as long as KSP is based on those models to build its universe. And while you are within the SOI everything matches. I agree that apoapsis does not make sense as "highest point of orbit" in all cases. But I care a lot about mathematical consistency. A negative apoapsis goes nicely with conservation of energy and the mathematical construct around it. And here apoapsis, periapsis, semi-major axis, eccentricity, specific orbital energy are all well defined. Instead of touching any of those variables apoapsis, periapsis, altitude, velocity:orbit I'd rather see new ones added, for example with a prefix. Gets the best of both views.

That's a nice workaround. I'll try that next time. Should be fixed next time we get a release nonetheless.

Double check the loop variables.

Hi Steven, Works as designed. One thing in advance. We have 1. orbital energy which is invariant and does only change when burning the engine (or thrusters), 2. how KSP approximates the laws of gravity. It uses patched conics. This is were SOI comes from and 1. and 2. are two different things. When we look at apoapsis we look at 1. To better understand what happens we also look at specific orbital energy soe. soe is defined like this: a) negative while captured (elliptic) 0 for parabolic escape c) positive for hyperbolic escape soe = - mu / sma // sma being the semi-major axis sma = (rper + 2*rmun + rapo)/2 // with periapsis, the bodies' radius and apoapsis, respectively. When you burn prograde you add energy to soe, retrograde you remove energy. How to explain the apoapsis values? On the picture it looks like your starting orbit was probably circular, i.e. periapsis ~230km as well. I use that number - and rmun = 200km - to compute soe. apoapsis: 229198, soe ~ -60000 (using mu for Mun with 6E+10) Now you have burned prograde, added lots of energy and produced a hyperbolic escape trajectory. soe has become positive. apoapsis: -1722155, soe ~ 1022155 (hyperbolic escape) How much energy you added to soe? Calculate for yourself: deltasoe = (v2^2 - v1^2)/2 As long as you don't burn here, no energy added or removed, soe remains constant and apoapsis doesn't change (have you checked?) Here you have started burning retrograde, removing energy, soe gets smaller, sma and apoapsis greater. apoapsis: -4018355 apoapsis: -5677602 apoapsis: -79147548 until soe crosses 0 and becomes negative, apoapsis starts to come down from infinity. apoapsis: +3312767, soe < 0 again apoapsis: +2342288 Once your apoapsis becomes smaller than soi KSP will show you a closed orbit. Geometrically apoapsis flip to the opposite side of the opening of the hyperbola. That and due to the maths it becomes negative. The vertex at the end of the blue line is the soi. It is due to KSP's approach on how to deal with gravity that the soi differs from the physics of an escape orbit. periapsis, apoapsis, velocity:orbit:mag, altitude are all about the potential and kinetic energy in the system. So why is soi so different from the energy escape orbit? The soi radius is used in KSP to simplify calculating gravitation. Within the soi only the body inside pulls at your ship (simple to calculate two body problem). All others planets, moon like Kerbin or the Sun are ignored. This is grossly wrong but good enough for the game and good enough for estimating transfers in reality. The soi is the boundary where Mun and Kerbin's gravitational force are equal. At the soi - in reality - your vessel will not move, in the game it falls to one of the bodies. That is why the game does not have Lagrange points. Essentially that is why physics and the soi vertex on the blue trajectory line do not match. Actually the guys who coded KSP obviously used the physical properties to determine status and not the soi. For getting the soi (or the radius) of a body you need to build a database - or better: we make those constants available in kOS. Btw: I agree with Camacha on: as a rule in a software system you should not change existing variables because it will break existing code. Instead add a new one. (Unless there is a very good reason to change it...)

I agree, it does not make sense as "highest altitude of an orbit", BUT the apoapsis variable carries information about orbital energy both for elliptic orbits and hyperbolic (escape) trajectories. Removing apoapsis information for hyperbolic trajectories removes information about the specific orbital energy which is required to calculate deltav for injection burn maneuvers (for example, perinode(alt) will calculate injection burns out of the box with kOS 0.9.2). If you have fluctuating numbers in a hyperbolic orbit I'd like to reproduce those - it might be a bug. Please provide information on how to reproduce. I don't see random apoapsis numbers. If you provide apoapsis, periapsis, velocity:orbit:mag, body and altitude we can calculate the specific orbital energy to check those numbers make sense. I'm referring to this change.

We are looking into an issue using apoapsis in escape trajectories. Dunbaratu has found random apoapsis numbers while coasting in an escape trajectory. I cannot reproduce this behaviour. On the contrary I have found reproducably and mathmatically sound apoaspis figures (here). Anyone having the same problem with random apoapsis numbers? We are looking for a way to reproduce this issue. If you can, please let us know. How to find out you are in a escape trajectory? 1. print status -> "ESCAPING", or check apoapsis > body's soi (soi numbers taken from the wiki) 2. Report orbital parameters print body. // and print periapsis. // for reference. 3. and then print apoapsis repeatedly. Please report if the numbers fluctuate between positive and negative numbers. Apoapsis carries information about orbital energy both for elliptic orbits and hyperbolic (escape) trajectories. A pull request based on https://github.com/Nivekk/KOS/issues/248 removes apoapsis information for hyperbolic orbits for future kOS versions. It deprives kOS scripts of the ability to calculate deltav for injection burn maneuvers (for example, perinode(alt) will calculate injection burns out of the box with kOS 0.9.2)

Your problem is known as Lambert's problem. Basically it is about fitting an elliptical orbit that touches your starting point and the endpoint of your transfer AND optimize the transfer for least fuel used. When searching I found a number of tools (freely available). NASA's site has a pretty exhaustive listing of available software packages somewhere. 1. General Mission Analysis Tool (by NASA): http://gmat.gsfc.nasa.gov/ 2. PyKEP (by ESA): http://sourceforge.net/projects/keptoolbox/ 3. for getting ephemeris data of real planets: http://ssd.jpl.nasa.gov/?horizons (not much use in the KSP universe but tells you about the full parameter set for an orbit - the stuff for grown-ups) The first two should actually be usable for mission planning in the KSP universe once you feed the ephemeris data for all bodies. Maybe we can create a kOS PyKEP plugin, so that Kerbin mission control can calculate transfer orbits and send them to vessels in orbit with RemoteTech...

I started with specific orbital energy which is a constant. While coasting in an elliptical orbit -mu/2a is invariant but v and r change. So for current altitude r and velocity:orbit:mag v and altitude ra and velocity:orbit:mag va at apoapsis we get this equation: which gets you set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in periapsis For the second derivation we again look at . We assume mu/r is constant immediately before and after the burn. We should burn prograde in periapsis (to come close to the impulse burn assumption, otherwise you waste deltav) so that r does change as little as possible while transiting periapsis (caveat: works only for impulse burns, for ion engines and burn times long compared to the orbital period you need to come up with something else). This is why it is important to distribute the burn duration equally before and after periapsis. Then we have v^2/2+mu/2a which is equal before and after burn: which gets you set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ). The benefit of thinking this through are precision orbits - and fuel savings.

Hi wingnut, I ran your script on one of my ships in an almost circular orbit. The difference in apoapsis is visible. The Hohmann transfer orbit formula having apoapsis at 600198km while my script has apoapsis at 599998km. The difference in the scripts is that perinode.txt (or the deprecated per1.txt) works with elliptical orbits to start with. In a first step set vom to velocity:orbit:mag. // actual velocity set r to rb + altitude. // actual distance to body set ra to rb + periapsis. // radius in periapsis set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in periapsis set a to (periapsis + 2*rb + apoapsis)/2. // semi major axis present orbit I calculate the ship's velocity va in periapsis from the current velocity vom and the distance r. In a second step the periapsis velocity is used for calculating burn deltav. For easier debugging I calculate after-burn periapsis velocity v2. // future orbit properties set r2 to rb + periapsis. // distance after burn at periapsis set a2 to (apoapsis2 + 2*rb + periapsis)/2. // semi major axis target orbit set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ). This first step, correcting for the slight eccentricity, makes the difference. I derived the solutions from the energy formula here.

Congratulations to your Kerbal engineers. Great job.