New FSXBA Hornet

[hd764jvgd843]

Jimi: I had some time to quickly test the prototype version provided, and one can see you are really trying hard to implement a lot of features that have been suggested, much appreciated. It will be definitely a big leap ahead. This weekend, with more time at my hands, I will have a closer look and will try changing/tweaking some PID settings and how they impact flight behaviour.

Another question: Pitch_Auto_Trim.xml - G Limiters
The g limiters have a total weight value of 44000. How is it used to influence g limits? - It seems to be just a threshold/trigger value? - I am not quite sure, what effect it has when the bird has a gross weight above that value.
Asking because of the CS D version which has max loadout ~49,500lbs compared to default NH version of ~42,000lbs.
Would you suggest raising the value in this case to e.g. 50,000 in order to always stay below it, or leave it at 44,000?

Best regards, Peter

[jimi08]

Jimi: I had some time to quickly test the prototype version provided, and one can see you are really trying hard to implement a lot of features that have been suggested, much appreciated. It will be definitely a big leap ahead. This weekend, with more time at my hands, I will have a closer look and will try changing/tweaking some PID settings and how they impact flight behaviour.

Thanks.  Pretty excited about it and big thanks to Orion for his help and patience.  Anticipate more good things.

Another question: Pitch_Auto_Trim.xml - G Limiters
The g limiters have a total weight value of 44000. How is it used to influence g limits? - It seems to be just a threshold/trigger value? - I am not quite sure, what effect it has when the bird has a gross weight above that value.
Asking because of the CS D version which has max loadout ~49,500lbs compared to default NH version of ~42,000lbs.
Would you suggest raising the value in this case to e.g. 50,000 in order to always stay below it, or leave it at 44,000?

According to NATOPS, the Hornet is G limited to 5.5 max at and above 44000lbs.  Below, 7.5 max.

[hd764jvgd843]

Thanks Jimi for the quick reply, that info helped a lot - and many thanks to Orion, for his support, too!

In the Pitch_Auto_Trim I have created an additional 2.0 G Limiter in order to avoid backflips with weights above 44,000lbs at speeds below 350kts, as a workaround - and it works wonders!

[jimi08]

Interesting....  Glad that it works.  I was kinda hesitant to implements such a thing after hearing that the Hornet has a pretty low cornering speed of around 310 KTAS.

[hd764jvgd843]

I have set it to 350kts because, with a loadouts above 44,000lbs at speeds of around 400kts, backflips could not be triggered, but at speeds of around 350kts they occurred reproducibly.

I have also noticed that the Elevator Effectiveness, table 341, seems to be asymetric, but in the wrong way. Left leg for pitch down behaviour has higher values than the right leg for pitch upwards. I have adjusted that, also in order to pull higher AoAs I slightly increased the right leg. Table values I use, in case you want to give it a try:

Y:       0.8       0.75       0.75       0.6       1.0       1.08        1.50
X:     -0.262   -0.209    -0.175     0.0      0.175    0.209     0.262

[hd764jvgd843]

Hi Jimi,

a few thing I have noticed ironing out these backflips:

- G Limiters: Noticed the settings for yoke/elevator position are set to 90% as a triggers - probably due to NATOPS. This results in breaking g limits in our case. When flying at sea level, 450-500kts and you apply full stick/elevator during a turn, the g limiter kicks in and everything is fine, up to the point when you gradually release stick. The bird, e.g. with max. loadout will transition from limited 5.5g relatively fast up to 7.5g and sometimes even g warning will sound. As you apply more stick again, she will get back into the limited 5.5g zone (working with thrust as suitable, in order to keep speed relatively constant). In order to avoid this behaviour I have changed elevator/yoke position values in g limiter sections. During my tests I found these to give the most reliable and smoothest, although still clearly noticeable results, getting in and out of g limits without breaking them.

- The additional two G Limiters I have added, work as wannabe AOA limiters (20deg. and 35deg. for loadouts above 44000lbs and below), suppressing very effectively backflips during tight turns at slow speeds. I have tested these with the following adjusted Elevator Effectiveness table 341 in the .air file - that allows for higher AoAs during slow speed turns, right to the limit - than compared to the current one in use. It differs only in the next-to-last Y value from the one in the above mentioned post.
Y:       0.8       0.75       0.75       0.6       1.0       1.13        1.50
X:     -0.262   -0.209    -0.175     0.0      0.175    0.209     0.262

As you may notice, I have removed G Force as a trigger value from the additional two G Limiters, because I have found, that it more hinders than helps in certain conditions, as when you are already below that trigger threshold, it won't snap anymore, e.g. protect against backflips.

- One more thing. In order to battle sideslip due to bank angle, I have adjusted the following values in the .air file, with good results. Table 1101 Primary Aerodynamics > Yaw moments:
  - Adjusted Cn_beta - Sideslip from '500' to '-200'. This battles sideslip due to bank angle.
  - Adjusted Cn_R - Yaw Rate from '-500' to '-1500'. This entry dampens induced instability due to inverted sideslip, so the jet does not spin out of control around the yaw axis. A must have in order to work for the before mentioned change.
  - Adjusted Cn_dr - Rudder (control) from '300' to '150'. Max applied rudder seemed much too strong, could lift entire jet effortlessly at slow speeds at 90deg. bank angle, so I reduced it by 1/2.
Overall result: There is still sideslip due to bank angle, which is good, so the flight envelope still looks natural but it is much more controlled than before. You do not have to pull elevator immediately in order to keep her from slipping during a turn, nor have to react with instantaneous rudder input during straight flight.


As usual, I hope this feedback helps in some way.

Best regards, Peter

P.S. I hope to release an updated version of the mod before the weekend, so you can give it a try.

-----------------------------------------------------------------------------------------------------------------------------------

<!-- G LIMITER: 7.5 -->

(L:FCS_ENABLE, enum) 1 ==
(A:G FORCE,G Force) 7.0 &gt; and
(A:AIRSPEED MACH,Mach) 1.8 &lt; and
(A:TOTAL WEIGHT,pounds) 44000 &lt; and
(A:ELEVATOR POSITION, Percent) 1 &gt; and
(A:YOKE Y POSITION, Percent) 1 &gt; and
if{ 1 (&gt;L:G_LIMITER_7.5_ENABLE, enum) } els{ 0 (&gt;L:G_LIMITER_7.5_ENABLE, enum) }
(L:G_LIMITER_7.5_ENABLE, enum) 1 ==
        if{ (A:G FORCE,G Force) 7.5 / (&gt;L:G_LIMIT_RATIO, number) } els{  }
(L:G_LIMITER_7.5_ENABLE, enum) 1 ==
        if{ (L:G_LIMIT_RATIO, number) (A:AIRSPEED TRUE, Knots) * (&gt;L:G_LIMIT_VALUE, number) } els{  }
(L:G_LIMITER_7.5_ENABLE, enum) 1 ==
        if{ 16383 (L:G_LIMIT_VALUE, number) - -0.9 * (&gt;K:AXIS_ELEVATOR_SET) } els{  }
(A:G FORCE,G Force) 7.5 &gt;
        if{ (&gt;K:ELEV_TRIM_DN) } els{  }



<!-- G LIMITER: 5.5 -->

(L:FCS_ENABLE, enum) 1 ==
(A:G FORCE,G Force) 5.0 &gt; and
(A:AIRSPEED MACH,Mach) 1.8 &lt; and
(A:TOTAL WEIGHT,pounds) 44000 &gt; and
(A:ELEVATOR POSITION, Percent) 1 &gt; and
(A:YOKE Y POSITION, Percent) 1 &gt; and
if{ 1 (&gt;L:G_LIMITER_5.5_ENABLE, enum) } els{ 0 (&gt;L:G_LIMITER_5.5_ENABLE, enum) }
(L:G_LIMITER_5.5_ENABLE, enum) 1 ==
        if{ (A:G FORCE,G Force) 5.5 / (&gt;L:G_LIMIT_RATIO, number) } els{  }
(L:G_LIMITER_5.5_ENABLE, enum) 1 ==
        if{ (L:G_LIMIT_RATIO, number) 500 * (&gt;L:G_LIMIT_VALUE, number) } els{  }
(L:G_LIMITER_5.5_ENABLE, enum) 1 ==
        if{ 16383 (L:G_LIMIT_VALUE, number) - -0.8 * (&gt;K:ELEVATOR_SET) } els{  }
   
      

<!-- G LIMITER: -3.0 -->

(L:FCS_ENABLE, enum) 1 ==
(A:G FORCE,G Force) -2.5 &lt; and
(A:AIRSPEED MACH,Mach) 1.8 &lt; and
(A:ELEVATOR POSITION, Percent) -1 &lt; and
(A:YOKE Y POSITION, Percent) -1 &gt; and
if{ 1 (&gt;L:G_LIMITER_-3.0_ENABLE, enum) } els{ 0 (&gt;L:G_LIMITER_-3.0_ENABLE, enum) }
(L:G_LIMITER_-3.0_ENABLE, enum) 1 ==
        if{ (A:G FORCE,G Force) -3.0 / (&gt;L:G_LIMIT_RATIO, number) } els{  }
(L:G_LIMITER_-3.0_ENABLE, enum) 1 ==
        if{ (L:G_LIMIT_RATIO, number) 3000 * (&gt;L:G_LIMIT_VALUE, number) } els{  }
(L:G_LIMITER_-3.0_ENABLE, enum) 1 ==
        if{ 16383 (L:G_LIMIT_VALUE, number) - 0.9 * (&gt;K:ELEVATOR_SET) } els{  }



<!-- G LIMITER: 2.0 (suppress backflip: loadout above 44000lbs, speed below 250kts, AOA above 20deg.) -->

(L:FCS_ENABLE, enum) 1 ==
(A:AIRSPEED INDICATED,knots) 250 &lt; and
(A:TOTAL WEIGHT,pounds) 44000 &gt; and
(A:INCIDENCE ALPHA,Degrees) 20 &gt; and
(A:SIM ON GROUND, bool) ! and
(A:ELEVATOR POSITION, Percent) 1 &gt; and
(A:YOKE Y POSITION, Percent) 1 &gt; and
if{ 1 (&gt;L:G_LIMITER_2.0_ENABLE, enum) } els{ 0 (&gt;L:G_LIMITER_2.0_ENABLE, enum) }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ (A:G FORCE,G Force) 2.0 / (&gt;L:G_LIMIT_RATIO, number) } els{  }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ (L:G_LIMIT_RATIO, number) 500 * (&gt;L:G_LIMIT_VALUE, number) } els{  }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ 16383 (L:G_LIMIT_VALUE, number) - -0.8 * (&gt;K:ELEVATOR_SET) } els{  }



<!-- G LIMITER: 2.0 (suppress backflip: loadout below 44000lbs, speed below 250kts, AOA above 35deg.) -->

(L:FCS_ENABLE, enum) 1 ==
(A:AIRSPEED INDICATED,knots) 250 &lt; and
(A:TOTAL WEIGHT,pounds) 44000 &lt; and
(A:INCIDENCE ALPHA,Degrees) 35 &gt; and
(A:SIM ON GROUND, bool) ! and
(A:ELEVATOR POSITION, Percent) 1 &gt; and
(A:YOKE Y POSITION, Percent) 1 &gt; and
if{ 1 (&gt;L:G_LIMITER_2.0_ENABLE, enum) } els{ 0 (&gt;L:G_LIMITER_2.0_ENABLE, enum) }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ (A:G FORCE,G Force) 2.0 / (&gt;L:G_LIMIT_RATIO, number) } els{  }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ (L:G_LIMIT_RATIO, number) 500 * (&gt;L:G_LIMIT_VALUE, number) } els{  }
(L:G_LIMITER_2.0_ENABLE, enum) 1 ==
        if{ 16383 (L:G_LIMIT_VALUE, number) - -0.8 * (&gt;K:ELEVATOR_SET) } els{  }

[Kea]

New texture folders up on my Drive (going up now).

https://drive.google.com/folderview?id=0B_KeMXMmL3b3WTZvVUVFOHB1X0U&usp=sharing

There are two zips - one with texture folders for A and C Hornets, the other with texture folders for B and D's. Included textures:


A's and C's:

RAAF 75Sqn (A21-23) - note this is a reworked version of the previous
RAAF 2OCU (A21-28)
RAAF 3Sqn (A21-21)
RAAF 77Sqn (A21-20)

RCAF 409Sqn (188747) - this is also a reworked version
RCAF 410Sqn (188749)
RCAF 425Sqn (188758)

Swiss AF (J-5002) - these are the same as previous with the WEF version included, just "repackaged" - read the readme included in the main zip

Finnish AF (HN-419) - same as the Swiss one



B's and D's:

RAAF 75Sqn (A21-112)
RAAF 2OCU (A21-115)
RAAF 3Sqn (A21-103
RAAF 77Sqn (A21-105)

RCAF 409Sqn (188931) - this is also a reworked version
RCAF 410Sqn (188917)
RCAF 425Sqn (188934)

Swiss AF 11Sqn (J-5232) - Special WEF paint
Swiss AF 13Sqn (J-5234)

Finnish AF 21Sqn (HN-463)
Finnish AF 21Sqn (HN-465) - note this one does not have the serial on the tail, this is deliberate.

Thanks again to Hani Michal for the great base textures used in these repaints.
If anyone spots any glaring mistakes, please let me know so I can correct them. I haven't had a great deal of time to properly check these in the sim, been a bit sidetracked doing some IRIAF repaints for Dino Cattaneo's Tac-packed F-14...

Hope you enjoy!

[tuldrich]

Hi Jimi, my name is Tom. I've been following this particular forum for long time, and have been flying the v15.2, and such, as released....I like your Hornet alot, and frankly I think your F18C is much easier to fly than the VRS bug. The FSXBA 'Fleet' bird is really a joy to fly and she flies really great behind the boat, which is what I love doing most.

At any rate, I read your recent posts about PID controllers, and wanted to offer some PID tuning advice because I'm a control systems engineer for a major chemical company, and I use PIDs at my work to control manufacturing/industrial processes.

I am going to suggest that you make the 'Kd' derivative term constant a zero (Kd=0), and try to tune the controller, first, this way. Essentially you will be starting with a PI controller. The 'Kd' term deals with the slope of the error as it changes in real-time, and the way some simulation jokers yank around on the control stick (yoke) at high speed, could cause the 'slope' of error to go almost infinite (infinite slope would be analogous to vertical line, +/- 90 degrees). So basically the 'Kd' term in the equation would be eating your lunch, or killing the error correction effects of the PID. Try that.

Next, for the Kp & Ki constants, I suggest starting with small values like: 0.1, or maybe smaller, and work up in small increments. The processes I'm used to dealing with in chemical plant are probably pretty slow processes (liquid levels and flows) compared to flight dynamic processes and parameters. So try starting with small values for the Kp & Ki constants, and working toward larger values.

Also, the Ki constant can get out of hand, because this represents the area under the error curve. So, if you have large error, and have accumulated a lot of error, and have large Ki constant, the PID output will go crazy, and get into oscillating. So work Ki tuning in small increments.

And I'm going to suggest that you tuning Kp & Ki at same time, meaning don't work 'Kp' alone, and try to max it out, then go tune 'Ki' ... Work and tune the two together.

Finally, you need to limit the PID output to "real" maximum and minimum output values, to prevent the output from getting jacked up ... PID output:
P ={0...100}  // range of output

So, if you are writing code to implement the PID algorithm, after your code goes thru steps to calculate the terms for the PID equation, and right before you use the PID output to apply the correction, and before the next iteration of the PID calculation loop, put in code like this example:
IF (P < 0) THEN               // P is PID output variable; If calculations resulted in P, output, being a value less than zero
   P = 0;                        // then limit the output to be no less than 0%, regardless of what the PID equation calculates for the output
ELSEIF (P > 100) THEN    // If output result is greater than 100%
   P = 100;                    // then limit to be 100, and not greater than 100, regardless of what the PID algorithm calculated
ELSE
   P = P;                       // otherwise, just use the calculated result.

Sorry to be so long winded about this, but I know what a pain PID controllers can be to tune. Hope this helps.

Regards,
Tom

USMC F-18C Veteran
VMFA-212 & VMFA-321

Here are some videos of your baby behind the boat:

[Orion]

Finally, you need to limit the PID output to "real" maximum and minimum output values, to prevent the output from getting jacked up ... PID output:
P ={0...100}  // range of output

So, if you are writing code to implement the PID algorithm, after your code goes thru steps to calculate the terms for the PID equation, and right before you use the PID output to apply the correction, and before the next iteration of the PID calculation loop, put in code like this example:
IF (P < 0) THEN               // P is PID output variable; If calculations resulted in P, output, being a value less than zero
    P = 0;                         // then limit the output to be no less than 0%, regardless of what the PID equation calculates for the output
ELSEIF (P > 100) THEN    // If output result is greater than 100%
    P = 100;                     // then limit to be 100, and not greater than 100, regardless of what the PID algorithm calculated
ELSE
    P = P;                        // otherwise, just use the calculated result.

That's actually already implemented in the current version of the FCS, except I constrain the values from -100 to 100 rather than 0 to 100, as 0 is neutral for the flight controls.  There's also similar code to mitigate integral windup as well.  Thanks for the feedback!

[jimi08]

Tom,
Thanks for the positive feedback and big thanks for the suggestions in regards to PID tuning.  I will definitely give them a go once I get the opportunity.

I see "USMC" down there in your sig block.  Thanks for your service and sacrifice.

Respectfully,
Jimi

[SpazSinbad]

Thanks for the great video Tom 'tuldrich' - it is a keeper. Great to see a visual circuit done so well - music is a bonus. 

[jc005e]

heres a little video i made promoting more people to get the f-18C/D

&feature=youtu.be

[einherz]

hi, it's me again:)
what thats mean?
http://i62.tinypic.com/rcvntc.jpg
and how fix? (p2d here)
thank you

[Orion]

hi, it's me again:)
what thats mean?
http://i62.tinypic.com/rcvntc.jpg
and how fix? (p2d here)
thank you

SIMCONNECT_EXCEPTION_UNRECOGNIZED_ID
  Specifies that the client event, request ID, data definition ID, or object ID was not recognized.

All the client events, requests, and data definitions (as well as the object ID) used in the gauge are constants, so the exception may suggest that the gauge may not have initialized properly.  If the FCS isn't functioning properly, try restarting the simulator.  Otherwise it may be an erroneous message.

[eagle01]

regards to all...
how to solve this problem.