Tune g limits for wing damage

onox commented 9 years ago

The current g limits might be too low and thus make it too easy to tear off the wings.

See https://github.com/Juanvvc/c172p-detailed/issues/134#issuecomment-110781583 and https://github.com/Juanvvc/c172p-detailed/issues/134#issuecomment-111212020 in #134.

wlbragg commented 9 years ago

I agree, I was testing the new 180 engine and touched the water a tad bit hard, should have busted a pontoon way before both wings. We really need to tune what causes these damage conditions.

dany93 commented 9 years ago

I may have a fix for this, I have to do tests.

The broken wings on landing or bouncing (particularly on water) come from the breaking criteria, based on the g's. Correct IMO for flying (it is the POH criteria for every aircraft) but touching the water gives many g's from the floats, which wrongly break the wings despite not being held by the wings. An extra hint IMO for the excessive brutality of the hydrodynamics settings, but this is another issue. My idea is replacing the g's with the lift forces, which come from the wings. I look at this and propose something it if I feel it can work. Waiting for it, please do not change too much this part of physics.nas

dany93 commented 9 years ago

dany93 test branch: wing-force-damages https://github.com/dany93/c172p-detailed/tree/wing-force-damages

onox commented 9 years ago

@dany93 Could you remove max_positive on line 18? It's unused now. max_negative and g aren't used either it seems :confused: Same thing for lines 10 to 13.

Also, can we increase the required g/force to something like https://github.com/Juanvvc/c172p-detailed/issues/134#issuecomment-111212020?

onox commented 9 years ago

@dany93 You can leave the current limits as they are if you want, I can no longer easily tear off my wings unless I go really fast (> 150 kt or something).

onox commented 9 years ago

Btw, you can define the limits in c172p-set.xml.

onox commented 9 years ago

@dany93 I've been doing some more testing. I noticed that in the air it's now very difficult to damage the wings at all. I need to dive towards the ground and then pull the yoke very fast. If I'm lucky I'll just get damage, but soon after that the wings get torn off.

dany93 commented 9 years ago

(I received you previous message during my writing...)

I can remove these useless lines with g, but I've left them on purpose in case wlbragg would like to use this criteria for something else. As you prefer (and @wlbragg).

For the different thresholds, my initial aim was to give a tool to enable wlbragg (or who wants to) doing what he wants with the thresholds and the effects. For me, the thresholds are plausible, and the effects are an example of what can be done. But it is obviously pure feeling, choices, and I'm not better than you on this. If you agree on the principle (force criteria on the wings), the best is that you change the values and the effects at your taste. I tried to do the FDM properties easy to understand and use, and the nasal file clear enough for that. Even the damages can take every value between 0 and 1, separately for each wing. This is like if you damage and had a yoke for the effect.

As you can see from the nasal file, there are three limits (equivalent to the previous ones with g's)

2550 lbs x 3.8 = 9690 lbs, (<==> 3.8 g's from the POH in normal category)
2550 x 3.8 x 1.25 = 12112 lbs,
2550 x 3.8 x 1.5 = 14535 lbs.

Tell me for the cleaning, I let you do for the effects. The wing damage was a request from @wlbragg .

dany93 commented 9 years ago

I need to dive towards the ground and then pull the yoke very fast

Yes, it's difficult to break both wings by overload. But keep in mind that the threshold forces were set for full load = 2550 lbs gross weight. Try with that weight, it becomes possible (although not easy). This makes more g's at default load. For the break threshold and criteria, I don't know the best. Do as you want. We are near the boundary of what can be (very imperfectly) done, and there will always be someone else to argue.

onox commented 9 years ago

@wlbragg I notice now that <int n="15" alias="/fdm/jsbsim/wing-damage/left-wing"/> and <int n="16" alias="/fdm/jsbsim/wing-damage/right-wing"/> should be floats.

To be honest though I'm not sure why they are floats. In principle each wing has 4 states:

Normal / repaired
Bended / damaged
Collapsed
Torn off

So we can use just two integers (one for each wing) for this to keep things simple. But in <multiplay><generic> we are using:

281         <int n="14" alias="/fdm/jsbsim/wing-both/broken"/>
282         <int n="15" alias="/fdm/jsbsim/wing-damage/left-wing"/>
283         <int n="16" alias="/fdm/jsbsim/wing-damage/right-wing"/>

For the pontoons the same thing, could be two properties instead of four:

277         <int n="10" alias="/fdm/jsbsim/left-pontoon/damaged"/>
278         <int n="11" alias="/fdm/jsbsim/left-pontoon/broken"/>
279         <int n="12" alias="/fdm/jsbsim/right-pontoon/damaged"/>
280         <int n="13" alias="/fdm/jsbsim/right-pontoon/broken"/>

Although I would like to refactor <int n="1" alias="/sim/model/c172p/lighting/beacon-top/state"/> and <int n="2" alias="/sim/model/c172p/lighting/strobes/state"/> to become floats (the voltage), because currently the transmission of the beacon and strobes is not very reliable.

onox commented 9 years ago

@dany93 Ok, but it's just difficult to get bended wings. Maybe it's also because of the roll moment required.

I have created branch bug-280 and imported your commit.

onox commented 9 years ago

I see the following numbers for wing-damage/left-wing and wing-damage/right-wing: 0, 0.12, 0.3, 0.5, 1.0

dany93 commented 9 years ago

I see the following numbers for wing-damage/left-wing and wing-damage/right-wing: 0, 0.12, 0.3, 0.5, 1.0

The used values are

0: not damaged,
0.12: for one wing damaged, can still fly by correcting with the ailerons. Lift slightly degraded.
0.3: for both wings damaged, can still fly with lift degraded. I have not set this value for one wing damaged because it necessitates ailerons + rudder correction to go on flying. Beyond the reach of many users.
1: one or both broken.

0.5 is not used, wing-damage/right-wing") < 0.5 is just to say "if this wing is not or only partly damaged, break it". Doesn't matter, currently there is nothing between 0.3 and 1.

onox commented 9 years ago

@dany93 I see they are used in the FDM. That's ok, but they don't really need to be transmitted over MP.

onox commented 9 years ago

I have done some refactoring in branch bug-280, because there so many getprop() calls that it seems to cause lag when damage occurs. (Or maybe FG doesn't load all the necessary .ac files until actually needed, but there were way too many getprop() calls :stuck_out_tongue_closed_eyes: )

dany93 commented 9 years ago

Does it mean that it is better to use nasal variables than getprop()?

onox commented 9 years ago

I mean doing getprop("A") multiple times instead of doing it once and the storing it in a Nasal variable.

dany93 commented 9 years ago

That was I thought to have understood. When you say it, it seems logical, but I hadn't thought of this. It is not only for concision of the code...

onox commented 9 years ago

I'm refactoring the MP properties a bit, to remove int[4], int[5], and int[14].

onox commented 9 years ago

@wlbragg Could you take a look at bug-280? I have managed to remove the three "broken" properties. Some remarks:

Currently we're using two floats to transmit the wing damage. Important values are:
- 0: undamaged
- 1: broken (torn off)
- 0.12, 0.3: damaged
As you can see the wing transmits just three possible states, so an integer should be suffcient to use (0, 1, 2). That would mean we can often use <equals> instead of <greater-than> + <less-than>, which is what we currently need to use because they're floats.

AFAIK the only reason why they are floats is because they're used in the FDM. But maybe we can make some small changes so wing-damage/left-wing and wing-damage/right-wing can be integers.
Same thing with the pontoons: we're using four properties, even though we only need two.
I find it too easy to tear off the wings. I find it very difficult to just get one or two wings damaged.
I find it almost impossible to get the "collapsed" state.
For the "collapsed" state we use /fdm/jsbsim/crash. But AFAIK that property is used by the MP lag code (in FlightGear/fgdata itself) to transmitting the position. It's also used by old c172p models, so I think we should use a different index (not int[3]) + not use /fdm/jsbsim/crash, but give it a proper name. Something like /fdm/jsbsim/wing-damage/collapsed.

wlbragg commented 9 years ago

In principle each wing has 4 states:

Not quite You need to be careful refactoring these. In reality we have:

normal / repaired both damaged both broke left damaged / right not left broke /right not left damaged / right broke right damaged /left not right broke / left not right damaged left broke

contact unit[4] and unit[5] control L and R wing broken individually. props control the rest.

I'll be able to respond in more detail tonight if you have more questions.

onox commented 9 years ago

Ok, 10 states:

normal/damaged/broken for left wing x normal/damaged/broken for right wing = 9

Plus both wings collaped = 10 :smile:

wlbragg commented 9 years ago

Yeah. forgot that one! :smile:

onox commented 9 years ago

Anyway, what I'm trying to say is that these three "broken" properties are not needed. We can do without them.

~~... I see how I can fix the wing collapse.~~ No, actually not. Think the old way was wrong.

wlbragg commented 9 years ago

Yeah, by using an int or a float that can represent multiple states. I was originally going to do that but dany93 needed a different configuration and I told him to do what he needed, it left us with extra props we really didn't need. I think it was a communication gap between the two of us. My fault for not clearing it up back then. So have at it!

onox commented 9 years ago

What do you think about (3) in https://github.com/Juanvvc/c172p-detailed/issues/280#issuecomment-116137167?

wlbragg commented 9 years ago

I agree, it seems easier to tear it off than damage it.

onox commented 9 years ago

Btw, about the wing-damage properties. What about:

0 = undamaged/unbroken 1 = broken 2 = 0.12 3 = 0.3

Then we can just do a wing-damage/left-wing > 1 check in the model xml file.

onox commented 9 years ago

I'm using a <switch> in the FDM, so that was fairly easy.

onox commented 9 years ago

I've made the changes to make the two properties ints. Pushing in a minute.

onox commented 9 years ago

I think I have fixed #336

dany93 commented 9 years ago

Btw, about the wing-damage properties. What about:

0 = undamaged/unbroken 1 = broken 2 = 0.12 3 = 0.3

Previously, the wing damages in flight could be fully controlled by only two properties. Directly understandable, intuitive and easy to use. But they are 0 - 1, double format. You have changed it for four states (integers), and a switch to do the connection to the FDM. Which worries me is for the future contributors.

Wouldn't have been more easy and more clear to keep the same properties but to have:

0 = undamaged/unbroken 100 = broken 12 = 12% damaged 30 = 30% damaged

They are integers, And we would have divided the factor in the FDM by 100, value = +/- 0.003 instead of +/- 0.3

            <function name="aero/coefficient/Cllwdmg">
                <description>Roll_moment_due_to_damaged_left_wing</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                    <property>>wing-damage/left-wing</property>
                    <value>-0.003</value>
                </product>
            </function>
            <function name="aero/coefficient/Clrwdmg">
                <description>Roll_moment_due_to_damaged_right_wing</description>
                <product>
                    <property>aero/qbar-psf</property>
                    <property>metrics/Sw-sqft</property>
                    <property>metrics/bw-ft</property>
                    <property>wing-damage/right-wing</property>
                    <value>0.003</value>

This avoids the intermediate function with the switch in the FDM, which hampers the understanding.

May be too late, or not easily consistent with you code for other damages?

Question: I didn't know for this way of using a switch. Where did you find it, is it explained somewhere? There is a severe lack on this.

dany93 commented 9 years ago

A weird detail: When I am in the bug-280 branch, the pilot appears when the option Human models is unchecked, and I have to check it to not have it.

onox commented 9 years ago

They are integers, And we would have divided the factor in the FDM by 100, value = +/- 0.003 instead of +/- 0.3

Please read the commits in the branch. See this: https://github.com/Juanvvc/c172p-detailed/blob/9493801c92f2cbc15f29b283b2632288f2292e41/c172p.xml#L908-L926

Question: I didn't know for this way of using a switch. Where did you find it, is it explained somewhere? There is a severe lack on this.

It is explained here: http://jsbsim.sourceforge.net/JSBSim/classJSBSim_1_1FGFunction.html

onox commented 9 years ago

Ah, sorry, I should better read, you actually found the switch. The reason I didn't use:

0 = undamaged/unbroken 100 = broken 12 = 12% damaged 30 = 30% damaged

is because otherwise I would have to add lots of extra checks in Models/c172p.xml to make sure that 100 is not considered when I want to check that the wing is just damaged.

onox commented 9 years ago

When I am in the bug-280 branch, the pilot appears when the option Human models is unchecked, and I have to check it to not have it.

Thanks for finding this. I'll take a look at it. It did change some code related to it, so I'm not surprised.

onox commented 9 years ago

Fixed it.

onox commented 9 years ago

@dany93 About the float/int problem: I was thinking about it: it's only the model that needs to know whether the wing is normal/damaged/broken. So what we could do is:

Just use floats in the FDM. Remove the two switches
Use floats in Nasal/physics.nas
Write two small funtions/filters that output 0 to a new property if normal, 1 if broken, 2 if damaged (no matter how much). That would mean very little changes to the model file, so it's easy to do. (or 1 for damaged, 2 for broken, if that's what you really want)

dany93 commented 9 years ago

If I understand well:

items 1. and 2. would amount to restore the previous form in Nasal/physics.nas and the FDM,
your filter (item 3.) would do the interface between physics.nas and the Models/. I guess that the new property = 2 value ("damaged") can be flexible enough (like new property = 2 for damage= 0.1 to 0.9, or not 1 and not 0) in case someone would change the damage value (currently 0.12 or 0.3). I guess that the filter may merely be in physics.nas, which would give the explanation to the future contributors.

Good idea, I like it. But it depends on you, if you accept my remark, enough to do this extra work.

1 or 2 for damaged or broken is rather for the Models/ management side, @wlbragg and you. I'm not disturbed by 2 for damaged, because I'm used to 1 for broken. Purely mnemonics.

Anyway, thank you. And thank you too for your JSBSim link. I had it, but there is so much in it and so concise that finding a subject is not always easy. Moreover, I must admit that I had forgotten it.... And your switch will have driven me to learn this way of using it.

onox commented 9 years ago

Alright, I'll make the necessary changes then :smile:

onox commented 9 years ago

@dany93 I have made the necessary changes.

dany93 commented 9 years ago

Thank you onox.

onox commented 9 years ago

I have made some changes to the lift forces needed to damage/break a wing. Pushing in a minute.

dany93 commented 9 years ago

Sorry, but I have to leave. This will be for to morrow (for me).

onox commented 9 years ago

Now I'm noticing that JSBSim doesn't execute my two <switch> blocks in replay mode :confused:

onox commented 9 years ago

Fixed it by moving it to a <property-rule>.

onox commented 9 years ago

@wlbragg I have adjusted the max lift force. Could you test it a bit?

onox commented 9 years ago

@wlbragg Could you explain why the overspeed/over-g code in Nasal/physics.nas often checks for damage on the opposite wing when it wants to damage/break the other wing?

For example, see this. The code checks that the left wing is undamaged, and if it is, it damages the right wing. Is this really how it should be or is this a mistake?

dany93 commented 9 years ago

No, this is not a mistake. I have written this code several weeks ago and I don't remember well the details. The idea is, you have 4 states:

one wing damaged (0.12) ==> the aircraft can still fly by aileron correction,
two wings damaged (2 x 0.3) ==> can still fly, lift degraded,
one wing broken ==> rapid roll spin,
two wings broken.

Without these checks for the other wing, you hardly had some of these states because the movements of the aircraft or your attempts to correct provoked a second damage on the other wing and you never had some of them, like one wing damaged or one wing broken. Try by deleting these checks and you will probably see what I mean. In RL, a second damage on the other wing is possible, but in FG all of these are scenarios. Which means that yo can invent...

onox commented 9 years ago

Okay, I have left the checks as they were when I moved the code to Systems/c172p-damage.xml.

c172p-team / c172p

Tune g limits for wing damage #280