Takeoff altitude fixed to 2

[kripper]

We do:

await drone.action.set_takeoff_altitude(1)
await self.vehicle.system.action.takeoff()

But the drone is receiving a Mavlink take off message with param alt = 2 [m]

This is the received mavlink msg:

[julianoes]

PX4 or ArduPilot?

[kripper]

RosettaDrone (I wrote the Mavkink 2 implementation).

[JonasVautherin]

RosettaDrone (I wrote the Mavkink 2 implementation).

Oh interesting! First time I hear of MAVSDK being used for something other than Ardupilot or PX4!

This is the implementation of the set_takeoff_altitude function:

Action::Result ActionImpl::set_takeoff_altitude(float relative_altitude_m)
{
    if (_system_impl->autopilot() == Autopilot::Px4) {
        return set_takeoff_altitude_px4(relative_altitude_m);
    } else {
        return set_takeoff_altitude_apm(relative_altitude_m);
    }
}

• If the autopilot is detected as PX4 it sets a param.
• For Ardupilot, it just sets it as a class variable to be used in later calls, e.g. here.

I see here that sometimes the implementation defaults to PX4 if the autopilot is not detected as Ardupilot.

So now it brings us to this new interesting situation: RosettaDrone! How does MAVSDK detect it / how does RosettaDrone advertise itself?

I would think that ideally, RosettaDrone should implement the MAVLink from Ardupilot or the MAVLink from PX4, but not yet another incompatible flavour of MAVLink 🙈.

What do you think?

[kripper]

Well, on the RD side, I prefer to be agnostic and use the altitude parameter sent via Mavlink.

On the MAVSDK side. I would prefer it to use the value set with set_takeoff_altitude(1), and otherwise send a 0 or null instead of some arbitrary hardcoded parameter.

[kripper]

Oh interesting! First time I hear of MAVSDK being used for something other than Ardupilot or PX4!

I decided to use MAVSDK because of the QGC mission implementation.

And yesterday I finished implementing and testing a computer vision based precision landing algorithm using MAVSDK which was previously based on Dronekit.

I'm now playing with ORB SLAM.

[kripper]

This is the implementation of the set_takeoff_altitude

The strange thing is that the take off command (int 22) is received with an altitude parameter = 2, which is different than the one I set with set_takeoff_altitude.

[JonasVautherin]

Well, on the RD side, I prefer to be agnostic and use the altitude parameter sent via Mavlink.

Hmm I don't think there is such a thing as being "agnostic". Either you use MAVLink-PX4, or you use MAVLink-Ardupilot, or you use MAVLink-your-own. But there is no such thing as "the one, standard MAVLink". That's why MAVSDK has if-else in those places where PX4 and Ardupilot do not agree 😇.

The strange thing is that the take off command (int 22) is received with an altitude parameter = 2, which is different than the one I set with set_takeoff_altitude.

Sure, apparently it does not work properly. But to understand why, we need to understand how your autopilot is being detected by MAVSDK. Looking at the action implementation, it seems like if it is detected neither as Ardupilot nor as PX4, then you will get a mix of them and it most likely won't work.

So what does your autopilot advertise itself as? I guess not as PX4 and not as Ardupilot, right? If that's correct, could you try having it advertise itself as one or the other and see if that helps?

[kripper]

In the heartbeats, we send:

msg.autopilot = MAV_AUTOPILOT.MAV_AUTOPILOT_ARDUPILOTMEGA;

What could be the reason that MAVSDK sends altitude = 2 in the takeoff msg, even when we did set_takeoff_altitude(1) before?
Why doesn't system.action.takeoff() accept an altitude argument when the mavlink takeoff msg supports this parameter?

[JonasVautherin]

What could be the reason that MAVSDK sends altitude = 2

Looking in the code, the logic won't be consistent if the autopilot is neither detected as PX4 nor Ardupilot. Not sure why it would be "2", maybe it's just undefined behavior?

Why doesn't system.action.takeoff() accept an altitude argument when the mavlink takeoff msg supports this parameter?

I believe it's because PX4 does not read this parameter, so it has to be done in two steps (set the param with the param protocol first, then takeoff).

[julianoes]

I believe it's because PX4 does not read this parameter, so it has to be done in two steps (set the param with the param protocol first, then takeoff).

Yes, PX4 is in the wrong here. I just wonder why it doesn't work though.

The param is:
https://docs.px4.io/v1.14/en/advanced_config/parameter_reference.html#MIS_TAKEOFF_ALT

[kripper]

Not sure why it would be "2", maybe it's just undefined behavior?

Defined in MAVSDK server?

Can we add an optional altitude parameter to system.action.takeoff() and send it in the Mavlink message instead of this mysterious constant?

[JonasVautherin]

Defined in MAVSDK server?

In the code I showed here, yes.

If I was to debug this, I would start there: see how MAVSDK detects your autopilot. As I said earlier, the MAVSDK implementation sometimes does if (PX4) ... else ... and sometimes if (Ardupilot) ... else ..., which means that if you are neither, you once get the logic for PX4 and once for Ardupilot. And that cannot be good 🙈.

[kripper]

Can we add an optional altitude parameter to system.action.takeoff() and send it in the Mavlink message instead of this mysterious constant?

I don't understand why two messages are required by MAVSDK, especially when the takeoff Mavlink message supports an altitude parameter.

Imagine the first message doesn't reach the aircraft (UDP) before the takeoff message is received and executed.

I believe other Mavlink implantations send the altitude parameter with the takeoff message.

[JonasVautherin]

I don't understand why two messages are required by MAVSDK, especially when the takeoff Mavlink message supports an altitude parameter.

Again, PX4 and Ardupilot don't use MAVLink the same way. Of course it would be great if they did, but that is not the case in practice and I don't think it will ever change. So we have to deal with it. QGC also implements different logic between Ardupilot and PX4 (and maybe even others).

[kripper]

Will MAVSDK support setting the altitude parameter that is sent with the Mavlink take off message (as defined in the Mavlink specs) or will MAVSDK always send some fixed hardcoded altitude value that can't be controlled by the MAVSDK user?

One thing is that PX4 and Ardupilot ignore this parameter and use the other one sent in the set parameter message instead (ie, both speak variations of Mavlink), and another thing is that MAVSDK doesn't support sending the Mavlink take off message correctly with a custom altitude.

If so, we could argue that MAVSDK isn't really designed to speak Mavlink, but the two Mavlink variations for PX4 or Ardupilot.

Besides, if those flight controllers ignore the altitude parameter sent with the Mavlink take off message, having MAVSDK sending the message correctly won't hurt them, right?

[julianoes]

If so, we could argue that MAVSDK isn't really designed to speak Mavlink, but the two Mavlink variations for PX4 or Ardupilot.

Unfortunately, yes. I was meaning to add a "Pure mode" that doesn't have any quirks, a long time ago, but never finished it after funding was pulled for it, and it became a weekend project...
mavlink/MAVSDK#1815

Besides, if those flight controllers ignore the altitude parameter sent with the Mavlink take off message, having MAVSDK sending the message correctly won't hurt them, right?

It's a good point. And that way we could slowly transition to be spec compliant.

[JonasVautherin]

I don't mean to copy-paste the links yet another time, but... how does this not use the takeoff altitude in the takeoff message? Let me copy-paste the code:

        command.params.maybe_param7 = get_takeoff_altitude().second;

As I stated in previous comments, it feels like your problem is broader than this: my guess is that MAVSDK does not detect your autopilot as Px4 or ArduPilot but rather as Unknown, and this is currently a bit of an undefined behaviour (if you read my comments above, I am pointing to places in the code where the default is sometimes PX4 and sometimes Ardupilot, meaning that "unknown" would receive a mix of those defaults, which obviously is not good).

If so, we could argue that MAVSDK isn't really designed to speak Mavlink, but the two Mavlink variations for PX4 or Ardupilot.

I have been working with MAVLink for years, and I genuinely don't know what the "true MAVLink, i.e. not PX4 or Ardupilot" is. I would agree that PX4 and Ardupilot don't fully honour the specs (for the parts of the specs that are non-ambiguous), but there are parts of the specs that are ambiguous.

I guess we could add a third autopilot, e.g. Rosetta, and adapt the MAVSDK code to it. But then someone would have to contribute that 😇.