[1.3] Trajectories - Prediction of atmospheric trajectories

[Kobymaru]

1 hour ago, PiezPiedPy said:

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

 Oh that's what you mean! That is the peak atmospheric deceleration and has nothing to do with the impact itself.

[PiezPiedPy]

3 minutes ago, Kobymaru said:

 Oh that's what you mean! That is the peak atmospheric deceleration and has nothing to do with the impact itself.

Good job someone knows what these numbers mean better than me lol

[APlayer]

21 hours ago, PiezPiedPy said:

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 ?

Yes, yes and yes. 

What do you mean by semi-transparent? What should the opacity be? And what buttons are needed for the GUI?

[Kobymaru]

Hey guys, I have a question. Do you like the following in-flight trajectory display?

 

 

The colors can be changed, but the the line thickness unfortunately can not be. The disadvantage is that the line can be only one pixel wide. The advantage is that it is one pixel wide even in the far distance, instead of being way too thin to see.

I have been experimenting with Vectrosity, but so far no joy  There should be a way to somehow draw a wider line using GL.Quads instead of GL.Line, but for this the DrawPath() and the GLPixelLine() functions have to be reworked, and I don't know how yet.

Would you prefer this new line over the old line? Or should we keep the old line for now?

[PiezPiedPy]

On ‎14‎/‎07‎/‎2017 at 0:21 PM, Kobymaru said:

Hey guys, I have a question. Do you like the following in-flight trajectory display?

Would you prefer this new line over the old line? Or should we keep the old line for now?

I much prefer the new style, the previous wide line was rubbing me the wrong way lol, I'm glad you've found a better way to draw the line  

[PiezPiedPy]

On ‎12‎/‎07‎/‎2017 at 4:59 PM, APlayer said:

Yes, yes and yes. 

What do you mean by semi-transparent? What should the opacity be? And what buttons are needed for the GUI?

The App button that you changed has a default KSP style that shows through the background and gives the button its look, if the transparency is lost then the button doesn't look right. I'm thinking we could try a few percentages anything from 25% to 90% maybe 25%,50%,80% at first to get an idea of what it looks like. You could try by replacing the texture in your GameData/Trajectories/Textures folder to get an idea of how it looks before you post

As for the Gui, icons for the four main buttons (Info, Target, Descent, Settings) and maybe the radio toggle buttons too (we will need an on and an off version), I will find out what size icons we need and get back to you,

There is no rush for these as the Gui is in development and I'm also learning how the new 1.3 stuff works along the way.

Thanks for the effort, you can see my awesome artwork in my avatar lol, so good job I'm not doing the icons.

[PiezPiedPy]

Got some more done to the Gui. I've added the Settings page and stuck on a button to switch between the Old and New, also the pages are now persistent and the App icon turns green when Show Trajectory is active  

Screenshot of the Settings page 

 

Screenshot of the updated Info page

Edited July 27, 2017 by PiezPiedPy

[Kobymaru]

That looks really cool, I like it

I think we're gonna make a release once you feel that your code is ready!

Edited July 18, 2017 by Kobymaru

[sjbuggs]

Love this mod, I have a KOS script that lands a SSTO rocket on the runway, well most of the time (some bugs to iron out still).

Still, I know parachutes aren't supported due to staging reasons, but what about airbrakes?  I kind of figured if they were turned on before planning the deorbit burn that Trajectories would be able to take that into account but not seeing any difference between the two.  

Generally, the airbrakes would burn up regardless but wanted to try with the Ablative Airbrakes mod to shorten the time to land.

Full disclosure, still running 1.2.2.

 

[Kobymaru]

1 hour ago, sjbuggs said:

Love this mod, I have a KOS script that lands a SSTO rocket on the runway, well most of the time (some bugs to iron out still).

Glad to hear!

 

1 hour ago, sjbuggs said:

Still, I know parachutes aren't supported due to staging reasons, but what about airbrakes?  I kind of figured if they were turned on before planning the deorbit burn that Trajectories would be able to take that into account but not seeing any difference between the two.  

Generally, the airbrakes would burn up regardless but wanted to try with the Ablative Airbrakes mod to shorten the time to land.

Parachutes, airbrakes, staging: none of these will work which is all different sides of the same coin.

For prediction, we do 2 things:

1. Ask KSP for the drag data of the current vessel in the current state
2. Use this drag data to calculate the forces at various positions in this future.

To do any of [parachutes, airbrakes, staging], we would have to get the drag data for a *future* state of the vessel, which means we have to keep a copy of the vessel object around (which I don't even know what that does) or manipulate the dragcube data manually. I just don't know how to do that, sorry. And even if I would, it would be a rather big undertaking for which I probably won't have time.

 

1 hour ago, sjbuggs said:

Full disclosure, still running 1.2.2.

Then good luck to you  Might wanna do a rebuild from source against the 1.2.2 libraries to get the newest goodies.

[sjbuggs]

I see why predicting the future state of the vessel would be a problem, no issue there.  However if the airbrakes are deployed during the de-orbit maneuver setup and kept deployed through landing, what's the change that requires prediction?  Wouldn't that just add extra drag throughout re-entry?

Just curious since that scenario seems different enough from staging changes during re-entry where chutes add drag, staging changing mass and drag, etc.

 

[Kobymaru]

8 hours ago, sjbuggs said:

However if the airbrakes are deployed during the de-orbit maneuver setup and kept deployed through landing, what's the change that requires prediction?

Sorry, it seems I misunderstood. That should actually work out of the box. Does it not? Could you test this? The best way is to set the settings, do your deorbit burn, "Set current impact" as target, wait until you hit the ground and then note the deviation.

If you do that twice and you get reasonably close each time, we know the airbrakes work. If not then, we'll go from there.

1.7.0 has a precision fix so you should probably use that for testing.

[Gordon Dry]

Suggestion for Trajectories:

Show the biome of the predicted impact coordinates.

[Kobymaru]

12 minutes ago, Gordon Dry said:

Show the biome of the predicted impact coordinates.

I see your point, and maybe we'll hack one in (create an issue here: https://github.com/neuoy/KSPTrajectories/issues) but I think what we really need is a good API and Kerbal Engineer Redux integration.

I think in the long run, I would like to actually reduce the functionality of this mod, and outsource things like a displaying of all calculated values and autopilots and helpers and whatnot.

For example,all the information that we display like impact velocity, max g, target deviation ... would be pretty awesome in a KER window instead.

Except the cybutel, the KER maintainer doesn't really merge PR's very often

Edited July 22, 2017 by Kobymaru

[Kobymaru]

OK, so I tried to implement a different integrator, namely Runge-Kutta 4 (and in the process made the Verlet Integrator explicit).

You can check out my work the "integrator" branch of my repository. I think @APlayer was interested in that, the integrator code is here and here.

Unfortunately, the RK4 integrator does not improve precision, and instead just nukes performance completely (because the expensive force calculation function is executed 4 times instead of 1). 

I would appreciate it if people could take a look at it, maybe I just made an implementation mistake.

[Youen]

Do you get the same result as with the previous integrator? That could mean either you did not implement it right (but I don't think so, chances are you would get completely wrong results in that case), or more likely it just proves that precision issues do not come from the integrator, or, even worse, that getting more "precise" results will diverge more from what KSP does. Because KSP does naive integration (with a small time step, but that might only increase numerical errors). That's just a quick thought, maybe I'm wrong

Maybe integrating with the same time step as KSP would make it better? For performances, you could use the same force in multiple integration iterations (assuming it wouldn't vary too much over a short time). And then try with a naive integrator instead of Verlet.

Edited July 23, 2017 by Youen

[Kobymaru]

12 minutes ago, Youen said:

Do you get the same result as with the previous integrator? That could mean either you did not implement it right (but I don't think so, chances are you would get completely wrong results in that case), or more likely it just proves that precision issues do not come from the integrator

Depends on your definition of "the same", but it's still mostly correct. Deviation is higher than with Verlet, but still in the right ballpark (20 km off instead of 3 km).

 

13 minutes ago, Youen said:

or, even worse, that getting more "precise" results will diverge more from what KSP does. Because KSP does naive integration (with a small time step, but that might only increase numerical errors). That's just a quick thought, maybe I'm wrong

Now that would suck! I don't actually know what kind of Integrator KSP has, but maybe it's worth looking into. I'll check it out.

[Youen]

4 minutes ago, Kobymaru said:

Now that would suck! I don't actually know what kind of Integrator KSP has, but maybe it's worth looking into. I'll check it out.

I think it's just the most naive thing you can do:

velocity = velocity + acceleration * time_step

position = position + velocity * time_step

[Kobymaru]

Just now, Youen said:

I think it's just the most naive thing you can do:

velocity = velocity + acceleration * time_step

position = position + velocity * time_step

If that's the case, I wonder if we can better "accuracy" if we just do the same thing with a small enough timestep. But that, of course, will lead to performance problems.

[Youen]

5 minutes ago, Kobymaru said:

But that, of course, will lead to performance problems.

Not necessarily. If I remember correctly the default KSP timestep is 0.04 (you can see it in the game settings). If you just use the same acceleration multiple times (we are trying to solve integrator accuracy, but not to increase force computation frequency), it should be fine, as it's just a bunch of multiplications and additions (you would have about 10 "sub-steps" for each simulation step? That means 20 additions and 10 multiplications). You can even pre-compute acceleration*time_step. I can't guarantee without testing, but I don't think it will have a big impact on performances.

Edited July 23, 2017 by Youen

[Kobymaru]

11 hours ago, Youen said:

Not necessarily. If I remember correctly the default KSP timestep is 0.04 (you can see it in the game settings). If you just use the same acceleration multiple times (we are trying to solve integrator accuracy, but not to increase force computation frequency), it should be fine, as it's just a bunch of multiplications and additions (you would have about 10 "sub-steps" for each simulation step? That means 20 additions and 10 multiplications). You can even pre-compute acceleration*time_step.

Well in this case I'm less worried about multiplication performance, but more worried about accuracy, since the acceleration does change over these simulation steps.

I have another idea though, maybe we could still use the RK4 integrator, but "simulate" the error of the naive integrator (which I think could be named "euler integration"). There's a formula for the error term on wikipedia.

I have tested jacking up the delta-T using RK4, and I went from 0.1 s up to 5.0 s. It was still wrong, but it was "wrong" consistently and always hit the same spot. So if we could use RK4 with such a large time step, that would be a giant performance gain and we could even skip the cache entirely.

All that assuming that the error is not from the force calculation, but that might be a completely different investigation.

Edited July 24, 2017 by Kobymaru

[Kobymaru]

I think you might be on to something, that it might be KSP and not Trajectories that does the integration errors.

I ran the same descent 2 times, once at 1x physics acceleration and 4x physics acceleration. 

With 1x:

• 5.5 km deviation (East) from the predicted target

With 4x:

• 10.2 km deviation (East) from the predicted target
• Physically landed 5.7 km further East than with 1x acceleration

So that would indicate that the prediction would be "correct" under real physics, but KSP underestimates the deceleration because of integration errors, and that gets worse with time warp.

So if we really want to predict in that accuracy range, we're going to have to replicate the error that KSP makes.

[Youen]

On 24/07/2017 at 9:42 AM, Kobymaru said:

I'm less worried about multiplication performance, but more worried about accuracy, since the acceleration does change over these simulation steps

I'm not sure it's an issue, when you use RK4 integration you do not feed it with different accelerations for each 0.04s time step. The force varies very slowly, that's also the assumption used for the cache system. To be more precise, you could adjust the force depending on velocity, by assuming it varies with squared velocity (that would still be faster than going through the whole force computation stuff).

On 24/07/2017 at 11:08 AM, Kobymaru said:

I ran the same descent 2 times, once at 1x physics acceleration and 4x physics acceleration.

I think it would make sense to only give accurate predictions for 1x time warp. Or maybe a prediction somewhere in between. Or ultimately give players the option to choose which one they want, but that's a bit far fetched... Also I'm not sure if using 4x warp means KSP time steps are multiplied by 4, or if it depends on the computer CPU power. In any case, if even the KSP simulation can't be reproduced with high precision, it won't be possible to predict it with a greater precision... I also remember that at some point I made tests and noticed that saving/loading could change the landing spot.

[Kobymaru]

1 hour ago, Youen said:

I'm not sure it's an issue, when you use RK4 integration you do not feed it with different accelerations for each 0.04s time step. T

Of course, that was the whole point of using RK4  I'm actually using a time step of 1s or 2s and I'm still getting good accuracy. Compared to 0.1s, that's like a 5x performance improvement. If we could make precision work under these conditions, we don't even need a cache.

1 hour ago, Youen said:

I think it would make sense to only give accurate predictions for 1x time warp. Or maybe a prediction somewhere in between. Or ultimately give players the option to choose which one they want, but that's a bit far fetched...

Right now I am just using the current value of the time warp for prediction. Using the Local Truncation Error estimation for Euler, I'm already getting pretty close to the old precision (but with better performance). But there is still this the force error high-altitude which probably interferes with the investigation, so it might be best to figure that out first.

1 hour ago, Youen said:

Also I'm not sure if using 4x warp means KSP time steps are multiplied by 4, or if it depends on the computer CPU power.

Yes, it means that the steps are multiplied.

1 hour ago, Youen said:

In any case, if even the KSP simulation can't be reproduced with high precision, it won't be possible to predict it with a greater precision...

Yes, there might be upper limits to what we can do with Trajectories, but I would quite like to explore those  Even if it means to replicate KSP's errors

1 hour ago, Youen said:

I also remember that at some point I made tests and noticed that saving/loading could change the landing spot.

The actual spot on the surface, or just the targeted point? If it's the latter, it's just that the world coordinates are not preserved between loads. But KSP does some funny things and coordinate translations on save/load and on-rails transition, so who knows.

[sjbuggs]

On 7/21/2017 at 1:25 AM, Kobymaru said:

Sorry, it seems I misunderstood. That should actually work out of the box. Does it not? Could you test this? The best way is to set the settings, do your deorbit burn, "Set current impact" as target, wait until you hit the ground and then note the deviation.

If you do that twice and you get reasonably close each time, we know the airbrakes work. If not then, we'll go from there.

1.7.0 has a precision fix so you should probably use that for testing.

My old (Ivy Bridge) system melted down, so haven't had a chance to try this until hopefully this weekend with replacement system.

Does Trajectories 1.7 work on with KSP 1.2.2?