Who are we

A group of volunteers interested in UAVs, programming, control systems, and much much more. A number of the developers of Tau Labs helped develop Open Pilot before forking to Tau Labs to have a greater degree of freedom.

Goals

The goal of Tau Labs 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 Tau Labs 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. A complete list of supported targets can be found here.

Reference Platforms and Inclusion into project

The current reference platforms are the Quanton for higher end applications and the ST F3Discovery board as an easily accessible platform. SThe F3discovery board is manufactured by ST and costs less than 25$, which makes it a great target for students wanting a flexible board. Sparky is also available as a small F3 based board.

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. Other targets are eligible to be merged to next provided they are supported by a maintainer and the hardware design is published with an open source license. People can also maintain their own forks to support other targets that to not meet these crtieria.

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 OmniLoco Foundation, which is the foundation behind Tau Labs. If the project needs funds then anyone 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. 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.