There’s been some discussion recently about roll and pitch control, and it seems like the existing toggle option (which allows switching the forward (F) + lateral (L) joystick to be roll (R) + pitch (P) control) is likely less useful than a similar option that allows instead switching out the vertical (V) + yaw (Y) or the vertical and lateral axes.
From a development perspective it’s quite simple to change the existing one, but developing a new separate command would likely take a fair amount of time. If the existing behaviour is not very useful then we’re happy to replace it with a better alternative, but we don’t want to upend any existing use-cases that may be reliant on it, so we’d like to know your preferences for how we should proceed:
The existing F+L / V+Y <=> R+P / V+Y behaviour is useful - new behaviour should be developed as a separate option
F+L / V+Y <=> F+L / R+P should replace the existing toggle
F+L / V+Y <=> F+R / P+Y should replace the existing toggle
Other option (please describe in a comment)
We’re also curious whether the existing toggle control is even being used. In stabilise and depth-hold mode (where we expect most roll and pitch control to be occurring anyway) it’s also possible to use the trim buttons, which allow increasing or decreasing the controlled (maintained) roll or pitch angle just by button presses:
For my purposes, I’m building a custom controller using x2 3 axis joysticks. I would love to be able to simultaneously control vert/pitch/roll and forward/lateral/yaw or other combination utilizing any other axis (L+R Sliders) available by whatever joystick or Xinput device. (This is a bit selfish )
otherwise I could work with
F+L / V+Y <=> F+L / R+P should replace the existing toggle!
Great that this is being discussed. My issue with the current setup is that while it’s great for orientation, it’s not great for piloting (e.g. traditional flight controls, pitch + roll / forward + yaw as per aircraft).
My use case here would be following divers or marine animals, where keeping the ROV moving forward but changing pitch/roll/yaw as the animal/diver moves. This is much more efficient (especially if the ROV has thrusters pointing forward as the new frame allows) and allows for higher speeds as well. Many other ROV manufacturers allow this sort of control, especially for ROVs without 6 degrees of movement.
Currently my only use for this function is to allow rapid dive/ascent (find it’s much faster then having the frame level to the horizon due to the larger surface area), and occasionally wanting to look at things directly below the ROV.
Having an option to have these controls rather than the roll and pitch toggle (most controllers are running out of buttons for the ROV at this stage) would be really useful in a fair few scenarios, though realistically I wouldn’t want both controls at once. Maybe a ‘shift’ button option for the roll and pitch toggle? Or a menu option in Qgroundcontrol (though I prefer everything available on the controller).
Fair enough @john6 - we hear you. We’re definitely planning to have much more arbitrary controls assignment available in future - this poll and discussion are more about an interim ‘quick change’ that may improve things a bit in the meantime (within the existing application and firmware structures), since larger structural changes take longer to develop.
@Vincent just to clarify, are you saying you would prefer something like F+L / V+Y <=> R+P / F+Y (like the third poll option but with different grouping)?
The button functions can be freely (re)assigned, so if you prefer to have the roll/pitch toggle as a shifted function rather than a primary one then you’re already able to do that from the Buttons tab of QGC’s Joystick page, and you can assign something else to the current button position
I use the ROV for inspections underneath vessels so I need to be able to pitch up to inspect the hull, or pitch down to search the seabed for the equipment someone just dropped and still maintain depth while translating. True 6DOF would be appreciated.
What if we were able to switch the camera gymbal over to pitch control?
I would think pressing A while operating the right stick would be kinda awkward, no? (edited after Eliot pointed out I was confused :))
At the moment that’s likely easiest to achieve with the pitch trim buttons while in depth hold, but it may also be possible by setting pitch with the joystick and then using input hold before toggling back out of roll/pitch mode.
It may be a bit easier to control with one of the two proposed roll/pitch toggle alternatives, because they would allow moving forwards while actively controlling pitch and roll, and depth hold can maintain the depth.
Agreed that both would potentially be useful. As above,
Not sure what you mean here - the left stick is on the opposite side to the A button, so they’re controlled with separate hands.
I choose “other option” but also have little experience diving. Anyway here is my 2cents.
For a start I would prefer F + Y and V + L.
It’s interesting to go forward and turning rigth or left by moving the joystick at say 40° or 320° (depth hold mode). At the moment this is achieve with 2 joysticks manipulations and using yaw tend to impact the depth.
To me, vertical and lateral are similar in terms of movement. They should only move the sub in one axe. At the moment, any movement on the V axis, make my sub starting to yaw a bit since they are on the same stick. If I only want to go down and inspect something in front of me while diving, I have to compensate for this unwanted yaw. I usually have to slow the dive to adjust back the yaw and return to dive.
I wish I could attribute the ascend and descend to buttons just like the gimbal of the camera! This way it would be possible to dive 100% vertically at constant speed.
In the shift configuration, I would attribute the P and R to the rigth stick controller and leave the forward/backward and Yaw available. Even more so if in the futur, ascend and descend is attributed to buttons.
Given how inconclusive this poll is, and the statistical insignificance of the relatively small number of responses so far, this isn’t something we’ve put additional thoughts or effort into in terms of ArduSub development.
In principle the joystick axis order is not really something the autopilot firmware should need to be concerned with, so this option is only really a stop-gap for insufficiencies in the topside control software (e.g. QGroundControl).
We’re currently working on some control software improvements that should allow more freely specifying and modifying the control axis ordering, in which case each user could set up their own preferred axis order profiles, and configure a joystick button to switch between them. It should also be possible for all motion axes to be controlled simultaneously, with appropriate input hardware, which requires some improvements to both the autopilot and the topside control software.
I just upgraded our BlueRov2 with the heavy kit and unfortunately discovered that the controls for roll and pitch has an inconvenient layout and I was hoping to find a solution to this, which is described in this post. That is, I wish for the ROV to be controlled with the layout F+L / R+P (or potentially F+Y / R+P, as long as Roll and Pitch is on one joystick (preferably right) and forward is on a separate one).
I believe this is the most natural control setup as it is similar to normal flight controls as Vincent mentioned in an earlier post. While it is true that this setup is based off of vehicles that typically needs to move forward constantly in order to stay airborne, which is not a limitation an ROV needs to adhere to, I still believe this is a good setup in order to effectively pilot the ROV.
A suggestion would be that instead of having a set of predefined joystick layouts you could instead let the users define what movement should be associated with which joystick output. That is, let the possible joystick settings be:
An extra suggestion. If the individual mapping of joysticks were to be implemented, one could also take the opportunity of adding the Left and Right, trigger and bumper buttons as well (or any other button for that matter). This would allow for all possible movements to be added to a button without relying on toggling or shifting