Minutes Dec 1, 2012
Attending: Stac, PT_Dreamer, Edouard, Kenz, peabody124, lilvinz, dschin, CheBuzz, Gussy
Summary
Goals:
The goal of PhoenixPilot is to focus on writing high quality open source code for autopilots that can easily provide the basis for research projects or further development by anyone. The project focuses on high quality code, robust testing, and ease of use. Our target audience is professionals, researchers, and students, but we want to make those more advanced techniques easy and accessible for anyone.
By “research”, we mean not only universities or institutions focused on research on UAVs, but any group who might have use for UAVs for their research purpose. Examples include UAVs used for agricultural surveys, air quality logging. By “students” we mean aiming the use of our project in the classroom, especially thanks to the availability of an entry-level reference platform (see below).
The PhoenixPilot software is released under the GPL and will be treated in that spirit. Porting the software to new boards is encouraged and fun. The project will also maintain a set of reference platforms which the code will be more frequently tested against and will be expected to perform optimally. As it was put, these will receive “A+ development support.” As Lilvinz put it, with open source you can only give and create and we want to continue doing that.
Reference Platforms and Inclusion into project:
The current reference platforms are the Freedom for higher end applications and the ST F3Discovery board as an easily accessible platform. The Freedom has been designed by the project and features a gumstix Overo header as well as a full complement of sensors. The F3discovery board is manufactured by ST and costs less than 25$.
A second tier of reference platforms that would be ideal are reference applications - a complete flying setup including board and airframe for certain applications. This is ideal for supporting researchers and students who might want to focus goals beyond just getting in the air.
As described in our goals, porting the software to other boards is encouraged. We liken this to the Android model where Google produces a reference platform and encourages a rich ecosystem of extensions and modifications. The conclusion of the meeting was to only maintain the reference platforms in the core source tree and allow other targets to live in their own forks so that the appropriate maintainers can ensure compatibility with any changes applied to the reference platform. Subsequent discussion implied we might allow targets in whose maintainers are active and responsive. Those targets will be considered as ‘contributions’, our reference platforms remaining the main focus for development and especially testing.
We will welcome patches back into the core architecture (e.g. PiOS) to support other targets if they are implemented cleanly and improve the code base. Also new drivers will be welcomed as this will improve the power of PiOS for everyone.
Financing and Infastructure:
The first goal is to keep running costs low. That means using free hosting services when possible. We will use the GitHub wiki and become proficient in it to see if that is really a limitation. There have been some offers to donate server bandwidth and Gussy and PT_Dreamer will follow up on that to see about setting up a forum. Edouard volunteered to provide backup storage.
The second goal is to avoid situations where people acquire debt which affects the project decisions. What finances the project does have to deal with will be run through the non-profit that Gussy and CheBuzz have already established. In addition we will try and merge that board of directors and the various committees into the project decision making process. We discussed if the project needs funds that all of the developers who would like to can contribute to a fund managed by the non-profit. Hardware provided to the developers should not be given away which creates implied obligations, but should be sold at cost.
Hardware manufacturing:
The project will not be responsible for making hardware directly. The reference platforms might already be available (e.g. F3 discovery) or will be release CC-BY-SA (e.g. Freedom). James will hand assemble a first round of Freedom for developers and provide them at cost. Some project members may participate in a group buy once the design is validated. We also won’t stigmatize any businesses that makes the design and sells it - keeping in mind the reference platform cannot be expected to perform in a specific way that is suited to a particular application. Anyone manufacturing can contribute profits back to the non-profit and this will be transparently documented in order to say “supports the Project”. By definition, the non-profit organization will publish regular accounts on its use of funds.
Boards from the OpenPilot project may be supported if a maintainer is found, otherwise they may be migrated to a “contributions” branch.
A first example for this model is Lilvinz, who has produced another board called “Quanton” whose files already openly available. The board will be compatible with our code and possibly merged into the main codeline while it is maintained, but will be separate from the ‘reference’ platforms. He may also choose to maintain it as a separate github fork if that makes development easier. He indicated this would not hinder his ability to push core improvements back upstream.
In terms of support, for forks and new boards there are no expectations of support from our project. Essentially if you build it, you support it. The project will provide support for the reference platforms and will document these well. However the goal at the moment is not to create a large and extensive user community with a large support load, but a small and focused developer group.