Reverse ROV controls in QGC?

I am wondering if there is a simple way to reverse the joystick controls so that the ROV can driven backward. For example, I usually drive the ROV in the normal forward direction, but I also have tools attached to the rear of the ROV. I want to be able to temporarily switch the controls to operate in reverse so I can use the rear mounted tools. Is there anything in QGC that can do that? Can it be added easily? Or do I need to use a custom controller and add a switch that physically re-routs the joystick signals to be reversed?

Hi @nperry,

It’s not a feature that’s currently built in, so the simplicity of the implementation depends largely on how well integrated you want the result to be.

In an ideal case (from a “responsibility” standpoint) it would probably be built in to ArduSub itself (perhaps as a button functionality, or via a parameter), but as you’ve realised if the aim is just for manual control then it may be possible to handle from the topside by remapping joystick inputs, which could be done either within QGC, or via a secondary program that monitors the joystick inputs and sends MAVLink messages to the vehicle to reverse its horizontal motors, for example.

I’m unsure what your background is, so I’m not sure of the respective difficulties of those approaches. Personally I’m quite well versed with Python, and don’t relish the thought of modifying QGC or both ArduSub and QGC to get that feature working, so my own instinct would be to use Pymavlink and a library like Pyglet to do the “handle things in the background via a separate application that monitors the joystick” approach. That said, if this is intended to be used by multiple people / needs better integration than “remember to run this Python program whenever you’re doing a dive and want to be able to reverse with forwards controls” then it’s likely worth going for one of the more involved approaches, even though that’s likely more work to working.

There’s also the question of importance and how soon you want it to work. If it’s not time critical then you could raise a GitHub issue to add support for it in ArduSub, which we may end up implementing at some point if it seems like there’s demand for it. If you think it’s a feature that others would likely be interested in having then you could raise an issue regardless of whether you end up pursuing a less integrated approach in the interim.

Happy to brainstorm a bit more on any of those approaches, or try to answer any follow-up questions you might have :slight_smile: