Mavsdk: Adding support for ArduPilot

[JonasVautherin]

Context

A while ago, @peterbarker worked on adding support for APM in the SDK (here). More recently, @jinchengde (and others) started looking into that, again. The goal of this issue is to discuss the high-level requirements and architecture.

Benefits for APM

The project is architectured in such a way that everything relies on a C++ MAVLink implementation. Making this implementation compatible with APM means that APM will also get the language bindings (Python, Swift, Java and future ones like Javascript).

The interface common to all our bindings is defined here and is used to auto-generate language-specific APIs (e.g. using RxSwift in Swift, RxJava in Java, and asyncio in Python).

SDK architecture (overview)

The SDK can been seen as composed from 4 parts:

1. The interface definition (protobuf files), common to all the languages (C++, Swift, Java, Python). Each proto file is considered a "plugin", which is a group of (MAVLink) features.
2. The C++ MAVLink implementation, which actually maintains a connection to the drone and does the MAVLink logic.
3. The backend, which exposes the C++ implementation of (2) as a messaging server through the interface of (1).
4. The language bindings (Python, Swift, Java), which implement (1) to communicate with the backend (3).

At the lowest level, each plugin (defined by one proto file) is a C++ library. The backend uses those libraries, as can been seen here.

[JonasVautherin]

I can see different ways to achieve that (and I'm looking for more thoughts). I believe that for each feature, there can be 3 situations:

1. The feature has (can have) the same interface between APM and PX4, but not the same MAVLink implementation
2. The feature does not have the same interface between APM and PX4, and therefore not the same MAVLink implementation
3. The feature is compatible between APM and PX4

Because features are grouped into plugins, that applies to plugins as well. The following scenarios could then occur:

1. We could keep the same interface (public headers) and build a different library that could be "swapped": for instance libdronecode_sdk_apm_mission and libdronecode_sdk_px4_mission, in case mission shares the interface but not the implementation. If the differences are really small, we could also imagine building the same library, but having an interface to decide whether it should start as PX4 or as APM (seems to me that it is what @peterbarker started here).
2. In this case, we could possibly have a separate plugin definition (e.g. mission_px4.proto and mission_apm.proto), and therefore a separate implementation.
3. There is nothing to do here, it should just work

The questions I have would therefore be:

1. Do we have plugins that are completely compatible between APM and PX4 (e.g. Action)?
2. What are the features that are not compatible?
3. For the features that are not compatible, could we share the higher-level interface (at the proto file level) and hide the difference as an implementation detail, or do we have to expose a different interface?

Great contributions would be to test the current SDK against an APM SITL and list the features/plugins that are working or not, and possibly why.

[jinchengde]

I suggest use the same interface but different implementation what peter had done before. because the different between APM and PX4 is not too much bust just some detail in MAVLINK, therefor we could implement takeoff and land example in APM sitl first.

[JonasVautherin]

Could we start a list of differences we know? I've heard that there are "not so many" differences quite a few times, but I still have no clue what that means and what they are :-).

[hamishwillee]

@auturgy and @peterbarker probably the best people for this. Generally speaking the systems use the same messages to achieve the same things, and will often use the same "main" message sequence. They may however use different sequences for edge cases, or use things that are not clearly defined in the spec.

The ones with highest impact are parameter protocol, mission protocol and command protocol.

• Param protocol high level differences here: https://mavlink.io/en/services/parameter.html#implementations
• Mission protocol high level differences: https://mavlink.io/en/services/mission.html#implementations
• Command protocol differences are not documented yet (so I don't know what they are). The main difference is that I believe ArduPilot does not use the LONG form of commands, so suffers rounding errors for positional messages.

In addition, ArduPilot uses different modes - ie Guided vs Offboard and may require different sending rates when in these modes.

I expect you'll discover lots more. Let me know - then I can document them :-)

[auturgy]

Just so they’re listed: Peter and Sid (@bugobliterator) have both done relevant work, although quite some time ago. Someone might be able to build on one of them.

https://github.com/peterbarker/DroneCore/tree/ardupilot

https://github.com/bugobliterator/DroneCore/tree/pr-apm-dronecore

Regards,

James

On 29 Apr 2019, at 12:17 pm, Hamish Willee [e-mail] wrote:

@auturgy and @peterbarker probably the best people for this. Generally speaking the systems use the same messages to achieve the same things, and will often use the same "main" message sequence. They may however use different sequences for edge cases, or use things that are not clearly defined in the spec.

The ones with highest impact are parameter protocol, mission protocol and command protocol.

Param protocol high level differences here: https://mavlink.io/en/services/parameter.html#implementations
Mission protocol high level differences: https://mavlink.io/en/services/mission.html#implementations
Command protocol differences are not documented yet (so I don't know what they are). The main difference is that I believe ArduPilot does not use the LONG form of commands, so suffers rounding errors for positional messages.
In addition, ArduPilot uses different modes - ie Guided vs Offboard and may require different sending rates when in these modes.

I expect you'll discover lots more. Let me know - then I can document them :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[JonasVautherin]

Also, for testing: is there a SITL that can run headless (e.g. on a CI server) for APM? We will need something like that to run integration tests.

[auturgy]

http://ardupilot.org/dev/docs/the-ardupilot-autotest-framework.html

On 24 May 2019, at 2:52 pm, Jonas Vautherin [e-mail] wrote:

Also, for testing: is there a SITL that can run headless (e.g. on a CI server) for APM? We will need something like that to run integration tests.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[fnoop]

Hi, has there been any movement/development on this?

[JonasVautherin]

Unfortunaly, not that I am aware of. On my end, I would still like to have an idea of the differences between PX4 and APM, in order to open a discussion also at the MAVLink level. IMO MAVSDK should implement the "standard" set of messages (presumably common.xml), and allow for "unofficial" plugins supporting dialects.

APM does implement parts of common.xml, and therefore parts of MAVSDK should already work with it. It would be awesome to try to make a proof of concept of that before thinking about how to deal with the differences.

What do you think @fnoop? Could you help with that?

[hamishwillee]

@JonasVautherin Just FYI, ArduPilot differs in (at least) Mission and Parameter protocols. Probably also in the command protocol, but I haven't documented that properly, so no detail.

EDITED: Deleted, just realised I posted most of this above already: https://github.com/mavlink/MAVSDK/issues/728#issuecomment-487436704

@fnoop FWIW While it will be much easier to add ArduPilot-specific plugins, long term it will be better for the standard and for ArduPilot maintenance to work on making the protocol implementations of the common protocols "more compliant".

[SamuelDudley]

Hi All,
I'm looking to help out with this issue. It seems that a compatibility check between ArduPilot and MAVSDK (in its current form) needs to be undertaken. Ideally we can come up with a set of functionality tests to track development...

These are my current thoughts / action plan:

1. Setup a CI server with MAVSDK and ArduPilot SITL.
2. Write tests to determine current MAVSDK functionality against Ardupilot.
3. Write plugins (or modify ArduPilot, or another approach TBD) for MAVSDK to bridge the gap where items in 2 are failing.

[SamuelDudley]

Initial testing of MAVSDK examples and integration tests result in a segfault occurring in the ardupilot SITL application.

Looking into why this might occur...

[SamuelDudley]

[New Thread 0x7ffffab80700 (LWP 8519)]
[New Thread 0x7ffffa370700 (LWP 8520)]
[New Thread 0x7ffff9b60700 (LWP 8521)]
[05:50:50|Debug] Ignoring msg 30 (system_impl.cpp:179)
[05:50:50|Debug] Ignoring msg 33 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 1 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 125 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 62 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 42 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 74 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 36 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 65 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 27 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 116 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 129 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 29 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 24 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 2 (system_impl.cpp:179)
[05:50:50|Debug] Ignoring msg 136 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 32 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 241 (system_impl.cpp:179) [05:50:50|Debug] Ignoring msg 147 (system_impl.cpp:179) [05:50:50|Debug] Forwarding msg 0 to 140737287032224 (system_impl.cpp:157)

gdb is not being kind to me but it looks like ardupilot is bombing out when the forwarded message is received by ardupilot.

I will have to add some debugging on the ardupilot side to see why the heartbeat (msgid = 0) is causing this issue.

[julianoes]

I will have to add some debugging on the ardupilot side to see why the heartbeat (msgid = 0) is causing this issue.

Heartbeat from MAVSDK?

[SamuelDudley]

Yeah, looks that way. If you can think of anything that may be responsible for a segfault in a heartbeat packet... It seems unlikely but certainly the ArduPilot SITL is exiting as soon as that heartbeat is sent.

[JonasVautherin]

It seems that one aspect on which MAVSDK relies and where PX4 and APM differ is the flight modes. Flight modes are not part of the MAVLink specification, and MAVSDK currently uses the PX4 definitions (because it is developed and tested against PX4). However, there has been work towards specifying common flight modes (see e.g. here).

The current state, as far as I can tell, is that the PX4 community is open to working on a flight modes specification and updating PX4 to comply with it, but this cannot be done unilaterally. Anybody wanting to work on that part on the ArduPilot side would be more than welcome to the discussion :blush:.

[auturgy]

I’m part of the discussion.
ArduPilot already implements modes via mavlink, and has done for many years. This might be a useful reference for you:
https://ardupilot.org/dev/docs/apmcopter-adding-a-new-flight-mode.html

Regards,

James

On 13 Jun 2020, at 7:37 am, Jonas Vautherin [e-mail] wrote:


It seems that one aspect on which MAVSDK relies and where PX4 and APM differ is the flight modes. Flight modes are not part of the MAVLink specification, and MAVSDK currently uses the PX4 definitions (because it is developed and tested against PX4). However, there has been work towards specifying common flight modes (see e.g. here).

The current state, as far as I can tell, is that the PX4 community is open to working on a flight modes specification and updating PX4 to comply with it, but this cannot be done unilaterally. Anybody wanting to work on that part on the ArduPilot side would be more than welcome to the discussion 😊.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.