Hi everyone, my name is Martina and I’m new to QGroundControl.
I am currently working with a BlueRov2 and am trying to replicate its mathematical model in Matlab Simulink along with its attitude and position control.
I was wondering if you could somehow get the PID GAINS used on the ROV for this type of control from QGC.
When on QGC I go between the vehicle settings, among the parameters I cannot read the parameters of the type MC_ROLL_P, …
(https://docs.px4.io/main/en/advanced_config/parameter_reference.html).
I read this page (https://docs.px4.io/main/en/advanced_config/parameters.html) but it didn’t help me much.
In the Tuning section of QGC I only get PID axes angles and PID axes rate for roll, pitch and yaw but I don’t think these are the parameters I need.
Can anyone tell me how I can get these parameters? Maybe even through a python script using the MAVLink protocol to communicate with Ardusub while the BlueRov2 is active and connected on QGC?
Hi @_martinareds, welcome to the forum 
That’s PX4 documentation, but the BlueROV2 runs ArduSub firmware (not PX4 firmware), so the specific parameters you’re trying to read don’t exist in the vehicle.
The How to Use the Blue Robotics Forums post includes a link to the ArduCopter attitude controller docs, which should be similar if not identical to how ArduSub is controlled (because the functionality is in an abstracted library that both firmwares use). Attitude control uses the ATC Parameters. On the general ardupilot docs site you will also find the position control docs, which tells you that the PSC parameters are what you’re after.
They can be found in QGC’s Tuning page by clicking the “Attitude Controller Parameters” and “Position Controller Parameters” buttons at the top, or on the Parameters page by searching for ATC_ and PSC_.
If you happen to want to do this, you could read all parameters and print/save the ones that have a param_id (name) starting with ATC_ or PSC_. It’s easier if QGC is not open at the same time, otherwise you’ll need to create an additional MAVLink endpoint in the vehicle to connect to via Pymavlink.
Hi @EliotBR, thanks for replying to my topic.
I had already read the guides for attitude control and position control, but I had some doubts about it.
Basically, from the guides I deduce that I will have a sequence [*] of this type:
POSITION CONTROLLER → target roll and pitch → ATTITUDE CONTROLLER → output that will go to the motors → MOTORS → information exploited by the mathematical model → MATHEMATICAL MODEL OF BLUEROV2 → speed, angular velocities, forces and moments
However, I know that in the MAVLink protocol there are set_target_depth() and set_target_attitude() functions, in which I can respectively define the desired depth and roll, pitch, yaw.
So I wonder what happens in the ArduSub firmware if I go to use these functions, since if I use set_target_attitude () the desired roll and pitch angles are not automatically calculated by the position controller, but are defined by me. While if I use set_target_depth () it goes to follow the sequence of before [*] even if the desired x and y have not been defined?
Basically, if I use these two functions will it still follow the sequence [*] I showed earlier? Or when these functions are used, the two controls are detached from each other and individual PIDs are used for each variable x, y, z, roll, pitch and yaw?
Then I would like to understand if the PID values used by BlueRov2 when using these functions are the same ones reported in the Tuning section of QGC.
I hope you understand what I mean and that you can answer me
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.
Hi @EliotBR , sorry for the late reply but I had paused my work for a few days.
As I told you, I made a code that allows my BlueROV2 to move autonomously from a starting point to a desired point. Currently, however, I cannot verify if it actually works in water and for this reason I am trying to understand how to implement the control used by the ROV on MATLAB SIMULINK to simulate the results. Thank you for the information you’ve given me.
I’m pretty sure all the control parameters I need to use are the ones found in QGC in the Tuning section. Now I just have to understand if the x and y control actually affects the roll and pitch control and if the z control affects the yaw control, to understand how to do the simulation scheme.