Jump to content

[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System


Dunbaratu

Recommended Posts

Is there another (preferred) way to get ALT:RADAR? I wasn't able to find a discussion about this on the Forum.

The Docs page for ALT: 

https://ksp-kos.github.io/KOS/structures/vessels/alt.html

... says that ALT "is grandfathered in for the sake of backward compatibility, but this information is also available on the Vessel structure as well, which is the better new way to do it:"

But I haven't been able to find anything in the Vessel structure that references a RADAR suffix.

 

 

Link to comment
Share on other sites

First of all, great mod. I cannot image playing KSP without it. :)

I do have a question. I use RSS+RO+RP-1 (with RemoteTech). Is it possible to transfer the the ScienceData from an experiment (like barometer) to a probe core., assuming the probe core has a ModuleScienceContainer? I can do it manually (with the Ship Manifest mod), but that only works when a have an active connection to the ship, and with the normal signal delay. I have a feeling KOS should be able to do the same, but I cannot find out how.

What I tried:
- The ModuleScienceContainer has an action "Collect All", but that does nothing.
- I tried the TransferAll from the resource transfer functionality. But apparently, the ScienceData is not in the Resources collection of the part that contains the ModuleScienceExperiment. So I cannot transfer it.

Anybody any ideas? The purpose is to use it in a automated script that collects sciencedata during a flyby (like Venus), and keeps collecting sciencedata when the planet is between the probe and earth (no connection). What I do now is having many duplicates of all Science experiments on board (like 3 thermometers). But I'd like to have just one science experiment, that collects data and transfers it automatically the the probe core.

Maybe the ScienceData of an experiment needs to be in the Resources collection of the part?

Edited by Willem_D
Link to comment
Share on other sites

kOS "POSITIONAT()" problems:

I'm having trouble making the kOS positionAt() function work the way I hope it can. The kOS documentation on vectors, reference frames, etc. are fairly baffling, so I've gotten myself into a very confused state by trying a lot of different things and making a lot of plots that are all starting to make no sense at all.

I'd appreciate any pointers.

The scenario:

(Note: I know there is likely an easier way to do this. I'm puzzling over how this particular function works. Also note that I'm also not using maneuver nodes).

I'm working on a kOS script to automatically match the inclination of a Target's orbit.

My ship is in a low-altitude inclined elliptical orbit.

I've selected a Target, which is in a much larger elliptical orbit, with a totally different inclination, and whose Ap and Pe are both higher than my ship's orbit.

When I select the target, the AN and DN markers appear on the Map view.

The end goal of the script is to automatically point the ship in the correct direction at the correct time to burn by the correct amount to match the inclinations.

Based on some helpful posts here on this Forum, I start by computing some cross-products to find the two vectors that are normal to my ship's orbital plane and to the the target's plane. I then compute the cross product of those two vectors, and the resulting vector points along the AN/DN (named "andn" in my code).

That seems to work fine. To verify that it works, I have a script that computes...

local angle_error is vang(ship:body:position, AnDn).

...and print this value in the console as my ship orbits. The value ranges from 0 to 180, and is at 0 exactly when my ship marker is over the DN marker, and is at 180 when my ship is over the AN marker, then trends toward 0 as the DN marker approaches again.

The value of the AnDn vector is stable for a given pair of orbits..

So I think the AnDn vector is correct, and I can measure the difference between my current position vector and the AnDn vector, and all that seems very tidy.

I'd like to warp ahead to just before my ship reaches the nearest of AN or DN. So I'm trying to use positionAt() to search into the future to find the time when angle_error reaches either 0  or 180. 

The problem:

The values I get for angle_error using my ship's future position vector are not consistent with the values I get for angle_error in real time.

For debugging purposes, I've got a loop that iterates through one ship's orbit, computes the future ship vector and angle_error, and logs the utime and angle_error to a CSV file.

// survey the predicted angle over one orbit of time in 1/100 increments
local dt is 0.
local tinc is ship:orbit:period / 100.
local tnow is time:seconds.

until dt > ship:orbit:period {
  local tim is tnow + dt.
  local an is angleAt(tim).
  log dt + "," + an to "search_data.csv". 
  set dt to (dt + tinc).
}

// return the future angle to the ANDN vector at a time 't'
// use this for making predictions with "positionAt()"
// note; andn is global vector of the An/Dn markers
function angleAt {
  parameter t.
  local ang is vang(positionAt(ship, t), andn).
  return ang.
}

 

When I run this script, let's say that the real-time angle_error is maybe 170 degrees, but the first value for the future predictions is around 55, and over the orbit period it increases to 180 and then decreases to around 125. It does not vary through a complete cycle of values over an orbit.

So there are two issues I haven't been able to resolve:

- Why is the initial angle_error prediction so badly incorrect?

- Why doesn't the predicted angle_error vary from its starting point up to 180, down to 0, and back to its starting value as I predict the future through one full orbit?

I've been wresting for a couple of days and am making no further progress. Hopefully someone on the Forums will recognize the symptoms and give me a head-slap.

One thing I tried which does not work is changing the angleAt() function to use (positionAt(ship:body), andn). That gives results which vary for the first few test examples and then asymptotes to a stable value for the rest of the orbit period. I would expect that to not work, because using the position of BODY in its orbit is not correct, but even given that, I don't understand why the value it returns has an asymptote behavior.

It seems like examples of POSITIONAT() that I've seen online tend to be used with adjusting a maneuver node. Is POSITIONAT() somehow tied to using maneuver nodes?

I'll post this before my internet connection burps and I lose it. I can post some images of the plots if it would be helpful.

Thanks for any assistance.

 

Edited by FloppyRocket
Cleanup
Link to comment
Share on other sites

@FloppyRocket

It looks like you are mixing up two different vectors. SHIP:BODY:POSITION will give you a vector from your ship's current position to the middle of the central body (e.g. Kerbin). POSITIONAT(SHIP,t) will give you a vector from your ship's current position to where it will be at time t. (aside: the good news is that if your orbit is elliptical, both vectors are relative to the central body, so you don't have to take into account the motion of the central body in the meantime). That is, it'll be a vector between two points on your orbit. You want both vectors to be to (or from) the central body to be able to compare them.

To convert between the two, you need to need to add/subtract the BODY:POSITION vector (note the SHIP: at the beginning is optional). I'm not great at explaining this bit, sadly. I think to get the predicted vector pointing towards the central body, you would need to use BODY:POSITION - POSITIONAT(SHIP,t).

Printing out the angles is good debugging practice, but I would also advise you to try drawing the vectors on the screen using VECDRAW(). I found it easier to keep track of what was happening that way. Of course, drawing vectors that don't originate at your current position is a learning curve in of itself...

Link to comment
Share on other sites

10 hours ago, ElWanderer said:

@FloppyRocket

It looks like you are mixing up two different vectors. SHIP:BODY:POSITION will give you a vector from your ship's current position to the middle of the central body (e.g. Kerbin). POSITIONAT(SHIP,t) will give you a vector from your ship's current position to where it will be at time t. (aside: the good news is that if your orbit is elliptical, both vectors are relative to the central body, so you don't have to take into account the motion of the central body in the meantime). That is, it'll be a vector between two points on your orbit. You want both vectors to be to (or from) the central body to be able to compare them.

To convert between the two, you need to need to add/subtract the BODY:POSITION vector (note the SHIP: at the beginning is optional). I'm not great at explaining this bit, sadly. I think to get the predicted vector pointing towards the central body, you would need to use BODY:POSITION - POSITIONAT(SHIP,t).

Printing out the angles is good debugging practice, but I would also advise you to try drawing the vectors on the screen using VECDRAW(). I found it easier to keep track of what was happening that way. Of course, drawing vectors that don't originate at your current position is a learning curve in of itself...

Thanks for the tip about what vector the POSITIONAT() function returns.  I'll give it a try.

Yes, I've struggled with VECDRAW() also.

Link to comment
Share on other sites

15 hours ago, ElWanderer said:

@FloppyRocket

To convert between the two, you need to need to add/subtract the BODY:POSITION vector (note the SHIP: at the beginning is optional). I'm not great at explaining this bit, sadly. I think to get the predicted vector pointing towards the central body, you would need to use BODY:POSITION - POSITIONAT(SHIP,t).

 

The situation is something like this? (please comment)

pqmi7G7.png

Edited by FloppyRocket
Link to comment
Share on other sites

7 hours ago, FloppyRocket said:

The situation is something like this? (please comment)

pqmi7G7.png

That looks right to me.

A note on VECDRAW (as it's much easier to talk about with a diagram): vectors A and C originate at the ship's current position, or V(0,0,0), so the origin parameter of the vecdraw would be V(0,0,0).

Vector B originates at the central body, so you would need to pass in BODY:POSITION as the origin parameter.

Link to comment
Share on other sites

19 hours ago, ElWanderer said:

That looks right to me.

A note on VECDRAW (as it's much easier to talk about with a diagram): vectors A and C originate at the ship's current position, or V(0,0,0), so the origin parameter of the vecdraw would be V(0,0,0).

Vector B originates at the central body, so you would need to pass in BODY:POSITION as the origin parameter.

Thanks!

Link to comment
Share on other sites

41 minutes ago, Kartoffelkuchen said:

 

Two airplanes simultaneously doing a fully autonomous landing at Cape Hook Global Airport, using my self-written airplane autopilot.

Just thought it was  a badass moment, so thought I'd share :)

 

That was cool! The next step is to lift off at the same time from the same runway, side by side, and land them to the other runway :D

Link to comment
Share on other sites

3 hours ago, infinite_monkey said:

Would it be possible to make kOS compatible with Kerbal Engineer (or is it already)? It would be handy to access KER's data instead of having to rewrite (and run) basically the same code.

Possible, yes.  Desirable?  Maybe not.  At a certain point it becomes too easy to just let other mods do all the work for you at which point why aren't you using Mechjeb instead if you wanted someone else to write your autopilot for you?

Edit: Okay that's a bit harsh, I admit, but the issue is relevant.  There are some things that really belong in the autopilot's code, and how much of that code do you want written for you versus how much do you want to make yourself?  The kOS cooked steering is already hiding a lot of the work for you that you'd have to do yourself if you moved the raw controls with code.  I sometimes do fear pushing a bit too far in that direction.  (For example, KER can calculate when to start a suicide burn, which is something I feel definitely belongs in the user's own script code.)

On 1/19/2019 at 1:01 PM, Kartoffelkuchen said:

 

Two airplanes simultaneously doing a fully autonomous landing at Cape Hook Global Airport, using my self-written airplane autopilot.

Just thought it was  a badass moment, so thought I'd share :)

 

That looks great!

One frustration (with the stock game) is how the landed PACK distance is so much smaller than the flying PACK distance.  (This is why the distant plane just froze in position the moment it touched the runway.  Once it touches, then you have to be within 300 meters for it to be fully using "physics".)  And this isn't an easy number to change because it's that way for good Kraken reasons.  The terrain polygons can shift and move as you get closer to the spot and they become more fine-grain.  If the terrain shifts from underneath the vehicle, it can cause ground collision as the ground pops up or down a little.  So they set it to 300m because that's the range at which they can guarantee no more adjustment of terrain will occur within that range, even at the lowest terrain detail setting in the graphics settings tab.

Edited by Steven Mading
Link to comment
Share on other sites

12 hours ago, Steven Mading said:

One frustration (with the stock game) is how the landed PACK distance is so much smaller than the flying PACK distance.  (This is why the distant plane just froze in position the moment it touched the runway.  Once it touches, then you have to be within 300 meters for it to be fully using "physics".)  And this isn't an easy number to change because it's that way for good Kraken reasons.  The terrain polygons can shift and move as you get closer to the spot and they become more fine-grain.  If the terrain shifts from underneath the vehicle, it can cause ground collision as the ground pops up or down a little. 

Yeah, that might be a big problem with procedurally generated terrain. But in case of runway landings I found it quite safe to extend the range to couple kilometers

Here is an example of almost simultaneous landing from opposite ends of KSC runway

And while in the video the carrier touchdown ended up not that far from the already landed shuttle, during the development tests there were even moments when the carrier landed before the shuttle and without issues (apart from hitting the lights couple times while I was working on making that script handle sharper turns and shallower approaches better)

Link to comment
Share on other sites

13 hours ago, Steven Mading said:

Possible, yes.  Desirable?  Maybe not.  At a certain point it becomes too easy to just let other mods do all the work for you at which point why aren't you using Mechjeb instead if you wanted someone else to write your autopilot for you?

Edit: Okay that's a bit harsh, I admit, but the issue is relevant.  There are some things that really belong in the autopilot's code, and how much of that code do you want written for you versus how much do you want to make yourself?  The kOS cooked steering is already hiding a lot of the work for you that you'd have to do yourself if you moved the raw controls with code.  I sometimes do fear pushing a bit too far in that direction.  (For example, KER can calculate when to start a suicide burn, which is something I feel definitely belongs in the user's own script code.)

I understand your point. Sure, calculations of g, TWR, available acceleration etc. are pretty easy to do, and probably not very heavy on the CPU. I think the main reason I want it is because Trajectories is still broken for kOS, and I have no idea how to take into account the atmosphere for calculating the landing spot and/or impact time.

Link to comment
Share on other sites

2 hours ago, infinite_monkey said:

I understand your point. Sure, calculations of g, TWR, available acceleration etc. are pretty easy to do, and probably not very heavy on the CPU. I think the main reason I want it is because Trajectories is still broken for kOS, and I have no idea how to take into account the atmosphere for calculating the landing spot and/or impact time.

Trajectories version 1.7.1 works with kOS.

Link to comment
Share on other sites

Just now, squidgeny said:

Alright I'm a bit new to this and I'm sure this has come up before so I apologise in advance but...

 

How do I open the console on the launch pad if the computer is inside a shroud? I can't click on the part :(

You should have an icon in the toolbar from where you can open the console

Link to comment
Share on other sites

1 hour ago, infinite_monkey said:

have no idea how to take into account the atmosphere for calculating the landing spot and/or impact time.

And the best thing about kOS is that you don't have to 100% accurately calculate landing spot and impact time. "Proper" way to calculate it would be per ship, to know exact coefficient of drag for ship or vessel. Cd again depends on ship shape, angle of attack, atmosphere mach number, atmosphere pressure (for fluid density calculation) atmosphere temperature that also influence mach number etc. Have also take into account ship mass that influence kinetic energy, that need to be drained at impact point if you want to use ship more than one time. And ship mass also change over time as you use rocket fuel, available thrust change too and whole equation become even more complex.

Even when you get proper equation, considered every possible thing that influence landing point you can get some random event during flight that add some error in equation and that you could not predict before.

So, how to do it then. Well, "dirty" but much easier way to calculate impact point with kOS would be to re-calculate impact point and time on each second of flight, instead of calculating it only once while ship is still in orbit. Fortunately, kOS and KSP game world can give you more than enough data to calculate it good enough on each game frame that makes thing a lot easier.

Instead of pre-calculating everything, start with more simple landing script and extend it later on. For start, disregard some things in equation.Start with assumption that your ship killed all of horisontal velocity and you are on Ap with zero vertical velocity. For first script assume that celesital body have no atmosphere too. Next assumtion is that your ship is perfectly oriented, so engines always face downwards or retrograde.

Now, instead of having complex equation you have simple free fall equation. Pretend for a moment that we don't even know free fall equation. What we know is gravity constant on that celestial body that would accelerate ship to the ground. Except, not even gravity acceleration is constant. It changes too as ship fall down to surface, not much, but significant enough to cause errors in calculations.
Good thing is that kOS and KSP game world give you enough data to re-calculate gravity acceleration each time you need it. Already prepared for kOS script:

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

OK, we now know gravity acceleration, with assumption that it will remain constant during the fall or landing you can get equation for ship (vertical) velocity on any given time:

Velocity(t) = Body_g * t + start_velocity

When you integrate above formula one more time, you will get equation for distance, that you already know from ship sensors - it is current altitude above impact point. With all that you can get equation for fall time.

// we can use simplified equation if starting velocity is zero
set FallTime to SQRT((2 * FallAltitude)/ Body_g ).

Knowing  falling time you have to calculate backward, what would be velocity at that time. You need it later on. Now, consider ideal vertical landing, what is ideal situation for ship to survive impact and burn least fuel as possible. Ideal situation would be that vertical velocity is zero and force from engine thrusts is equal as force from gravity but in oposite directions to cancel each out. Ship should also stand on it's landing legs too, so it would be safe to shut down engines on very next time frame.

Sir Issac Newton told us that force is calculated like this:

F = m * a

If you trust that his equation is correct then you can calculate both forces, from body gravity and from ship engines:

local CraftWeight to SHIP:MASS * Body_g.
local CraftMaxThrust to SHIP:AVAILABLETHRUST.

You have also need to put in consideration what kind of info ship sensors would provide. In "normal" velocity/distance equations distance at zero time frame is also zero and velocity is positive as time pass. Ship sensors will give you oposite, as ship falls down, vertical velocity become more negative as time pass and you start with positive altitude that become lower and lower down to zero.
With that in mind Fall time calculation looks like this:

// On this line is NaN if equation under SQRT gives imaginary result, or divide by zero occur or any other undefined value
// happened also if cheated to Mun orbit with engines off, could be due to celestial body changes between physical ticks or number becomes too small

		if (MAX(0,(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )) > 0) and (CraftMaxThrust > 0) and (Body_g > 0)
		{
			set FallTime to -1 * ship:verticalspeed/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g))  + SQRT(ship:verticalspeed^2 +4 * (((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)*FallAltitude )/(2*(((CraftMaxThrust - CraftWeight) / SHIP:MASS) - Body_g)).
		}
		else
		{
		 set FallTime to 0.1.
		}.

Again, above works only in certain situation, that ship vertical velocity is either zero or negative, ship TWR is above 1, so you can choose proper solution of quadratic formula etc. You need to put that in consideration for the rest of script code, so it does not throw errors in run time. In example above, if you put negative number in SQRT function, script will throw error, so you have to consider this.

Why all this written above ? We have started with most simple situation, but now you also can tackle down situation that also put in consideration that ship mass, body gravity and velocity change over time. You don't need know what kind of situaton was before or what would be changed on the whole landing time, all you need to know if thrust from ship engines are powerful enough to reduce vertical velocity to zero and also capable to maintain it at zero (equal or greater acceleration against celestial gravity acceleration) at the moment of impact.

Now, things are much more simple to tackle, all you need to worry during landing is to not allow vertical velocity become too high that ship engines could not counter part it.

All of that above is not to give you ultimate solution, it is rather a starting point to think in different way and come to solution even when you don't know complex equations.
It is up to you to extend this info further, instead of ship pointing 90 degree all time to counterpart vertical velocity, you can put in consideration that is on some angle and instead of full thrust force that engine can provide you can put only vertical fraction of velocity vector.

In case of celestial body with atmosphere you not need to worry that engines would start too late as drag force would only help engines to slow down ship and when you are very close to the ground it can be also disregarded. But you need to worry about it depending of ship shape/design because when your velocity is too high in atmosphere then your ship can flip and main engines no longer points in desired direction etc.

I have also extended pieces of code shown above to put in consideration different height of landing legs or ship:alt:radar value, different veritcal velocity that is "safe" to maintain in atmosphere without fliping rocket in undesired direction. Instead of landing imediately, I prefer to hover rocket 20 m above ground and switch to semi-automatic landing mode that allows me to choose better landing spot and so on.

Link to comment
Share on other sites

13 minutes ago, squidgeny said:

Alright I'm a bit new to this and I'm sure this has come up before so I apologise in advance but...

 

How do I open the console on the launch pad if the computer is inside a shroud? I can't click on the part :(

You can get one to open automatically if you stick the following in a boot file:

CORE:DOEVENT("Open Terminal").

Link to comment
Share on other sites

21 minutes ago, ElWanderer said:

You can get one to open automatically if you stick the following in a boot file:

CORE:DOEVENT("Open Terminal").

This did not work for me.  Does there need to be a `WAIT 1`. before it or something?

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...