Hi there,
I am wondering if there possibility to change mode Roll/Pitch control so I can choose NOT between ascend/descend and Forw/Backw/Lateral OR acend/descend and Roll/Pitch but I want to use Forw/Backw/Lateral with Roll/Pitch control mode which give me more option to move around water.
OR let’s say to which way I should dig in to setup custom made joystick which has more stick inputs comparing with regular logitech/gaming joystick.
Thank you
Hi @nurjan14,
To respond directly:
No, that’s not currently possible with ArduSub. It does seem useful, so I’ve raised an issue for it that can be tracked for any progress. You’re of course welcome to submit a pull request to add the functionality if you implement it yourself 
Additional control axes are also not currently supported in ArduSub and also not in QGroundControl, although that is something we’re planning to support in future.
This thread may be worth a read for understanding more about complex surface-controller setups
Hi Jacob,
Is there scope/planning for this to eventually turn into mixed throttle control as well? As I understand it the ‘roll_pitch_toggle’ input will only switch roll and pitch, but not change throttle from being ‘up and down’ to ‘forward and back’ as in a conventional aircraft?
Since the BlueROV is so much more streamlined going forward than up and down, I could see a lot of benefit to easily being able to switch between the two modes to traverse greater distances up and down without using as much current.
Hi @Vincent,
I’ve moved your comment here because it’s more related to this topic than the one you posted it in
As above, I raised an issue a couple of months ago which (if I’m understanding your comment correctly) is about the behaviour you’re asking about, so it’s trackable, but as far as I’m aware there’s nobody working on that at the moment, and no particular expected date when it will be implemented.
Hi @EliotBR
I am also interested in getting the pitch and roll working separately to the other inputs, hopefully utilizing the Left and Right Slider inputs from different joysticks if possible. 
@nurjan14 / @Vincent, I’ve made a poll about how best to proceed, because if enough people agree that the new behaviour would be better than the existing one then we can change it. If we have to develop the new behaviour as a separate option it will take longer.
If I’m understanding correctly you’re wanting support for additional control axes, to which I’ll direct you to the following:
If you’re specifically talking about trying to use the triggers on an xbox controller, this comment is relevant.
If I haven’t properly addressed your idea then please clarify what you’re after - we’ll likely be doing some more advanced work with joystick support later this year or early next year, and it’s good to know what features people are interested in
Quick question to clarify my understanding of this as I was looking to do something with a controller which looks like it may not be possible currently:
If I were to have a controller that had additional analogue inputs that it could read to allow me to separately the lateral (left/right), forwards/backwards, ascend/descend, pitch, roll and yaw to avoid using the roll_pitch_toggle mode, this would not currently be possible due to limitations in ardusub?
Correct. As above:
As some extra context:
MANUAL_CONTROL MAVLink message to send joystick axes and buttons to the vehicle
RC_CHANNELS_OVERRIDE inputsRC_CHANNELS_OVERRIDE messages directly you can already control all 6 axes at once (so it’s only kind of a limitation of ArduSub)
MANUAL_CONTROL messages as well but with the motion parts ignored (which still requires a change in ArduSub, albeit a slightly simpler change than implementing additional axes)
@EliotBR Reviving this old topic to see if there has been any progress to this issue now that wea re in the BlueOS ecosystem?
Hi @StrikeLines,
In Cockpit you can arbitrarily assign the joystick axes (instead of just choosing between common RC mode groupings), so this is readily possible.
We’re also working on making the joystick outputs even more configurable, after which it should become possible to dynamically adjust the axis assignments in response to Actions, in which case you could make a frontend-equivalent of ArduSub’s roll+pitch ↔ forward+lateral toggling feature with your axes of choice.
Sorry if this is a stupid question, but is this what the axis values in Cockpit correspond with?
(Edit: corrected my values. Thanks @EliotBR!)
X- Forward/Reverse (W and S keys in a first person shooter)
Y- Slew Left and Right (like A and D keys )
Z- Up/Down
T- Roll (like Ailerons)
S- Pitch down and up (like elevator)
R- Yaw (like rudder pedals)
Also, it’s not clear in Cockpit how I set the values of the joystick axes when the controller is toggled to Roll/Pitch mode.
I see in this image how to change the values of the four standard axes 0-3. These axes all move when I wiggle the sticks on the controller. They seem to be the default position on the roll/pitch toggle.
I am unable to get axis 4-7 to respond to any inputs while on this config page. Do axis 4-7 correspond with the joysticks when the controller is toggled to roll/pitch mode?
My goal is to have the joystick axes switch to these values when roll/pitch toggle is activated:
Left stick up/down = fwd/rev
Left stick left/right = yaw ccw/cw
Right stick up/down = pitch up/down
Right stick left/right = roll left/right
Not quite - Cockpit’s joystick axis assignments are (currently) for the MAVLink Manual Control protocol, and the motion axes that the input axes correspond to are determined by the autopilot. In normal usage you have R and T swapped (i.e. R should be yaw, and T can be used for roll control), but when you use the roll/pitch toggle button function X and Y also become pitch and roll.
One of the downsides of the autopilot having input-modifying functionalities is that it makes the control station software more confusing to use. Cockpit doesn’t know whether ArduSub’s roll/pitch toggle functionality is active - it just sends values to the X and Y axes and the autopilot interprets them however it’s been configured to do so.
Does your controller have 8 joystick axes? If it only has 4 then you’ll only be able to provide inputs to those 4.
As mentioned in my previous comment, dynamic axis assignments (during operation) will become possible in Cockpit, but is not yet an implemented functionality. There is already support for arbitrary axis assignment, so if you want those axis functions to be consistent then you could assign them that way, but the only dynamic/toggling functionality is currently the one built into ArduSub, which only supports switching roll+pitch with forward+lateral.
@EliotBR I suppose some of the confusion is in the terminology. “Arbitrary axis assignment” vs “dynamic axis assignment”. I think I follow you now.
So to correct my earlier post: The actual cockpit axis assignments are:
X- Forward/Reverse
Y- Slew Left and Right
Z- Up/Down
R- Yaw (rudder pedals)
S- Pitch down and up (like elevator)
T- Roll (like Ailerons)
If I want to configure my ROV to fly like an airplane, as described above, by default, then the arbitrary axis settings in cockpit should be:
0 - left stick L/R - yaw - R
1 - left stick U/D - fwd/rev - X
2 - right stick L/R - roll - T (Heavy config)
3 - right stick U/D - pitch - S (Heavy config)
Is this correct?
Next question: Is it possible to bind a custom joystick configuration to a one preset cockpit configuration/user, and the standard joystick configuration to a different preset config/user? Thus allowing you to quickly switch between joystick mappings by changing profiles/user…
Final question: I think the answer is “no,” but… I know that the progressive triggers on the xbox controller can return a range of values depending on how far they are pulled. is it possible to map those triggers to a joystick axis?
Sorry to get in the weeds with questions, but I can’t find any documentation that covers all of the specifics of controller config. Thanks for the help!
Apologies for the confusion - I was meaning that during setup Cockpit allows assigning the axes to whichever joystick you want (compared to the 4 pre-defined mappings in QGroundControl), but it is not yet possible to change those axis during operation using commands or buttons (unless you change their meaning at the receiving end, which is what ArduSub’s roll-pitch-toggle button function does).
In practice this is correct when using ArduSub, but technically speaking Cockpit doesn’t actually assign a meaning to the axes, it just sends values for axes X/Y/Z/R/S/T, and lets the autopilot interpret them however it wants to.
Yeah, that seems consistent 
Yep - joystick mapping sets are stored per user, so to change which mapping is in use you can either switch to a different one, or switch users.
We’re working on improving the joystick setup interface, because there are three available mappings (per joystick type), but the hardcoded naming (“ROV JOYSTICK MAPPING”, “BOAT JOYSTICK MAPPING”, and “MAV JOYSTICK MAPPING”) makes it seem like they only work for particular vehicle types, when in reality you could use them as three different mappings for a single vehicle type if you wanted to.
Switching the current mapping currently just involves opening the joystick page and clicking on a different one. I suppose we could make an Action for switching between joystick mappings, which would also be a fast-track workaround to achieving (limited but functional) dynamic joystick axis assignment, by swapping the entire mapping for one with identical button function assignments but swapped around axes…
Not quite, but it should become possible when the MANUAL_CONTROL inputs are made directly configurable - same as the dynamic axis switching. Alternatively it may become possible once axis values can be used in the data lake, if you’re willing to forego the autopilot’s built in button functions and switch from MANUAL_CONTROL to RC_CHANNELS_OVERRIDE for the motion control.
That said, it is already possible to create a custom data lake variable, assign an analog trigger’s “button function” to control that, and then use its value in a custom Action (e.g. to send a MAVLink message to directly control a servo, or combine it with another value for some more advanced functionality).
No worries - these questions are helpful for us to understand how and where our documentation can be improved, and it’s always cool when people are pushing the limits of what the software is capable of
Thank you for the helpful info. The big picture is becoming more clear.
I think I will bind the two joystick configurations to two of the mappings on the joystick page. (One for sub and one for boat). That is a good workaround for now.
Another question:
Does this limitation still apply? I saw the 4 additional joystick axes in Cockpit. If my controller had an additional stick, could I map it to roll/pitch and simultaneously send 6 control axes to the ROV?
ArduSub supports the extended MANUAL_CONTROL protocol now, so it does handle the S and T axes. Cockpit supports up to 32 axes if I’m remembering correctly, but not all of them can be sent to ArduSub simultaneously (although they may be useful for other purposes, especially once axis values can be accessed through the data lake).
QGroundControl has not yet added support for S/T, but Blue Robotics no longer actively contributes to its development, so I’m not sure when/whether that’s likely to be implemented.
Yep! Although three sticks may be a challenge to manage with two hands, unless you have a HOTAS joystick or similar (where one stick is thumb controlled, and mounted on the side of a larger stick).
Well, this opens up the possibility of remapping the axes dynamically in the controller hardware. Digital RC Aircraft controllers have function switches to swap channels between the sticks during use. They can also scale input gains, response curves, etc.
As long as ardusub can accept all of the raw inputs simultaneously, then everything else can be handled in the controller.
I’m kind of surprised that’s not how you guys are approaching the controller configuration with Cockpit. Seems like you could build an extension that sits between the controller and Ardupilot and translates arbitrary controller inputs to whatever messages Ardupilot expects. Then you could completely customize your controller behavior with a config file.
That is already partly how Cockpit’s controller support works (e.g. the button functions have an indirection layer between Cockpit inputs and what gets sent to ArduSub, which is also designed to avoid breaking configurations made in other control station software), and is also a direction we’re moving further towards (hence the GitHub Issues I’ve been linking you to).
The initial controller support was added to be roughly equivalent to QGroundControl’s (so people can transfer without missing core functionality), and came in before the more versatile Actions and Data Lake systems were in place. Now that they exist we have the infrastructure to support a more dynamic approach, and we’re working to apply that consistently, both for the additional customisation it affords, and the more streamlined codebase and development processes.