Project Glider for O2016

[BrianJ]

Hi,
thanks for this interesting project :thumbup:
I wondered if it would be possible to use TetherMFD to tow the glider up.
Turns out you can, but it has a few "quirks".
I tried using the DG but it was a bit overpowered for this purpose.
So I resurrected the legendary Kev33's Cessna172 (had to make a new .dll compatible with Orbiter2016, but Kev33 left us the code for this one - thanks Kev


N.B. You need to fly both aircraft into turns.
If things get unstable and "jerky" on the tether, its easy to get flung into hyperspace->CTD.
Exiting scenario while TetherMFD in use crashes Orbiter after saving "current_state".scn.

If you want to give it a go, you can use the attached .zip along with TetherMFD , Kev33's Cessna172 ver3, and the Glider v0.10

Attached .zip has new glider_tow.cfg (added attachment point), cessna172.dll, cessna172.cfg, scenario "Cessna_Glider_tow".
Scenario - Glider attach point is tethered to Cessna, ready to take off.

Thanks again,
BrianJ

 

[zachary77]

Hi,
thanks for this interesting project :thumbup:
I wondered if it would be possible to use TetherMFD to tow the glider up.
Turns out you can, but it has a few "quirks".
I tried using the DG but it was a bit overpowered for this purpose.
So I resurrected the legendary Kev33's Cessna172 (had to make a new .dll compatible with Orbiter2016, but Kev33 left us the code for this one - thanks Kev
View attachment 15702
View attachment 15703
N.B. You need to fly both aircraft into turns.
If things get unstable and "jerky" on the tether, its easy to get flung into hyperspace->CTD.
Exiting scenario while TetherMFD in use crashes Orbiter after saving "current_state".scn.

If you want to give it a go, you can use the attached .zip along with TetherMFD , Kev33's Cessna172 ver3, and the Glider v0.10

Attached .zip has new glider_tow.cfg (added attachment point), cessna172.dll, cessna172.cfg, scenario "Cessna_Glider_tow".
Scenario - Glider attach point is tethered to Cessna, ready to take off.

Thanks again,
BrianJ

Wow, thanks! I’ll definitely try it and report back. Much appreciated, BrianJ!

---------- Post added at 09:01 AM ---------- Previous post was at 03:44 AM ----------

Well, just tried it and it works beautifully!

Really cool. I'm officially endorsing this as another launch method.
Thanks BrianJ!:tiphat:
P.S. No CTD for me when saving.:thumbup:

 

[Urwumpe]

I think it would be good enough to implement the effects directly into the vessel class. It is not necessary to have a generalized simulation of thermals in Orbiter. Ideas for implementation:

1. Detect sun angle on surface as well as texture brightness of surface directly beneath the vessel's position.
2. Use both to calculate thermal effect from a look-up table.
3. Get Orbiter's wind vector as well as terrain slope directly beneath the vessel's position.
4. Use both to calculate a slope wind effect from a look-up table.
5. Add both to get an upwind/downwind effect.

Of course that's not the perfect real-world simulation, but it could be enough to get the idea and have some fun.

Another idea would be using a "weather feature map" in in the planet.dll to produce procedural wind vectors. Would not be realistic, but could be easily extended by adding new "weather features" to the map. The idea would be not using global coverage then, but produce local map data for special regions around bases. Of course, theoretically, there could also be a weather feature generator using the terrain data of Orbiter and a simplified flow solver for a limited region (eg, the Alps)

Some sort of like your wind effect and look-up table works, but not being limited to vessels supporting it. Theoretically you could then also let it apply to monstrous storms and turbulences in Saturns atmosphere as well. Also it could make some older Mars related add-ons more interesting.

Of course, it would be far more interesting if we could also add single clouds to Earths atmosphere to show where thermals are...

 

[Thorsten]

(Disclaimer: I wrote the weather code for Flightgear including the thermal soaring part)

Thermals are so fine-grained, they won't show on any fluid dynamics simulation you could realistically run. Best pick random spots (ideally based on underlying terrain - no thermals over ice and water), check whether your craft is inside such a region of interest and run a thermal then (if you have a 3d model, you can at the same time place a cap cloud).

If anyone needs a parametric lift distribution for a thermal (it's based on my own and some other pilot's experiences in the ASK-13 glider), I can dig up the pointer to the code.

The interaction of thermals and rough mountain terrain is a bitch to model - generally you need to know plenty of non-local things like the elevation distribution of the terrain in the vicinity to be halfway realistic (at least based on cap clouds) - the reason is that the cloudbase always moves somewhat with the terrain elevation, but isolated spots and canyons don't really affect it.

Ridge lift is also a non-local affair which depends on the shape of the terrain both upwind and downwind - again, I can probably find the reference for a realistic function if anyone is interested.

 

[zachary77]

Alright, progress update:
Working on not needing to turn trim on/off (similar to Airbus flare law). The good news is that below 100 m, the trim shuts off and vice versa. However, it’s unstable during the transition from manual to auto. Also, I’m running into issues with the flaps (Face’s idea). While they extend and retract alright (both positive and negative, 8 stages in all!), they do so much too quickly. I’ve tried setting the delay parameter to 30 s in accordance with CreateControlSurface3, but it seems to have no effect. The flaps still take <1/2 seconds to extend/retract 1 stage (I can see that in the debug string). Any suggestions?

 

[Urwumpe]

I think this delay is just if you are using keyboard control of the control surfaces.

Better implement the flap extension animation yourself as state machine.

 

[Marijn]

I’d really like the model, thanks.

Found it. How can I sent it to you? It's a zip.

 

[zachary77]

Found it. How can I sent it to you? It's a zip.

I guess you could attach it to a post, or if you’d prefer, PM me.

Much appreciated,
zachary77

---------- Post added at 03:15 AM ---------- Previous post was at 03:14 AM ----------

I think this delay is just if you are using keyboard control of the control surfaces.

Better implement the flap extension animation yourself as state machine.

Umm, what is a state machine?

 

[Thorsten]

Umm, what is a state machine?

I guess calling it a kind of coding philosophy describes it best...

Something that has internal states, can receive inputs to change the states and does outputs dependent on input and internal state.

 

[Marijn]

I guess you could attach it to a post, or if you’d prefer, PM me.

I'd prefer a PM, but I don't see a way to attach a file.. Am I overlooking something?

 

[Ripley]

I guess he'll PM his email address to you.

 

[Marijn]

I guess he'll PM his email address to you.

That's the easiest way. @zachary77, if you PM me your email, I'll reply with the model attached.

 

[Urwumpe]

Umm, what is a state machine?

I guess calling it a kind of coding philosophy describes it best...

Something that has internal states, can receive inputs to change the states and does outputs dependent on input and internal state.

Well yes. I prefer calling it a tool, because using a finite state machine in a design is not the same as the implementation - you can have many different ways to implement the same state machine, still all behave similar.

You might even want to make a state machine around a state machine (which could then be designed equally as a single state machine - but gets more complicated to understand then).

Like: You have three flap positions: Retracted (R), take-off (T) and landing (L).

These would also be states in your state machine.

For getting from one to the other, you would need a transition. Now, if you don't want to instantly switch from retracted to take-off, you would also need states between, which describe when your flap in in motion.

So, you would have the following states:

R, T, L, RT, TL, LT, TR.

Maybe you also want to skip over T and instantly go from retracted to landing or landing to retracted. Then you could have also the states RL and LR.

Now, you also need rules that describe how you get from one state to the other.

For example:

If you press F on the keyboard (the event 'OAPI_KEY_F'), the following transitions could happen depending on the current state:

R -> RT
T -> TL
L -> LT
T' -> TR

T' is here a special clone of state T, which represents "T while retracting flaps". Its exactly the same as T, it just reacts differently to the event.

For implementing such a state machine, it could be as simple as just have a numeric constant representing each state, storing the current state as int or better as enum.

It just helps knowing the states you need in advance then, because extending such a state machine can become increasingly difficult.

Or you have a State Pattern in OOP, which also works in C++:

https://en.wikipedia.org/wiki/State_pattern

 

[Marijn]

Current features:

• Glide ratio 20:1
• Ballast to fine-tune glide speed

So, what do you guys think? Feature requests? Fire away!
zachary77

The glide ratio, when given as a single number like 20:1 or just 20, always means the BEST glide ratio. Any best glide ratio is only true at a certain speed (and pressure). Any other speed, either faster or slower, means a less favorable glide ratio is realized. If you plot the horizontal speed of a glider on the x-axis against the vertical speed on the y, you will get a curved line called a polar. This is the single most important characteristic of any glider. I think your add-on should reflect this. And it's rather easy to implemend I would say. Example: http://sarmed.netfirms.com/pakgliding/NEW_SITE/gliders/asw28.htm

A polar can be described with just three pairs of speeds and two weights like in the example below:

*ASW-20 WinPilot POLAR file: MassDryGross[kg], MaxWaterBallast[liters], Speed1[km/h], Sink1[m/s], Speed2, Sink2, Speed3, Sink3
377, 159, 116.2, -0.77, 174.3, -1.89, 213.04, -3.3

Current onboard flight-computers use this format. With these numbers, you can express the polar as a simple quadratic equation which can give you the sink speed for any airspeed with high accuracy. Also, you can adjust for headwind, tailwind, sink and lift by shifting the polar to the left, right, down and up. Corrections for changes in ballast can also be implemented.

The math is quite elegant and not very difficult I would say: Ws = aV² + bV + c.

I can help with giving you the formulas to get a, b and c.

If you do it correctly, you will find that carrying any ballast without encountering natural sources of lift and or headwinds will always compromise the performance. The same is true for using negative flaps.

 

[Urwumpe]

Well lets describe it like that: A nominal flight condition polar. Since all gliders are only reaching very small Mach numbers and use rather conventional wing profiles, its easy to use such an approximation without big differences to the real flight behavior.

But if you are approaching stall, are spinning or tumbling, the lift function enters the place where the simple approximation won't work anymore.

 

[zachary77]

The glide ratio, when given as a single number like 20:1 or just 20, always means the BEST glide ratio. Any best glide ratio is only true at a certain speed (and pressure). Any other speed, either faster or slower, means a less favorable glide ratio is realized. If you plot the horizontal speed of a glider on the x-axis against the vertical speed on the y, you will get a curved line called a polar. This is the single most important characteristic of any glider. I think your add-on should reflect this. And it's rather easy to implemend I would say. Example: http://sarmed.netfirms.com/pakgliding/NEW_SITE/gliders/asw28.htm

A polar can be described with just three pairs of speeds and two weights like in the example below:

*ASW-20 WinPilot POLAR file: MassDryGross[kg], MaxWaterBallast[liters], Speed1[km/h], Sink1[m/s], Speed2, Sink2, Speed3, Sink3
377, 159, 116.2, -0.77, 174.3, -1.89, 213.04, -3.3

Current onboard flight-computers use this format. With these numbers, you can express the polar as a simple quadratic equation which can give you the sink speed for any airspeed with high accuracy. Also, you can adjust for headwind, tailwind, sink and lift by shifting the polar to the left, right, down and up. Corrections for changes in ballast can also be implemented.

The math is quite elegant and not very difficult I would say: Ws = aV² + bV + c.

I can help with giving you the formulas to get a, b and c.

If you do it correctly, you will find that carrying any ballast without encountering natural sources of lift and or headwinds will always compromise the performance. The same is true for using negative flaps.

Well, that’s a bit outdated now. I managed to nudge it to 40:1. But, yes, I get your point. Could you give me the formulas? Thanks

 

[Marijn]

The model is in your inbox. It's an ASW28.

 

[zachary77]

The model is in your inbox. It's an ASW28.

I got it, thanks. I'll see what I can do.

 

[Marijn]

Could you give me the formulas? Thanks

I found a complete copy of Helmut Reichmann's Cross-Country Soaring. This famous book explains all the theory. Have a look at page 105:

https://www.j2mcl-planeurs.net/dbj2...es/Cross-Country Soaring_(Reichmann_1978).pdf

 

[zachary77]

I'm having issues with XRSound. I'm initialising it in clbkPostCreation like so:

void Glider::clbkPostCreation()
{
	XRSound *CreateInstance(VESSEL *pVessel);

}

But when I ask it to play a sound, like this:

XRSound::PlayWav(10037, true, 1.0);

I get "a nonstatic member reference must be relative to a specific object".
How do I fix this?