Implementation of proper air breathing engines (ABEs)

[DaveS]

I was working on the base texture for the new SSU orbiter mesh and I was thinking it would be nice if a proper simulation of air breathing engines (ABEs) could be implemented. Right now it has to be implemented on a vessel-by-vessel basis (see the default Delta Glider and its SCRam-jet version). But what I want to see in any future versions of Orbiter is generic versions of not only SCRam-jets but also Ram-jets and regular ABEs. After all, there's a helicopter flying on Mars right now and we have the Titan Dragonfly mission coming up for launch in 2027 (arrival at Titan in 2034). And there have been proposals for other aircraft missions to both Mars and Venus.

There used to be a generic aircraft implementation add-on called "Aircraft.dll" (Aircraft.dll source code on SourceForge) but it fell by the wayside. But now I think it is time for it to make a come back.

 

[N_Molson]

Yes with stuff like bleed air valves

 

[jedidia]

Something at the back of my head tells me this would be better at home in a library that developers can pull in, but I also think some standard engine models in the core that are supported by CFGs out of the box does sound like a good idea... I'm not sure I'm missing something, I usually don't have that much cognitive dissonance about boundaries

 

[steph]

I was under the impressio that at least XR5 Vanguard does take into account stuff like AOA etc for scramjet performance. One of the ways you could get it to fly really high was to get it firing under high AOA. It cools the intake temp a bit

 

[DaveS]

Something at the back of my head tells me this would be better at home in a library that developers can pull in, but I also think some standard engine models in the core that are supported by CFGs out of the box does sound like a good idea... I'm not sure I'm missing something, I usually don't have that much cognitive dissonance about boundaries

Right now, only regular rocket engines are supported natively while something like ABEs require middle-ware like Aircraft.dll as they are not supported natively at all.

 

[Urwumpe]

Actually, Orbiter supports no engines at all, only sources of thrust. Your implementation decides, if its a rocket engine, a jet engine or even a propeller.

 

[DaveS]

Actually, Orbiter supports no engines at all, only sources of thrust. Your implementation decides, if its a rocket engine, a jet engine or even a propeller.

Yes, of course this is correct. But in terms of config files, the default treatment is as a rocket engine where the fuel and oxidizer are one and the same. That is what I meant by "natively". With the OAPI you can implement it as what you want, but with the built in config files and to some extent Lua script interface, it is rocket engines and anything more requires going full C++ with the OSDK.

 

[Urwumpe]

Its the simplest case of the rocket equation - not more, not less. Still, it doesn't care, how the mass flow is produced. By some magic, the fuel flows at constant rate into the thruster and produces thrust, that only depends on ambient pressure.

From a pure engineering or physics perspective, Orbiter is still mostly implementation agnostic, except by the plain fact, that thrust without mass flow has to be a generic force. There is no large bias towards rocket engines.

 

[N_Molson]

It would help to have an "out of the box class" that would give devs a generic framework for ABE implementation.

 

[Urwumpe]

It would help to have an "out of the box class" that would give devs a generic framework for ABE implementation.

What about doing two things:

1. Develop a framework that provides some core elements for implementing air breathing engines. Maybe as extra, building blocks for typical aircraft subsystems.
2. As test and reference for the framework, provide a generic vessel module, similar to aircraft.dll, that makes use of this framework.

If you want to develop your own advanced aircraft - goto 1. If you just want to play with aircraft, goto 2.

 

[Urwumpe]

If somebody wants to continue Aircraft DLL, the sources still exist since 2004.

CCCP Fleet Project - Browse /Aircraft DLL Source/Current Source Code at SourceForge.net

Wockets for Orbiter

sourceforge.net

 

[DaveS]

If somebody wants to continue Aircraft DLL, the sources still exist since 2004.

CCCP Fleet Project - Browse /Aircraft DLL Source/Current Source Code at SourceForge.net

Wockets for Orbiter

sourceforge.net

Which I mentioned and linked to in the first post.

 

[N_Molson]

Yes but the issue is that you add a dependency each time you use it, and that isn't exactly user-friendly ?

 

[DaveS]

Yes but the issue is that you add a dependency each time you use it, and that isn't exactly user-friendly ?

Which is why created this thread, to see if there was implementing it as a core function rather than an abandoned middle-ware plug-in.

 

[Urwumpe]

Yes but the issue is that you add a dependency each time you use it, and that isn't exactly user-friendly ?

Of course it it. The opposite is bloat, which is far worse.

There is nothing bad about the number of dependencies in your project as long as you can manage them. Managing can mean many different strategies. For example, you can encapsulate a dependency, you don't trust to stay with your software until its death.

 

[N_Molson]

Honestly I'm with @DaveS on this one. After all it wouldn't prevent someone who wants to implement an exotic type of engine to do his own thing.

 

[Urwumpe]

Honestly I'm with @DaveS on this one. After all it wouldn't prevent someone who wants to implement an exotic type of engine to do his own thing.

I am on the "Write your own middleware now or wait until a miracle happens" side of things.

BTW: It would be far more likely to integrate an existing middleware into the Orbiter SDK than creating a new middleware inside the Orbiter SDK. But don't listen to me.

 

[jedidia]

Actually, Orbiter supports no engines at all, only sources of thrust.

That's not entirely correct. Yes, orbiter supports sources of thrust, but those sources of thrust need to be connected to propellant tanks, and the consumption of that propellant is strictly based on the assumption that this is the only reaction mass flowing through the thruster. To deviate from that assumption you either have to work around it by transfering stuff into a dummy propellant tank (even for something simple as simulating bi-propellants from two different tanks), or you have to implement a new thruster entirely from scratch by adding force vectors and exhausts yourself.

 

[Thunder Chicken]

Also, by air-breathing engines, do you include engines that drive rotors and propellers? In that case, you need to not only tie the output of the engine to ambient air pressure (intake air), but also the net aerodynamics forces acting on the blades as a function of ambient density, pitch, yaw, and engine speed. Once you start down this rabbit hole, you then discover that propellers and rotors of helicopters and such can and often do develop asymmetric local thrust, so in addition to linear thrust you can have torques applied on all three axes. Oh, and now you have parts with rotational inertia, so here come the Euler equations...?‍?

Even on "simple" engines like turbojets, you also have throttle lag due to the inertia of the rotating components, compressor stall, etc.. which requires knowledge of those components to be built into the model.

I wrote a dll long ago to implement propellor effects for a Cessna 172 model to enable correct spin behavior and damn near drove myself insane. Tread carefully.

 

[Max-Q]

Also, by air-breathing engines, do you include engines that drive rotors and propellers? In that case, you need to not only tie the output of the engine to ambient air pressure (intake air), but also the net aerodynamics forces acting on the blades as a function of ambient density, pitch, yaw, and engine speed. Once you start down this rabbit hole, you then discover that propellers and rotors of helicopters and such can and often do develop asymmetric local thrust, so in addition to linear thrust you can have torques applied on all three axes. Oh, and now you have parts with rotational inertia, so here come the Euler equations...?‍?

Even on "simple" engines like turbojets, you also have throttle lag due to the inertia of the rotating components, compressor stall, etc.. which requires knowledge of those components to be built into the model.

I wrote a dll long ago to implement propellor effects for a Cessna 172 model to enable correct spin behavior and damn near drove myself insane. Tread carefully.

Which is EXACTLY why we need this stuff in the orbiter core! You can't expect every addon dev who wants to do something with non-rocket engines to code all this complicated mess...

• One person who knows what they are doing should add this into the core so anyone can use it! It doesn't even need to be extremely complicated, a simplified model would work (even though my engineering mind screams "NO" about simplifying stuff).
• And not just for planes, what about Ingenuity on mars or the mission to Titan that is in the works?
• Every flight sim in existence has dealt with this; there are even some open-source ones out there. FlightGear, for example. It's free and open source (GPL), maybe we could borrow some code from there or at least see how it is done?