[WIP] Re-Entry Calculator & Monitor

[cm2227]

Hello KSP community,

I just started into taking orbital mechanics a little bit more serious than just guess my touchdown location or use the mechjeb landing autopilot. No hurt feelings here, I like mechjeb and used it extensively for cargo delivery to the munar surface. But as I actually got my dad (72y/o, professor of materials science) to play KSP with me, we started taking mission planning and orbital mechanics a little bit more serious.

I wrote an iterative solution to estimate the touchdown location when returning from a 0° inclination orbit (actually just the longitude) in c++ and it works well.

Now I want to include the community in my project, and the project as a plugin to get live values from the running game.

Only yesterday did I write my first class in C#, and having started programming 20years ago in BASIC and PASCAL, C# seems counter-intuitive to me.

What I have is my iterative loop for determining the the location of touchdown, which would work in any language.

Here is my first problem I want to share with you and would highly appreciate any advice, help or useful information.

My method takes the orbital parameters from your re-entry orbit, which is an elliptic orbit with apoapsis above maxAtmosphereAltitude and peripasis below maxAtmosphereAltitude.

From that, it calculates the angular position of your re-entry interface relative to your periapsis position and from there your entry angle and expected velocity at this altitude.

Then the iterative solver finds touchdown coordinates from entry angle and initial velocity.

What I need for this calculation is spacecraft mass and parachute count.

Parachute release altitude has to be considered, as partially inflated parachutes do affect drag.

How do I get the mass of a certain stage?

I would give the pilot the possibility do define a re-entry stage from the current vessel, and then use the remaining weight after these stages. I happen to rember that mechjeb does not account for mass changes during descent other than fuel. I cannot take the current spacecraft mass as a de-orbit burn has yet to be performed after using my re-entry calculator, and the results are needed for this burn.

How do I count the parachutes on the active vessel?

Somehow I have to go to the parts tree and look for parachutes. As I have not yet worked with the parts structure yet, some sort of shortcut would be appreciated.

What I am aiming for is a useful helper for any kind of atmospheric landing, with a visual interface like the Apollo Entry Monitoring System:

http://nassp.sourceforge.net/wiki/Entry_Monitoring_System

TL;DR: How do I get the mass of a certain stage? How do I count parachutes?

Edit: If anybody is interested in more detailed information or ready to support my coding in C# (which would be highly appreciated) feel free to contact me.

Thank you in advance,

cm2227

Edited December 5, 2013 by cm2227

[Trueborn]

A lot of these calculations have been done in other mods. Take a look at MechJeb or Kerbal Engineer's source code (available in their threads). That's what I did when starting out. But here's the basics.You'll need to do is iterate through the active vessel's part list, and the module list in each part. From each part you can find its mass (also check the physicalsignificance property for each part, some parts don't have mass when flying). The mass of a specific stage is somewhat harder than simply looking at each part, but I believe both of the mods mentioned above track staging, so take a look at how they do it, and see if it works for you. Then you can look in each module for a ModuleParachute. This should also allow you to dynamically look at drag numbers and deployment parameters.

[Camacha]

Are you looking to do a stock model or something like FAR?

[cm2227]

I'm not quite sure what your question is. I created a numeric solver for atmospheric re-entry on the stock aerodynamics.

[Camacha]

I'm not quite sure what your question is. I created a numeric solver for atmospheric re-entry on the stock aerodynamics.

Well, that answered my question I was wondering whether you were aiming to make a calculator for the stock aerodynamics or for FAR. The latter is a little more complicated, but very useful and interesting too. A lot of folks wanting to make accurate predictions would be using FAR.

[cm2227]

First things first, then I can take on new challenges.

Programming plug-ins in C# is very much like KSP itself - it has a steep learning curve.

Two days ago I found out they're written in C#, today I managed to open a second GUI window by pressing a button. That's one big step for me.

I think I know how I can manage the parachute and re-entry weight issues. But another question came up today.

Reading the current surface coordinates is no big deal, but to predict the right orbital phase angle for the de-orbit burn, I need the current spacecraft location in surface coordinates.

But the read-out in orbit suggests that longitude and lattitude are displayed in fixed frame coordinates, not rotating frame as on the surface.

Does anybody know more about this issue? I know the reference frame switches at a certain altitude over each celestial body, but all I need is the actual position over the surface of the body. Compensating the body's rotation is no big deal.

Thanks

cm2227

[cm2227]

Until now I only accomplished to run a successfull re-entry simulation in an external C++ program. I failed to make the same algorithm run in my KSP plug-in. I can now predict splahdown coordinates and understand a lot more about orbital mechanics. But my focus on this project has shifted. I need different sort of help than I anticipated.

Mass (almost) only affects touchdown time, not the coordinates. So getting the vehicle mass is not really necessary. Also, even for flat trajectories, the actual amount of parachutes or the resulting drag are almost irrelevant, except for precision landings. I am happy with a few hundred meters inaccuracy, and these problems can be postponed. The most influence on touchdown location lies in timing the de-orbit burn, in terms of exact ignition time and duration, i.e. velocity change. As discovered in the sixties (I recommend the book "Digital Apollo" on this issue) no manual control can deliver the necessary precision.

I now focus on two questions, for which I encourage the community to contribute:

Is anybody willing to port my messy C++ code to a working C# plug-in? I won't publish any code yet, but I would work together with a willing partner.

Does anybody know how to make the iterative solver run in its own thread (like MechJeb does) to stop the game from freezing when the new impact point is calculated?

Bonus: Is any programming guru willing to solve BOTH at once?

Thanks

cm2227

[Trueborn]

I would be interested in integrating this into SteamGauges. Conversion to C# shouldn't be too bad, but I haven't done any threading in KSP yet. Not sure how much time that would take me, although there are some examples that should make it easier. No guarantees until I see your code though.