When the Apple iPad first appeared on the market in 2010, I didn’t jump in to buy one. I didn’t own an iPhone, I had a company-issued Blackberry, so I wasn’t motivated. Besides, I figured there would be a better model a year or so later. So I waited. By the time Apple released the iPad 2 in 2011 all my friends had one. It looked and felt great in the hand. I thought the user interface (UI) was pretty slick. But I also heard about this thing called Android in development by Google and the Open Handset Alliance (OHA) with a similar and perhaps better UI. I was conflicted about which to buy first. I eventually got an Android tablet on the promise of what could be an open source model. However, after one disappointing experience after another, I got rid of it and switched a year later to an iPad first generation. I stayed on that path and haven’t looked back since.<\/p>\n
As Diffen<\/a> says:<\/p>\n Google’s Android and Apple’s iOS are operating systems that provide a good example of open source vs. proprietary. Both are used primarily in mobile technology, such as smartphones and tablets. Android, which is Linux-based and partly open source, is more PC-like than iOS, in that its interface and basic features are generally more customizable from top to bottom. However, iOS’ uniform design elements are sometimes seen as being more user-friendly.<\/p><\/blockquote>\n But wait, I thought we were going to discuss drone software. We are.<\/p>\n For all drones, the interaction between the user and the aircraft, and the aircraft and its hardware is mediated by software. As I have written here<\/a>, the quality of the pilot experience can be driven by the features and the quality of implementation, but the comparison with tablet and smartphones is a good one. Just as with your smartphone and tablet systems, choosing the wrong software platform for your drone can produce some very high switching costs should you decide later you need to change. In this post, I’m going to look beyond manufacturers\u2019 claims and help you understand the differences with the following explanations of what is it, who makes it, who uses it, and what you need to know.<\/p>\n What is it?<\/strong> Open source software is distributed under a variety of licensing terms, but almost anyone can modify the software to add capabilities not envisaged by its originators. Most often the software originator or distributor declare a group off standards or technology specifications and make them widely available, allowing many companies to create products that will work interchangeably and be compatible with each other. One such standard is an Application Programming Interface (API). An API is a feature of a software application that allows other software to interoperate with it, automatically invoking its functionality and exchanging data with it.<\/p>\n Who makes it?<\/strong> At a recent small unmanned systems business expo in San Francisco, Chris Anderson said his company 3DRobotics<\/a>\u00a0and its ecosystem of partners are in the process of “Building the Android of UAVs.” He compared the APM firmware, software, and its partners with the Android operating system open source software stack. You can watch that presentation here<\/a>\u00a0beginning at 3:51:40.<\/p>\n Parrot<\/a>, maker of the AR. Drone, Bebop and parent of Sensefly <\/a>and Pix4D<\/a>\u00a0is another open source vendor. They have\u00a0an older open API platform with shared source code released under the terms of the AR.Drone License<\/a>.\u00a0You can read about their software development kit (SDK) here<\/a>.<\/p>\n OpenPilot<\/a> is another widely used open source UAV autopilot created by the OpenPilot Community (an all volunteer non-profit community). They boast there are no hard-coded settings and an extensible flight plan scripting language.\u00a0OpenPilot was started at the beginning of 2010 and was\u00a0aimed at civilian and research purposes, but its\u00a0emphasis has been on\u00a0making the platform especially suitable for aerial photography and aerial video applications. The OpenPilot forums can be found here<\/a>.<\/p>\n Who uses it?<\/strong> What do you need to know?<\/strong> APM offers this, plus some great features like point-and-click programming\/configuration, multiple command modes, failsafe programming options in the event of lost control signal or low battery conditions, camera gimbal control and stabilization, some limited real-time telemetry and data logging, and of course, APIs to third-party software and hardware.<\/p>\n Cons –<\/strong> Like the early versions of Android, the APM interface and basic features are generally more customizable. That means ‘partial assembly required’ for commercial use. In other words, you’ll need to tap a community of engineers to determine the compatible components and integration possibilities if you want extended capabilities like the support of large heavy-lift multirotors. Granted, 3DRobotics has made progress with the release of its IRIS quadcopter, which contains the Pixhawk open source hardware unit. While Pixhawk with its 32-bit architecture, faster processor, more memory, etc., is shaping up to be the successor to earlier APM-supported hardware, it’s still not quite ready for multi-duty aircraft where you need to hot swop configurable sensors. Other companies will need to aggregate more reliable components on top of Pixhawk or wait for the next generation of APM to accomplish that.<\/p>\n What is it?<\/strong> Vendors typically distribute proprietary software in compiled form, usually the machine language understood by the drone’s central processing unit. They typically retain the source code, or human-readable version of the software, written in a higher-level programming language. By withholding source code, the software producer prevents the user from changing how it works. This practice is denounced by some critics, who argue that users should be able to study and change the software they use, for example, to modify unwanted features, or fix malfunctioning vulnerabilities.<\/p>\n Who makes it?<\/strong> Who uses it?<\/strong> What do you need to know?<\/strong> Some of the other benefits are less apparent.<\/p>\n Tech support.<\/strong> First, you\u2019ll never have to fix inherent problems when something goes wrong. With any software, things occasionally go wrong. When this happens with open source software, you, or an engineer who owes you a favor, may need to spend time debugging the problem. This entails reading through code, working with an open source community, or your open source support provider, and applying a fix. With closed source, on the other hand, once you determine that the problem lies in your vendor’s code, you’re all done! All you have to do is file a ticket and wait. It can take some time to decide whether you want Service Level Agreement (SLA) support with guaranteed response times, or if you feel comfortable posting issues on forums or doing your own support. With closed source, you pretty much never have to worry about where you’re going to get support. Sure, you might not ever get to speak to an actual engineer, but at least you always know who to call. Sure, you may have to wait for the next software release version for the fix, and sometimes it never comes at all, but there’s nothing you can do about that. Just kick back, relax, and hope for the best.<\/p>\n Fewer options.<\/strong> Yes, sometimes fewer options is a benefit. With closed source, you don’t have to contend with so many options. You only have to explore two or three large vendors in each market. You can save time. Open source offers lots of solutions when considering a motor, electronic speed controller, camera trigger, telemetry downlinks, etc. In practically every category, you can find robust offerings built by a variety of vendors with different architectural approaches. It’s also very common to find similar tools that are optimized for different use cases (e.g., performance versus scalability versus simplicity). To make sure a tool will work best for your particular use case, download it and give it a try.<\/p>\n Cons \u2013<\/strong> In some instances proprietary isn’t the best option. For example, you may want to take advantage of the growing use of the air vehicle communication protocol standard MAVLink<\/a>. MAVLink has been extensively tested on the open source platforms and serves there as communication backbone for the MCU\/IMU communication as well as for Linux interprocess and ground link communication. This protocol has enable companies like DroneDeploy<\/a> to create a very user-friendly web-based mission planner which allows control of multiple drones. I suspect this protocol will become the de-facto standard in the growing \u2018mission planner\u2019 functionality race and proprietary protocols will leave their solutions inadequate.<\/p>\n So, there you have it. A few good reasons why you want to consider closely whether you want your business to use open source or proprietary drone software. Do you have others you’d like to share? Please comment below. If you have questions and would like to discuss further, email me at colin@droneanalyst.com<\/a>. Cheers.<\/p>\n Image Credit: Shuttestock<\/p>\n","protected":false},"excerpt":{"rendered":"Open Source Drone Software – the Google Android model<\/h3>\n
\nThe term open source refers to software whose source code \u2014 the medium in which programmers create and modify software \u2014 is freely available on the Internet. By contrast, the source code for proprietary commercial software is usually a closely guarded secret. The most well-known example of open source software is the Linux operating system, but there are open source software products available for every conceivable purpose.<\/p>\n
\nThe best example of an open source software product for drones is 3DRobotics\u2019 ArduPilot Mega\u00a0or ‘APM<\/a>.’ APM is the leading open source auto-piloting software. It\u2019s billed as the first universal autopilot, which means it enables same hardware to provide fully autonomous control to a multitude of vehicles, from multicopters and traditional helicopters to fixed-wing planes and even ground rovers. APM is a full UAV autopilot, which means it supports both piloted and unpiloted (fully autonomous) flight, including hundreds of GPS waypoints, camera control, and auto-takeoff and landing.<\/p>\n
\nThousands of hobbyists and researchers, but very few commercial drone operators – at least not yet.<\/p>\n
\nPros –<\/strong> The common theme of \u201copenness\u201d in the above definitions is the ability of diverse parties to create technology that interoperates. When evaluating your drone business’ current and anticipated software needs, a software solution\u2019s capability to interoperate is an important criterion. To extend the value of your physical aircraft investment, you may want to select a software solution that is based on open standards and APIs that facilitate interoperability and has the capability for direct integration between various vendors\u2019 products.<\/p>\nProprietary Drone Software – the Apple iOS Model<\/h3>\n
\nProprietary software, or closed-source software, is drone software licensed under exclusive legal right of the copyright holder with the intent that the licensee is given the right to use the software only under certain conditions, and restricted from other uses, such as modification, sharing, studying, redistribution, or reverse engineering. Usually the source code of proprietary software is not made available.<\/p>\n
\nJust about everybody other than 3DRobotics and AR.Drone. Examples of commercial-grade software embedded in small drones include: PrecisionHawk<\/a>, Draganfly<\/a>, and Aeryon<\/a>, to name a few.<\/p>\n
\nThousands of civil and public small UAS operators and a few hobbyists worldwide.<\/p>\n
\nPros —<\/strong> The fact is, proprietary source is better than open source in certain situations — like when you want a turnkey hardware \/ software solution to support a commercial sUAS service such as mapping, agriculture, or industrial inspection. Just know that you will pay more and be limited to the improvement roadmap of a single vendor.<\/p>\n