RC Override Control Not Working after change Ardusub Version

[Brandonyxf (Brandon)]

Hello,

I cannot control any thruster through the code from the example from the BlueROV webside.

Here is my code, I have stop the heartbeat check from QgroundControl, and marked some of my adjustment. The code is now the same as the example

# Import mavutil
from pymavlink import mavutil

# Create the connection
master = mavutil.mavlink_connection('udpin:0.0.0.0:14550')
# master = mavutil.mavlink_connection('/dev/ttyS1', baud=115200)
# Wait a heartbeat before sending commands
master.wait_heartbeat()


# Create a function to send RC values
# More information about Joystick channels
# here: https://www.ardusub.com/operators-manual/rc-input-and-output.html#rc-inputs
def set_rc_channel_pwm(channel_id, pwm=1500):
    """ Set RC channel pwm value
    Args:
        channel_id (TYPE): Channel ID
        pwm (int, optional): Channel pwm value 1100-1900
    """
    if channel_id < 1 or channel_id > 18:
        print("Channel does not exist.")
        return

    # Mavlink 2 supports up to 18 channels:
    # https://mavlink.io/en/messages/common.html#RC_CHANNELS_OVERRIDE
    rc_channel_values = [65535 for _ in range(18)]
    rc_channel_values[channel_id - 1] = pwm
    master.mav.rc_channels_override_send(
        master.target_system,  # target_system
        master.target_component,  # target_component
        *rc_channel_values)  # RC channel list, in microseconds.
    print("signal sent")


# master.mav.mount_configure_send(
#     master.target_system,
#     master.target_component,
#     mavutil.mavlink.MAV_MOUNT_MODE_RC_TARGETING,
#     0, 0, 0)

# ############################################################# Arm
# master.mav.command_long_send(
#     master.target_system,
#     master.target_component,
#     mavutil.mavlink.MAV_CMD_COMPONENT_ARM_DISARM,
#     0,
#     1, 0, 0, 0, 0, 0, 0)

# Set some roll
set_rc_channel_pwm(5, 1600)

I can read the message “signal sent” from the terminal. however, the propeller does not move at all. Since I have removed the heartbeat check, it should keep moving.

I have done some tests by revising the code, just hope they will help you to investigate the problem:

1. If I tried set_rc_channel_pwm(9, 1600), the light shows up, which means the light works properly.

2. If I armed the ROV(uncommented the arm code in above code), some propellers (not all of them, I believe they should be 3, 4, 6) will move at a max speed, which caused the ROV drive crazily in the water.

3. I could be able to control the ROV propeller properly before, with the same code above. At that time, my Ardusub was 4.2.0(development version). Now I downgraded it to 4.0.3 (stable version) and had this problem. My Companion is 0.0.26, and I did not change it.

I was wondering if you could deal me with this problem.

I really appreciate your help!

[EliotBR (Eliot)]

Hi @Brandonyxf,

@Brandonyxf

I can read the message “signal sent” from the terminal. however, the propeller does not move at all. Since I have removed the heartbeat check, it should keep moving.

Removing the heartbeat check allows the latest controls to continue running, but you’ll still need to arm the ROV before it will allow any of the thrusters to move in the first place.

@Brandonyxf

1. If I tried set_rc_channel_pwm(9, 1600) , the light shows up, which means the light works properly.

It’s good that a connection is being established correctly, and that the light is working as expected.

@Brandonyxf

2. If I armed the ROV(uncommented the arm code in above code), some propellers (not all of them, I believe they should be 3, 4, 6) will move at a max speed, which caused the ROV drive crazily in the water.

Good that arming/disarming seems to work, although it’s unclear why the thrusters are moving at max speed, or why it would be those ones in particular. Which ROV frame are you using? Your code is only set up to set some roll, so I’d expect it should only try to use the motors with roll components. It may be worth explicitly setting the flight mode to 'MANUAL' in your code, to ensure it’s only doing the controls you’re commanding.

@Brandonyxf

3. I could be able to control the ROV propeller properly before, with the same code above. At that time, my Ardusub was 4.2.0(development version). Now I downgraded it to 4.0.3 (stable version) and had this problem. My Companion is 0.0.26, and I did not change it.

If it weren’t for this post, which you solved by bringing your ArduSub version back down to 4.0.3 from 4.2.0 I’d suggest going back to 4.2.0. Very odd that the thrusters worked in 4.2.0 but the camera mount didn’t, whereas now the camera mount and lights work in 4.0.3 but the thrusters don’t. I’m not particularly sure what to make of that, so I’ve brought it up internally with our software team, and hopefully one of them has more of an idea about what could be going on.

[Brandonyxf (Brandon)]

Hello Eliot,

Thank you for your reply.

Which ROV frame are you using? Your code is only set up to set some roll, so I’d expect it should only try to use the motors with roll components. It may be worth explicitly setting the flight mode to 'MANUAL' in your code to ensure it’s only doing the controls you’re commanding.

I am using the BlueROV2 frame.

The weird thing is that even I did not give any RC channel pwn value, the thrusters will still drive at maximum speed after I armed it. (The last command of the script is to arm it)

I also tried to set the mode to ‘MANUAL’ before, the problem is still there, no difference with the case if I did not set any mode.

If it weren’t for this post, which you solved by bringing your ArduSub version back down to 4.0.3 from 4.2.0 I’d suggest going back to 4.2.0.

I have tried to upgrade the ArduSub back to 4.2.0 (development), but it looks like the ArduSub just crashed, and got stuck in the upgrade web page forever. the screenshot is below:

Now the BlueROV2 has no ArduSub in it, and I cannot install any ArduSub.

Could you please help me with it?

I really appreciate your help.

[EliotBR (Eliot)]

@Brandonyxf

I am using the BlueROV2 frame.

Good to know.

@Brandonyxf

The weird thing is that even I did not give any RC channel pwn value, the thrusters will still drive at maximum speed after I armed it. (The last command of the script is to arm it)

I also tried to set the mode to ‘MANUAL’ before, the problem is still there, no difference with the case if I did not set any mode.

Interesting, and definitely odd. Does it also do that if you arm the ROV from QGroundControl instead of via a script?

@Brandonyxf

Now the BlueROV2 has no ArduSub in it, and I cannot install any ArduSub.

Could you please help me with it?

Generally the best way of sorting out a failed Pixhawk firmware flash over companion is to make a direct USB connection between the Pixhawk and your topside computer and flash through QGC instead.

[Brandonyxf (Brandon)]

Hello Eliot,

Thank you for your reply.

@EliotBR

Generally the best way of sorting out a failed Pixhawk firmware flash over companion is to make a direct USB connection between the Pixhawk and your topside computer and flash through QGC instead.

I have reinstalled the ArduSub 4.0.3 by following your instruction.

@EliotBR

Does it also do that if you arm the ROV from QGroundControl instead of via a script?

There is no problem when I armed it with QGC.

In fact, after I reinstalled the ArduSub, this problem is still there.

After I ran the code,

master.mav.command_long_send(
    master.target_system,
    master.target_component,
    mavutil.mavlink.MAV_CMD_COMPONENT_ARM_DISARM,
    0,
    1, 0, 0, 0, 0, 0, 0)

This problem is still there after I upgrade it to the development version.

In 4.0.3, the motors are 1, 2, 6, in 4.2.0, the motors are 1, 2, 3, 4.

I have already set the mode to ‘MANUAL’, here is my code:

# Import mavutil
from pymavlink import mavutil
import time
# Create the connection
master = mavutil.mavlink_connection('udpin:0.0.0.0:14550')
# master = mavutil.mavlink_connection('/dev/ttyS1', baud=115200)
# Wait a heartbeat before sending commands
master.wait_heartbeat()


# Create a function to send RC values
# More information about Joystick channels
# here: https://www.ardusub.com/operators-manual/rc-input-and-output.html#rc-inputs
def set_rc_channel_pwm(channel_id, pwm=1500):
    """ Set RC channel pwm value
    Args:
        channel_id (TYPE): Channel ID
        pwm (int, optional): Channel pwm value 1100-1900
    """
    if channel_id < 1 or channel_id > 18:
        print("Channel does not exist.")
        return

    # Mavlink 2 supports up to 18 channels:
    # https://mavlink.io/en/messages/common.html#RC_CHANNELS_OVERRIDE
    rc_channel_values = [65535 for _ in range(18)]
    rc_channel_values[channel_id - 1] = pwm
    master.mav.rc_channels_override_send(
        master.target_system,  # target_system
        master.target_component,  # target_component
        *rc_channel_values)  # RC channel list, in microseconds.
    print("signal sent")


# master.mav.mount_configure_send(
#     master.target_system,
#     master.target_component,
#     mavutil.mavlink.MAV_MOUNT_MODE_RC_TARGETING,
#     0, 0, 0)

############################################################# Arm
master.mav.command_long_send(
    master.target_system,
    master.target_component,
    mavutil.mavlink.MAV_CMD_COMPONENT_ARM_DISARM,
    0,
    1, 0, 0, 0, 0, 0, 0)

# Choose a mode
# mode = 'ACRO'
mode = 'MANUAL'

# Check if mode is available
if mode not in master.mode_mapping():
    print('Unknown mode : {}'.format(mode))
    print('Try:', list(master.mode_mapping().keys()))
    exit(1)

# Get mode ID: return value should be 1 for acro mode
mode_id = master.mode_mapping()[mode]
master.mav.set_mode_send(
    master.target_system,
    mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED,
    mode_id)

# Set some roll
set_rc_channel_pwm(5, 1600)

Thank you for your help!

[EliotBR (Eliot)]

@Brandonyxf

This problem is still there after I upgrade it to the development version.

In 4.0.3, the motors are 1, 2, 6, in 4.2.0, the motors are 1, 2, 3, 4.

I’ve just noticed the code snippet you showed uses set_rc_channel_pwm(5, 1600), which is for forwards motion, not roll (as per the RC Inputs), so the code comment there is incorrect, but the 4.2.0 behaviour seems to be correct (at least by the motors that are moving). The pymavlink example uses the # set some roll comment for the command set_rc_channel_pwm(2, 1600) (which should only affect motors 5 and 6) - I’m assuming you’ve changed that code and didn’t update the comment?

For the ‘max speed’ thing, our Flight Modes documentation specifies

• MANUAL: The roll and pitch input control the rotation rate of the vehicle. As long as the joystick input is deflected, the vehicle will continue to rotate. A centered joystick input commands a rotation rate of zero.

so at least for roll and pitch control if you keep the input command set to 1600 (which you’ve ensured by turning off the failsafes and by only sending one command) then unless you send another command telling it to stop rotating it will try to drive the thrusters faster until the ROV rotates at the set rate (which can’t happen in bench testing). I’m not sure if the same behaviour is true for forward motion, but it might be (I can’t find clear information about that in our documentation).

I’m not sure why the ArduSub 4.0 behaviour is incorrect (wrong motors), but I’ve brought this up with the software team in case they know anything about it.

[Brandonyxf (Brandon)]

Hello Eliot,

Thank you for your reply.

You are right. Everything works well with Ardusub 4.2.0.

I really appreciate your help!