Simulation details

[loche]

Hello. I'm interesting how detailed your helicopter simulation is.

 

• Do you simulate auto-rotation mode and vortex ring?
  
• Do you simulate any emergency situations like blade segments loss or tail boom rope breakdown?
  
• Do you simulate airborne systems malfunctions like various fuel system pump failures or electric system open-circuites ?
  

[Ratgnagna]

Do you simulate auto-rotation mode

Yes! See on the Power-off video on the main DCS web site. ;)

[-Skipper-]

I recommend to watch the Producers Notes and the other videos available. At least most of your questions are covered there or in the FAQ.

 

e.g. we had an auto-rotation landing:

 

 

and it was already mentioned in videos and comments, that the vortex-ring-state is modelled and very deadly.

 

The second point probably is answered by this:

 

 

And the last points are covered in the dev-updates. :smilewink:

[Cosmonaut]

Hello. I'm interesting how detailed your helicopter simulation is.

 

• Do you simulate auto-rotation mode and vortex ring?
  
• Do you simulate any emergency situations like blade segments loss or tail boom rope breakdown?
  
• Do you simulate airborne systems malfunctions like various fuel system pump failures or electric system open-circuites ?
  

 

I'm unsure what you're asking exactly. Failures can be set to occur in Lockon so I can bet you can do the same thing, for the systems you've mentioned, in BS.

 

The question you should be asking is can you break the Chopper by flying so aggressively or improperly as to cause a failure and I believe the answer to that question is yes. Although I'm not sure what failures or how that will work exactly.

[sobek]

Did you check any stickies or use search function at all? There's so much info in these forums available to new guys and pardon me bu somehow I feel your post is just trying to be anoying...

 

Don't be mean to the newbie. I understand, how annoying such questions are to forum vets but we have to treat every newcomer like a noob to forum etiquette. Being turned down by the community when your first post is a little bit off is surely not the way we want things to go here, do we?

[Maximus_G]

Hello. I'm interesting how detailed your helicopter simulation is.

 

• Do you simulate auto-rotation mode and vortex ring?
  
• Do you simulate any emergency situations like blade segments loss or tail boom rope breakdown?
  
• Do you simulate airborne systems malfunctions like various fuel system pump failures or electric system open-circuites ?
  

 

Hi,

you can obtain some information here and here.

[Kuky]

Don't be mean to the newbie. I understand, how annoying such questions are to forum vets but we have to treat every newcomer like a noob to forum etiquette. Being turned down by the community when your first post is a little bit off is surely not the way we want things to go here, do we?

 

EDIT: after reading again I feel I was bit rude to the guy... I've deleted my previous post...

Edited October 27, 2008 by Kuky

[sobek]

not at all, reason I said what I said is because for his first post and being registered just today his question seemed to me very unusual... too specific for a typical 'noob' and I had the impression he's just trying to be anoying... I could be wrong but that's what it looks like to me...

 

Could be that he's got RL aviation experience. However, i can see your point. I just think we should be lenient with newcomers until they exhibit explicit misbehaviour.

[ZBear]

Not a friendly bunch are we :cry:

 

Bear

[loche]

Hi,

you can obtain some information here and here.

 

Thank you very much for useful information and excuse me for dumb questions :doh: 1 years ago I participated in a similar project "Mi8T, Mi8MTV, Ka225 helicopters trainers" as a leader of airborn systems modeling team, so I was a little bit agitated when read about your project.

 

Here is a link to our department page and the videos. Not much information unfortunatelly.

 

Comparing our systems I can tell:

 

* Our rotor model and hull aerodinamics uses finite elements method. It's based on TSAGI wind tunnels blowing statistics. I'm not sure but it seems more precise. For instance, we are modelling turbulent streams during landing on moving aircraft-carrier.

 

* your damage model is much more detailed. We only imitate "the whole helicopter destruction" and some landing emergencies like "tail boom touchdown".

 

* our environment modelling is also primitive - just some vehicles, aircrafts and ships, moving on predefined trajectories.

 

* our visualisation/sensor system looks similar. It models various weather conditions like different kind of static clouds, fog, rain, day/night cycle, primitive dynamic shadows

 

* for airborn systems modelling we used discrete integration with fixed step and executable statechart diagrams. Our airborn system models seems more detailed. We had implemented most of airborn systems malfunctions, specified in flight engeneer's manual. For instance for Ka226 we modelled such systems as "air system", "anti ice system", "electro system", "fire system", "fuel system", "heating system", "hydro system", "start system", "anti dust dumpers", "communication system", "transmission" and all navigation equipment. Example of Mi8T electro system malfunctions: "left/right generator failure", "accumulators failure", "main/aux current transducer faulire", "voltage loss during warm-up"

 

The differences in level of detalization of our systems is due to different purposes: your model used in gaming, where higher level of interaction needed, and our is used to train newbie pilots, so we need more precise aerodynamics and airborn systems modelling sacrificing realistic environment.

 

P.S. Sorry for my English :smilewink:

Edited November 13, 2008 by loche

[Groove]

Thanks for the interesting infos loche.

[fragal]

Great read loche :D thanks

[Yo-Yo]

 

Comparing our systems I can tell:

 

* Our rotor model and hull aerodinamics uses finite elements method. It's based on TSAGI wind tunnels blowing statistics. I'm not sure but it seems more precise. For instance, we are modelling turbulent streams during moving aircraft-carrier landing.

* your damage model is much more detailed. We only imitate "the whole helicopter destruction" and some landing emergencies like "tail boom touchdown".

* our environment modelling is also primitive - just some vehicles, aircrafts and ships, moving on predefined trajectories.

* our visualisation/sensor system looks similar. It models various weather conditions like different kind of static clouds, fog, rain, day/night cycle, primitive dynamic shadows

* for airborn systems modelling we used discrete integration with fixed step and executable statechart diagrams. Our airborn system models seems more detailed. We had implemented most of airborn systems malfunctions, specified in flight engeneer's manual. For instance for Ka226 we modelled such systems as "air system", "anti ice system", "electro system", "fire system", "fuel system", "heating system", "hydro system", "start system", "anti dust dumpers", "communication system", "transmission" and all navigation equipment. Example of Mi8T electro system malfunctions: "left/right generator failure", "accumulators failure", "main/aux current transducer faulire", "voltage loss during warm-up"

The differences in level of detalization of our systems is due to different purposes: your model used in gaming, where higher level of interaction needed, and our is used to train newbie pilots, so we need more precise aerodynamics and airborn systems modelling sacrificing realistic environment.

 

Concerning aerodynamics: FEM can be implemented in simulation if you can afford separate computer or even a cluster for these calculations. We have only one computer for all purposes so we use the method that provides acceptable accuracy and is much more processor friendly. This model allows to obtain most of effects inherent to the helicopter and have main model parametres pretty close to prototype.

The systems is modelled using physical level of modelling and not a statechart. As we mentioned before the engines is modelled using thermodynamics model similar to the models used for engine design. Hydroulics and fuel system based on elements and equations of liquid flow.

This handling allows to have damage model parametrical and not scripted that is more flexible and convenient to implement.

We don't need to describe what must be with an engine if air dump valves stays open when the engine is working at TO power - just leave the valves open and the model will do the rest.

The engine icing is simulated throttling the compressor. Engine deterioration is simulated modifying some parameters of its parts.

 

There is no need to describe what will be if fuel pump 27 V bus is down. Just kill this bus and the system will do the rest... regarding its state and states of its valves, tanks and pipes.

Also we can drill a hole in a tank or a pipe, foul a filter...

Though it seems to be more complicated this handling is very fruitful allowing to use its advantages after you complete the first step of modelling.

Etc, etc...

[d0ppler]

Wow, great reading, and a very acceptable reply from the DEV team. I sooo can't wait to get my hands on this russian baby!

[burnzoire]

that level of detail makes me warm inside :)

[EagleEye]

Wow, that`s a nice read Yo-Yo!

I wonder if there is another simulation which is using these techniques?

[urze]

Wow, that`s a nice read Yo-Yo!

 

Absolutely!

After some thinking I come to the conclusion that you can choose in 6-10 years(?) if you want to join the server as Pilot(messing things up) or Ground crew (fixing it again). :)

[Yo-Yo]

Absolutely!

After some thinking I come to the conclusion that you can choose in 6-10 years(?) if you want to join the server as Pilot(messing things up) or Ground crew (fixing it again). :)

 

 

By the way, there are some screws at least in the fuel governor that could be accessable for the ground crew to tune the fuel automatics. We even thought to make them accessable but there is no interface for ground crew man... ) No good physics for a screw driver too...

Edited October 28, 2008 by Yo-Yo

[192nd_Erdem]

I think that is a very clever kind of modelling, to let the simulation do the job rather than defining everything with scripts.

 

Oh and while we're at it, why don't you devs make a "Dev diary entry" about how the whole simulation of Black Shark works? I'm sure the sheer amount of work gone into it will attract much more people to buy your products.

[EvilBivol-1]

http://www.digitalcombatsimulator.com/index.php?end_pos=950&scr=default&lang=en

[urze]

No good physics for a screw driver too...

 

You don't have to start with such a complicated device like a screwdriver....

...sure a big hammer will be sufficient for 90% of the repairs. :P

 

Edit:

Serious-

Everyone should read through the description of the simulated systems:

http://www.digitalcombatsimulator.com/index.php?end_pos=950&scr=default&lang=en

Edited October 28, 2008 by urze

[nscode]

I think that is a very clever kind of modelling, to let the simulation do the job rather than defining everything with scripts.

 

Oh and while we're at it, why don't you devs make a "Dev diary entry" about how the whole simulation of Black Shark works? I'm sure the sheer amount of work gone into it will attract much more people to buy your products.

 

 

Yes, it's nice IF you get the modeling right. If not... funny things happen :D

[Yo-Yo]

Oh and while we're at it, why don't you devs make a "Dev diary entry" about how the whole simulation of Black Shark works? I'm sure the sheer amount of work gone into it will attract much more people to buy your products.

 

I am afraid it will be named "Dev diarrhea entry" by somebody... :) Too much to write.

But speaking seriously we always unveil the details of simulation if it is possible.

 

The main idea of our current simulation work is "Live system". It means that the system must be physically modelled and tuned bottom-up to achieve required performance at the points that can be checked even if we don't know initial low-level parameters of the system.

If there are not too many unknown variables or degrees of freedom it's not that extremely hard... :)

The model plays a role of complicated inter- extrapolator providing physically based behavior even far from these points.

 

As I begin to unveil our kitchen I'll say a few words about undercarriage, hydro and oil system.

 

While retracting or lowering the model calculates real kinematics and gets the hydro cylinder force. The cylinder is the element where hydro system meets undercarriage mechanics.

That's why retracting is slower and the undercarriage can not be locked in UP position if you turning maintaining g>1. Of course hydro system pressure affects too.

It's obvious that the liquid flow can be simply calculated during this process and it is used in the general hydro system calculations as well as the liqiud flow to control boosters, wheel brakes, etc.

 

The oil cooling system uses the heat balance equations and calculate heat sink of radiator really taking in account cooling air parameters and heat inflow from the engine or gear-box. So there is a big difference in steady oil temperature at various ambient air parameters and TAS. Of course it's not very accurate because we do not know exactly most of parametres but generally the behaviour is natural and the system malfunction such as insufficient oil flow causes reasonable consequences.

[deviletk]

I am afraid it will be named "Dev diarrhea entry".

 

HAHAHA!! :megalol:

[burnzoire]

Wow, that`s a nice read Yo-Yo!

I wonder if there is another simulation which is using these techniques?

 

http://kartsim.blogspot.com/ - A Karting sim that a good friend of mine is developing. They're doing much the same level of physics modelling for their engines & fuel etc. :thumbup: