Yi Xie, People's Public Security University of China
Mingbo Zhuang, Beijing LongFanHuiZhong Robotic Technology Co., Ltd

Open Source has for a long time been "limited" to software, increasingly the concepts of open-source tough are being applied to entire systems be it SoC on open-cores or, as in our case, a quadcopter.

In this work we present a novel quadcopter project called Opendrone. This project is maintained by an open source group named Opendrone after the project. There are several open source quadcopter projects maintained by individuals. They are usually compactly written and function-oriented. Some projects are even implemented in a single source file. The unstructured implement may puzzle potential contributors willing to get involved in the project for a while before they can figure out the schema of the project. In order to improve the accessibility of our code, we design our project in a pure community oriented way.

What does community oriented mean? This means we took time to:

• select the right technologies for design, documentation and implementation
• built on existing open-source projects - careful not to duplicate
• had a clear focus on easy entrance to our project
• build exclusively on easily available components
• and of course make our work open-source from the very beginning.

At a technical level this translates to a predominantly object-oriented design and an newly-designed flight control board base called Flymaple.

The object oriented design facilitates the community collaborative development of the quadcopter projects in mainly three ways. First, with all sensors, motors and control algorithms encapsulated in classes with comprehensible names, functions related to any specified device or algorithm can be found in the definition of its corresponding class easily by casual maintainers. Second, the adoption of static sensors object keep maintainer from modification to the existing code when they want to add drivers for new sensors. To calibrate the sensor added to the configuration, we typically need to add calibration code to the init function of flight controller. Thank to the auto initialization of static objects, the static objects of the sensors execute their calibration codes residing in the constructors respectively right after the firmware is runned. Thus, if maintainers abide to the design pattern of sensor, the init function are not necessarily modified after a new sensor is enclosed in the configuration.

The firmware of our project is designed for Flymaple board. The flight control board is designed by DFRobot base on Maple board for our group. Flymaple carries 10 degrees of freedom IMUs and a 72-MHz microcontroller. It provides our group an all-in-one hardware platform.

Opendrone has not been completed yet. But the community oriented approaches applied in our project ensure the accessibility of our open-source project and encourage the broad participation from community.