• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Multiple Pitch Controlling Devices

J

jimi08

Messages
61
Country
us-california
Hello all,

I am wondering if there is a way to create two separate pitch controlling devices for one aircraft. For example, two separate, independent elevators or two, separate elevator trim tabs, that can be controlled completely independently from one another control the aircraft.

My aim would be to assign one pitch controlling device to reflect pilot input, while the other could be assigned of other buttons/functions and would work in the background to serve a completely different function independent of pilot input.

The ultimate goal would be for one pitch controlling device to (i.e. elevator trim) to be used in a traditional manner, where the pilot can manually increment/decrement trim as needed depending on flight conditions. The secondary elevator trim would control the longitudinal axis of the aircraft and is completely independent from direct pilot input. It would be used to automatically keep the jet trimmed under certain conditions.

Any help would greatly be appreciated. Thanks.
 
I think you'd have to create your own flight simulator to accomplish that.
 
I think the easiest way to achieve this would be via a SimConnect module, or maybe FSUIPC, that controls the trim, or elevator, and then intercepts the user's input to include in its calculations. Basically the module does everything and the user's input doesn't get passed directly to FS but is used as an input to the module to calculate the desired final value.
 
Read further... where he goes into detail about differing trim controls, one set by the pilot and one set by the aircraft's avionics.
 
Those were given as examples. Elevator and trim offer two pitch controlling devices. That's probably the best he'll get with FS.
 
All you would need is the math.

In flight, if trim1 = +1 and trim2 = -1 net trim = 0... except you would have increased drag for no useful reason. But in any case, trim2/elevator2 could be added to the actual trim/elevator to get the effect you want.

This would in essence equate to a fly by wire system...
 
Sorry, but in the scenario that I'm attempting to create, it is not just simple math. Part of this is due to using either the elevator or the simulator trim functions to be used simply as initial values, which will then be used by an algorithm or two to produce the desired result.

The current problem is, I can't find a way to disconnect elevator or elevator trim indication with the position of the actual elevator or elevator trim without having to use something such as FSUIPC. Take the elevator trim for example. I would like to use a gauge to control the elevator trim, but not have its position reflected on the elevator trim indicator. Although the actual elevator trim is continuously moving and trimming the aircraft, the elevator trim indicator is independent from the actual elevator and its value is only changed by the user pressing the trim up and trim down keys. The pilot can change the value on the elevator trim indicator, but it has no direct effect on the actual elevator trim.

Ultimately, I want to design a pitch auto trim system, where the actual elevator trim is constantly working to trim the aircraft to 1.0 G, zero pitch rate flight automatically once the controls are released. When the sim pilot manually adjusts the pitch trim (by using the standard/default elevator trim functions), he/she will actually be adjusting a simple numeric value that does not directly control the jet. Instead the value will be used in an algorithm to increment or decrement the baseline G that the auto trim system is seeking to maintain. For example, if the pilot pushes the nose up trim function, the pitch auto trim will now seek to maintain 1.1 G instead of 1.0 G. If the pilot pushes the nose-down trim function, the system will seek to maintain 0.9 G instead of 1.0 G.

As it stands right now, I have had no success. Because I cannot disconnect the trim from its indicator, there is no way form the trim indication to remain static and to be used as a guide without freezing the trim itself. I can set the elevator indicator to a certain value, but as soon as the actually elevator trim moves (due to the auto-trim system), the value changes as well.

Same thing with the elevators. Eventually, I would like to create a system where the pilot actually commands G with his flight stick and not stab/elevator position. For example, the F/A-18 has a max G of 7.5. So as long as the aircraft has the energy, full aft stick will give the pilot 7.5 Gs. Half aft stick will give the pilot 4.7 Gs, regardless if he is flying at 300 knots or 700 knots. The percentage of stick pushed or pulled translate directly to a certain G maintained by the aircraft. Just like the elevator trim situation, I would need to be able to detach the fore/aft stick position from the actual elevator position. The stick would merely serve as a simple numeric value to be fed into another algorithm to decide the actual position of the elevator control surfaces.

I hope this isn't too confusing and thanks for the help!
 
Jimi
The autotrim you have in your FA-18 actually works very well in flight and I have used it experimentally in other models. I'm not sure why you want to change it other than your point about having a direct relationship between controller position and g.
I know you have had problems with compatibility with Multiplayer. However even through your autotrim constantly outputs Trim events, these events are not "all aircraft" in multiplayer and should not have been the cause for "flooding". They would be a cause for problems in shared cockpit, but not regular Multiplayer.

Roy
 
I thought i had a growing sense of deja vu. The OP got a fairly comprensive response to this subject here:

http://www.fsdeveloper.com/forum/sho...d.php?t=206666
Click to expand...

You are correct, same issue. Just looking at attacking it from a different angle...


Jimi
The autotrim you have in your FA-18 actually works very well in flight and I have used it experimentally in other models. I'm not sure why you want to change it other than your point about having a direct relationship between controller position and g.
I know you have had problems with compatibility with Multiplayer. However even through your autotrim constantly outputs Trim events, these events are not "all aircraft" in multiplayer and should not have been the cause for "flooding". They would be a cause for problems in shared cockpit, but not regular Multiplayer.

Roy
Click to expand...

Thanks for the compliment Roy. We have worked a lot to tweak the jet as a whole so that it doesn't flood in multiplayer. Yes the autotrim works nicely, but trying to make it even better by allowing the pilot to interact with the trim system by changing the baseline G Force that the system trims to. This same concept would be applied to the jet in Approach mode as well, where the pilot would be able to adjust the baseline AOA that the jet trims to by adjusting the trim.
 
Jimi,
If you want to use the trim button for another purpose, then assign it to another purpose, like radio 2 frequency INC/DEC.

Use the radio frequency when in approach mode to set the Commanded Approach AOA. The PID will control trim to maintain AOA

When in G control mode use the frequency to generate some value of L:ROTATION VELOCITY BODY X to compare with A:ROTATION VELOCITY BODY X and therby use trim to satisfy a datum g.

There may be another INC/DEC variable rather than Radio 2 frequency that you are not using in the FA-18, but the general idea is to have a controllable INC/DEC variable which is not trim to indirectly control trim the way you want it to do so, according to the mode you are in.

Roy
 
Jimi,

Everything in aerodynamics, especially in a computerized simulator.... is math. Especially what you are attempting.



Make custom variables, use math, then send the net output to the actual elevator & trim. Display the inputs in the gauge.


If you already have the math to know how much stick is needed for a given airspeed, then you could simply use:

A:Yoke position & A:Elevator trim position + speed adjustment = value to send to ELEVATOR. In this case there is no need for a second trim, as the stick range is calibrated to G at all speeds. The trim would be internal to the algorithm, nullifying the need for FS trim (unless elevator is exceeding its limits)



But if you don't have all that worked out then:

Yoke & trim position ---> sent to algorithm that outputs net trim and elevator ---> fed to FS control surfaces & custom gauge display.

The custom display gauge would show the trim adjustment(s) from the algorithm, but the control surfaces would receive the net result. In this case you could have 30 trims if you wanted, as long as the net effect is sent to the surfaces.




use a gauge to control the elevator trim, but not have its position reflected on the elevator trim indicator. Although the actual elevator trim is continuously moving and trimming the aircraft, the elevator trim indicator is independent from the actual elevator and its value is only changed by the user pressing the trim up and trim down keys. The pilot can change the value on the elevator trim indicator, but it has no direct effect on the actual elevator trim.
Click to expand...

You answer your own question here.

Simple.
 
jx,

I understand that it seems like simple math initially, but take your example...

Yoke & trim position ---> sent to algorithm that outputs net trim and elevator ---> fed to FS control surfaces & custom gauge display.
Click to expand...

In the example stated above, you are assuming that the initial indications are static and are provided and set by the pilot (pilot sets trim & and yoke). From there the algorithm works on that set of initial inputs. But the problem with FSX is that it does not separate the difference between indication and position...

Let's say you set trim value "x" in the INDICATION window to have the system do a certain function. Lets use the value of 10 (x=10). The basic algorithm says take the initial value and double it for a final trim POSITION value. Because FSX doesn't make a distinction between the indicated value and actual value, as soon as the trim POSITION starts moving to chase after the final value (20), it changes the initial input INDICATED value that it started with. So 10 now changes to 1 because that is how far the trim POSITION actually moved before changing the INDICATION. Now the algorithm looks a 1 as its initial INDICATED value and starts working with that number.

Your system would work great (as it should) assuming that the initial input parameter stayed static. But it does not. Because you cannot separate the trim INDICATION from the trim POSITION, you create a closed loop that continually "chases after it's tail" before getting to the desired result.

Now of course you can create additional coding or use other variables to make this work, but my goal is for the pilot to be able to adjust his/her trim using the default trim assignments, and not have to so do some some special rigging in order to make the trim function work. The goal is for it to be seamless to the user.

If you still are unclear in what I am trying to convey to you, I'd suggest you try it out and make a code in FSX dealing with trim and it will be very apparent what I am talking about.

Thanks again.
 
Okay, here is what i meant...


#1 - algorithm calculates gauge display correction

(A:MACH, TAS, or whatever) ---> algorithm ---> display correction %
Click to expand...

#2 - algorithm sends correction to gauge variable.

<string> (A:FS TRIM) * (L:display correction)
Click to expand...

Trim is changed as normal but pilot viewed display is corrected by algorithm.

In the example you gave previously the algorithm would send out 0.5, so at +20 FS trim the display sees +10 using the FS variable * 0.5. The pilot would believe his trim is set to +10.


#3 - dynamic adjustment without loop

Now if I understood you correctly, as the dynamic situation changes, you want the algorithm to also adjust the FS trim position on it's own.

To do that without a loop, you 1st need to trap the trim setting at last user input:

<Keys>
<On Event="ELEV_TRIM_UP">
(A:FS TRIM) (>L:LOCKED LAST TRIM SET)
</On>
<On Event="ELEV_TRIM_DN">
(A:FS TRIM) (>L:LOCKED LAST TRIM SET)
</On>
</Keys>
Click to expand...


This sets (L:LOCKED LAST TRIM....) to whatever the pilot last set as trim through normal FS controls. You need to be sure to trap all possible key events the user may be able to use.


Now the algorithm has a constant to compare against. =)


(A:FS TRIM) (L:LOCKED LAST TRIM....) (L:trim correction) + != if{ (L:LOCKED LAST TRIM....) (L:trim correction) + (>K:ELEVATOR TRIM SET) }

Or in english,

If A:FS TRIM is not equal to Last locked trim + trim correction, then set it to be.
Click to expand...

Trim will constantly update, but only when trim correction changes. The next time the pilot manually adjusts trim, the process starts over from the new values.


Now I have not thought through the start up sequence, but if you program your correction value to cover all conditions, it should simply update the display after one stable cycle.



=====



Here's another way, if the increase in trim is a trim moment tied to Mach...

Open up the airfile and find sections 1101 and 420. Go to 420, write down the values, then set all to zero. Under 1101 go to the pitch section and find Cm_de. Add whatever value was at Mach 0.2 in 420 to whatever value is currently in 1101 Cm_de.

Open flight sim, and perform maneuvers at Mach 0.40, note the trim error... assumed to be too little.

goto 420 and add +10 to mach 0.2 thru 0.6 (horizontal at 0.40) . Perform maneuvers in FS at M0.40 again and note the new trim error. Find the difference between the 2 error readings, and divide by ten (error value). Subtract what trim was from what trim should have been, then multiply that by the error value.

This is the setting of x for table 420, at y= M0.40. Repeat the process for each +0.20 Mach up to max Mach.


=====

Or,

If the trim is a trim moment that can be tied to q...

open the airfile and find section 1525


q = 1481.4 M^2 delta

That is Mach square * 1481.4 * pressure ratio

So for sea level Mach 0.5 = 0.5^2 * 1481.4 * 1.0 = 370.35
Click to expand...

Anyway,

You can figure out q for any Mach and pressure ratio, then increase the trim moment accordingly in 1525. x=2.0 is doubling the moment while 0.50 is halving.
 
Jimi,

The complex part in what you intend to do is to figure out a good PID to link FSX trim with a variable of your taste. Rest is very simple.

Let's say you want to tie trim to G, then you'll need to build a PID where you input G value and output TRIM_SET events to keep the desired A:var value constant.

For example:

(L:G Value, unit) --> PID controller --> ELEVATOR_TRIM_SET --> (A:G variable)

This is done in the <Update> section of a gauge of your choice.

Now, the pilot has a G indicator gauge where he dials the desired G, OR he uses the standard trim buttons on the joystick to accomplish the same.

Then:

- Using a control in the gauge, <Click> --> Update (L:G Value, unit)

-Using joystick buttons: Capture the related events, discard the new trim values and update (L:G Value, unit).

In this case you'll need to capure both ...TRIM_DEC and ...TRIM_INC:

Code: 
<On Event="...TRIM_INC">
  (A:Current Trim Position,percent, etc) --> Convert to a 16383 factor --> >K:ELEVATOR_TRIM_SET  (do NOT use _AXIS_ version)
  Update (L:G Value, unit) as if it would have been updated trough a mouse click on the gauge
</On>

The same for ...TRIM_DEC, And that's it.

Bear in mind though, in FSX if you want the pilot to be able to update trim when in Spot or any external view, you must code the event controller in C++ because XML events are not captured when in these view modes.

Tom
 
taguilo said:
Bear in mind though, in FSX if you want the pilot to be able to update trim when in Spot or any external view, you must code the event controller in C++ because XML events are not captured when in these view modes.

Tom
Click to expand...

If you put the XML gauge in the virtual cockpit section of the panel cfg in FSX, it should always be loaded.
 
You must log in or register to reply here.
Back
Top