ArduPilot support limitations

[bazfp]

This is used as a tracking issue for ArduPilot incompatibilities.

Some, but not all MAVSDK plugins have ArduPilot support. This ticket will list known compatibilities and incompatibilities. If not listed, the state is unknown - It may work, it may not.

Please comment if you have tested functions and can confirm/deny working.

If you would like an ArduPilot feature included in MAVSDK, please contribute.

Known API functional with ArduPilot :

• Telemetry
  • set_rate_position_async
  • set_rate_gps_info_async
  • health_all_ok
  • subscribe_position
  • subscribe_heading
  • subscribe_raw_gps
  • armed
• Mission Raw
  • NOTE: First mission item must be home position for ArduPilot
  • upload_mission_async
  • subscribe_mission_progress
  • clear_mission_async
  • start_mission_async
• Action
  • arm
• MAVLink Passthrough
  • subscribe_message_async
  • send_command_int
• Param
  • set_param_float

Known Broken API

• Mission
  • Needs to account for first mission item being home in Ardupilot
• Probably much more :)

[ykhedar]

Further broken APIs discovered through running Integration Tests with APM-SITL:

• Action

- takeoff             // Results in Error:     command unsupported (21). (mavlink_commands.cpp:187)

- land                // Results in Error:  command unsupported (21). (mavlink_commands.cpp:187)

- set_takeoff_altitude // Results in Error:    Error: Retrying failed get param busy timeout: 
                                  // MIS_TAKEOFF_ALT (mavlink_parameters.cpp:793)
                 //      sending again, retries to do: 3  (MIS_TAKEOFF_ALT). (mavlink_parameters.cpp:780) 

- goto_location  // Results in Error:  command denied (192). (mavlink_commands.cpp:180)

There are probably more but need to fix these basic functions before moving to more advanced ones.

[LorenzMeier]

These are things that you would need to address on the Ardupilot side. The design goal of MAVSDK is to implement the MAVLink standard (and in the process address things that are not properly standardized, e.g. we're working on a scheme for common flight modes to be able to rip out stack-specific flight modes in MAVSDK).

These examples you are listing can be added to the flight stack, without even having to remove any existing functionality or impact existing users of the flight stack. We're more than happy to help with examples or suggestions how to do this, so this is not a nicer way to say no, but encouraging you by all means to tackle it with our support.

Otherwise what will happen is that MAVSDK has to cater to too many ways of doing things, too intense testing and will burn out its maintainers. The fact that this happened with QGC shows us that it is not a hypothetical problem and is why we're so adamant about it from a TSC perspective. It is all about protecting the integrity and long-term maintainability of the project.

[julianoes]

@ykhedar thanks for the data points, that's good to track.

@LorenzMeier

The design goal of MAVSDK is to implement the MAVLink standard

That is one of the goals for the future indeed. Until then, in my opinion, there will have to be some pragmatic steps, to get there. I'm planning to add a "Pure" (or standard) mode to MAVSDK next to the PX4 and ArduPilot specific custom implementations. This will make it really explicit of what is standard and what is not, and allow us to work on the diff to get there. The goal is to be able to remove the custom implementations over time.

Otherwise what will happen is that MAVSDK has to cater to too many ways of doing things, too intense testing and will burn out its maintainers.

This is an important point and that's why I very much appreciate the help from the ArduPilot side in testing this. Discovering and understanding where there is a diff, is the first step to be able to come to a "common" implementation.

[ygratz]

Hi ykhedar, Do you know if the broken API's mentioned in:
https://github.com/mavlink/MAVSDK/issues/1568#issuecomment-1016419022 were fixed?

I'm using MAVSDK 1.4.6. I tried set_takeoff_altitude () and do get the MIS_TAKEOFF_ALT . However, it does change the takeoff_alt (only returns MIS_TAKEOFF_ALT).