Kobymaru

[1.3] Trajectories - Prediction of atmospheric trajectories

Recommended Posts

I never test it in near, I have far..

But I had understand that the only difference that nears has with far is all the UI that show your flying data.. but if in nears works fine, then I am mistake.

It's a bit more complicated than that. NEAR doesn't break parts due to aerodynamic failures, doesn't change aerodynamic behavior depending on mach number, and apparently is proportional to air density while FAR isn't. So NEAR really uses a simpler model (which still looks convincing to me, huge improvement over stock).

I'll try to make a pre-release of the FAR fix today (seems to work already, but I haven't made a lot of tests)

Share this post


Link to post
Share on other sites

I found the bug that was causing NaN with FAR when exiting/entering the atmosphere : it's the new rho calculation depending on altitude that was sending rho=0 to FAR. Easy to fix as in this case there is no air, so no aerodynamic force. I think it's now ready for the pre-release, I'll post the DLL here for anyone that want to test, and send a pull-request to Kobymaru for the actual release.

EDIT:

here is the pre-release : https://github.com/neuoy/KSPTrajectories/releases/tag/v1.1.3-rc1

@Kobymaru I sent you a pull request, let me know if you want to publish the release or if I do it (it's fine by me either way, really a matter of who is more available at the time)

Edited by Youen

Share this post


Link to post
Share on other sites
As per the first page of this thread: It is a known issue that FAR/NEAR landing predictions are inaccurate due to the methods used by Trajectories to calculate with the new drag model. Methods to improve accuracy without drastically reducing performance are being developed.

...

Keep at it Kobymaru!

It would be perfectly acceptable so the calculation would not be live. I don't need recalculation 10 times per second. There could be a button "Recalculate" Which would compute trajectory for current path and planed maneuver node. it can take up as much as 30s, I have all the time in the world.

And it should use this sound:

Have a nice day

edit:

I almost always enter atmosphere in reverse/retrograde. Can you set the default AoA in the descent profile to -180° for all sliders. Or make a button for retrograde, a button for prograde, and use the sliders for something in between.

Edited by sralica
new idea

Share this post


Link to post
Share on other sites

I have a boring UI bug.

I have blizzy's toolbar installed, and I checked off the Trajectories box, but it doesn't appear. I want to turn on (or off?) body-fixed mode so that my landing predictions are accurate.

In case I misunderstand the issue, here's a detailed decription of the problem symptoms:

When I go to plan re-entry, I make a maneuver node so that the impact X is where I want ti (usually the KSC). I usually plan this about a quarter to a half orbit before the actual burn so I have lots of time to tweak it. After I actually execute the burn my blue orbit matches up with the trajectory, until it hits the atmosphere, as expected. Once I'm actyually in the atmosphere though, both my blue orbit and the red line go down, and I end up landing way short of the target. I figure this is either because Trajectories is not accounding for the rotation of the planet, or because i'm using NEAR, and that's somehow messing up the calculations.

Share this post


Link to post
Share on other sites
I have a boring UI bug.

I have blizzy's toolbar installed, and I checked off the Trajectories box, but it doesn't appear. I want to turn on (or off?) body-fixed mode so that my landing predictions are accurate.

In case I misunderstand the issue, here's a detailed decription of the problem symptoms:

When I go to plan re-entry, I make a maneuver node so that the impact X is where I want ti (usually the KSC). I usually plan this about a quarter to a half orbit before the actual burn so I have lots of time to tweak it. After I actually execute the burn my blue orbit matches up with the trajectory, until it hits the atmosphere, as expected. Once I'm actyually in the atmosphere though, both my blue orbit and the red line go down, and I end up landing way short of the target. I figure this is either because Trajectories is not accounding for the rotation of the planet, or because i'm using NEAR, and that's somehow messing up the calculations.

The mod should work with NEAR and take planet rotation in account. The red X always shows the landing location on the planet (it rotates with the planet). Landing short of the target is a common symptom of planning a prograde entry but performing a retrograde, can you check you have set the four sliders to 180° in the descent profile (assuming you are entering retrograde)? Also, version 1.1.3-rc1 may help with prediction accuracy.

Share this post


Link to post
Share on other sites

I'm, not sure what you mean by 'four sliders' - There's no UI for trajectories that I can see, just the lines in map mode?

Share this post


Link to post
Share on other sites

You should have a button in the toolbar in map view, that opens the UI window (unless there is a bug, let me know if that's the case)

Share this post


Link to post
Share on other sites
I thought I would not fall again, but apparently I couldn't resist trying KSP 0.90 and have been playing again for some days (and nights).

...

Hi! Sorry I have been hiding, I had an important exam. Now I should be more active.

Thanks for your great work! I tested it and prediction is spot on. Costs quite a bit CPU, though (~40% on my box).

I saw that you already uploaded it to KerbalStuff. Is there any other place where you want to release it as well?

Edited by Kobymaru

Share this post


Link to post
Share on other sites

Hi,

No problem, we all have our lives :-) I hope your exam worked out fine.

You could release on your github page (since it's linked on the release thread) and update the release thread title, and I think that's it :-)

Also, I've deleted on my github repo the automated test projects, as well as the API (I think no one uses it at this time, so I wanted to trim down the code to ease maintainance, but might have been a bad timing since someone just posted about it in the release thread). I didn't include that in the pull request but if it's fine by you we could merge to have the same code base and avoid future merge headaches?

Share this post


Link to post
Share on other sites
You could release on your github page (since it's linked on the release thread) and update the release thread title, and I think that's it :-)

Done!

Also, I've deleted on my github repo the automated test projects, as well as the API (I think no one uses it at this time, so I wanted to trim down the code to ease maintainance, but might have been a bad timing since someone just posted about it in the release thread).

Maybe we should wait until either the question is clear or we haven't heard from the guy in like, 1-2 weeks?

I didn't include that in the pull request but if it's fine by you we could merge to have the same code base and avoid future merge headaches?

Yes, that would be very nice. I tried to merge your branch, but there was a conflict. I think it is because Trajectory.cs was basically rewritten in this commit: 7043119. Is there a reason why the file seems completely new? Is that a Line Ending issue or something?

Share this post


Link to post
Share on other sites

Sorry, didn't see your post. I don't know why the whole file appears modified, maybe line endings as you said, or indentation or something. I didn't change much actual code (if I remember correctly, I just merged some test code I hadn't commited before).

Share this post


Link to post
Share on other sites

Many people have problems with FAR predictions accuracy. I suggest making an input box in the advanced menu of Trajectories called "Drag Factor" with a number by changing which we can tweak the drag predictions.

For example "1" will be default drag model.

Those who are coming short of the target location will input a number higher than 1 to correct the inaccuracy.

Those who are coming far ahead of the target location will input a number less than 1.

For example I will increase the drag factor to 1.15 for most of my pods. Some crafts will need a drag factor of 1.20, some of 0.95. Trajectories mod can't model the drag in FAR very accurately, and people will have an option to find the right drag factor for each of their craft to get an exact atmospheric trajectory prediction.

Share this post


Link to post
Share on other sites

I am actually quite interested in Trajectory's API, I have a question about it. The API only lets you query for the active craft. How hard would it be to extend the API to let someone specify one of the loaded craft?

Share this post


Link to post
Share on other sites

Hi, just showing up with an item for the wishlist: a checkbox to calculate with airbrakes deployed.

Considering they make a major impact of trajectory, I think being able to include them would be a pretty big change for the better.

Anyway, thanks for the awesome mod, cant live without it!

Share this post


Link to post
Share on other sites

And finally, we can do things like these:

LqNDqJt.png

I hope this really helps with numeric debugging.

Share this post


Link to post
Share on other sites

Just a heads up on a New Gui I'm cobbling together.

If anyone wants to follow progress of the code you can view it on GitHub here NewGui-Test

I'll be posting screenshots of how the GUI progresses and any input from you guys can only help with a GUI that covers most users needs.

I'm also adding Localization so any help with translations when the time arises will be greatly appreciated.

Share this post


Link to post
Share on other sites

Quick screenshot of the the new Gui so far

1lBc1R9.png

Edited by PiezPiedPy

Share this post


Link to post
Share on other sites

Wow, that looks amazing!

I'm really looking forward to it :)

Just as a side note though: you shouldn't recreate the old UI one to one, instead we should try to find a more "natural" user experience. That's why I asked to put early versions in this thread: I'm sure you could recreate the old UI without problems, but I wanted to use the opportunity to clean it up and make it clearer.

For example: the craft position in lat/lon is not really necessary at this place, is it? It doesn't necessarily help with landing, and if I *did* need it, I would take the readout from MechJeb2 and Kerbal Engineer.

Share this post


Link to post
Share on other sites

@Kobymaru Thanks!

Its early days, so we can change things on the fly.

Regarding the craft position I have no idea why it was displayed in the old gui. I'll give it the boot. Or maybe we should add the Impact lat and lng values in its place.

I'm also toying with the idea of a tiny popout info window that shows only the Impact G-Force and Impact Velocity values.

 

 

Share this post


Link to post
Share on other sites

So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. :)

And, while we are at things like that, if I may make a feature request...

So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.

Share this post


Link to post
Share on other sites
2 hours ago, PiezPiedPy said:

I'm also toying with the idea of a tiny popout info window that shows only the Impact G-Force and Impact Velocity values.

What is the "impact g-force" and how do we calculate it? Depending on the how the craft "crumbles", impact g-force can be infinite :wink:

I'm not sure if putting numeric readouts into popup windows is a good idea, because that will make them hard to find for novices and annoying to read out for those who need them.

On the other hand, I understand the desire to "put them away" since I don't recall ever having used them in day-to-day life.

2 hours ago, PiezPiedPy said:

Regarding the craft position I have no idea why it was displayed in the old gui. I'll give it the boot. Or maybe we should add the Impact lat and lng values in its place.

I had a thought: what if we add some sort of "Info" section (or popout window?) that looks similar to a Kerbal Engineer Redux window with all kinds of numerical readouts? This doesn't have to be configurable (for now), we'll just stuff it full with all that we have now.

That reminds me... we should really polish up the API so that maybe we can even plug Trajectories into Kerbal Engineer.

1 hour ago, APlayer said:

So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. :)

Well if it takes less than five minutes, you could do it real quick and show us the result, and we go from there :wink:

 

1 hour ago, APlayer said:

And, while we are at things like that, if I may make a feature request...

So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.

I am very much in favor of that and have been missing this feature forever. I don't know yet when to find time to implement that, though...

By the way, as it so happens, I am currently working on a section about feature requests in the contributors documentation. It's not completed yet, but you should check it out!

Share this post


Link to post
Share on other sites
1 hour ago, Kobymaru said:

[...] you could do it real quick and show us the result [...]

Here we go: MkdF3Lr.png

Share this post


Link to post
Share on other sites
On 9.7.2017 at 9:12 PM, APlayer said:

Here we go: MkdF3Lr.png

Ok, thanks, I think I get the picture now.

The problem that I see is two-fold: First of all, simply a different color is not a great indicator of what is going on. Seems very unrelated to the Body-Fixed setting. Sure, it could be mentioned in the README - but no one reads that anyway. Button naming / icons should work without a README and be obvious without ever having touched a manual.

Secondly, I just don't think that the state of "body-fixed" is important enough to change the icon color. Currently it's in the main window anyway, and the checkbox itself is plenty visible. Why would we need to make this so prominent?

If anything, a color change would be warrented when the trajectory is calculated vs when it's not.

Edited by Kobymaru

Share this post


Link to post
Share on other sites
On ‎09‎/‎07‎/‎2017 at 7:04 PM, Kobymaru said:

I had a thought: what if we add some sort of "Info" section (or popout window?) that looks similar to a Kerbal Engineer Redux window with all kinds of numerical readouts? This doesn't have to be configurable (for now), we'll just stuff it full with all that we have now.

Sounds good too me.

 

4 hours ago, Kobymaru said:

If anything, a color change would be warrented when the trajectory is calculated vs when it's not.

I have to agree with this but rather the colour should be green. (Edit: I have just implemented this in the new Gui)

We could also use the yellow icon when the trajectory is calculated and auto fixed body is on but it only shows when fixed body mode is active. Also since fixed body when in auto mode is only active when in the atmosphere it will be like an indicator showing when the craft is currently in the atmosphere which I like a lot :wink:

 

On ‎09‎/‎07‎/‎2017 at 8:12 PM, APlayer said:

Here we go: MkdF3Lr.png

Can you change the blizzy icon too please, also can the background be semi-transparent on the new icons and if you can, would you be willing to create icons for the buttons in the Gui ?

Edited by PiezPiedPy

Share this post


Link to post
Share on other sites
On ‎09‎/‎07‎/‎2017 at 7:04 PM, Kobymaru said:

What is the "impact g-force" and how do we calculate it? Depending on the how the craft "crumbles", impact g-force can be infinite :wink:

private static string Get_ImpactGforce()
{
    return string.Format("Impact G-force:  {0,6:0.00}", Settings.fetch.DisplayTrajectories ? Trajectory.fetch.MaxAccel / 9.81 : 0);
}

The code above is what I've used in the new Gui and was based on the old Gui math.

Share this post


Link to post
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.