Calculate landing coordinates on Kerbin

[MusicalHQ]

Is there any way to semi-accurately predict where a craft would land? Mechjeb does this and gives a latitude and longitude, but I do not understand how it works. I'm trying to write a script that lands a sub-orbital rocket back on the launch pad in python using kRPC.

Also, what would be a good way to steer the rocket onto the launch pad? The standard space plane control surfaces wouldn't work for a rocket in freefall.

[Dman979]

9 minutes ago, MusicalHQ said:

Is there any way to semi-accurately predict where a craft would land? Mechjeb does this and gives a latitude and longitude, but I do not understand how it works. I'm trying to write a script that lands a sub-orbital rocket back on the launch pad in python using kRPC.

Also, what would be a good way to steer the rocket onto the launch pad? The standard space plane control surfaces wouldn't work for a rocket in freefall.

 

There's a mod called Trajectories that can give you an idea of where the craft will land.

A.I.R.B.R.A.K.E.S at the top of the rocket could be used to create drag on one side of the rocket's body, causing it to tilt away from the prograde vector; the resulting body lift can cause some small course changes.

Edited August 4, 2017 by Dman979
Clarification.

[MusicalHQ]

Just now, Dman979 said:

 

There's a mod called Trajectories that can give you an idea of where the craft will land.

A.I.R.B.R.A.K.E.S could be used to create drag on one side of the rocket's body, causing it to tilt away from the prograde vector; the resulting body lift can cause some small course changes.

The air breaks sound interesting - thanks. 

However, I need to be able to get the coordinates for the landing within in my python program. kRPC allows python to interface with ksp, but doesn't interface with mods. Is there an equation to estimate the landing site? This would probably get complicated taking into account drag, so assuming a vacuum.

[Mudkip909]

reminded me i need mechjeb. thx.

[OhioBob]

4 hours ago, MusicalHQ said:

However, I need to be able to get the coordinates for the landing within in my python program. kRPC allows python to interface with ksp, but doesn't interface with mods. Is there an equation to estimate the landing site? This would probably get complicated taking into account drag, so assuming a vacuum.

Even without drag, it's still not easy.  Do you know the semimajor axis and eccentricity of the lander's orbit (even though it's suborbital, it's still an orbit)?  If so, what I would probably try doing is compute the lander's true anomaly at its current position, and its true anomaly intersecting the planet's surface.  True anomaly can be computed using equation 4.43.  From that there is probably a way to compute the location of the landing site in relation to the lander's current position.  Unfortunately I have no idea what the solution is off the top of my head.

[Spricigo]

Maybe you get more luck asking on the threads of the mods how they do it.  (both the data and the calculation they do) And try to reproduce it with kRPC. 

Alternatively you may also look at kRPC thread (also KoS)  if someone did something similar. 

I say that because for the 'regular player'  that's too much hassle to care. A rough estimate is enough for our needs(or we can use a mod)

 

Edit: well,  at least that is what I thought that before @OhioBob reply. 

 

And everything that you may use to steer a plane can also be used to steer a rocket.  The  rocket only lack the aerodynamic characteristics (like lot of wings)  to make it effective. 

Edited August 4, 2017 by Spricigo

[OhioBob]

Adding to my previous post...  The difference in true anomaly, Δν, between the current location and where the orbit intersects the ground is the angular distance the vehicle will travel along its current heading until touchdown.  If you know the coordinates of the sub-vehicle point and the heading, you should be able to compute the landing site.  Just move Δν degrees from the sub-vehicle point in the direction the vehicle is moving and you're there.  If you want to know the linear distance rather than angular, it's πRΔν/180, where R = radius of planet.

So if you know semimajor axis, eccentricity, current altitude, heading, and sub-vehicle point, it should be solvable.  I think all of those are given by KER and MechJeb, so hopefully you have access to them.  If you don't know one or more of those, then you're going to have to figure something else out.

I also agree with @Spricigo.  Ask those who have already figured it out.
 

Edited August 5, 2017 by OhioBob

[artwhaley]

I'm working on a similar problem...  starting with vacuum landings and going to play with atmospheres at SOME point.   At the moment I've got a decently functioning vacuum lander script - that doesn't do any targeting - but controls descent with reasonable efficiency.   It's the lander script in my example directory -https://github.com/krpc/krpc-library/blob/master/Art_Whaleys_KRPC_Demos/landing.py

The fun bits are mostly a KRPC/Python port of the mechjeb suicide burn calculation equations, which seems like it might be useful to you.  I don't begin to understand the maths, but I get the same numbers mechjeb does, so it's working.  ((actually, my routine is maybe slightly BETTER at avoiding terrain than mechjeb - because mechjeb only looks at the altitude of the projected landing site...  and my routine samples terrain heights along the landing path and tries to kill horizontal velocity by the altitude of the highest obstacle along the course.  

The closest I can get off the top of my head to what you want to do is this bit-  

v = conn.space_center.active_vessel
radius = v.orbit.body.equatorial_radius + v.flight().surface_altitude
TA = v.orbit.true_anomaly_at_radius(radius)
TA = -1 * TA   #look on the negative (descending) side of the orbit
impact_time = v.orbit.ut_at_true_anomaly(TA)
impact_place = v.orbit.position_at(impact_time, v.orbit.body.reference_frame)

And IMPORTANT - that position_at(ut, reference frame) bit is actually in the development builds of KRPC but not the .39 release yet - I just added it to the code last month.  It should be in the next release.    The missing piece THEN becomes...  turning a vector position into a latitude and longitude?   Which I don't think exists yet...  so maybe I'll see if I can figure that out and get it into the development release too, because it seems a useful bit to have?  Off the top of my head...  you could maybe cludge it using what already exists in KRPC by getting the vector position at the vessel's latitude and longitude, at the same altitude as 'radius,' then calculating the distance between the two points...  then using some haversine derived math to get the lat and lon of the second point based on distance and heading?   PART of that math is in that same landing.py file -  the coords_down_bearing(lat, lon, bearing, distance, body): function.  You just need to calculate the bearing.  

 

Update - a quick peek in the KSP API confirms that getting the latitude, longitude and altitude of a point in world space is easy -  I've opened an issue on the KRPC github to see how djungelorm prefers me to do it, but as soon as he gets back to me on that, I'll add those methods to KRPC and then you'll have them in the development build...  which..  will..  MOSTLY get you where you want to be for vacuum planets.  Atmospheres...  that's a different animal.  I'd look at how the trajectories mod does it and try to port that over if the license allows. And in fact... I WILL be doing that at some point soon for my own curiosity as well!  

 

 

Edited August 5, 2017 by artwhaley

[MusicalHQ]

So far I've been able to get the vector position of where the orbit intersects the ground (thanks, the position_at() seems very useful). However, the vector doesn't take into account Kerbins rotation, so doesn't give the true landing site. Is there any way to account for this? 

[artwhaley]

You're totally right about error from that one.   I don't see an obvious way to get that answer without computing it via haversine related math.  

In that landing script I linked above, the coords_down_bearing function does the right math, mostly, for you.   It takes a current latitude and longitude, a bearing and a distance and gives you the new latitude and longitude.  So...  ONCE I get Djungelorm's guidance on adding the lat and longitude from position vector routines to KRPC...   what you'll have to do sounds like...

Get the Lat and Lon where you'd land if you were landing NOW...

Get the time till impact

multiply that time by the rotational speed of the planet to get the degrees rotated between now and then

Find the circumference of the planet at the landing latitude

use circumference and the rotation angle to get the overland distance between where you'd land now and where you'll actually be landing then....

and then the math from that coords_down_bearing function will get you the rest of the way  - coords_down_bearing(current_lat, current_lon, 270, overland_distance, orbital_body_in_question)

 

 

[MusicalHQ]

I played around with the position_at() function, and managed to get it to work, so that it gave me my landing predictions as a position vector. But... it wasn't accurate enough for me. So I started from scratch on a predictor that took into account drag. Using some equations, I was able to start with a velocity, and simulate what would happen using a basic physics model until it hit the ground. This turned out to be a lot simpler than I thought it would be - the hardest part was figuring out the atmospheric density on Kerbin at different altitudes (because its modeled on the US standard atmosphere).

I wrote some functions (https://github.com/MusicalHQ/KSP-Landing-Predictions/blob/master/Landing.py) for this.

So far, you can use the functions to calculate landing coordinates (right now just position vectors for body.reference_frame) on bodies with no atmosphere, and on Kerbin. I'll try and add Eve, Duna, Laythe, Earth, Venus, Mars, Titan and maybe some OPM moons too.

My trajectories line up pretty well to mechjeb's, but that's the problem. My only way of checking whether my math is correct is comparing my results to mechjeb. If someone could have a look at the code and tell me whether my math makes sense, it would be appreciated.

The only thing holding back the speed of the calculations is drawing the trajectory. I have a few ideas about how to fix this, but right now if you want to calculate the landing site, turn off drawing.

[OhioBob]

@MusicalHQ, it looks like you're computing Kerbin's atmospheric temperature, pressure, and density using an equation from the KSP Wiki and this web page.  I'm actually the guy who wrote that part of the Wiki and the reference web page.  It looks to me like the code you've written will work, but the downside is that is only works for Kerbin's stock atmosphere, nor does it account for location.  You probably want a more universal way of doing it that will work with any planet or atmosphere.

KSP computes temperature and pressure using animation curves.  A couple years ago @NathanKell told me how the curves are evaluated.  I'm not a computer programmer so I don't necessarily understand it all, but perhaps you will.  This is what he told me:

Quote

All curves are evaluated like this:

http://answers.unity3d.com/questions/464782/t-is-the-math-behind-animationcurveevaluate.html

Pressure is calculated by evaluating the pressure curve against altitude. (result, kPa). Ambient temperature at that altitude is (in K):

1. atmosphereTemperatureOffset = (currentMainBody.latitudeTemperatureBiasCurve.Evaluate(latitude)

+ (currentMainBody.latitudeTemperatureSunMultCurve.Evaluate(latitude) * sunDotNormalized)

+ currentMainBody.axialTemperatureSunMultCurve.Evaluate(sunAxialDot));

2. temperature = currentMainBody.GetTemperature(altitude) // base temperature

+ currentMainBody.atmosphereTemperatureSunMultCurve.Evaluate((float)altitude) // altitude-based multiplier to temperature delta

* atmosphereTemperatureOffset;

Density is then pressure * 1000.0 * atmosphereMolarMass / (PhysicsGlobals.IdealGasConstant * temperature); (in kg/m^3)

The temperature equation above is outdated because there were additional curves added about a year ago.  I can probably go through my notes and construct an updated equation, but I don't want to bother unless it is something you need.  If the above is something you can use, please let me know and I'll figure what changes are necessary.
 

Edited August 8, 2017 by OhioBob

[OhioBob]

I just remembered that I included the updated temperature equation in this thread.  The equation is,

Temperature
= currentMainBody.atmosphereTemperatureCurve.Evaluate(altitude)
+ atmosphereTemperatureOffset * currentMainBody.atmosphereTemperatureSunMultCurve.Evaluate(altitude)

where,

atmosphereTemperatureOffset
= currentMainBody.latitudeTemperatureBiasCurve.Evaluate(latitude)
+ currentMainBody.latitudeTemperatureSunMultCurve.Evaluate(latitude) * sunDotNormalized
+ currentMainBody.axialTemperatureSunBiasCurve.Evaluate((float)currentMainBody.orbit.trueAnomaly * Mathf.Rad2Deg) * currentMainBody.axialTemperatureSunMultCurve.Evaluate(latitude))
+ currentMainBody.eccentricityTemperatureBiasCurve.Evaluate((float)((currentMainBody.orbit.radius - currentMainBody.orbit.PeR) / (currentMainBody.orbit.ApR - currentMainBody.orbit.PeR)))

I believe the pressure equation should be,

Pressure = currentMainBody.atmospherePressureCurve.Evaluate(altitude)

And finally,

Density = pressure * 1000.0 * atmosphereMolarMass / (PhysicsGlobals.IdealGasConstant * temperature)
 

Edited August 8, 2017 by OhioBob

[Vanamonde]

It looks like this is seeking or planning to make a mod, and so, moved to the modding subforum. 

[artwhaley]

I gave this a try... and am getting results that agree exactly with the aeroGUI window...  so I think it's working.   I temporarily had a method to get the temperature out, and that agreed with the aero GUI as well, and was considerably warmer than the FlightGlobals.getExternalTemperature results, so I THINK it's getting the correct temperature adjusted for latitude.

            var adjustedPosition = referenceFrame.PositionToWorldSpace(Position.ToVector());
            var altitude = InternalBody.GetAltitude(adjustedPosition);
            var latitude = InternalBody.GetLatitude(adjustedPosition);
            var pressure = FlightGlobals.getStaticPressure(adjustedPosition);
            var temperature = FlightGlobals.getExternalTemperature(altitude, InternalBody)
                              + InternalBody.atmosphereTemperatureSunMultCurve.Evaluate((float)altitude)
                              * (InternalBody.latitudeTemperatureBiasCurve.Evaluate((float)latitude)
                                 + InternalBody.latitudeTemperatureSunMultCurve.Evaluate((float)latitude) // fix that 0 into latitude
                                 + InternalBody.axialTemperatureSunMultCurve.Evaluate(1));
            return FlightGlobals.getAtmDensity(pressure, temperature);

Here's a VERY experimental version of the space center dll, that should replace the one in your gamedata/krpc/ folder...  TEMPORARILY AND WITH CAUTION.  https://drive.google.com/file/d/0B3q8VwW68f8AdXhEQVR3UlpPWUk/view?usp=sharing

It adds four methods to the celestial body class that have been spawned by this discussion - 

latitude, longitude, and altitude, and atmospheric density from position methods.    Is there any need to be able to get temperature or pressure at a given position, if you already have the density?   They're easy to implement, but if they're unnecessary I hate to clutter up the API. 

The code for the changes I've made is all visible in my fork, via the pull request.

[OhioBob]

7 hours ago, artwhaley said:

Is there any need to be able to get temperature or pressure at a given position, if you already have the density?

If all you're trying to do is take drag into account, then you should only need density.  If there's a way to get density without temperature and pressure, then I don't see any reason to get temperature and pressure.

[artwhaley]

Well, then...  that experimental version of the SpaceCenter dll ought to help, as it lets you grab density for any point in space.  Let me know if there's anything else that would both help, and be broadly applicable to others.  I think all 4 methods in that PR fit the bill. I always try to strike a balance between those two with contributing methods to KRPC, and Djungelorm has been pretty patient with me so far!  lol.