Removed

[sobek]

Well darn i installed VS2015, but it seems to work out of the box. The only thing it altered is the tool version in the project file.

 

I must say i somewhat underestimated the size of the project. You won't be seeing pull requests out of me anytime soon, i need to get my C++ back up to snuff. ;)

 

desktop client

 

Such a ghastly word! ;)

 

Thanks for the heads up.

 

It used to be trickier before with older versions. FM should be pretty self-contained now without external dependencies.

 

Kudos!

Edited August 21, 2016 by sobek

[Vitormouraa]

Without the SDK you are very limited, that's a fact, you can make some clickable buttons, but you are limited when it comes about systems and etc as Sevas already said, so without that it would be just a mod. But I don't know what they want, maybe just a mod for the community.

[kazereal]

Well darn i installed VS2015, but it seems to work out of the box. The only thing it altered is the tool version in the project file.

 

Ok, I expected as much but good to know. :thumbup:

 

I must say i somewhat underestimated the size of the project. You won't be seeing pull requests out of me anytime soon, i need to get my C++ back up to snuff. ;)

 

Ok, no worries, no rush :)

 

Point is about learning to make sim stuff, not about rushing to some end.

[kazereal]

But I don't know what they want, maybe just a mod for the community.

 

Like said many times before, this is tool for learning sim development.

 

Aim is not to make a final module or even playable mod, primary point is for people to learn how to develop modules: how things work with DCS, what kind of stuff you need in a module and so on.

 

Getting it all right takes plenty of time of course, learning how to simulate various things. That takes time to research, experiment and test things to learn how to do them.

 

Result of course can be more or less usable simulation of the F-16, but that is not the end goal: learning and demonstration of how to do simulation is the primary goal here.

 

If someone has other ideas of how to use this stuff they can fork (branch) their own and continue from there.

 

Publishing it as for-sale thing is out of the question: license rules for the 3D mesh prohibit that.

Getting permission for the NASA data and Smiley's original code would be needed too. Plus permission from GD/LM, PW, GE..

Edited August 24, 2016 by kazereal

[kazereal]

For people who are not that familiar what simulation approaches are like let me try to explain..

 

Let's use engine thrust output as example. There's different approaches here:

 

1) Using simple multiplier "this much throttle gives this much thrust" - it might be fine for demonstration purposes, but real world is not that simple. Especially since there is rarely linear rate like that..

Engine management uses sensors to determine amount of air and amount of fuel required so that fuel/air mixture can ignite and burn most efficiently.

 

2) Better approach is to use lookup-tables (*). These work better in non-linear cases where air density (altitude) and pressure ("ram effect") can change amount of air entering engine and you need different fuel amount for the mixture. And as a result, engine thrust output changes too.

Performance of lookup-tables is generally very good but depends on "resolution" of data (amount of data points in range).

Using lookup-tables often needs interpolation between datapoints to improve accuracy but data "resolution" still is a major factor here.

Aerodynamic coefficients are in lookup tables in this F-16Demo (for example).

 

(*) Simple lookups can be hacked with if-else but these are:

A) hard to maintain (if parameters change)

B) really really complicated when number of parameters increase (combinations of multiple conditions/parameters), and

C) often slowest possible way to run simulation. Even with branch prediction, instruction cache and so on CPU are still very slow to handle branching code comparing to unconditional (non-branching) code.

So for small amount of parameters/conditions these can be fine but better to avoid in complex things.

 

3) Mathematical equations. These can provide best accuracy without having large amounts lookup-values.

 

When the equation is correct and has enough parameters it can adjust to wide range of different scenarios. When amount of air entering engine changes, fuel mixture changes but also if fuel parameters change (energy output, ignition point etc.) you can use same bit of code to simulate wider range of flight conditions and aircraft conditions.

 

Bonus is that you can often reuse same code for different variations (different inlet size, compression ratios and so on) with just changing the parameters of the equation.

 

Downsides are that this needs most research into understanding what parameters you need and how they relate to make equations and program them. Also if you don't have some parameter included, it might not work outside some conditions.

Adding more complex equations with larger amount of parameters also increase computation time. Code structure and optimization plays a part here.

 

So this is my short explanation why some progress is slower than other, why results are often different and why there are different approaches/considerations to writing code.

Edited August 24, 2016 by kazereal

[kazereal]

I've added a rough light-blinker handling: this supports having different sequences

so that you can put different patterns of blinking for the lights.

 

There's only one hard-coded sequence used now and only input-binding for navigation lights is there. Something to test and play around with though.

In theory that could be made configurable.

 

Have fun :)

Now back to researching other things..

Edited August 25, 2016 by kazereal

[SkateZilla]

I've added a rough light-blinker handling: this supports having different sequences

so that you can put different patterns of blinking for the lights.

 

There's only one hard-coded sequence used now and only input-binding for navigation lights is there. Something to test and play around with though.

In theory that could be made configurable.

 

Have fun :)

Now back to researching other things..

 

Nice :-)

[kazereal]

Nice :-)

 

It does need some bugfixing though.. :music_whistling:

[BR55Sevas]

Gents, does anyone know what this software do?

http://www.openvsp.org

What useful can we get from it? Thx

Only cg coordinates and net for some another cfd wind tunel?

[kazereal]

Gents, does anyone know what this software do?

http://www.openvsp.org

What useful can we get from it? Thx

Only cg coordinates and net for some another cfd wind tunel?

 

No idea what that could provide. Basically you can input anything you like and get something as result, if that is usable is another matter entirely..

 

If by CG coordinates you mean center of gravity location that we know already for the "dry" configuration.

 

The thing that I have planned is calculation for new CoG when fuel tanks have different amounts of fuel in them (for example, leak in one tank from shrapnel -> change in balance).

And there are multiple internal tanks like in many aircraft.

 

Basically weight of the fuel remaining in the tank and location (relative distance to reference CoG) is the thing that is needed for calculation. I haven't got around to it yet since I've researched some other things that will be needed later.

 

There's already plenty of aero coefficients available, CFD would not provide much new information (unless you do it better than NASA). For that you would need very detailed CAD model and that is not simple thing for professionals either to find the coefficients (buddy does CFD stuff for a living).

 

Basically, adding more data does not help for aero stuff, quality of the data is different matter and there's no simple solution to getting that unless you are prepared to spend a lot of time on it..

If you can reliably verify existing data with that and determine what is "trash data" that would be more helpful since that would reduce amount of work.

Edited August 25, 2016 by kazereal

[SkateZilla]

It does need some bugfixing though.. :music_whistling:

 

The Lighting for the 3d Model will change w/ new model.

[kazereal]

The Lighting for the 3d Model will change w/ new model.

 

Cool :)

[kazereal]

There's a rough first prototype of the code for calculating "wet" mass center of gravity.

Does not include external payloads yet (I haven't looked at external data yet).

 

This is still rough and tank positions are not there and new cog is not used correctly in resulting calculations.

Should work as example of the concept anyway.

 

(I think I saw some values somewhere, need to go through documents again..)

(And of course there are different coordinate systems and different units so as not to make things too easy..)

 

Edit: for those interested, DCS and many many 3D software use coordinate system where origo is in middle of the aircraft (and there's two variations of that, left-handed and right-handed).

The old NASA documents usually have system where origo is at tip of the nose of aircraft.

Just an example of what the differences can be.

Edited August 26, 2016 by kazereal

[kazereal]

I've finished cleaning up the aero-calculations which used to calculate some things multiple times per each "slice" of simulation.

 

Hopefully code is easier to follow now too.

 

Have a look and let me know if you spot a new bug due to changes made.

You don't need to report bugs existing before these changes, just if you spot something troubling that was not there before.

 

Code is in usual place:

https://github.com/ipr/F-16Demo/

 

Edit: changes I mentioned are pretty much limited to here:

https://github.com/ipr/F-16Demo/blob/master/FlightModel/Aerodynamics/F16Aero.h

 

You can compare with diff tools, split-view in github seems to work nicely (unified view can be difficult to follow due to amount of changes).

 

Edit: for people interested, result of changes is that the file is now around 300 lines shorter than a day before (~730, down from ~1000).

That should also make it simpler to modify the calculations and improve upon (goal is to have better supersonic aerodynamics at some point there).

Edited September 3, 2016 by kazereal

[kazereal]

I've removed old hack that had hard-coded default pitch trim to -0.3

 

Now that there is working binding for trimmer use that instead if necessary.

 

Removing some old workarounds and such should help make better end-result.

[kazereal]

And here's another rant about people misunderstanding what simulation code means.

 

If real aircraft has performance numbers like "roll rate is X, climb rate is Y" you don't input those values into simulator code, that would skip the whole purpose of the thing.

 

For one thing, performance numbers like that depend on atmosphering conditions, payload and a large number of other variables.

 

Performance numbers are mostly the "target value" you compare simulation peformance against.

 

Actual simulation has the other things that actually determine what the performance will be: aerodynamic properties, engine thrust and efficiency at given altitude and so forth.

 

Casual games often skip whole thing about simulating aircraft and use those performance values regardless if they actually fit the flight conditions.

 

Simulators need to use more time for development and those values are not more than "guidelines" of how the simulated aircraft should perform in same conditions to validate that simulation works correctly: when different properties of aircraft are handled correctly they should be a match.

[kazereal]

Flight control system code is now split into separate parts so it should be easier to make further changes.

 

No functional changes at this point, just preparing code for further changes.

[kazereal]

There's some cleanup of the units used in calculations: there was plenty of conversion back and forth in different places, I think those are now all gone. Check if you spot something that seems "off" somehow.

 

Trailing edge flaps now follow landing gear up/down lever so that when gears are set down flaps will be coming down as well. Since flaps are normally used as ailerons it can be weird sometimes how they are.

 

Edit: Also, looks like as a result of clearing the units in calculations, elevators don't have that huge flutter any more in supersonic speeds.

 

Edit 2: another thing for testing: position of lift moves as function of speed, meaning that:

* in sub-sonic speeds lift is in front of center -> tendency to pitch up

* in supersonic speed lift after center (towards tail) -> stable flight

This does not have proper calculation yet, it is just moved frontmost to aftmost position for now. There's plenty more to do in that regard anyway..

Edited September 7, 2016 by kazereal

[kazereal]

Looks like old code does not consider all combinations of commands to flight surfaces.

It does take some input but does not go to same lengths in using those surfaces as should be.

 

I'm looking into that now to combine inputs.

 

For example, when flaps are commanded down, they still have some roll authority.

At least that is my understanding, but I'll need to look at more information on that and other surfaces to get full use of them into simulation.

 

Edit: and that brings a problem in the 3D model draw arguments: I think the draw argument for flaps needs to be disabled (removed)

so that DCS is not conflicted on what values to use for drawing their position.

Since the way the API works, we need to give some value there but we can't tell "don't use this value for drawing".

 

Edit2: after I've done flight control changes, I need to go back to aerodynamics code and calculate values both sides

that might have different deflection instead of just using same value for both sides..

That old aero-code does not handle those kinds of situations.

Edited September 8, 2016 by kazereal

[kazereal]

Another update.

 

I was looking at trailing edge flaperon conditions at how they behave and made some modifications to the code.

 

Please give feedback if you have better source of information (surprisingly hard to find accurate information on this..).

 

Anyway, they way it works now:

* when landing gears are out, flaperon are adjusted to lower position

* position depends on dynamic pressure (or airspeed)

* below 370 kts the angle gradually changes

* below 240 kts they are at full deflection

* on take-off they are full up when at 370 kts

 

The thing that is troubling me, if landing gear is up, but speed is below 370 kts, is it still supposed to give some deflection of the flaps? Comment this if you have better information.

 

When landing gear is up the flaperons behave as normal ailerons so that is not a problem.

Additionally, when flaperons are at full deflection, there's bit more to their movement but that's one thing I'm looking at (they can adjust some then).

 

There's other things after this regarding stabilizers and so on but I wanted to get this out of the way before those.

I assume there's some amount of flaps in transonic speeds but that is still bit too far to think about that..

 

Edit: and please, make sure information source is something useful, there's too much guessing around..

Edited September 9, 2016 by kazereal

[kazereal]

I've added better information about license meaning limitations to use:

no changes, just clearer to find the information.

 

Have a look and leave a comment:

https://github.com/ipr/F-16Demo/blob/master/README.md

 

Video of current status:

[SilentEagle]

Please give feedback if you have better source of information (surprisingly hard to find accurate information on this..).

 

Yes, it is. I used a combination of FLCS diagrams, operators manual descriptions, photos, videos, and some educated guesses to write the trailing edge flap logic.

 

The thing that is troubling me, if landing gear is up, but speed is below 370 kts, is it still supposed to give some deflection of the flaps? Comment this if you have better information.

 

No, the trailing edge flaps only change for 3 reasons.

* Gear down and speed below 370 kts.

* Alt Flaps switch activated and speed below 370 kts.

* Transonic speeds actually make flaps go up (max 2 degrees)

 

Technically, the digital backup mode has different logic, but you can get into that if you ever model it. (I did)

 

You should also probably switch to using dynamic pressure ratio instead of knots, as the FLCS on the real aircraft does. qc_ps = qc_psf / Ps_psf; Where qc_psf is the dynamic pressure in psf, and Ps_psf is the atmospheric pressure in psf.

 

Note: With STANDBY GAINS activated, Ps_psf is set to sea level pressure (2116.217 psf). Also, with STANDBY GAINS activated, qc_psf is set to 200 psf when gear handle is down, ALT FLAPS is activated, or the refueling door is open, but it is 1400 psf any other time with STANDBY GAINS activated.

 

When landing gear is up the flaperons behave as normal ailerons so that is not a problem.

Additionally, when flaperons are at full deflection, there's bit more to their movement but that's one thing I'm looking at (they can adjust some then).

 

So, the FLCS diagrams actually give some insight into the mixing between trailing edge flap deflection and aileron deflection to give a final flaperon deflection command to the actuators. The targeted trailing edge command is identical for both flaps, and is scheduled with an integrator. That integrated output for each flap is sent to mixing with aileron roll commands that are different for each side (one is plus, the other minus). However, after the initial adding/subtracting of each aileron command, one side may be more than +21.5 or less than -21.5 degrees, but only the overshoot of the limits in the positive regime (+21.5) is then sent back and subtracted from the opposite side (this is called a breakout), so that the difference between the two flaperons is closer to the actual aileron command. Since this is a discrete simulation, that subtraction only shows in the next simulation frame, so the outputs still need to be limited from -21.5 to +21.5. The outputs of the limited values are then sent through the integrated servoactuator dynamics filter and then the mechanical bias (-1.5 deg) is added to each side. Finally, the final limits are applied for each flaperon (+20, -23).

 

What this actually looks like when the flaps are down (gear down, speed at 240 kts) and a full deflection roll is initiated, is that one side's flaperon will not change and will stay fully down, while the other will go all the way back to neutral so that the difference between the flaperons is 21.5 degrees. A normal aileron command will have a difference of 43.0 degrees (21.5 deg up on one side and 21.5 deg down on the other side).

 

The way I modeled this in the aerodynamics was by taking the average of the position of both flaperons to determine how much extra lift is added by the trailing edge flaps. Also, I took the difference between each flaperon and divided by two to use for the roll moment calculation.

Edited January 4, 2020 by SilentEagle

[mvsgas]

Please give feedback if you have better source of information (surprisingly hard to find accurate information on this..).

 

This is what I got on the flaperons subsystem, I don't know if the information is useful at all.

Integrated Servo Actuator (ISA) movement positions the flaperons in response to commands from the DFLCC. Roll rate signals from the roll rate gyro and the side stick controller are input to the DFLCC additional inputs from the landing gear handle, AIR REFUEL switch, ALT FLAPS switch, and ROLL TRIM control are also used to generate flaperon position commands.

 

Aircraft roll rate is controlled by inputs from the roll rate gyro assembly. This assembly is mounted to allow the internal gyro spin motors to sense the rate of movement about their axes. These motors generate four discrete and redundant roll rate signals to the DFLCC through their respective pickoff transformers.

 

Another aspect of roll control involves gun firing compensation which is automatically performed by the DFLCC. During gun firing, the gun produces a yawing moment due to the off-center location of the gun. Within the DFLCC, the gun fire signal is processed along with airspeed, altitude, and air pressure signals. This data is then combined with yaw and roll rate signals to produce the required compensating deflection commands. These commands are output by the DFLCC to the flaperon and rudder ISA’s to initiate the control surface corrections.

 

Positioning the landing gear handle to DN with the ALT FLAPS switch in NORM provides a signal to the DFLCC. This signal commands the flaperons down a maximum of 20 degrees (depending on airspeed) to increase lift.

 

If the flaperons do no lower automatically (with landing gear handle in DN position), a backup method is used. Positioning the ALT FLAPS switch to EXTEND sends a signal to the DFLCC lowering the flaperons.

 

The DFLCC electronically commands differential operation of the flaperons for roll assists while the flaperons are down. Roll trim is commanded by moving the TRIM switch on the side stick controller left or right. The ROLL TRIM thumbwheel on the MANUAL TRIM pane may also be used. The ROLL TRIM thumbwheel is oriented in the panel to correspond to right wing down or left wing down trim. A semicircular position indicator adjacent to the thumbwheel provides a visual trim reference. When the TRIM switch is used for trimming, the thumbwheel is motor driven in the direction of commanded trim.

 

Roll commands are summed electronically in the DFLCC. These commands are applied to the coils of servo valves SV1, SV2, and SV3 in each ISA. Under normal conditions, servo valves SV1 and SV2 are active and SV3 is in standby. Active servos will port hydraulic fluid to position the main control valve. This control valve then ports hydraulic power to drive the ram in the desired direction. A mechanical feedback nulls the main control valve and servo valves when the ram has reached the commanded position. Each servo valve coil contains two separate input windings.

 

Normal operation of the servos is possible with either the primary or secondary winding. Outputs from the DFLCC servoamplifiers are monitored by other DFLCC circuitry. A malfunction will switch operation to the standby amplifier and the secondary winding for that servo valve. A hydromechanical monitoring and voting system within the ISA monitors the outputs of the three servo valves. Any detected failure in SV1 or SV2 will vote out the malfunctioning servo valve and transfer control to SV3. Any failure will light the MASTER CAUTION light and the FLCS FAULT caution light. A fault message will also appear on the pilot fault list display. Failure detection/correction is latched in after a malfunction. Reset is possible by placing the FLCS RESET switch to RESET and releasing. Reset cannot be accomplished if the malfunction still exists. If a servo malfunction is indicated (flaperon PFL), a single FLCS reset will reset the appropriate ISA. A recurring fail (same pressure switch) will duplicate the PFL.

 

The ISA’s will continue to operate with one hydraulic system failed. If pressure for both hydraulic systems drops below 720 psi, a spring will position the ISA’s to neutral.

[kazereal]

Yes, it is. I used a combination of FLCS diagrams, operators manual descriptions, photos, videos, and some educated guesses to write the trailing edge flap logic.

 

No, the trailing edge flaps only change for 3 reasons.

* Gear down and speed below 370 kts.

* Alt Flaps switch activated and speed below 370 kts.

* Transonic speeds actually make flaps go up (max 2 degrees)

 

Technically, the digital backup mode has different logic, but you can get into that if you ever model it. (I did)

 

Thanks for information :)

That is what I though as well but it is better to check assumptions.

 

There's still plenty of ways to go so we'll see how far I'll progress..

 

You should also probably switch to using dynamic pressure ratio instead of knots, as the FLCS on the real aircraft does. qc_ps = qc_psf / Ps_psf; Where qc_psf is the dynamic pressure in psf, and Ps_psf is the atmospheric pressure in psf.

 

Yep, that is in plans but like many things might have to wait a bit, there's always so much to do..

 

http://i.imgur.com/nLkcuTR.png

 

Yes, I've been looking at that pretty much lately :)

Thanks for that :)

 

I do like to work off from information than direct source code. Maybe slower progress but anyway..

I like the coding, learning and figuring out stuff, so without that there would be no point at all in doing this..

 

What this actually looks like when the flaps are down (gear down, speed at 240 kts) and a full deflection roll is initiated, is that one side's flaperon will not change and will stay fully down, while the other will go all the way back to neutral so that the difference between the flaperons is 21.5 degrees. A normal aileron command will have a difference of 43.0 degrees (21.5 deg up on one side and 21.5 deg down on the other side).

 

Yep, I've found that information too but haven't gotten to implementing it yet.

 

I've been looking at mixing flaperon and elevon (stabilizer) control for roll command: since the stabilizer can work both symmetrically (elevator) and differentially (aileron) mixing that for both flaperons and elevons can be tricky.

 

It is essential to have but means changes to both flight control and aerodynamics: old aero code assumes always symmetrical deflection for flaperons and elevators and does not calculate separate lift and drag for different sides of aircraft.

Edited September 11, 2016 by kazereal

[kazereal]

This is what I got on the flaperons subsystem, I don't know if the information is useful at all.

 

Thanks, maybe not at this moment yet but later when progressing to coding other systems.