patched conics aerobraking calculator.

[Whirligig Girl]

If your trajectory enters the atmosphere, it'd be nice to know where your trajectory would be after your atmospheric encounter.

[Hanoj]

This would be hard to calculate, but if SQUAD implemented this it would make reentry much more accurate.

[boomerdog2000]

Mechjeb can do it accurately, so we know it's possible, it's probably just not a priority right now.

[Nuke]

id love to have this. you would probibly have to run an integral from the point of atomspheric interface to determine the resulting orbit on exit. so it would be less than real time, but i think it could be done.

[RocketPilot573]

We defiantly need this, it's the main reason why I got Mechjeb! I don't even use the autopilot!

[Fox62]

This shouldn't actually be too hard. Just have the game figure out what your coefficient of drag is, have it figure out what the force of drag at the lowest altitude that you are going to hit is, crunch the numbers, and show us what the results are.

[Kasuha]

Theoretically it could be approximated by a static table calculated beforehand for each planet with values in between approximated by regression. Indexed by two orbital parameters such as semi-major axis and eccentricity and coefficient of drag, assuming the ship has no lift.

Of course that would be very off for spaceplanes because for these it's very important how exactly are you passing through.

[Nuke]

thing is the amount of drag would need to be computed on a point by point basis. it would be somewhat dependent on your orientation. going nose to the wind would be completely different than coming in broadside. would probibly be computed in a nose to the wind fashion (or whatever control from hear part would need to have its z(y?) axis be tangential to your trajectory) throughout your maneuver. meaning your ship has to be built not to flip around or flail uncontrollably (which could effect your cross section).

[Kasuha]

thing is the amount of drag would need to be computed on a point by point basis. it would be somewhat dependent on your orientation. going nose to the wind would be completely different than coming in broadside. would probibly be computed in a nose to the wind fashion (or whatever control from hear part would need to have its z(y?) axis be tangential to your trajectory) throughout your maneuver. meaning your ship has to be built not to flip around or flail uncontrollably (which could effect your cross section).

As far as I understant KSP's drag model, your orientation is irrelevant. It is relevant only for parts which produce lift. Or when you're using some more realistic aerodynamic model such as FAR.

[BrokenPhysics]

@Nuke: afaik, at the moment drag is completely unaffected by the orientation of your craft. Though this will probably change when squad does overhaul the atmospheric model.

Though I'd like to see this in game, I fear it would be quite heavy on physics-calculation, which is already the bottleneck of the game. Especially at launch this could be a problem (highest part count and deep in atmosphere).

[stupid_chris]

@Nuke: afaik, at the moment drag is completely unaffected by the orientation of your craft. Though this will probably change when squad does overhaul the atmospheric model.

Nope, it does Every part has an "angular drag" value, and that's pretty much that. Else if you would drop a fuel tank from orbit on reentry, it would look like it tumbles down freely instead of adopting the most aerodynamic position naturally, which they currently do.

[Seret]

Mechjeb can do it accurately, so we know it's possible, it's probably just not a priority right now.

Blimey, can it? That's extremely useful. There are tools online like this, but it won't do things like Mun to Kerbin maneuvers.

[BrokenPhysics]

Every part has an "angular drag" value, and that's pretty much that. Else if you would drop a fuel tank from orbit on reentry, it would look like it tumbles down freely instead of adopting the most aerodynamic position naturally, which they currently do.

Good to know But does that angular drag actually increase drag, or does it just impose torque on the part?

[Nuke]

it does appear there is currently at least some directionality to the drag model, at least enough for the angle of your ship to affect your trajectory in an aerobraking maneuver. probibly some room for improvement.

how about a drag model involving a system of triaxial ellipsoids, which would represent parts drag parameters. the diameter of each axis represents the cross section of the part on that axis. these ellipsoids can have their own position and orientation with regards to the ship. you can slice any ellipsoid at any angle through the center and get a ellipse as a result. you can then use ellipse-ellipse intersection maths to determine the area of overlap between any two ellipses.

parts would be sorted front to back with regards to airflow and transform (from ship local to wind space coordinates where z is the axis of airflow) is applied to the ellipsoids. ellipsoids would then be sliced along the xy plane to get the ellipse to represent the cross sectional area of the part. this ellipsoid would be scaled by the cD (this could also be dimensional so you have different cD at different angles of attack). this allows for drag happy parts to have very large areas, making them difficult to cull out completely (parts in rear thus can affect stability).

then a process of culling starts with the forward most part, and works its way back, each time determining what factor of the current ellipse is covered by parts in front of it. the ellipse is then scaled by this factor for further part culling. this process repeats until the last part is scaled. the area of each ellipse would then be used to determine the drag forces on each part. you can not only determine the overall net drag of the system, but also local drag, and therefore net torque from drag for the whole system.

[Guest]

That sounds resource intensive.

Read some other posts of yours recently, all good. Like this one.

[Nuke]

you might be able to simplify stuff, like using spheres instead of ellipsoids, and circle-circle intersections instead of ellipse-ellipse intersection. ksp seems to have a min and max drag and then use the aoa of the part to determine which to use (lerp between min at 0 aoa and max at 180). that is probibly good enough. i assume the angular drag parameter is how much extra drag the part produces at maximum aoa, and is reduced to 0 when aoa is 0. the sum of the two would be equivalent to your cross sectional area. non zero values of angular drag might result in torque to turn the part into the wind. which kinda makes sense and is adequate to explain part behavior in the atmosphere.

determining our part cross sections the ksp way would also work. the result would be a one dimensional value that would be represented by the area of a circle, and those are easy to intersect. then just do the nose to tail occlusion factoring (i just made that up) thing. the result would be close enough to be useful.

Edited November 2, 2013 by Nuke

[TMS]

To be honest, I'd be happy if someone managed to take the code out of mechjeb's aerobraking module and made it a standalone mod. It's the one thing about mechjeb that I really miss.

[Fox62]

@Nuke: afaik, at the moment drag is completely unaffected by the orientation of your craft. Though this will probably change when squad does overhaul the atmospheric model.

Though I'd like to see this in game, I fear it would be quite heavy on physics-calculation, which is already the bottleneck of the game. Especially at launch this could be a problem (highest part count and deep in atmosphere).

Simple. Turn it off until you reach orbit for the first time.

[SolarLiner]

Though I'd like to see this in game, I fear it would be quite heavy on physics-calculation, which is already the bottleneck of the game. Especially at launch this could be a problem (highest part count and deep in atmosphere).

MechJeb calculates it and this does not take too much CPU, so I might not be as resource expensive as one might think ...