@TCIII @pazrul @bokum,
I’m currently the primary engineer/developer in charge of the embedded software, ESCs, controls, etc. I joined OpenROV just over a year ago, and have mostly focused on Trident development (cameras, new microcontroller, Raspberry Pi, etc), though I have done quite a bit of refactoring on the firmware side of things. When I reworked a lot of the firmware, I made the decision to let the controls side of things for the 2.X series sit on the backburner, mainly because I knew that I would eventually be developing a new system for the Trident. Part of the work I’m doing now is the development of a new set of control schemes which are mainly applicable to Trident, but will also likely serve as a significant upgrade to the 2.X series as well (or at least those equipped with the IMU+Depth sensor).
The primary mode of control that we are imagining the Trident to be piloted with is two controllers working together which can interchangeably be absolute position or rate controllers. For example, The depth controller can be set in absolute position mode, while the yaw controller can be set in rate mode, allowing the user to maintain a constant depth without needing to touch the controls, while the yaw/throttle axes of the joystick can be used to manoeuvre in a 2D plane. When you let go of the joystick, you will be essentially commanding a 0 deg/s yaw rate, which will drive the control system to bring you to a stop. You could also put the yaw controller in absolute mode, and it will maintain a fixed heading (to the best of the sensor’s abilities to estimate the heading). In absolute mode, you have the option to lock the control such that yaw inputs on the gamepad don’t affect it any more, or allow the setpoint to be modified by the controller in a sort of “carrot on a stick” control scheme. In general, we expect that most people will prefer to control the depth with a modifiable setpoint, in the same way that depth lock works on the 2.X series, while the yaw mode will vary depending on the user’s preferences and the situation.
This development is important for the 2.X as well, because it currently does not have a rate controller, and the vertical and horizontal control planes are currently entirely decoupled, so short of using the existing heading and depth lock controls, you can’t achieve isolated vertical control. Arguably, because of the uncertainty in the sensors we have, the arrangement of the thrusters, the unknown underwater dynamics, propeller dynamics, and more, you can never achieve perfect control along any given control surface with the 2.X series (or any vehicle), but with a proper control allocation step, we can improve the situation.
The new control software that I will be working on will feature the following to hopefully achieve a flexible and more complete set of control mechanisms:
- A thruster abstraction which contains information about the thruster’s capabilities, physical properties, and orientation
- An Allocator stage which relates and mixes input signals pertaining to principle axes of control (yaw, pitch, x, z) to thruster signals for a given thruster arrangement (similar to our current concept of the CThrusters2x1 class in the arduino firmware)
- A rate controller (PID or something else) which maps input signals (from a gamepad or another control system) to desired velocities along principle axes
- A position controller which maps input signals to desired absolute positions (mainly only achievable for yaw and depth with a three thruster setup).
An allocation stage which includes a model of the vertical thruster’s effect on the yaw axis combined with a rate controller allowing only user requested yaw inputs, should be the answer to eliminate the twist while not having to put the vehicle in heading hold, as addressed in this thread. Once the Trident implementations are mature and tested, I will definitely be looking into bringing the 2.X series in line. That said, we certainly encourage anyone to feel free to write a new CThruster configuration or CAutopilot implementation in the current firmware and give a shot at tackling the problem.
We are also completely open to discussing new control schemes and methods going forward, so feel free to voice any ideas you might like to see explored. Having so few sensors inputs, so many unknowns, and strange, unmodeled dynamics, precise control of the 2.X is a tricky subject which will probably require some clever thinking to tackle beyond what I’ve got planned.