Copter/MAVLink: update MAV_CMD_NAV_TAKEOFF's param3 to specify whether GPS is required

[khancyr]

Hi all,

I try to use new takeoff function in takeoff.pde wih alt_hold mode.

But I don't understand the parameter : must_navigate . It is describe as must_nagivate is true if mode must also control horizontal position

This parameter come from (float takeoff_alt_cm, bool must_navigate) which is called in GCS_Mavlink.pde in response of MAV_CMD_NAV_TAKEOFF // param3 : horizontal navigation by pilot acceptable do_user_takeoff(takeoff_alt, is_zero(packet.param3))

In mode Alt_hold, when land, if I request a takeoff with apmplanner2 or mavros , it doesn't takeoff...

By looking at Mavlink definition :

MAV_CMD_NAV_TAKEOFF Takeoff from ground / hand
Mission Param #1    Minimum pitch (if airspeed sensor present), desired pitch without sensor
Mission Param #2    Empty
Mission Param #3    Empty
Mission Param #4    Yaw angle (if magnetometer present), ignored without magnetometer
Mission Param #5    Latitude
Mission Param #6    Longitude
Mission Param #7    Altitude

Param 3 is empty. In mavros it's always 0 . I find two takeoff definitions in apmplanner2 and both set param3 to 0

I made some test by setting

bool current_mode_has_user_takeoff(bool must_navigate)
{
    switch (control_mode) {
        case GUIDED:
        case LOITER:
        case POSHOLD:
        case ALT_HOLD:
                return true;
        case SPORT: <-- I don't know this mode so I don't touch it
            return !must_navigate; 
        default:
            return false;
    }
}

And I achieved good takeoff (with 100% reliability and repetability) in alt_hold mode with or without GPS and no sonar. I use git branch https://github.com/diydrones/ardupilot/tree/411a96b4b3cefdb4277b48b8df38d212efbb1f92 on erlebrain (linux + pxf cape). By the way, apm works well with g++ 4.8.2

[rmackay9]

This is really a dev question so it probably belongs on drones-discuss@googlegroups.com.

The issue is really that the mavlink change to the meaning of param3 hasn't been done officially by submitting a patch to the mavlink repo. The definition of param3 is "1" if the autopilot must control the horizontal position during take-off or "0" if the pilot will control it.

[khancyr]

Ok I understand ! So currently it is not possible to use autotakeoff with Alt_Hold and Sport mode ?

[rmackay9]

@khancyr, Actually it should work in those modes as well as long as the GCS sets param3 to "0" if the vehicle is in AltHold or Sport at that moment. Basically setting that to "0" means that the pilot will control the vehicle's horizontal position. It's a safety check.

[khancyr]

Humm... It doesn't work for me. I am using BBB+PXF cape with diydrone repo and use mavros with rcoverride. I do :

• (landed) set to alt_hold
• arm
• put some throttle (1500ms) (without throttle takeoff is launch but the uav hasn't enough power to takeoff )
• call take off command with request altitude = 2.0 : https://github.com/mavlink/mavros/blob/master/mavros/src/plugins/command.cpp#L317 ( param3 = 0 )

--> mavlink send back takeoff failed

With other modes it works as intend.

Is my reasoning wrong ?

If we send param3 = 0  
    ==> is_zero(packet.param3) == True
    ==> must_navigate == True 
    ==> current_mode_has_user_takeoff(must_navigate) == false 

So we need :

bool Copter::current_mode_has_user_takeoff(bool must_navigate)
{
    switch (control_mode) {
        case GUIDED:
        case LOITER:
        case POSHOLD:
            return true;
        case ALT_HOLD:
        case SPORT:
            return must_navigate;
        default:
            return false;
    }
}

instead of

 return !must_navigate;

No ?

[magicrub]

Please provide a reason for closing.

[khancyr]

@magicrub you are right, after reading again I should stay open as docs on mavlink parameter hasn't been done yet .

[magicrub]

I wasn't saying anything right or wrong, I just wanted to know why it closed.

[OXINARF]

@khancyr Do you want to do a PR to MAVLink repo to add the description for param3?

[IamPete1]

We still haven't documented param3....

Looks like we only support this "user-takeoff" in alt hold, flow hold and sport. I'm not sure what it does exactly. I wonder if we should just remove the ability. @rmackay9 ?

[rmackay9]

@IamPete1,

I guess this was added for Solo or skyviper to support a takeoff button on the transmitter. This was probably "necessary" because a significant number of new users don't takeoff assertively enough which leads to the vehicle being "not landed" even though its legs are still on the ground and then the vehicle can flip when the GPS position moves.

Sadly we seem to have two solutions to the same problem, the other being the PILOT_TKOFF_ALT parameter which forces an assertive takeoff.

I don't personally like either feature because it leads to a kind of out-of-control takeoff from the pilot's point of view but I'm not sure we can really remove it.