ArduSub has different flight modes, and different controls are available depending on the mode and the degrees of control of the vehicle’s frame (e.g. see our vehicles).
- In “manual” mode there is no control system at play - the operator provides input commands about the desired forward, lateral, vertical, roll, pitch, and yaw motion (as thrust commands), which get translated via the vehicle’s frame thrust factors into ESC commands which are sent to the motors
- In “stabilise” mode only the attitude control system is in use, in which case the operator manually controls translations, but rotation angles are maintained once set (by joystick or by
set_target_attitudecommands) - In “depth hold” mode there is attitude stabilisation plus depth-only position control, where the operator can set the depth target by controlling the vehicle to a given depth using a joystick (and then releasing it), or by using
set_target_depthcommands - In “guided” mode (which requires a positioning sensor, which many vehicles do not have) there is full positional control, in which case the operator specifies target positions (via commands to set the speed, position, and orientation targets, or via a pre-planned set of coordinates (waypoints) to travel through (a ‘mission’) which then get converted into those targets)
- Note that ArduSub’s vectored thrusters mean the vehicle can be capable of moving in arbitrary directions, so its position controller can provide direct horizontal motion commands, instead of outputting only pitch and roll angles like a vehicle with only vertical thrusters would require in order to move forwards or sideways
I don’t have much experience with the controller internals, but as I understand it ArduSub does not have a mathematical model of the vehicle, outside of the thruster motion contribution factors specified by the frame - it does not run predictive control, but is rather entirely reliant on feedback from sensor measurements to allow it to correct for errors in its targets, when a controlled flight mode is in use.
One of the major benefits of feedback is not needing to have an explicitly developed mathematical model of the thing being controlled. That comes at the cost of some control optimality, but brings the benefit of significantly simpler control algorithms, and fewer required input parameters.
The thesis you’ve linked to is an alternative approach, and describes a way of controlling a vehicle like the BlueROV2 Heavy using a combined feed-forward (model-based) and feedback (sensor-based) control system that is different to the feedback-only PID system used in ArduSub.
From a practical standpoint, making use of such an algorithm requires potentially quite challenging and resource-intensive vehicle characterisation, which raises the barrier to entry for new and modified vehicle designs. Given our platform is made to be modular and easily modifiable, that’s impractical to set as a requirement unless we can provide quick, cheap, and easy ways of determining the relevant characterisation features for every arbitrary vehicle with arbitrary attachments, which is not an easy problem to solve.
EDIT: having re-read it, this section may have been unrelated to your topic (but is hopefully still interesting, to you or others) - in the case of trying to run a simulation you would need to use a mathematical model in the place of the real vehicle, which is presumably what you were planning to do
In the controlled flight modes the parameters available in QGC’s Tuning page are indeed used. You will note that the position controller has shared parameters for x and y, with separate parameters for z, and the attitude controller has individual parameters for all three rotation angles.