The Dronecode SDK WG is tasked to develop a Drone Application Development SDK. This SDK should allow developers to create drone “applications” that can run on mobile devices (tablets, phones) and on-board companion computers, and that can also seamlessly integrate drones with cloud-based services. The SDK should ideally support Python, C++ and Android Developer APIs, including options like ROS, Cloud etc., and also integration with any simulation environment.

Currently we are evaluating existing developer APIs.

Some requirements include:

• Robust, SDK solution for commercial deployments of PX4, and other compliant flight controllers
• First Pass should include: Dronecode SDK with : basic onboard / basic mobile / basic cloud (RESTful) APIs implemented

Bi-weekly meeting: Tuesday 8 AM PST.

Join the call: www.uberconference.com/lf-dronecode Dial in number: 415-891-1494 No PIN needed

Note: Essentially Mobile SDK is same as onBoard SDK with an additional wrapper layer and remote connection support

Mobile SDKs:

OnBoard SDK:

SDK WG Meeting Minutes - July 18th

• Considering the current options available for SDK, we have two options for dronecode SDK – AirLib, DroneLink
• Licenses: AirLib – MIT; DroneLink – BSD 3
• Presented the comparison for both AirLib and Dronelink from app developer’s perspective (included sample as well) – This included architectural discussion too
• Unordered List ItemLorenz suggested for more use-case level discussion

o Lorenz - to share the User stories (PX4 user's feedback) o Anitha – has requested UX team to share the user's feedback on SDK expectations perspective, which would be shared by July 26th

• Unordered List ItemDroneserver - > Lorenz mentioned AirLib had some assumption to go with this architecture, which needs more discussion. Need to get some details about his view on this case.
• Unordered List ItemDiscussed purpose of RPC in Airlib. As per Microsoft developer it is required to make application code independent of vehicle (Simulator or actual vehicle with any flight controller).
• Above purpose can be achieved even without RPC by having abstract base class in SDK.

Lorenz mentioned about DJI SDK, Currently DJI is leading market. So try to recreate the same user experience that DJI is providing - all SDK variants (mobile, onboard). → DJI SDK has been considered as one our reference SDKs during comparative analysis.

Next steps:

• Explore towards usage of Cloud SDK
• Current gaps in supporting Cloud APIs/requirements in the SDKs we are considering
• Planning to run apps on the real platforms, as we have only run on simulators for now

SDK WG - June 20th

→ Comparative analysis of existing SDKs (listed above) was discussed in brief

→ Mark:

• Licensing information to be added
• API/Interfaces available as part parrot SDK could be considered as reference
• Need to consider both Commercial and industrial applications/use cases

→ AirLib → SDK from Microsoft

• MIT License
• It has both CPP and Python Interfaces
• Cross flight stack friendly and not only MAVLink tied (it has provided flexibility to add non mavlink protocols too)
• Supports UDP, UART, TCP connection.
• No support for Android and iOS
• Supports only clang compiler
• Mavlink library is ported to CPP. With this object oriented approach - makes easy to have pack/unpack function for each MAVlink message
• Allows apps to configure drone connection parameters; so apps can choose which drone it wanna talk to.
• msr::airlib::takeoff(float limit) takes altitude param; so every takeoff can be tuned.

→ DroneLink - > CPP Library provided by PX4 (Julian)

• Only CPP support for now
• BSD 3 License
• Tightly coupled with PX4 and Mavlink like there are px4 custom modes support in source code.
• Supports only UDP connection for now, TCP and Serial connection not implemented for now
• REST Interface support - on going - to be shared
• Wrapper for iOS and Android - To be implemented and shared (However, build infrastructure for Android and iOS is present)
• Auto detects the tool chain on the current platform
• Uses discovery model so that apps binds to a well-known port used by MAVROS (14540).(Author mentioned this as part of code that either this SDK or mavros can be used)
• DroneLink::Action::takeoff() doesn't take altitude as parameter, rather it uses altitude set by default.

Quick Observations/Issues DroneLink:

• Suggested Documentation changes related to App development - resolved by Julian.
• Raised an issue regarding Example app build error - resolved by Julian.

Plan/Next Steps:

• Offline discussion with other relevant stakeholders who could not attend the call (on Slack maybe) and capture the inputs/suggestions and update on WG Wiki
• Julian to share his road map for DroneLink implementation
• Progress/updates could be shared on wiki
• To evaluate efforts on supporting Android and iOS on AirLib
• To figure out on collecting inputs/suggestion by the application developers

Observations on Dronesmith SDK:

• Dronesmith SDK is not opensource SDK
• It is specific to Luci hardware, though they support MAVLink
• Luci hardware is combination of Edison and STM32F427 Cortex which acts as Flight controller.
• Luci runs a customized fork of PX4 Firmware to handle the flight control.
• Dronesmith Engine is been provided as release binaries which runs on Edison board and host webserver.
• Support for Cloud APIs and local REST APIs(Which onBoard apps can use) is been provided.

Observations from developers:

Current Status:

1. Built RpcLib, AirLib and MavlinkCom individually. There were linker errors (-lpthread) while building apps.
2. Now, using Android Ninja build system for the same - In progress.
3. Android has slightly different implementation of pthreads. So, we may have to make changes in AirLib sdk source code for Android under a flag.
4. Posted queries in GitHub::Airsim on SDK architecture which happens to be in their TODO list.
5. Shared HelloDrone example source for both AirLib and DroneLink sdks in Slack #sdk group. Examples are tested on jMAVsim.