Every now and then, I find myself in a regrettable foray into a deeply technical project for a ridiculous cause. Fortunately, I wasn't alone in this adventure.
My ACM student organization and I have been toying with our new AR Drone. The goal is for the drone to deliver tacos autonomously. Of course, this objective has several obstacles: buildings that obstruct paths, birds that steal tacos and customers that refuse payments.
The project and its subproblems seem qualified enough to be worthy of an exploration into drones. We begin our exploration with a API choice and I will elaborate what we mean by a "good API."
Criteria for a Good API
As a team, we believe that a good API has two properties:
- a familiar programming language and
- long-term support and maintenance
Our selection processs proceeds by selecting APIs based on the language requirement and eliminating the results with the second requirement. A third requirement, although not necessary for a good API, follows with the goal that this project is exploratory: the API must enable rapid prototyping.
Language Requirement
When several APIs are available in different languages with varying degrees of support, you are only restricted by the languages you know. This is where being a polyglot programmer may be useful.
Since my team is capable of a combination of Java, Python, Ruby and JavaScript, we began narrowed our results to the following five APIs:
JavaDrone : The project does not use Parrot's SDK, but that's okay because it adheres to the simple networking protocols. Seems good.
ODC (OpenDroneControl) : Independent of the drone implementations. ODC uses JavaDrone as its implementation for the AR Drone. Additionally written in Scala which also runs on the JVM.
python-ardrone : Still uses Python 2.x! It is possible that this is no longer being maintained and a fork may arise as the new official release.
Argus : Also may not be maintained. Consider using one of the forks.
node-ar-drone : Also implements the networking protocols directly as JavaDrone does. Seems good.
While there is an official SDK from Parrot, the company that manufactures AR Drones, the non-mobile examples are written in C. The language was unfavorable for rapid prototyping as our team needs, so the official SDK with C was not an option.
The most obvious concern here enables me to eliminate some options.
Pruning Unmaintained APIs
Since my team must focus on the development of the project, API maintenance is certainly not in our requirements list. Hence, we prune out APIs that appear unmaintained. Here are some statistics that may point to a lack of maintenance:
| API | Language | Last Update | Stars |
|---|---|---|---|
| JavaDrone | Java | Feb 4, 2014 | 37 |
| ODC | Scala | Nov 18, 2013 | 7 |
| python-ardrone | Python | Feb 08, 2013 | 66 |
| argus | Ruby | Nov 20, 2013 | 79 |
| node-ar-drone | JavaScript | Feb 05, 2014 | 702 |
The unmaintained APIs seem to be python-ardrone and argus which were both last updated three months ago. Additionally, both have pending pull requests for months with forks that are more updated! Nascent forks may be considered as an option, but that is beyond the scope of this post.
Good Candidates APIs
Since we now satisfy the requirements for a "good API," we remain with three choices: JavaDrone, ODC and node-ar-drone. Further elimination is difficult, however, recall that we have a third requirement:
the API must enable rapid prototyping
This requirement eliminates JavaDrone and ODC which both require build tools! Naturally, node-ar-drone is easy to prototype with on top of node.js by simply installing and using the package. Hence, we choose node-ar-drone.
Conclusion
While node-ar-drone is our API of choice for exploration of drones, it may be possible that JavaDrone or ODC may be used in the future once we acquire a strong vision of where to take this project.