MAVSDK-Python: MissionRaw upload results in ' UNSUPPORTED'

I’m currently attempting to use the orbit feature of MAVSDK with the mission_raw command. The result of the following code outputs the following error:

‘mavsdk.mission_raw.MissionRawError: UNSUPPORTED: ‘Unsupported’’

I was hoping for some guidance on using the raw mission command as it would be beneficial for my work.

Thanks for your help!

` import asyncio

from mavsdk import System from mavsdk.mission_raw import MissionItem from mavsdk import mission_raw

MAV_CMD_DO_ORBIT = 34 ORBIT_YAW_BEHAVIOUR = 0 MAV_MISSION_TYPE_MISSION = 0 MAV_FRAME_MISSION = 2

async def run(): drone = System() await drone.connect()

print("Waiting for drone to connect...")
async for state in drone.core.connection_state():
    if state.is_connected:
        print(f"Drone discovered with UUID: {state.uuid}")
        break

print_mission_progress_task = asyncio.ensure_future(print_mission_progress(drone))

running_tasks = [print_mission_progress_task]
termination_task = asyncio.ensure_future(observe_is_in_air(drone, running_tasks))

mission_items = []
mission_items.append(MissionItem(0,#Seq
                                 MAV_FRAME_MISSION,#frame
                                 MAV_CMD_DO_ORBIT,#command
                                 1,#current
                                 0,#autocontinue
                                 5.0,#param1
                                 float('nan'),#param2
                                 ORBIT_YAW_BEHAVIOUR,#param3
                                 0,#param4
                                 1,#x float('nan') Using the nan results in error.The documenation for orbit states:'NaN: Use current vehicle position or current center if already orbiting.'
								 1,#y float('nan') 
								 25.0,#z
								 MAV_MISSION_TYPE_MISSION))

print("-- Uploading mission")
await drone.mission_raw.upload_mission(mission_items)

print("-- Arming")
await drone.action.arm()

print("-- Starting mission")
await drone.mission_raw.start_mission()

await termination_task

async def print_mission_progress(drone): async for mission_progress in drone.mission_raw.missionProgress(): print(f"Mission progress: " f"{mission_progress.current}/" f"{mission_progress.total}")

async def observe_is_in_air(drone, running_tasks): “”" Monitors whether the drone is flying or not and returns after landing “”"

was_in_air = False

async for is_in_air in drone.telemetry.in_air():
    if is_in_air:
        was_in_air = is_in_air

    if was_in_air and not is_in_air:
        for task in running_tasks:
            task.cancel()
            try:
                await task
            except asyncio.CancelledError:
                pass
        await asyncio.get_event_loop().shutdown_asyncgens()

        return

if name == “main”: loop = asyncio.get_event_loop() loop.run_until_complete(run()) `

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 34 (20 by maintainers)

Most upvoted comments

Thanks again for your help!

DoppleGangster on Feb 1, 2021

This is for anyone’s reference coming in looking for answers to the error: The argument BUILD_BACKEND has been replaced by #BUILD_MAVSDK_SERVER. To build mavsdk_server, use -DBUILD_MAVSDK_SERVER=ON.

Just set DBUILD_BACKEND=OFF the next time you call cmake: sudo cmake -DBUILD_BACKEND=OFF -DBUILD_MAVSDK_SERVER=ON …

aquaMatt900 on Feb 9, 2021

Watched the video and seems straight forward enough. I’ll give it a go and try and implement orbit as an action. Assuming I don’t run into issues I’ll contribute my changes.

Thanks for the responses.

DoppleGangster on Jan 13, 2021

I’m trying to get the changes made with the enum to compile and I’m running into an issue with the auto-generated file action_service_impl.h

It seems that the translations do not generate the correct names for the enum as it adds on “ORBIT_YAW_BEHAVIOUR_” in from of certain parts of the enum. If I manually correct the issue everything generates correctly. Did I do something incorrectly with my proto file?

Below if the troubled code:

static rpc::action::OrbitYawBehavior translateToRpcOrbitYawBehavior(const mavsdk::Action::OrbitYawBehavior& orbit_yaw_behavior)
    {
        switch (orbit_yaw_behavior) {
            default:
                LogErr() << "Unknown orbit_yaw_behavior enum value: " << static_cast<int>(orbit_yaw_behavior);
            // FALLTHROUGH
            case mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TO_CIRCLE_CENTER:
                return rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TO_CIRCLE_CENTER;
            case mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_INITIAL_HEADING:
                return rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_INITIAL_HEADING;
            case mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_UNCONTROLLED:
                return rpc::action::ORBIT_YAW_BEHAVIOUR_UNCONTROLLED;
            case mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE:
                return rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE;
            case mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_RC_CONTROLLED:
                return rpc::action::ORBIT_YAW_BEHAVIOUR_RC_CONTROLLED;
        }
    }

    static mavsdk::Action::OrbitYawBehavior translateFromRpcOrbitYawBehavior(const rpc::action::OrbitYawBehavior orbit_yaw_behavior)
    {
        switch (orbit_yaw_behavior) {
            default:
                LogErr() << "Unknown orbit_yaw_behavior enum value: " << static_cast<int>(orbit_yaw_behavior);
            // FALLTHROUGH
            case rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TO_CIRCLE_CENTER:
                return mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TO_CIRCLE_CENTER;
            case rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_INITIAL_HEADING:
                return mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_INITIAL_HEADING;
            case rpc::action::ORBIT_YAW_BEHAVIOUR_UNCONTROLLED:
                return mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_UNCONTROLLED;
            case rpc::action::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE:
                return mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_HOLD_FRONT_TANGENT_TO_CIRCLE;
            case rpc::action::ORBIT_YAW_BEHAVIOUR_RC_CONTROLLED:
                return mavsdk::Action::OrbitYawBehavior::ORBIT_YAW_BEHAVIOUR_RC_CONTROLLED;
        }
    }

Thanks again.

DoppleGangster on Jan 29, 2021

Got it thanks. The PR is in.

DoppleGangster on Jan 26, 2021

@JonasVautherin great makes sense! Hopefully I’ll get some time later this week to continue testing.

Really appreciate your responses.

DoppleGangster on Jan 19, 2021

The link between both repositories (mavlink/mavsdk and mavlink/mavsdk-python) is the proto submodule (mavlink/mavsdk-proto). I gather you already modified it in mavlink/mavsdk. You need to propagate those changes into your clone of mavlink/mavsdk-python. Either by copying mavsdk/proto to mavsdk-python/proto, or by making your mavsdk-python clone point to your fork of mavsdk-proto.

Then, you can generate the python wrapper with ./other/tools/run_protoc.sh.

Let me try to give an example, because I understand it may be a bit confusing 😅.

Example

Say you have DoppleGangster/mavsdk in /tmp/mavsdk and DoppleGangster/mavsdk-python in /tmp/mavsdk-python.

cd /tmp/mavsdk-python

# Synchronize proto/ between both clones
rm -rf proto
cp -r /tmp/mavsdk/proto .

# Generate the python bindings in a venv
python3 -m venv venv
pip install protoc-gen-mavsdk
./other/tools/run_protoc.sh

To go further, note that cp the proto changes is not exactly the nicest way. Actually, you will need to make a fork of mavlink/mavsdk-proto and make a PR with your changes. Your fork will be DoppleGangster/mavsdk-proto, and both your clones DoppleGangster/mavsdk and DoppleGangster/mavsdk-python could point to that fork, such that they can access your changes. But that’s not needed, cp will work just fine.

JonasVautherin on Jan 19, 2021

Awesome that did the trick. Hopefully I get a chance to test the command today.

Thanks again!

DoppleGangster on Jan 18, 2021

@JonasVautherin yes, in PX4 it is only supported as standalone command. PX4 goes into a special flight mode for orbit, which is is semi-automatic (depends quite a bit on the exact version of PX4 as there is ongoing development). Is the sending of a simple COMMAND_LONG documented somewhere for MAVSDK? I couldn’t find any documents.

dayjaby on Jan 13, 2021