As Cockpit recognises LT & RT axis on the X-box controller. Is there a way to use these as axis for controllable tilt/pitch, as opposed to using them as a tilt/pitch set point?
Hi @3dMB,
Thatâs not currently feasible, but should be once this change has been implemented.
Thereâs an underlying requirement for that which is in our current quarter goals, but the full feature may not get implemented until later in the year.
That said, once that requirement is implemented it should technically be possible to set up through a workaround, if youâre willing to not use the built-in MANUAL_CONTROL pipeline, and instead implement joystick outputs entirely through data-lake variables and one or more custom Actions.
you lost me on the third paragraphâŚ.ill take it as a ânot yetâ 
I have seen similar themed posts, however they do not completely fit the bill.
I use Mode2 layout on the Xbox controller, and would like to modify the controls slightly.
I wish to:
Change Ascend/descend from left stick, to LT/RT axis
Change left stick forward/back (currently ascend/descend) to pitch up/down.
The above will allow me to have pitch and yaw on left stick, and ascend/descend not have the potential of accidental yaw.
This is with Cockpit, so the LT/RT will work (unlike QGC).
I am aware of the Trim Pitch control parameter, is there a different control parameter that could be used on the stick axis?
Hi @3dMB,
Thereâs actually a small factor thatâs blocking this from working at the moment - I recently implemented a fix for it, but it needs to be reviewed before it can be included in a release. Iâve just marked that for fast-tracking, since there have been multiple requests for this kind of thing lately.
Youâre welcome to test the pull request by downloading a relevant artifact (requires being logged in to GitHub), but otherwise Iâm hopeful it will be available in a beta release some time this week or next 
Axis T controls pitch. Iâm also working on making that clearer, but it requires some infrastructure improvements that need to be well considered so we can maintain them effectively - apologies for the ambiguity/confusion in the meantime.
Thanks @EliotBR
Was there any progress on this in a beta release, please @EliotBR ?
It will be one of the first changes included in a 1.19 beta, which should be released just after the 1.18.0 stable (expected in the coming weeks). Sorry for the delay on my initial expectation!
If youâd like to test it sooner youâre welcome to do so via the Artifacts
Hi @EliotBR - now 1.18.x is released, is the beta for this still on the cards?
Still on the cards, but Iâm on break at the moment.
IIRC the feature is partially held up from a desire to avoid requiring a migration later for some more advanced functionality that I was hoping to roll in with it (frontend all-vehicle gain and reversing), but if those seem low priority to you we can potentially merge and release just the base axis transfer and then do the extra migration work after I get back. Do you have a preference?
Enjoy your holiday @EliotBR - lets pick this up when you are back 
@EliotBR I appreciate that you finished with a question, to which I didnât respond to. Has the development of this progressed at all?
We ended up merging in the axis data-lake transition (available in recent 1.19 betas), so (per the pull request description):
You could do similarly for pitch (Axis T) or another axis, but they use the -1000 to +1000 range, so the compound variable definition would be 1000 * ({{ inputs/mavlink/axis-t-plus }} - {{ inputs/mavlink/axis-t-minus }}) instead.
The gain/reverse functionality is waiting on the ability to (easily) trigger notifications to share the new state, so we decided to push ahead without it, and will implement it with a relevant migration step later
@EliotBR I am looking at the Datalake variables trying to translate your previous description into laymanâs terms.
My datalake shows âAxis Z outputâ and âAxis Zâ. I do not have the âAxis Z+â or âAxis Z-â as said in the first part of the description. Do I need to âadd variableâ for each of these, then paste the bracketed âinputsâŚâ into the actions/expression? Then paste the â500 * ({{ inputsâŚâ into the âAxis Z Outputâ actions/expression?
For the âAxis Tâ, I have similar:
For this would I then just paste the â1000 * ({{ inputsâŚâ into âAxis T Outputâ actions/expression?
Exactly. The inputs/⌠I included as example IDs that will help them match the existing datalake variables with related functionality, but you can adjust both the names and IDs of variables you create as you see fit (e.g. you may wish to call the Axis Z +/- variables âUpâ and âDownâ instead).
Yep! Replace the existing definition with the new split-axis one, so your controller isnât trying to use both the triggers and a joystick at the same time for controlling a single axis.
Indeed - youâll need to create new variables and change the output definition for any axis you want split.
RightâŚI think I have it. According to my thruster directions, Axis T is Roll, not Pitch. Axis S shows as pitch.
IF I set the following (but with 'axis-s-plus, etc), AND use -1000 to 1000 on the joystick variables, the thrusters go mad.
IF I remove the â1000*â from the above text and set the joystick to -75 to 75, it seems to be much more realistic.
I will do a wet test over the next couple pf days.
Iâve just checked in the code and that is in fact correct. It seems I got the pitch/roll ordering the wrong way around in my axis naming Issue in Cockpit, and Iâve presumably carried that mistake around since then when referring back to it - sorry!!
If youâre trying to split Axis S then the Axis S Output compound variable definition shouldnât be referring to the original inputs/mavlink/axis-s variable anymore - it should only be using the new -plus and -minus ones (in which case the âAxis Sâ variable you may have assigned to a joystick input will no longer have any effect, including its range).
When you say âsplit Axis Sâ, do you mean psplitting pos & neg on different control buttons, as with the Z-axis, or is âsplitâ uses in a different way? I seem to have found a way that works on the bench, Ill double check exactly what I have done tomorrow and report back.
Yes, if thatâs what youâre trying to do.
Following up on this, Iâve just found that the s and t inputs arenât being scaled properly in the firmware, and arenât respecting the pilot gain, so for now it makes sense that youâll want a smaller multiplier there 
400 instead of 1000 would be equivalent to 100% gain (with any higher scales saturating partway through the range of the input), and 75 would just be equivalent to a lower gain.
ok - as that is what I had assumed, and as the thumbsticks are not split, I had assumed that the split was not necessary, but that lead to the Datalake registering the stick movement, but that did not do anything to the thrusters (thatâs the reason for the deleted posts). IIRC I did do a split, but bound the stick to only Axis S - variable, but will confirm tomorrow