Feedback on current state of Parrot SDKS


Hey Hi, I have a Parrot Mambo mission, I have been in contact with @Jerome and thought I would provide some feedback on the current state of programming drones with Parrot.

My gut feeling is that programming drones the way I want to do (with actual code) is not the main focus of Parrot. The main focus of Parrot sdk seems to be more geared towards education with tools like Tynker and Blocky. And that’s great! Teaching kids to have fun doing some programming with drones is clearly awesome.

Now onto the more “geeky” ways to code, with say JavaScript or Node.js. There’s right now not a single good solution for that.

I just saw you updated with minidrone-js and pyparrot. minidrone-js is currently broken and is a low level API and pyparrot does not works on macos for BLE only drones.

Here’s what, as a developer, I seek as an API in JavaScript:

  • const drone = pdrone({filter: uuid => return uuid === ‘vvodrone’});
  • drone.connect() => Promise
  • drone.disconnect() => Promise
  • drone.takeOff() => Promise resolved when drone has completed takeOff (not just when command acked)
  • => Promise resolved when drone’s claw has completed open
  • etc… you get it

^ This is what I am trying to achieve but to do so I need to swim into a giant PDF document from 2015 describing a low level protocol that I am not at all good at decyphering. I consider myself a good API designer in JavaScript, not someone that grasp what does little endian means or someone that can craft raw buffer by hand.

Then you have to dig even more into obscure forum discussions containing even more protocol details that are not in the PDF etc…

At the end of the journey, I am just trying to and it took me ages, and I am not even yet having a good control flow with Promises etc because I have no idea how to link the command sent to the ACKS sent by the drone etc…

I am not asking any technical question here, in the end I managed to have something that is workish and will fulfil my needs. But it took me DAYS, instead of minutes.

I am here to give you my honest POV as a JavaScript developer working with your product, it’s an horrible experience (for now). And I know it’s not your focus but I believe there’s a big opportunity miss here.

Parrot could be THE technology for drone programming hackathons, the whole city of SF is full of engineers bored at work willing to have one good hackathon some time in the year that is not just about building a webapp with React and google maps.

But to achieve that, we need good libraries, good solid and well crafted libraries instead of almost-good, maybe-maintained, not-really sound libraries. And the responsibility is on you Parrot developers to my POV.

I work at a company selling a SAAS API, we built 12 API clients in all languages for our customers. We could have relied on the fact that our “community” might craft good API clients but that usually don’t really happen and you end up with half of your SDKs that are good and the other half that are not so good. It ends up sending a bad signal to developers and then those developers will have a bad image of your company.

Right now if someone asks me “Hey are Parrot drones great for programming?” I will most probably answer “No”. Which is sad and a state I hope you will reconsider by publishing your own JavaScript (and python if you want) libraries instead of relying on the community to do so.

If you think that it will become a struggle because then you will have to support those API clients, just look at how many messages and questions your developers had to answer that are just about “How is this SDK really working? I don’t understand how to implement feature X”. Implement it once well, with all features, in JavaScript and you will never have to explain anymore how to do it, it will be done and your clients will be able to use your products the way they want.

Your community will benefit from it.

Also I propose to spend some time with your engineers if they are not JavaScript aficionados to help them craft the best high level API and they will provide me the right SDK knowledge needed to implement it well. We can meet, skype anything as you want, ultimately I’d like to bring back a bit of NodeCopter to 2018 :slight_smile:


While I am not answering for parrot, I will answer as a user developer. I looked into all of the companies who sell COTS for drones before deciding to work on an interface for parrot. A lot of the other companies have SDKs but will not publish protocols or even talk to the developers about actual programming (they only want you to use their SDK, which is entirely geared to mobile development). So while parrot may not be geared to what you want as a company, they are very friendly to the hacker community.


Was going to say similar… What may take days on a parrot drone simply doesn’t happen on others.


I agree with you here, it’s already awesome to have those protocol papers and community forum and parrot developers hanging out here. I only wish we did not even have to think about it and just use official libraries like kids are using official simple to use tools.



Here is a personal statement about the SDK situation (not an official Parrot position :wink: ):

The SDK as it is right now (the C libraries) are mostly an open-source release of code written internally for FreeFlight development, assorted with a huge effort (mostly by @Djavan) to write the documentation. The only piece of software on the SDK which was not written for FreeFlight is libARController, which was written as an “easier” interface to the SDK than the raw libARCommands/libARNetwork/... libs.

To add more background here, the “SDK Team” at Parrot is composed of embedded software engineers (my case) and mobile developers, so the languages on which we can provide support are mostly C, Java and Objective C (+ Kotlin/Swift).

I decided (and Parrot approved) to write & release a complete protocol documentation so other developers (internal or external) could write “Non-C” programs for the drone without having to “guess” the protocol from our code.

As @CaptainSaavik pointed out, this allowed many “other languages” framework to appear, without having to rely on wrapping the C libraries (which would have many portability issues). This includes languages in which we’re not proficient, as JavaScript. Part of the reason why we did setup this forum is actually to provide a way for external framework developers to gather information from a single source (i.e. we read all the posts, and will try our best to answer your questions with reliable answers, not guesses), and to promote their work to other developers.

So yeah, the official SDK is “geared to mobile development”, as it is basically what we’re doing with the drones (again, the SDK is the basis of FreeFlight), and that is unlikely to change in the short term. But as a “drone geek” myself, I find it really pleasing to see people developing external frameworks for the drones to do things that would not be easy to do with our SDK, and I am happy to help such things happen when I can.



Thanks for all the context information @Nicolas, to be clear I love Parrot products, the Mambo mission is a nice drone, we bought twenty of them for a company event that will take place next week.

I think I had wrong expectation. Looking at and I thought that programming a Parrot Mambo using JavaScript would have been a “solved” challenge for long time now, since NodeCopter is an old initiative from the community. Given those wrong expectations I then was frustrated by the current state of available libraries for programming Parrot Mambo mission.

I will ask specific questions about the protocol in another thread when needed, thanks a lot for the hard work still!


Hey vvo!

I’ve just started developing some small things in nodejs for the parrot mambo and I just wanted to ask you (because of your experience) if it’s possible to get a video stream to the application from the drone.
I want to integrate face recognition but I’m not sure about how to retreive the video stream.

Any idea?

Thanks in advance! :slight_smile:


The Mambo with its camera accessory uses rtsp (over the wifi) to stream its video. You can find more in this thread: Streaming address of Mambo FPV for videoprojection