Jump to content

[old thread] Trajectories : atmospheric predictions


Youen

Recommended Posts

OK, I thought it was updating the drag coefficient while the fuel was consumed to simulate a different drag/weight ratio (i.e. drag is more important relatively to the weight when the tanks are empty). But maybe there is no issue specifically with SDF in the end.

These considerations are still valid for air brakes that are probably changing the drag coefficient during flight.

Link to comment
Share on other sites

It does, and the net result is drag force for an empty part. So if your plugin looks at it when it's full and then later when it's empty, the drag force result ends up the same. AND I just realized how that can throw predictions off. Maybe. Inertia.

Non existent in stock because it always receives enough drag to offset inertia. I *think* it's still not a problem for prediction though.... It still has to apply the force against mass somewhere right?

Link to comment
Share on other sites

Sorry for the delay.

there is some pictures

Javascript is disabled. View full album

i think there is too much approximation

i had low pass over Venus once and AT showed me that I will aerobrake(there was red line), but near Pe i still wasn't in atmosphere(i could do non physical timewarps there). From what i know the RSS uses pressure curves (i don't know if it is relevant). I'm not sure it will show some changes in the orbit, i need do more testing on that

another thing about descend profile:

The height where there is switch to another angle slider is fixed, or it is changing according to the planet's atmosphere height?

Edited by Bedi
Link to comment
Share on other sites

Sorry for the delay.

there is some pictures

i think there is too much approximation

i had low pass over Venus once and AT showed me that I will aerobrake(there was red line), but near Pe i still wasn't in atmosphere(i could do non physical timewarps there). From what i know the RSS uses pressure curves (i don't know if it is relevant). I'm not sure it will show some changes in the orbit, i need do more testing on that

another thing about descend profile:

The height where there is switch to another angle slider is fixed, or it is changing according to the planet's atmosphere height?

Question, you're using default RSS right? Not 10x Kerbol or 1/10th Solar System or anything? And nothing custom about it?

If the answer is yes then replace the RealSolarSystem.cfg file with this one: RealSolarSystem.cfg

And check to see if you still have the problems with Atmospheric Trajectories that you reported.

Rationale: Atmosphere Curves in and of itself is not a problem. However, some of the atmospheric entries have bad values for the maxAtmosphereAltitude. Specifically they have values that are higher than the maximum altitude present in the AtmosphereCurve data. That would definitely make Trajectories think there is atmosphere where (hey, guess what?) there is not.

Edited by Starwaster
Link to comment
Share on other sites

i think there is too much approximation

i had low pass over Venus once and AT showed me that I will aerobrake(there was red line), but near Pe i still wasn't in atmosphere(i could do non physical timewarps there). From what i know the RSS uses pressure curves (i don't know if it is relevant). I'm not sure it will show some changes in the orbit, i need do more testing on that

another thing about descend profile:

The height where there is switch to another angle slider is fixed, or it is changing according to the planet's atmosphere height?

The white curve is just a display thing, actual calculations are made with the stock orbit representation (so the straight lines visible on your screenshot are unrelated with computation precision ; there is an entry in the bug tracker to fix that though).

I use the max atmosphere height provided by the KSP API. I don't know if RSS has atmospheres going over that number. I also read once that the variable I use is not completely accurate and that there is another method to find the actual atmosphere limit, but I haven't searched yet. Something that can come into play as well is that your Pe will change when you go in/out warp. The Trajectories mod makes a simple thing to find out if you encounter atmosphere or not : it compares Pe with the max atomsphere height.

The heights in the descent profile are proportional to the atmosphere height (that is documented if you hover the labels : it's 100%, 50%, 25% and "near ground" which I don't remember exactly but I think that last one is a fixed height with a non-linear interpolation).

Hope this answers your questions (I think I will install RSS some time because it looks like an interesting mod, but I don't plan that soon as I have a lot of other things to do).

Link to comment
Share on other sites

What version of FAR is this compadtible with? I've tried using it with far but it is very in accurate, when I aim for the KSC I normally end up in the mountains or deserts. When using the stock aerodynamics though it's amazing, give your self a pat on the back :)

There are precision issues with FAR, but it should be enough to get a precise landing if you have some control during descent (with a spaceplane for example). Also, ground intersection is not very precise yet, so it won't find collision with mountains for example (but it does account for altitude near the impact point, it's not just intersection with sea level). Keep in mind that, aside from precision issues of the mod, FAR is very sensitive to your piloting (a fraction of a degree in the direction you point your craft can make you land at a completely different place), while stock is completely independent of that (unless you have wings, or use thrusters).

Link to comment
Share on other sites

I use the max atmosphere height provided by the KSP API. I don't know if RSS has atmospheres going over that number. I also read once that the variable I use is not completely accurate and that there is another method to find the actual atmosphere limit, but I haven't searched yet. Something that can come into play as well is that your Pe will change when you go in/out warp. The Trajectories mod makes a simple thing to find out if you encounter atmosphere or not : it compares Pe with the max atomsphere height.

The only time maxAtmosphereAltitude might be inaccurate is when _body.useLegacyAtmosphere == False (oops, not quite true, see the edit below)

If you want to add an additional check for that you can then look at the last key in its pressureCurve which should be its true max atmospheric altitude (in kilometers, not meters). Note that at that point it's still possible to have a malformed pressureCurve but at that point you've done all that could reasonably be expected of you and it would be an issue for whichever mod/modder is responsible for that data. (in this case RSS, and I've already submitted a pull request to RSS with the updated config that I posted above, which ought to fix the issue he's having)

Edit: From MechJeb's code. The part after the useLegacyAtmosphere check is a good idea too because even in stock it's possible for maxAtmosphereAltitude to be wrong. And the 'else' makes MJ more accurate with RSS.


public static double RealMaxAtmosphereAltitude(this CelestialBody body)
{
if (!body.atmosphere) return 0;
if (body.useLegacyAtmosphere)
{
//Atmosphere actually cuts out when exp(-altitude / scale height) = 1e-6
return -body.atmosphereScaleHeight * 1000 * Math.Log(1e-6);
}
else
{
return body.pressureCurve.keys.Last().time * 1000;
}
}

Edited by Starwaster
Link to comment
Share on other sites

What version of FAR is this compadtible with? I've tried using it with far but it is very in accurate, when I aim for the KSC I normally end up in the mountains or deserts. When using the stock aerodynamics though it's amazing, give your self a pat on the back :)

I'm gonna guess that you are reentering with a pod or something, probably backwards? When using FAR it assumes you are going to be pointed prograde the entire time, if that isn't the case then you need open up the GUI while in the map screen and adjust the reentry profile sliders to the AoA you plan on using during the different stages of reentry, it should be fairly accurate with that, at least get you within visual range of the KSC.

Link to comment
Share on other sites

I'm currently writing tools to automatically test the mod (because, as support for other mods is likely to grow (FAR, NEAR, SDF, RSS, DR, etc.), the number of tests to check non-regression will increase as well). As part of this task, I'm also implementing an API to access Trajectories from other mods (that will of course be re-usable for other purposes). The idea is to provide a TrajectoriesAPI.dll that you can directly reference, and that handles all the reflection code to indirectly use Trajectories.dll. So you can safely redistribute the TrajectoriesAPI.dll with your mod, and it won't create an actual dependency on the main Trajectories.dll.

First automated tests show that, for what I think is a typical pod reentry, I have about 600m precision for stock aerodynamics, but 6km for FAR.

What is annoying is that a part of the precision issues do not come from my mod. Apparently, the "on-rails" orbital behavior (which I use to compute conditions at atmospheric entry) do not match the physics simulation, which leads to a slight error in entry conditions, that turn out to make a difference of at least 1km at the impact point. Also, depending on the physics warp factor, another 1km or more can appear (meaning that, starting from the same save file, you won't land at the same place depending on wether you warp or not).

Things get worse with FAR that depends a lot more on the physics simulation (deformation of the craft changes its aerodynamic behavior), which is somewhat random (i.e. not reproducible). And there are more prediction errors related to FAR, which I haven't clearly isolated yet.

While there are certainly things that can be done to improve prediction accuracy (and probably bugs to fix), I'm more and more thinking that the solution is not accurate prediction, but tools to help correct the trajectory during the flight (which is what I started with the nav ball indicators, but there is still a lot of room for improvement).

In any case, don't expect precise landings with crafts you can't control (that's kind of realistic actually, even if it's not on purpose).

Link to comment
Share on other sites

First automated tests show that, for what I think is a typical pod reentry, I have about 600m precision for stock aerodynamics, but 6km for FAR.

Things get worse with FAR that depends a lot more on the physics simulation (deformation of the craft changes its aerodynamic behavior), which is somewhat random (i.e. not reproducible). And there are more prediction errors related to FAR, which I haven't clearly isolated yet.

While there are certainly things that can be done to improve prediction accuracy (and probably bugs to fix), I'm more and more thinking that the solution is not accurate prediction, but tools to help correct the trajectory during the flight (which is what I started with the nav ball indicators, but there is still a lot of room for improvement).

Boldface mine

I keep on saying that. Is 6km bad? Look at the set of landing ellipses below. Because that's what you get in real life :) (6km is 3.72 miles for those unsure)

6km is GOOD. Better than good, it's GREAT.

You might be able to get things MORE accurate but some inaccuracy is inherent to FAR or any other system where drag depends on orientation for all the reasons already discussed. That's just the nature of the beast.

zLK8OBgl.jpg

Link to comment
Share on other sites

This is a brilliant mod. My only wish is that I could turn trajectories off when not in use as the thick white line makes seeing the symbols hard, My first attempt saw me nearly miss my burn because I couldn't see where my craft was in orbit. But if you figure that out and maneuver nodes I'll be adding this to my mod list and be telling all my friends :)

Link to comment
Share on other sites

This is a brilliant mod. My only wish is that I could turn trajectories off when not in use as the thick white line makes seeing the symbols hard, My first attempt saw me nearly miss my burn because I couldn't see where my craft was in orbit. But if you figure that out and maneuver nodes I'll be adding this to my mod list and be telling all my friends :)

Never mind I found how to turn it off, Maneuver Node integration and Blizzy toolbar would make this perfect

Link to comment
Share on other sites

If I might make a suggestion: Please Add toolbar support (Either stock or Blizzy's) because while having the ability to turn the trajectories on and off are amazing, it is a tad bit annoying to have the boxes constantly displayed in map view.

Link to comment
Share on other sites

If I might make a suggestion: Please Add toolbar support (Either stock or Blizzy's) because while having the ability to turn the trajectories on and off are amazing, it is a tad bit annoying to have the boxes constantly displayed in map view.

That's implemented since version 0.1.1 (stock toolbar button to show/hide the GUI window), are you sure you have the latest version ?

Blizzy toolbar would make this perfect

Are there particular benefits of integrating in Blizzy toolbar, more than the stock toolbar ? (that's a real question, I find the stock toolbar works just fine for me, but maybe with lots of plugins or I don't know whatever reason you could have)

Link to comment
Share on other sites

I keep on saying that. Is 6km bad? Look at the set of landing ellipses below. Because that's what you get in real life :) (6km is 3.72 miles for those unsure)

Earth is about 10 times bigger than Kerbin, so you should translate 6km to 60km if it was in real life (to keep proportions with the planet size, but that's biased since Kerbin's atmosphere is not to scale). That's still acceptable compared to your examples though. But they had to deal with real aerodynamics, wind, etc, while FAR is "just" a "simple" simulation, of which we even have source code. Also, that's for forward simple pod entry, but I get awful results for backward entries at this time (35km or more for a simple rocket), something must be wrong somewhere. It gets worse with deadly reentry shields, but I don't know yet if it's just the same bug that has exagerated results, or if there is some sort of incompatibility with DR.

Link to comment
Share on other sites

AH, finally found the bug that made weird things for FAR and NEAR predictions : the vessel mass was incorrect ! I think what I was using is the dry mass, so vessels with fuel, and maybe DRE shields and other parts, were introducing a big error in the prediction. This did not impact stock aerodynamics since the weird approximation Squad has chosen for this (temporary ?) model makes it independent of mass. I will make the necessary adjustments to fix this bug, and things should become much more precise and reliable (doesn't mean there aren't other bugs of course).

Link to comment
Share on other sites

Great job. Do you think that you would be able, sooner or later, to plot a landing ellipse showing the reachable area (with approximations, doesn't need to be realtime) instead of the simple cross?

Sure, why not, but that's clearly not a priority at this time. Added on the feature requests.

Link to comment
Share on other sites

This looks absolutely splendid. I won't be able to test this for you because I have too many mods, it would probably conflict with like 90% of them. You say that FAR aerodynamics profile will work correct? What about for several mods like B9, TV aerospace, K9 Rocketry and several miscellaneous mods, would they work with it?

I really hope this gets implemented in a later update. This seems REALLY REEAAAAALLLLYYYYYY handy to have.

Link to comment
Share on other sites

This looks absolutely splendid. I won't be able to test this for you because I have too many mods, it would probably conflict with like 90% of them. You say that FAR aerodynamics profile will work correct? What about for several mods like B9, TV aerospace, K9 Rocketry and several miscellaneous mods, would they work with it?

I really hope this gets implemented in a later update. This seems REALLY REEAAAAALLLLYYYYYY handy to have.

I haven't tested it with other mods, but it should work with most mods. B9 and other part mods are "just" adding parts with their own settings, so that's fine.

There are mods however that could add forces of their own (apparently, firespitter air brakes don't, but as an example, it could have been implemented that way). The bug with air brakes / stock drag fix should be corrected now by the way, but I haven't tested (neither before or after the fix). Basically, only mods that add plugins (dll files) could maybe cause problems. Of course, software stuff are always full of surprises, so until more tests are made, there is no way to know for sure.

Link to comment
Share on other sites

Version 0.3.0 is out, with the bug fixes discussed above. I hope it will be much more reliable for everyone now.

The worst case with my automated tests is now 5km. I will add more tests soon (with wings, aerobraking, heavy/complicated crafts, inclined orbits, etc.)

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...