[1.4.+] Kerbal Wind Tunnel Development Thread

[Booots]

All I wanted was to figure out how much excess thrust I had for my spaceplane along its ascent profile. And then I wanted to know the lift curve slope and level flight AoA so I could program my kOS spaceplane autopilot better.

Next thing you know, I'm writing a mod to work in the Spaceplane hangar to calculate flight envelopes, alpha curves, and so much more. And it works, sort of totally! Check out the release thread here: https://forum.kerbalspaceprogram.com/index.php?/topic/177302-ksp-142-kerbal-wind-tunnel/

 

This shows that the Aeris 4A has a ceiling of about 22km and a max speed at sea level of about 790m/s and a max overall speed of about 1360m/s at around 14km using its air-breathing engines. Then, at 15km and at 964m/s its level-flight AoA is 2.8 degrees and it has 365kN of excess thrust. Great!

But now I want to freshen up the GUI (thanks @TriggerAu, but this was clearly designed for Transfer Window Planner ) and add in Lift, Drag, and L/D curves for a given altitude and mach number. I also want to move to using background threads for calculating (right now, I either hang the program for 20 seconds while it calculates that graph or put up with artifacts from my non-thread-safe implementation on the BackgroundWorker, as you can see).

First, some credits:

Thanks to @linuxgurugamer and @Boris-Barboris. I learned a ton about the aerodynamics model from your Correct COL mod. Also your method of drawing line graphs is coming in handy for the lift curves I'm working on drawing.

Thanks to @TriggerAu. I learned a ton about making the graph from your Transfer Window Planner.

And thanks to the MechJeb team. I'm using a lot of your tricks to make things more thread-safe.

Edited August 10, 2018 by Booots

[MaverickSawyer]

Okay, THIS looks like a future must-have mod.

[Booots]

Okay, so I've gotten some of the GUI issues sorted out. I'm still having trouble with my new graph-generation method, but when logged to Excel, the data looks good.

Not the best visualization, but it looks like my new threads are getting the same-ish data as before, but in a fraction of the time and without cross-threaded artifacts.

I've also added part highlighting to add a sort of CFD feel. Now it'll highlight high-drag parts in red, and low-drag parts in blue, with green somewhere in the middle.

Seen here, the engines are the draggiest part since they have no taper to the back. The wings (because of the drag component of lift) and the nose also contribute a fair amount. At higher speeds, the RCS pods and antenna also turn orange/red because they stick out into the airstream.

Edited May 4, 2018 by Booots

[Booots]

Just pinging a few people who have asked for a feature like this in the past.

Would you mind giving some feedback? Is this starting to fall in line with what you envisioned?

@p1t1o @Jonfliesgoats @BT Industries @Spartwo @ZooNamedGames. And @eddiew, you once said "I'm going to be that guy and ask what the wind tunnel/testing ground will offer that launch/try/revert doesn't..." so I'm pinging you to see what your comments are. Does this show promise as a design tool beyond repeated testing?

Edited May 6, 2018 by Booots

[Booots]

Also, as I start planning for a beta release in the next week or two, I need to sort out some licensing things.

I'm using @TriggerAu's KSP Plugin Framework (which is MIT-licensed), a root-finding algorithm that is BSD-licensed, and a derivative work of the SimulatedVessel and SimulatedPart classes from @sarbian's MechJeb2 (which is GPLv3). I'm not very familiar with open-source licenses and so I want to make sure I get this right (or at least, right by the people who's code I'm helped by).

My current plan is this: my own code will be MIT, TriggerAu's code stays MIT, the BSD code stays BSD, and my derivatives of Sarbian's work will be GPLv3. The compiled DLL (and the project as a whole) would then have to be GPLv3 because it links to GPL code, right? And from what I understand, MIT and BSD code is compatible with such an arrangement. TriggerAu and Sarbian, are you both satisfied with this arrangement?

Edited May 7, 2018 by Booots

[sarbian]

No problem here. If I could I would change MJ's licence to something else...

Edit: I did not look if you use thread or not but if you don't you should be able to use the stock dragcube calls without using MJ code

Edited May 7, 2018 by sarbian

[Booots]

21 minutes ago, sarbian said:

No problem here. If I could I would change MJ's licence to something else...

Edit: I did not look if you use thread or not but if you don't you should be able to use the stock dragcube calls without using MJ code

Yeah, it's the threading that's doing it. Also, I'm guessing you're stuck with the license because of inheriting a license from an older version by someone else? If that is the case, you could theoretically license your own bits of the code under a different, but compatible license as long as the project as a whole stays GPL (according to my reading, at least). Since it looks like the SimulatedVessel and SimulatedPart classes are by you, personally, doing this to those files would let me avoid the GPL for this project, too. Just throwing it out there as a possibility, not actually asking you to do that for me - I don't like imposing on other authors.

[sarbian]

Yeah, those are 100% mine. 

Ok. I grant you the right to license those file under the MIT license. I'll do something more explicit one when I have the time

[Mathrilord]

Is it compatible with parts/physic mods?

Feature request:

Part focus
Possibility to add equation

New variable:

             engine performance(first stage); fuel consumption rate, efficiency(f.c.r. X speed), range, climb rate(aka vertical speed), air intake, ec production

             simmulation; time, mass variation(due to fuel burn), throttle, acceleration, heat status, angular momentum, angular force

             info; heag(rtinate), drag, lift, dynamic pressure, pressure, dynamic temperature, temparature, air speed,
             reaction wheel usage and control surface deploiement(to maintain the AoA), ec usage frome S.A.S.

Assignable axis; x, y and z (color)
(toggle fourth and fifth axis;
how: (x, y, z, w, v) color intensity
for axis((z(),w(),v())(x,y))
axis()(color(blue, red, yellow)
axis() assigned var range(min,max) into axis()(0, 1/3%) 
z()+w()+v()+white()=100%

May have use the wrong term or expression, english isn't my native language.

[ZooNamedGames]

On 5/6/2018 at 7:56 PM, Booots said:

Just pinging a few people who have asked for a feature like this in the past.

Would you mind giving some feedback? Is this starting to fall in line with what you envisioned?

@p1t1o @Jonfliesgoats @BT Industries @Spartwo @ZooNamedGames. And @eddiew, you once said "I'm going to be that guy and ask what the wind tunnel/testing ground will offer that launch/try/revert doesn't..." so I'm pinging you to see what your comments are. Does this show promise as a design tool beyond repeated testing?

I'll have to definitely give this a shot. From what I'm seeing currently, this is absolutely what I was looking for; which is providing static data for the vehicle. The only suggestion, I can provide (without testing the mod) is adding the lift/drag markers that can be seen in flight, but have each show for when each surface is activated (so you can see the L/D when static in the SPH/VAB).

But once it becomes available, I'd love to see how it works.

[eddiew]

On 5/7/2018 at 12:56 AM, Booots said:

And @eddiew, you once said "I'm going to be that guy and ask what the wind tunnel/testing ground will offer that launch/try/revert doesn't..." so I'm pinging you to see what your comments are. Does this show promise as a design tool beyond repeated testing?

It's entirely possible I don't understand enough of what the numbers are saying to pass judgement... but most likely yes xD

The drag analysis is definitely interesting to me, since that's one of the hardest things to debug, even with the visualisations. Quite often I see a mass of red lines from the centre axis, and it'll turn out to be something inside a cargo bay that shouldn't be draggy but mysteriously is, so if your wind tunnel can highlight that then it's definitely useful ^^

An idea that might be useful, but I'm not sure how easy it would be to implement...

• Input an altitude/velocity profile, e.g. 300m/s at 5km, 600m/s at 10km, 900m/s at 15km, 1400m/s at 22km (1500m/s at 24km for the thrill seekers)
• Input a desired ascension angle, e.g. I want my prograde to be 5 degrees above the horizon. Maybe allow this to be entered per-altitude as above.
• Calculate the AoA required to maintain that prograde angle, the drag, and thrust at each point.
• If thrust is always significantly more than drag, then you have enough engines. (If it's like 3x the drag or more, you may have excess engines.)
• The lower the AoA the healthier the plane, though the AoA required naturally climbs with altitude. Under 5 degrees over prograde ASL is good.
• In an ideal world, calculate how much fuel is burnt during the ascent. If the readout says you'll get to 24km at 1400m/s having burnt 600LF, then players can tweak tanks to see their rocket range in MJ or KER. (Honestly, LFO to LF ratio is one of those things that players start to intuit after a while, but a lot of newbies ask for numbers and there simply isn't a hard and fast ratio because every plane is different.)

I mean, all of these things can be handled without maths by trial and error flight, but if you want to do on-paper modelling, then that's the sort of output I feel would be valuable. In my mind, the above readouts would give me a clue as to whether I could point the SAS at 10 degrees above the horizon and fly dead-stick until the rockets kick in   

Edited May 9, 2018 by eddiew

[Boris-Barboris]

Keep in mind that CorrectCoL math is not precise: mod did not search for equilibrium control surface position to maintain this particular AoA and always assumed default (neutral) pitch\roll\yaw.

If you desire correctness, you should tackle this.

[Booots]

On 5/9/2018 at 10:46 AM, eddiew said:

• Input an altitude/velocity profile, e.g. 300m/s at 5km, 600m/s at 10km, 900m/s at 15km, 1400m/s at 22km (1500m/s at 24km for the thrill seekers)
  • I'll one-up this. :p It already covers the whole speed/altitude range you can dream of, all at once.
• Input a desired ascension angle, e.g. I want my prograde to be 5 degrees above the horizon. Maybe allow this to be entered per-altitude as above.
  • This is a good idea, between speed, altitude, and prograde angle, I can put out an apoapsis. This may or may not account for drag after your air-breathing engines cut out. I'll see what I can do. I like this idea.
• Calculate the AoA required to maintain that prograde angle, the drag, and thrust at each point.
  • Already got!
• If thrust is always significantly more than drag, then you have enough engines. (If it's like 3x the drag or more, you may have excess engines.)
  • The charts above show the speed/altitude envelope where thrust is greater than drag.
• The lower the AoA the healthier the plane, though the AoA required naturally climbs with altitude. Under 5 degrees over prograde ASL is good.
  • That chart takes into account the effect of AoA - high (unhealthy) AoAs have more drag and so the chart cuts out because you stall or don't have enough thrust.
• In an ideal world, calculate how much fuel is burnt during the ascent. If the readout says you'll get to 24km at 1400m/s having burnt 600LF, then players can tweak tanks to see their rocket range in MJ or KER. (Honestly, LFO to LF ratio is one of those things that players start to intuit after a while, but a lot of newbies ask for numbers and there simply isn't a hard and fast ratio because every plane is different.)
  • I might* be able to implement this, it depends on how easy the line integration is walking up the excess thrust/energy envelope.

 

21 hours ago, Boris-Barboris said:

Keep in mind that CorrectCoL math is not precise: mod did not search for equilibrium control surface position to maintain this particular AoA and always assumed default (neutral) pitch\roll\yaw.

If you desire correctness, you should tackle this.

Thanks for reminding me. I'm making that same assumption so far too. That is possible with the current solving framework I've got, but it would add a lot more computation time because it adds a second level of equations to solve. I have to solve which AoA the craft needs for level flight, then what control input is needed for that AoA, and then what effect that has on the lift produced (and then changes the AoA needed) and so recurses. Actually, y'know... It might be faster to solve what control input is needed for level equilibrium flight directly because that removes the recursion need. I think this will be a later feature to add.

[Boris-Barboris]

30 minutes ago, Booots said:

It might be faster to solve what control input is needed for level equilibrium flight directly because that removes the recursion need

There's no direct way, only iterative approximation. Anyway, it's your call.

Edited May 12, 2018 by Boris-Barboris

[Booots]

Another development update: It turns out the threading is still causing something weird. I was pretty sure I had taken all appropriate precautions but I'm still getting a different result depending on if I the drag cube calculations on a background thread or the main thread. It's super weird (as multithreading bugs often are). I've narrowed it down to one or three methods, but I still can't figure out where they're going wrong. 

Once I get those sorted out, it's a matter of drawing axis on the graphs and working out tooltips and this should be ready for a beta release.

[sarbian]

7 minutes ago, Booots said:

Another development update: It turns out the threading is still causing something weird. I was pretty sure I had taken all appropriate precautions but I'm still getting a different result depending on if I the drag cube calculations on a background thread or the main thread. It's super weird (as multithreading bugs often are). I've narrowed it down to one or three methods, but I still can't figure out where they're going wrong. 

Once I get those sorted out, it's a matter of drawing axis on the graphs and working out tooltips and this should be ready for a beta release.

Do you use copy of the FloatCurve or do you use the original ? The class is not thread safe at all (it has some strange caching)

Edited May 15, 2018 by sarbian

[Booots]

17 minutes ago, sarbian said:

Do you use copy of the FloatCurve or do you use the original ? The class is not thread safe at all (it has some strange caching)

I copy it to the each SimulatedPart, SimulatedVessel, and SimulatedLiftingSurfaces when they're created but these are then shared between my background threads. I am locking against these everywhere I use them, though. Same with the cloned DragCubeLists. I'd rather not have to clone the whole SimulatedVessel tree for each of the 12-ish background threads and just use locking (because that should work, right?) because I suspect cloning will take longer than the time penalty for locking.

[sarbian]

I cache the cloned curves since the value never changes so I can reuse them for threads

Edited May 15, 2018 by sarbian

[Booots]

Sorry I haven't posted any updates in a while. My girlfriend and I adopted a puppy a few weeks ago. And while he's super adorable, supervising him is almost a full-time job so I haven't had any time for working on this. I'm hoping to get a bit done this week, though!

[Booots]

Success! While the puppy napped today, I found that one of the KSP functions I was calling was resetting a few FloatCurves to the global ones in the game instead of the cloned ones I was using for each thread. Now there are no more cross-threading issues and the results look good. Now it's just a matter of cleaning up the UI; adding axes and units and stuff to the graph; adding tooltips and the ability to click on the graph for info (this, admittedly, might take me some time); and then a releasable version should be ready to go.

Later version features I want to add:

• A line showing the optimal ascent path for a given orbital altitude (and an estimate of the rocket stage's dV requirement).
• Accounting for the deflection of control surfaces.
• Anything else?

[Booots]

It's ready for a pre-release! Grab it here from the Github page: https://github.com/DBooots/KerbalWindTunnel/releases

@eddiew@ZooNamedGames@Mathrilord@MaverickSawyer, would you guys mind trying it and letting me know what you think? Thanks!

Edit: It still has the same icons as my ReCoupler mod (I'm not good with graphics) so don't be too confused.

Edited June 21, 2018 by Booots

[FleshJeb]

This goes beyond my wildest dreams.

At one point, I wanted to design a rudimentary machine-learning system that would take a basic characterization of the aerodynamics and thrust of a spaceplane, fly a few ascents, and find an ascent profile approaching optimal; attempting to improve each time. That would obviously be very time-consuming, and examining per-part drag values in flight is a giant pain. (I got to the point where I asked the KRPC dev to please make them available.) This is SO MUCH BETTER.

My only critique thus far is that it may be hard to identify parts that have low absolute drag, but are highly draggy relative to other parts of their size. You mentioned that the RCS blocks eventually showed up as being highly draggy, but something like the 1.25m reaction wheel (which should never be exposed to air IMO) may not. Or the opposite case where service bays are extremely slippery.

Potential solution to above:

• CorrectCoL has the ability to compress/exaggerate the lower end of the AoA scale. You could do this by having the option to exaggerate the ends of the highlight color scale.
• Alternately, or in addition: The ability to restrict the highlighting by form factor and ignore the rest. i.e. Only examine parts of a certain size class; surface attached parts only; above or below a specified mass.

Do you think it's 1.3.1 compatible? I may just have to try it and find out.

EDIT: Forgot to ping @AeroGav

Edited June 21, 2018 by FleshJeb

[eddiew]

Acknowledging the ping, and yes I will give it a test, I just... totally forgot... and now it's bedtime. 

[eddiew]

Right, some impressions!  

Love the drag highlighting; immediately spotted a rocket engine that I hadn't capped with a hidden nosecone. Identified stuff stuck to the end of the cargo bay not being properly protected. Didn't seem to spot raised airbrakes, but that's basically fine because we know that those do.

Could perhaps do with clarification about the colour highlighting rules though; I see a lot of teal and I'm not sure if that means none, not applicable, or beyond green or... 

AoA curve lift/drag ratio; brilliant. Immediately tells me to fly at 6-7 degrees AoA for best effect.

Mildly confused by Flight Envelope/Thrust Available; suggesting lots of thrust at 500m/s while looking at a craft that tops out around 200-250. Excess Thrust seems right on the money, and maybe what I'm seeing in Thrust Available is the speed it would reach without drag?

[Booots]

EDIT: There's a new version on the Github page ( https://github.com/DBooots/KerbalWindTunnel/releases ) if you want the latest.

23 hours ago, FleshJeb said:

This goes beyond my wildest dreams.

At one point, I wanted to design a rudimentary machine-learning system that would take a basic characterization of the aerodynamics and thrust of a spaceplane, fly a few ascents, and find an ascent profile approaching optimal; attempting to improve each time. That would obviously be very time-consuming, and examining per-part drag values in flight is a giant pain. This is SO MUCH BETTER.

Right?! I wanted to simply know the CL-alpha curve so I could write a kOS autopilot that accounted for the physics of the plane instead of brute-force multi-layered control systems.

My only critique thus far is that it may be hard to identify parts that have low absolute drag, but are highly draggy relative to other parts of their size. You mentioned that the RCS blocks eventually showed up as being highly draggy, but something like the 1.25m reaction wheel (which should never be exposed to air IMO) may not. Or the opposite case where service bays are extremely slippery.

Potential solution to above:

• CorrectCoL has the ability to compress/exaggerate the lower end of the AoA scale. You could do this by having the option to exaggerate the ends of the highlight color scale.
• Alternately, or in addition: The ability to restrict the highlighting by form factor and ignore the rest. i.e. Only examine parts of a certain size class; surface attached parts only; above or below a specified mass.

I like this idea, and it should be as simple as writing a function that compresses the values or normalizes them by size

Do you think it's 1.3.1 compatible? I may just have to try it and find out.

Maybe? It's compiled for 1.4, but it only calls on GUI functions and stock aero methods so it might work.

Replies injected into the quote in blue.

1 hour ago, eddiew said:

Love the drag highlighting; immediately spotted a rocket engine that I hadn't capped with a hidden nosecone. Identified stuff stuck to the end of the cargo bay not being properly protected. Didn't seem to spot raised airbrakes, but that's basically fine because we know that those do.

Could perhaps do with clarification about the colour highlighting rules though; I see a lot of teal and I'm not sure if that means none, not applicable, or beyond green or... 

AoA curve lift/drag ratio; brilliant. Immediately tells me to fly at 6-7 degrees AoA for best effect.

Mildly confused by Flight Envelope/Thrust Available; suggesting lots of thrust at 500m/s while looking at a craft that tops out around 200-250. Excess Thrust seems right on the money, and maybe what I'm seeing in Thrust Available is the speed it would reach without drag?

Teal is less than green. I'll see if I can show the colour scale somewhere to make it easier. It essentially goes teal-green-orange-red.

Thanks for pointing out that I should add tooltips to the options so people know right away what it's plotting. Thrust available is what your engines are putting out at full throttle (accounting for the thrust limiters) for a given altitude and speed. Excess thrust is thrust available minus drag. Also note that Thrust Available is only the component in the direction of flight (so thrust times the cosine of the angle of attack (the angle of attack is set to the AoA needed for level flight at that speed/altitude)).

And yeah, I figured somebody would have to be real Kerbal to want to know their top speed with airbrakes deployed. :p Although depending on how they're coded, if you click 'Update Vessel' while they're deployed it might account for them (that's something I haven't tested).

Also, for accurate results, make sure your landing gear are retracted before it calculates. Down the line I want to have an option to auto-retract them or at least put out a message on the screen warning that they'll throw off results.

Edited June 21, 2018 by Booots