Individual thruster control is required for vehicle control (understandably), but that isn’t necessarily the level you want to work at. ArduSub (and more generally the whole ArduPilot project) is made for doing that, with the intent that it abstracts the control for the user/operator. Instead of commanding individual thrusters users can instead control the motion of the vehicle (i.e. you can send a command for “go to this yaw angle”, and it should work for several different ArduPilot vehicles if they have their frames set up correctly - they could be different vehicle frames, and even different vehicle types, it shouldn’t matter for the user’s control). If positioning information is available to the vehicle the control can be abstracted one level further, with commands like “follow a path and go through this set of waypoints”.
Low level control like this is already implemented in ArduSub, but unfortunately we don’t yet have documentation on the ArduSub-specific implementation that I can point you to. The closest thing is the ArduCopter Attitude Control docs.
Note also that ArduSub vehicles aren’t the same as quadcopters. In your video link it’s discussing pitch and roll requirements for horizontal translation, but in ArduSub that’s instead accomplished with horizontally oriented thrusters that can push the vehicle sideways/forwards without affecting the vehicle rotation in the same way.
I haven’t heard of that interface, so I’m not sure whether it’s well established and just poorly documented, or whether it’s in the process of being developed, or perhaps just an expression of the general idea that control instructions don’t need to come from the flight controller.
ArduSub vehicles use directional control, which can be specified with either MANUAL_CONTROL or RC_CHANNELS_OVERRIDE MAVLink messages. Unfortunately the optional s and t axis fields in MANUAL_CONTROL are very new and not yet available in ArduSub, so to specify commands for all 6 DoF at once requires using RC_CHANNELS_OVERRIDE.
The flight modes are specified here, and the ones that take motion control rather than position controls are described in the “Roll and Pitch Control” section. There are additional descriptions in the ArduCopter docs, along with descriptions of several modes that don’t exist in ArduSub.
I don’t believe there are any modes that directly command vehicle velocity (so you may need to make a velocity controller if consistent velocity is important to you), but manual mode controls rotation rates and translational thrust, stabilise mode controls rotation angles and translational thrust, and depth hold mode is the same as stabilise but controls to a set depth.
Note that accurate velocity control requires an accurate position/velocity sensor, like a DVL or underwater GPS system. The vehicle can report a current velocity estimate, from integrating the IMU accelerometer values, but that value is prone to drift due to error buildup.
These are the RC Input Channels. By default channel 4 is for yaw control, so that comment is specifying that some yaw action is controlled. Values are between 1100 and 1900, where 1500 is stopped, 1900 is full positive, and 1100 is full negative. The effect of the specified value(s) will depend on the flight mode, joystick/pilot input gain, and potentially also the RC3_* parameters if you’ve changed them.
It may be helpful to refer to this gist that I made last year as an example of a full pymavlink program, that hopefully makes understanding the setup and control a bit easier/more intuitive. I unfortunately haven’t yet had a chance to transfer those components to our documentation examples.