Waiting for the vehicle to arm

Good days,

My purpose is that make arm pixhawk by using pymavlink library but I had a problem when ı worked the code into this link(Pymavlink · GitBook)

When I worked this code, I just took “waiting for the vehicle to arm” and then I do not take anymore. Please how can I fix this problem. If I used wrong code, could you write true code?

Hi @huseyinefe, welcome to the forum :slight_smile:

I’ve moved your question to its own post, because it was unrelated to the one you originally posted it in.

If your code is getting to that print statement then it’s connecting correctly to the flight controller, but that example works well for me so I’m not sure why it’s not working for you. Can you try using master.arducopter_arm() instead of the explicit command_long_send call, and maybe send two arm calls before doing master.motors_armed_wait()?

More generally, which versions of Pymavlink and ArduSub are you using?


Thank you Eliot. I solved this problem thanks to your reply


I have new problem. I am using pixhawk with Ardusub. How can I control the thruster with pymavlink. I need to know as soon as possible. Would you mind explaining the codes

import time
import math
# Import mavutil
from pymavlink import mavutil
# Imports for attitude
from pymavlink.quaternion import QuaternionBase

def set_target_depth(depth):
    """ Sets the target depth while in depth-hold mode.

    Uses https://mavlink.io/en/messages/common.html#SET_POSITION_TARGET_GLOBAL_INT

    'depth' is technically an altitude, so set as negative meters below the surface
        -> set_target_depth(-1.5) # sets target to 1.5m below the water surface.

        int(1e3 * (time.time() - boot_time)), # ms since boot
        master.target_system, master.target_component,
        type_mask=( # ignore everything except z position
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_X_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_Y_IGNORE |
            # DON'T mavutil.mavlink.POSITION_TARGET_TYPEMASK_Z_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_VX_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_VY_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_VZ_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_AX_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_AY_IGNORE |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_AZ_IGNORE |
            # DON'T mavutil.mavlink.POSITION_TARGET_TYPEMASK_FORCE_SET |
            mavutil.mavlink.POSITION_TARGET_TYPEMASK_YAW_IGNORE |
        ), lat_int=0, lon_int=0, alt=depth, # (x, y WGS84 frame pos - not used), z [m]
        vx=0, vy=0, vz=0, # velocities in NED frame [m/s] (not used)
        afx=0, afy=0, afz=0, yaw=0, yaw_rate=0
        # accelerations in NED frame [N], yaw, yaw_rate
        #  (all not supported yet, ignored in GCS Mavlink)

def set_target_attitude(roll, pitch, yaw):
    """ Sets the target attitude while in depth-hold mode.

    'roll', 'pitch', and 'yaw' are angles in degrees.

        int(1e3 * (time.time() - boot_time)), # ms since boot
        master.target_system, master.target_component,
        # allow throttle to be controlled by depth_hold mode
        # -> attitude quaternion (w, x, y, z | zero-rotation is 1, 0, 0, 0)
        QuaternionBase([math.radians(angle) for angle in (roll, pitch, yaw)]),
        0, 0, 0, 0 # roll rate, pitch rate, yaw rate, thrust

# Create the connection
master = mavutil.mavlink_connection('udpin:')
boot_time = time.time()
# Wait a heartbeat before sending commands

# arm ArduSub autopilot and wait until confirmed

# set the desired operating mode
DEPTH_HOLD_MODE = master.mode_mapping()[DEPTH_HOLD]
while not master.wait_heartbeat().custom_mode == DEPTH_HOLD_MODE:

# set a depth target

# go for a spin
# (set target yaw from 0 to 500 degrees in steps of 10, one update per second)
roll_angle = pitch_angle = 0
for yaw_angle in range(0, 500, 10):
    set_target_attitude(roll_angle, pitch_angle, yaw_angle)
    time.sleep(1) # wait for a second

# spin the other way with 3x larger steps
for yaw_angle in range(500, 0, -30):
    set_target_attitude(roll_angle, pitch_angle, yaw_angle)

# clean up (disarm) at the end

I have used this code but i did not understand exactly. Would you mind explaining parametres in this code?
Thank you to your helps .

Glad to hear it :slight_smile:

What kind of control do you need? ArduSub is set up to allow control of the applied thrust across motion directions (in manual mode), and includes control algorithms for maintaining depth and attitude (orientation / rotation) in other flight modes.

If you for some reason want control of individual thrusters instead of making use of the frame configuration and internal control loops then that’s also technically possible, but requires workarounds as it’s not a functionality that’s directly supported by ArduSub.

I’ve moved your code into a code block so it’s readable - you can learn how to do that (and more) in the How to Use the Blue Robotics Forum post.

The code you’ve posted is from our Set Target Depth/Attitude Pymavlink example, which shows how to set the desired depth target or attitude target when using the depth hold or stabilise flight modes.

Which parameters are you unsure about? The explanations of the parameters used by each function are specified in the function doc strings, and the comments in the code describe each step that is taking place.

I would like to set the forward/reverse thrusters to move the vehicle at a constant speed. I am looking for a forward throttle control code.

This post may be worth a read - accurate speed measurement (and control) requires some form of speed or position feedback.

Take a look at the Send RC (Joystick) and Manual Control examples. I’d also recommend looking through the various forum posts with the pymavlink tag - some of them are quite detailed and helpful :slight_smile:


I have the same issue. Even when i run master.arducopter_arm() twice before the master.armed_wait(), my code is hanging waiting for the motors to arm. Why is this?

Hi @BennyAmk,

Additional arming calls shouldn’t be necessary, but have helped at least one person.

If you’re not already doing so, it may also help to specifically wait for vehicle heartbeats, since BlueOS sends additional heartbeats with different types from some of its services.

Thanks Eliot. Is it possible there is some kind of conflict? In the same code, I am using RC_CHANNELS_OVERRIDE_SEND to turn on and off my lights. The same codes provided here

I’m not really sure what you’re asking here - if you’re connecting to the same port with a different program then there could be port access conflicts, but for just sending/receiving messages within a single thread of a program I don’t see how there could be a conflict, since the messages are unrelated.

That said, if something isn’t working I’d recommend starting with a minimal program to test one behaviour at a time, and only adding extra functionalities once you know they work independently. That way you can find out immediately if a particular combination isn’t working, and try to resolve things from there.