-
-
Notifications
You must be signed in to change notification settings - Fork 530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ArduPilot support limitations #1568
Comments
Further broken APIs discovered through running Integration Tests with APM-SITL:
- 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. |
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. |
@ykhedar thanks for the data points, that's good to track.
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.
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. |
Hi ykhedar, I'm using MAVSDK 1.4.6. |
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 :
set_rate_position_async
set_rate_gps_info_async
health_all_ok
subscribe_position
subscribe_heading
subscribe_raw_gps
armed
upload_mission_async
subscribe_mission_progress
clear_mission_async
start_mission_async
arm
subscribe_message_async
send_command_int
set_param_float
Known Broken API
The text was updated successfully, but these errors were encountered: