Desired depth and heading commands in a manual mode (e.g. depth hold mode)

Blue Robotics Software
1

Hi - Is there anyway to send desired depth and heading commands while the ROV is in a manual mode such as DEPTH HOLD mode or STABILIZE mode via MAVProxy?

I am integrating a BlueROV2 with a larger ASV, and I would like to send depth and heading commands to the ROV from the ASV. I can do this in the GUIDED mode via mavlink_msg_set_position_target_local_ned message or mavlink_msg_command_long (MAV_CMD_CONDITION_YAW) message. But as soon as I put the ROV to the GUIDED mode (with a faked underwater GPS input) it does some weird movements and we can’t afford that when the ROV is attached to another robot. So I am wondering if we can send depth and heading set points when the ROV is in the DEPTH HOLD mode? Or do you have any other suggestions?

2

For depth hold, you can use set_attitude_target to select the desired attitude of the vehicle, for the depth, you’ll need to use rc_channels_override_send with thrust set points until you hit the desired position.

This is probably because your GPS information is not a real system that can give position error information to the ROV, without a real position information (or something close to it), the vehicle will do weird things.

5

Hi @patrickelectric -
Thanks a lot for your response. I’m currently creating a MOOS interface app for BlueROV2.
A couple of questions:

For depth hold, you can use set_attitude_target_no_gps to select the desired attitude of the vehicle

  1. How do you send set_attitude_target_no_gps commands? I can use below piece of code to send mavlink_msg_set_attitude_target messages, but it seems this only works for GUIDED MODE. How do you send set_attitude_target_no_gps commands?

     if(key == "ROV_DESIRED_HEADING") {
       m_rov_desired_heading_deg = dval;
       // Euler angles to Quaternion
       double cy = cos(m_rov_desired_heading_deg*M_PI/180* 0.5);
       double sy = sin(m_rov_desired_heading_deg*M_PI/180 * 0.5);
       double cp = cos(m_rov_desired_pitch_deg*M_PI/180 * 0.5);
       double sp = sin(m_rov_desired_pitch_deg*M_PI/180 * 0.5);
       double cr = cos(m_rov_desired_roll_deg*M_PI/180 * 0.5);
       double sr = sin(m_rov_desired_roll_deg*M_PI/180 * 0.5);
       double q_w = cy * cp * cr + sy * sp * sr;
       double q_x = cy * cp * sr - sy * sp * cr;
       double q_y = sy * cp * sr + cy * sp * cr;
       double q_z = sy * cp * cr - cy * sp * sr;
       float q[4];
       q[0] = q_w;
       q[1] = q_x;
       q[2] = q_y;
       q[3] = q_z;
       time_boot_ms = (uint32_t) (get_time_usec()/1000);
       uint16_t length2 = mavlink_msg_set_attitude_target_pack(system_id, component_id, &m_mavlink_msg,
                                                               time_boot_ms, target_system, target_component, SET_ATTITUDE_NO_RATE, q, 0, 0, 0, 0);
       m_udp_client->send(&m_mavlink_msg);
   }

for the depth, you’ll need to use rc_channels_override_send with thrust set points until you hit the desired position.

  1. It seems like I need to control individual thrusters if I use mavlink_msg_rc_channels_override. Can’t I use mavlink_msg_manual_control messages in DEPTH HOLD mode for this purpose? That way I just have to give a thrust in the z direction until it reaches the desired depth. See the below code:
if(key == "ROV_THRUST_Z") {
          double m_rov_thrust_z = dval;
          uint16_t length2 = mavlink_msg_manual_control_pack(system_id,1,&m_mavlink_msg,target_system,0,0,m_rov_thrust_z,0,1);
          m_udp_client->send(&m_mavlink_msg);
      }

Thanks,
Supun.

6

set_attitude_target_no_gps Is only possible in ALT HOLD mode.
Your codes appears to be fine, the only problem is the mode that you are using.
Take a look in the patch that add such feature here, it’ll probably help.

Yes, you can, both messages are valid.

7

Thanks @patrickelectric. I tried mavlink_msg_set_attitude_target message according to my above code in ALT HOLD mode, but the ROV did not respond.

My BlueROV-MOOS interface apps run in the ASV’s computer and ideal would be just sending desired depth and heading commands to the ROV. I can run a simple feedback controller in the topside (ASV) computer but sometimes data through the mavlink_msg_vfr_hud message has a large delay (>3 seconds). Is this usual?

8

Hello,

The SET_ATTITUDE_TARGET message is currently not supported in ArduSub Stable, only in Beta.

VFR_HUD is the message used by QGC to show the ROV heading, this delay seems unusual.

9

Hi @supun I wanted to use that mav_set_attitude_no_gps but can’t find the actual message anywhere. Would you be willing to provide it or direct me to where you found it? Thank you!

10

Hi @Coco,

Try this gist.

1 Like
11

Thanks @williangalvani

Whenever I use the mav_set_attitude message though it appears to define the attitude of the flight controller itself because the compass and horizion line I can see in QGC go totally crazy- like its overriding the internal compass data. Any idea why I am getting this instead of the desired result?

12

That is odd,
What version of Ardusub are you running?

1 Like
13

@williangalvani 3.5.4

14

IIRC that was done properly after 3.5.4, try 4.0.1

15

Thanks @williangalvani

I have a couple mods that I made to ALT_HOLD mode in 3.5 that for now I’d like to avoid moving the 4.0 (they aren’t what is causing it to freak out- it does the same thing in the stock version of 3.5). If I am trying to stick with 3.5 for now it sounds like I could use the msg_manual_control? For parameters like pitch that would effect the depth can I give null values somehow or does it not matter because ALT_HOLD will override those?

16

try cherry-picking this, then:

17

Hi @williangalvani

Just for kicks I tried sending the set_attitude_msg from an arduino on the latest version of Sub and still had the error where the horizon line and compass in QGC change every time the message is sent. Thoughts?

Is there any chance that the routing in my message is incorrect and that’s causing it to think that the message is coming from the IMU or something not a companion arduino?

18

Does the rov respond at all? It does sound sound like you are are sending an ATTITUDE message to the GCS instead of a SET_ATTITUDE_TARGET message to the ROV

19

Hi,

Just a kind reminder that you’ll need to send set_attitude_target periodically in a shorter time interval than 5 seconds, otherwise the controller will use the joystick inputs again and forget about the attitude target message.

1 Like
21

@williangalvani @patrickelectric do either of you know if I could use the mavlink_msg_set_roll_pitch_yaw_thrust message to set a yaw target? If so can I just use 0 as a null value for the other values I don’t care to control?

I know set_attitude_target is what is recommended but it isn’t in the message list for the arduino library and manual control won’t stay on a target heading it only reacts to direct input.

22

Hi @Coco,

That message doesn’t seem to be supported by Ardupilot at all.

Being in the “common” dialect, set_attitude_target should be available for you with arduino. Any thoughts @patrickelectric?

23

Hi @Coco,

Sorry if you are having problems with it, but is a bit weird, can you explain a minimal example and the error message ?
You can try my arduino minimal example here: GitHub - patrickelectric/minimal-arduino-mavlink-example: A simple and minimal MAVLink arduino example

Remember to start and update the git submodule after cloning it.