ArduPlane Takeoff Seg Fault "Cannot translate flight mode to ArduPilot Plane mode."

[OliverHeilmann]

Hi!

Sort of a continuation of #2031, where the takeoff command was causing issues for ArduCopter. I managed to get around the issue by using takeoff_async, though it still sub-optimal to have a takeoff (blocking) which throws seg-faults when there is no position lock (due the the GUIDED mode requiring this).

Now, I am testing on a fixed wing with ArduPlane SITL and I was hoping that my takeoff approach would work for it as well- unfortunately not. I have done some characterising of the problem and I have observed the following:

1. action->takeoff(); causes seg-fault. Going into the debugger, it looks like the takeoff command doesn't directly throw the fault but it happens when the mission starts (though this command by itself works as expected).

2. action->takeoff_async does not cause seg fault and only works sometimes. I have used the set_takeoff_altitude() method before using the takeoff_async() method which is successful, however, even when doing so, the plane only takes off sometimes which is the strangest behaviour. As you may be able to see in the logs (and as mentioned in the title, I am getting a "Cannot translate flight mode to ArduPilot Plane mode" when I run the takeoff command. Perhaps this is related to my issue? Additionally, the sample code provided below which I used to run the takeoff_async command consistently fires twice with a warning saying "Asset failed to take off!" You can also see this in the logs.

    action->takeoff_async([](mavsdk::Action::Result result) {
        if (result == mavsdk::Action::Result::Success) {
            LOG_INFO("Asset took off successfully!");
        } else {
            LOG_WARNING("Asset failed to take off!");
        }
    });

3. When I use the mavsdk::MissionRaw mission items and send a mission to the plane with a takeoff hight of anything above ground e.g. 10 m, then the plane does successfully takeoff (even without the mavsdk takeoff command at all). I am essentially saying that this gives me the behaviour I am looking for/ this works!

    // Add Takeoff (required for ArduPilot missions)
    m_missionItems.push_back(makeMissionItem(1, 3, MAV_CMD::NAV_TAKEOFF, 0, 1, 0, 0, 0, 0, 0, 0, <THIS IS THE ALTITUDE VALUE>, 0));

So I have essentially found a work around in the way of MissionRaw takeoff items which is great but I wanted to point out that the MAVSDK version does not work correctly. I would prefer to use your approach if possible but it doesn't seem to work currently.

Thanks again for your help in advance.

[julianoes]

Hang on, why does it segfault? Can we fix that?

[OliverHeilmann]

I can see how my post was a little confusing, sorry!

The segfault arrises when using the mavsdk takeoff (blocking) command while connected to an ArduPlane. I have been testing using ArduPilot SITL. I am not 100% sure where exactly this error is coming from but it only happens when I use this takeoff command.

My code logic is the same/ similar to the mavsdk examples:

• Push Mission Items (including setting takeoff altitude)
• Upload Mission
• Arm
• Takeoff (I have tried takeoff after Start Mission as well)
• Start Mission

For the ArduRover, I don't need the takeoff command so haven't had any issues. For the ArduCopter, I have posted in #2031 about my findings, but using the takeoff command also has some issues.

For ArduPlane, I am getting this segfault as well as an error in the mavsdk logs which reads "Cannot translate flight mode to ArduPilot Plane mode" (which is in the images I provided).

[JonasVautherin]

The error message comes from here, I assume that it gets a MAV_TYPE::MAV_TYPE_FIXED_WING. And apparently flight_mode_to_ardupilot_plane_mode returned PlaneMode::Unknown.

It would be nice to check what FlightMode is passed there that returns Unknown. Still it should not segfault, but this is already an issue IMO.

[OliverHeilmann]

I will check the flight mode and also try to replicate my segfault issue with some sample code which I'll share here.

I do suspect it is coming from something related to the takeoff command- please do let me know if you find anything from testing on your end.