Project/components names

[JonasVautherin]

The discussion has been started on Slack already, but I'd like to continue here. The main issue was that "DroneCore" is close to "Dronecode" which makes it confusing for people.

I've read propositions of going for "Dronecode Mobile API" and "Dronecode Onboard API".

Feel free to share your opinion here.

[JonasVautherin]

API vs SDK

In my opinion, we should consider what people already know:

• I believe the main one is DJI: DJI Mobile SDK/DJI Onboard SDK (the former being for Android/iOS and the latter in C++)
• The Parrot SDK (on their dev page they call it "the SDK")
• DroneKit. From the official page: "DroneKit offers an SDK and web API".

So I would use "SDK" instead of "API", just because we answer the same problem as these other SDKs.

Mobile / Onboard

Now, our structure is a bit different than DJI's in that we don't have a concept of "Mobile" vs "Onboard". We could certainly run everything onboard, or everything on the ground, be it on a mobile or not. Of course, not all combinations make sense. But it can be done.

My proposition

Here is how I personally see DroneCore:

• Core libraries: those are the C++ libraries composed of "core", which does the mavlink communication and maintains the connection to the drone, and the plugins that add features (e.g. action, telemetry, mission).
• Backend: this is a gRPC server wrapping the core libraries and providing a gRPC interface in the form of proto files. The backend may or may not run onboard the drone.
• Frontends: those are language wrappers making a nice interface to the gRPC backend. So as an app developer, instead of having to build my mobile app on top of the proto files defined by the backend, I can use, say, DroneCore-Java, which takes care of the gRPC communication under the hood. A frontend connects to the backend over the network.

More than those components is the packaging, i.e. what we will provide to our third-party developers. And I believe that the main "product" we will provide will group the core librairies, the backend and a frontend. I would call that an SDK ("the Java SDK", "the Swift SDK", etc.).

So the goal is to just call it "Dronecode SDK", optionally with the language: "Dronecode iOS SDK" or "Dronecode Python SDK". New users should see that. Advanced users can read more about the components and learn about the core libs etc.

Examples using my proposition

• Android apps can use the Dronecode Android SDK. If the drone to which you connect is running the backend onboard, the SDK will automatically connect to it. Otherwise, it will automatically run a backend on your phone.
• If your drone is running a backend onboard, you can create a Python program using the Python frontend and running onboard the drone as well.
• If you are looking for performance and want to reduce overhead, you can decide to use the core libraries directly in C++. That can be run onboard the drone or on the ground.

[shakthi-prashanth-m]

I agree to this. Very clear proposition.

[zlite]

Go with "SDK", not API, for all the reasons stated above

[anitha-suresh-zz]

As discussed earlier, I agree with 'Dronecode SDK' (as DroneCore vs DroneCode seems to be confusing).
Also, it is just not an API, but much more than that - as Jonas has clearly explained.

[hamishwillee]

The proposition makes sense. I'm not sure yet whether it is needed or desirable to have separate SDK/deliverable by target (ie just a Dronecode SDK for everything makes sense).

From a docs maintenance point of view if the different languages share a lot of commonality then having a single documentation set (SDK) will make things easier for us.

[hamishwillee]

PS I like the simplicity of "Dronecode SDK" and I appreciate the arguments for not specifying "onboard" or "mobile".

That said, is it possible/likely we will have another type of SDK in future and will hence need to differentiate? E.g. (say) Dronecode Platform Porting SDK ....

[JonasVautherin]

That said, is it possible/likely we will have another type of SDK in future and will hence need to differentiate? E.g. (say) Dronecode Platform Porting SDK ....

I am not sure I understand the example :-). So you mean having another type of SDK for other kinds of drones, or having another type of SDK doing something different (like a weather forecast API for drones)?

[hamishwillee]

That said, is it possible/likely we will have another type of SDK in future and will hence need to differentiate? E.g. (say) Dronecode Platform Porting SDK ....

I am not sure I understand the example :-). So you mean having another type of SDK for other kinds of drones, or having another type of SDK doing something different (like a weather forecast API for drones)?

We have a camera streaming daemon that runs on a companion computer and acts as a camera server - providing a MAVLink Camera Protocol interface and RTSP video streaming interface to cameras that are connected to it. The daemon has a configurable backend that can be updated to support new types of cameras. We might conceivably create a Dronecode Camera Integration SDK to make it easier to package everything needed to work with cameras.

I'm not saying that will happen, I'm just saying if we have multiple SDKs in future then we'd need naming to differentiate them. Using up the namespace of Dronecode SDK makes that more challenging.

[JonasVautherin]

Just to take this particular example, I would say that the goal is to integrate the camera into the Dronecode SDK. For me as a third-party developer, I don't necessarily want to know the implementation detail of the camera. If the Dronecode SDK just allows me to do something like below, I guess I'm fine with it:

Camera camera = new Camera();
camera.takePicture();
camera.startTimelapse(3);

In other words, on the frontend/third-party dev side, this is an implementation detail. The frontend has access to a camera, and a camera is a plugin. On the drone manufacturer side, the system needs to be setup in such a way that the frontend can access the camera. I could imagine having different plugins for different kinds of cameras, e.g. MAVLink, PTP, or a REST API. The frontend should not be affected by this.

So the "Dronecode SDK" allows you to "control your drone". Whatever sensor being on the drone can be controlled by the Dronecore SDK given that there is a plugin for that.

Does that make sense to you? Or am I missing something?

[hamishwillee]

Does that make sense to you? Or am I missing something?

Yes. OEMs are developers too. Assume the hypothetical SDK is for the OEM backend camera streaming daemon plugin developer. Can those instructions live in the Dronecode SDK? If not, then you potentially have another SDK that you have to name.

More generally is there any possible integration point with Dronecode that might require a separate SDK? If so, then naming is potentially a problem.

I don't know of such an integration point. If you can't think of one either, then go forth and use the proposed naming :-)

[JonasVautherin]

NOTE: I realize it is a long example, but I'm trying to put in perspective how I would call the different modules being part of the Dronecode SDK :-).

Can those instructions live in the Dronecode SDK? If not, then you potentially have another SDK that you have to name.

I think they can.

So for instance, if a company named "MagicDrones" has a special camera based on PTP (but, say, with custom commands). The Dronecode camera plugin (dronecore_camera) being a generic MAVLink plugin, it won't work for MagicDrones. So they can make a plugin for the Dronecode SDK that is called magicdrones_ptpcamera. In order to integrate it perfectly into the Dronecode SDK, they will need to implement the core library libmagicdrones_ptpcamera.so, the corresponding backend (let's say magicdrones_ptpcamera_backend.so) and the corresponding frontend in the languages they want to support (e.g. in Java, they call it "magicdrones-ptpcamera").

Now, users wanting to write an app specific to this drone can do something like (I'm inventing for the example):

in the build system:

compile 'io.dronecore:dronecore-core:1.3.2'
compile 'io.dronecore:dronecore-action:1.3.2'
compile 'com.magicdrones:magicdrones-ptpcamera:1.0.1'

in the code:

DroneCore dronecore = new DroneCore();
Action action = new Action(dronecore.getPluginInfo('action');
PTPCamera ptpCamera = new PTPCamera(dronecore.getPluginInfo('magicdrones-ptpcamera');

action.takeoff();
ptpCamera.takePicture();

Now let's review the naming:

• The Dronecode SDK in our example consists of the core and action modules (which are supported by Dronecode), and the third-party magicdrones-ptpcamera module.
• Just as the action module consists of a core plugin (part of the C++ core libraries), a backend implementing the grpc server for this plugin, and a frontend implementing the grpc client for this plugin, the magicdrones-ptpcamera module consists of a core plugin, a backend and a frontend.
• To an app developer, we can say that he must use the core, action and magicdrones-ptpcamera modules for his use-case, and he doesn't need to know how it is implemented.
• The MagicDrones developer had to learn about the core, backend and frontend concepts in order to create her plugin, but it was fine, because we gave her a skeleton of a plugin from which she could build hers :-).
• Finally, the MagicDrones developer did not write the whole PTP logic herself but used a helper library provided by the Dronecode SDK. I would call this library a "helper" being part of the "Dronecode SDK", aiming at helping plugins developer in accomplishing a task (here, implementing a ptp plugin).

I don't think (or I can't imagine an example where) we need to create a separate SDK. As long as it is used by people using the Dronecode SDK to control a drone, it can be part of the Dronecode SDK.

[hamishwillee]

Works for me then.

[hamishwillee]

So given that, assume we have a document set "Dronecode SDK". What does that have in it?

• Dronecore C++ API?
• Does it also have the Python, iOS etc APIs?
• Can I add Camera Streaming Daemon docs in there too?

Basically, how do I differentiate the different layers in the document and refer to the different APIs?

[JonasVautherin]

I believe all of that belongs to the "Dronecode SDK" documentation, indeed.

My proposition is to really consider our 3 levels:

• core libs (what you call "the C++ API")
• backend (the grpc server using the core libs)
• frontends (the wrappers in different languages connecting to the backend)

I see 3 kinds of users:

• "normal users", who will use the frontends and who don't need to know about the backend and the core libs
• "advanced users", who understand all the three levels and might decide to use only the core libs (e.g. for low-overhead).
• "plugin developers", who understand all the three levels and are able to write a plugin consisting of a core lib, a backend and a frontend

Now, there is some abstraction coming from the packaging, too :-). Currently, the "DroneCore-Java" repo contains the Java frontend. But what we will package as the "Dronecode Android SDK" will consist of a mix of frontend, backend and core modules that still needs to be defined (i.e. in the first version, the "core" module will have the backend for all our supported plugins, and later that may or may not change).

Does that make sense to you? Maybe the "core libs", "backend" and "frontend" words are not the best ones for that, but I really see those 3 levels in DroneCore.

[hamishwillee]

I think so. It hinges on this line:

But what we will package as the "Dronecode Android SDK" will consist of ...

So you are talking about SDK flavours! That is quite different from a single monolithic "Dronecode SDK" I thought was being proposed. With "flavours" you can simplify naming because I don't need a special way to differentiate the different bits and pieces within an SDK.

We can then have "Dronecode CSD SDK" that is for developers wanting to write CSD plugins. It has nothing to do with "dronecore" at all.

And if we were to have a monolithic structure, we would still make it from the flavours:

DC SDK
  - Core & Plugin SDK  # front end and backends and plugins (assuming this makes sense)
  - Android SDK  #Just front end
  - 
  - ...
  - Python SDK #Just front end
  - CSD SDK  # Setup and backend plugins - nothing to do with DroneCore API

[JonasVautherin]

Yeah I think we agree, except that I am not sure what the Dronecode CSD SDK is. I thought it was some kind of "camera plugin" :-). Is it more some helper library that one might use to create a camera plugin, then?

[hamishwillee]

Yeah I think we agree, except that I am not sure what the Dronecode CSD SDK is. I thought it was some kind of "camera plugin" :-). Is it more some helper library that one might use to create a camera plugin, then?

I guess I should have provided a link :-). I've been working on the documentation here. The summary is that it that the Camera Streaming Daemon is an extensible Linux camera server for interfacing cameras with the Dronecode platform. Basically it turns any camera attached to a linux companion computer into a MAVLink Camera Protocol-compatible camera - allowing DroneCore to talk to it via MAVLink.

[JonasVautherin]

Looks nice. I haven't looked into details, but if possible, I would like to have this as another "plugin", somehow. So that for the app developer, there is action, telemetry, gimbal, and camera. He doesn't have to know that camera doesn't use the usual protocols.

[hamishwillee]

@shakthi-prashanth-m is way ahead of you: #292 :-)

(though to be very precise, CSD implements MAVLink Camera Protocol, and that "is the standard")

[JonasVautherin]

That's perfect =).

[anitha-suresh-zz]

Just to finalize on the SDK naming (renaming the existing Dronecore SDK before a formal release) - As already mentioned in the very first point by Jonas: "the goal is to just call it - Dronecode SDK". Please comment if you have any concerns specifically about this.

[hamishwillee]

I'm a little concerned, because I'm not sure exactly what the final docs product(s) will actually look like. A few things are easy enough when this is approved. I (?) will:

• Get URL and logo changed on http://dronecore.io/ ?
• Update http://dronecore.io/ to say Dronecode SDK
• Update url/logo for docs

Not entirely sure how I will refer to things - is it just a "search/replace":

• "DroneCore is a MAVLink Library for the PX4 flight stack, with APIs for C++, Python, Android, and iOS (coming soon)."

  To

  "The DroneCode SDK is a MAVLink Library for the PX4 flight stack, with APIs for C++, Python, Android, and iOS (coming soon)."

  • Wording looks wrong to me. SDK is software development kit that delivers a product.
    • But we have no product name any more.
    • A MAVLink library is not an SDK.

• Then when we add the other libraries, I'm not at all clear on packaging. Are you expecting different languages to all be in the same "SDK"/document set or in separate sets.

[julianoes]

@hamishwillee I guess dronecore will have to redirect to something like dronecode.org/sdk.

What about:
The DroneCode SDK is a software development kit to interface with the PX4 flight stack, with APIs for C++, Python, Android, and iOS (coming soon).

[hamishwillee]

Works for me. I'm sure this is going to be harder than we think.

[JonasVautherin]

Works for me. I'm sure this is going to be harder than we think.

That's for sure :-).

One thing is that we could also decide to wait until we actually have some concrete packages for, say, iOS and Android. So then we see more clearly what we have.

[laurenwinter]

This proposal, if I clearly understand it, looks good to me. As a customer developer I'd like to have a single DroneCode SDK that encompasses all the code, tools, simulator, etc. The Dronecode SDK - iOS API would then be a component that we'd use for developing our iOS App.

[anitha-suresh-zz]

@hamishwillee @JonasVautherin @mrpollo : Can we close this issue and take below items separately:

Get URL and logo changed on http://dronecore.io/ ?
Update http://dronecore.io/ to say Dronecode SDK
Update url/logo for docs

[hamishwillee]

Sure. I consider the URL and logo to be preconditions for everything else. If you hand me those I can do the rest :-)

[JonasVautherin]

Fine for me :-).

[hamishwillee]

Question, is there an intention to "purge" DroneCore from the docs. For example, we have a DroneCore class - will that have a different name?

[julianoes]

@hamishwillee good idea. We could rename it to DronecodeSDKCore.

[hamishwillee]

OK, created #450 to track that. Something for one of you to do :-)