PhoenixPilot Meeting Notes

1,539 views
Skip to first unread message

peabody124

unread,
Dec 2, 2012, 6:20:17 PM12/2/12
to phoeni...@googlegroups.com
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.

Reddog

unread,
Dec 2, 2012, 8:24:02 PM12/2/12
to phoeni...@googlegroups.com
Love that the mission of the project is available so very early. Brilliant work guys.

peabody124

unread,
Dec 3, 2012, 10:09:02 AM12/3/12
to phoeni...@googlegroups.com
To follow up on the part we were discussing online, was how to handle contributed targets and keeping them maintained.  It was suggested to go ahead and put contributed targets into the main tree.  We can then include them in all_flight to quickly catch if a build problem occurs.  At the point there is a problem (from a legitimate change that needed to be done) we notify the maintainer.  If there is no response in a week then we can remove that target from all_flight.  At that point we will search for a new maintainer and if we fail to find one delete that target after a few months (and note the last git hash where it was known to work).

Maintainers can also maintain targets in separate repositories if they want to track the main development more slowly.

Lilvinz

unread,
Dec 3, 2012, 11:19:59 AM12/3/12
to phoeni...@googlegroups.com
That sounds very reasonable and makes keeping cc* and revo* in the repository a consistent thing.

Kenn Sebesta

unread,
Dec 3, 2012, 12:45:42 PM12/3/12
to phoeni...@googlegroups.com
This is great. The only thing I would change is not asking our developers if they're interested to support abandoned hardware. If developers want to step forward that's great, but we avoid a lot of politics if we require this to be an opt-in instead of opt-out decision for supporting abandoned hardware.

peabody124

unread,
Dec 3, 2012, 2:17:39 PM12/3/12
to phoeni...@googlegroups.com
I more meant that we publicly announce "target blah will be deleted on such a date if a maintainer is not found" but agreed.

Kenn Sebesta

unread,
Dec 3, 2012, 3:53:45 PM12/3/12
to phoeni...@googlegroups.com
+1.

CheBuzz

unread,
Dec 4, 2012, 12:12:24 AM12/4/12
to phoeni...@googlegroups.com
Agreed.  I think that strikes a good balance between avoiding code clutter and keeping actively maintained code in the main tree.

metRo_

unread,
Feb 18, 2013, 8:56:01 AM2/18/13
to phoeni...@googlegroups.com
Will stay tunned:)
already have a STM32 F3 :p

Menno

unread,
Mar 4, 2013, 8:40:38 AM3/4/13
to phoeni...@googlegroups.com
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.


I don't mean this as a hostile remark but is the STM32F3Discovery still a reference board in practice? I have a feeling that the Quanton board and the F3 board have switched places in above summary. Ideally it would not matter which board developers prefer as most of the code would be board independent. At the moment however I think that we are not yet at this stage. Are we?

Perhaps as a user I have my expectations set to high, and if so, please tell me. I would vote for announced firmware test releases for the F3. Once tested and approved we mark the release as stable and recommend it for this specific board.

Lilvinz

unread,
Mar 4, 2013, 8:57:25 AM3/4/13
to phoeni...@googlegroups.com
Quanton is a contributed target, FlyingF3 and Freedom are reference targets. This has not changed.
A lot of the code indeed is hardware independent but the hardware abstraction code is not.
Freedom and Quanton share the same cpu, DiscoveryF3 has another, smaller cpu and the hardware abstraction
for that is quite young compared to the processor used in Freedom and Quanton.
This fact and the smaller amount of available system memory require additional work on the FlyingF3
which is not needed on the boards utilizing the bigger cpus.
Even if you get the feeling that development has stalled for the f3, please keep in mind that we (read developers)
are doing voluntary work as we see fit. That being said i have invested some time yesterday in trying to track
down the bug you discovered on the F3 but had no luck yet.

Menno

unread,
Mar 4, 2013, 10:52:23 AM3/4/13
to phoeni...@googlegroups.com
All the work done by the people in this group is highly appreciated by me. And I believe that 99.9% of the users feel the same way. In no way is it my intention to rush the developers or sound dissatisfied. Please don't misunderstand me in that. 

It's just that I noticed that the F3 is not the main platform for development by the developers. Maybe it will never be and this is not a problem at itself. But in this case it could be useful to introduce milestones to which a person can revert in case they run into problems with there board. This could be as easy as mentioning the last known stable build in the Wiki. Right now there are new releases about every other day but I don't think that there is any way of knowing what the changes are and whether somebody has already tested this on the F3.


Kenn Sebesta

unread,
Mar 4, 2013, 11:22:32 AM3/4/13
to phoeni...@googlegroups.com
What being the reference platform means is that we commit to fixing bugs and ensuring that support is top-notch. Compare this with Quanton, VBrain, and other contributed targets which must be maintained by their manufacturers, or else the board support will be deprecated. 

However, in the short run it can happen that a bug is found and it takes us several days to find the volunteer time to fix it. I think that once we have a long period when FlyingF3 is stable and has full support of all ports, etc... we will make a GCS/firmware release package and then people won't feel they have to chase "next".

P.S. I have one quadcopter with a Quanton, and 12 with FlyingF3s. So here in Luxembourg we get very quick feedback on anything that's broken. ;)

peabody124

unread,
Mar 4, 2013, 11:27:52 AM3/4/13
to phoeni...@googlegroups.com
I think you misunderstand the purpose of the files on jenkins.  Those are snapshots of whatever the latest code is.  While generally these are steady improvements, that is not to say regressions will never occur (we try and test lots of things, but with the number of platforms now we cannot test everything).

Currently I would not recommend anyone try autonomous flight.  It's something I've been working on heavily for the last month, but it will be a bit longer before it's at the stage of easy user testing.  That means most of the things you are having issues with (e.g. GPS behavior), while extremely useful for providing us feedback and letting us catch bugs early, aren't regressions in the ability to fly sense.  However FlyingF3 is absolutely a reference platform and especially Lilvinz has invested huge amounts of time into making sure the pinout is sane, and freeing up large amounts of memory to support future enhacements.

The nightly snapshots are not the same as a "release" and strictly speaking Tau Labs hasn't actually had a formal release yet.  It would be good to have a recommended version to run in the mean time, and whichever version is working for you would be what I recommend staying with unless there is a paritcular bug or feature you want.


Menno

unread,
Mar 4, 2013, 2:37:20 PM3/4/13
to phoeni...@googlegroups.com
Got it now. Sometimes I get a bit carried away in my enthousiasm ;-). I'll retain to reliability testing the basic functions for now. Let me now when there is a new function ready for testing on the F3. 

RC Flyer

unread,
Mar 5, 2013, 11:50:10 AM3/5/13
to phoeni...@googlegroups.com
That would be great if DiscoveryF3 will continue as a reference target as long as possible. Many hobbyists who already started their journey with DiscoveryF3 boards will be unhappy if their hopes to start hobby with minor investment fade in the middle of the road.
Since Freedom and Quanton share the same F4 cpu, and F3 stays behind due lo lower processing power there is still a chance that this board sooner or later will be abandoned by developers. Even if it is considered now as a reference target. It is fully understandable.
But if is inevitable, it is probably better to reach some point of design maturity where people can use this project with stated limitations.
Those who wants to go further and get more functionality can switch to F4 design later. 

There is also Discovery F4 board. It has the same processing power as Quanton and Freedom and tons of IO-s due to LQFP100 package.
Would it be interesting to finalize a pinout and design a shield for this board?

Kenn Sebesta

unread,
Mar 5, 2013, 12:11:19 PM3/5/13
to phoeni...@googlegroups.com
We have committed to supporting this as a reference target, so in my opinion that means at least two years of steady support.

The limitation of the CC3D was RAM. It just barely had too little RAM. The FlyingF3 more than doubles the amount of RAM, so everything we wanted to do in the past is now possible. Faster processors aren't as crucial for this level of flying.

The problem with the F4 is that there are no sensors on the board. So the entire package is by necessity more complex. If someone were interested in completing lilvinz's work on this then I'm certain that would be welcomed, but it won't be as quick, easy, and cheap as the FlyingF3.

JamesL

unread,
Mar 5, 2013, 11:50:09 PM3/5/13
to phoeni...@googlegroups.com
just my two cents

if the boards like quanton, Vbrain which is consider to be maintained by the manufacturer.. F3/F4 boards are to be maintained by dev.. 

on research application.. I dont really care how it looks like as long as it gives me enough freedom and works. 

but, it might sound a bit confusing to end users... cuz F3/F4 boards (plus their attachment board) isnt so much considered end product to some end users.. they would probably like to have boards like quanton or VB that looks like the FC they are familiar with. and also PnP like APM (with an all-in-one GC)... another problem making here is that if they are not supported (as far as they can be).... there is no point to have them cuz you dont know when are you going to get cut off..( like PX4 in some ways)


CheBuzz

unread,
Mar 6, 2013, 6:52:56 PM3/6/13
to phoeni...@googlegroups.com
There is no way that Tau Labs developers can be expected to support every commercial board to which somebody ports our software.  It's just not feasible.  What we have come up here is the best possible solution: reference platforms are provided that we have committed to supporting.  Third parties are welcome to port the software, join the development team, and add support for their hardware as a contributed target.

If you buy hardware from a third-party company, you are also buying into having them support your board.  If some commercial company wanted a no-maintenance-for-them board, they could use the same components and pinout as a reference platform (FlyingF3 for example) and be able to use that firmware on their board.  Similar to if you buy an Android handset, some companies are great at updating software while others are not so great.

JamesL

unread,
Mar 6, 2013, 7:04:28 PM3/6/13
to phoeni...@googlegroups.com
the thing i was trying to imply was a possible official schem/pcb/board design that people can replicate from to have full support from the team.. the shield is good for dev purpose.. but for use.. not quite

Reddog

unread,
Mar 6, 2013, 9:47:05 PM3/6/13
to phoeni...@googlegroups.com
I am not saying this to be pushy, you guys dev on whatever you please, thats your choice and has nothing to do with me.

In saying the above, development will be much simpler on a single board or single processor. I know this is what Freedom is about, but its not here yet. There will be much less wasted dev time if it was all focused on a single board.

Is there a benefit to using a cheap board ($40 to me) or having a board that is $200 and getting results quicker? Honestly this is the way I see my purchasing going with Tau Labs. Buy F3, get it working and flying, realise I need a smaller board to do some real stuff, buy Quanton, Freedom comes out, buy it because its officially supported and has all the bells and whistles. Total expense on boards, $400 -$450. Alternatively I buy Freedom $200 and now I have a board that can do anything I need for at least 2 years ($100 per year not too bad). I wouldn't care if Quanton became the board of choice, but it would be great to know where to invest now to get value for money.

Stefan Cenkov

unread,
Apr 9, 2013, 3:54:17 AM4/9/13
to phoeni...@googlegroups.com
I would like to present VRBrin board manufactured by Virtual Robotix Network Team.
http://www.virtualrobotix.com/
http://vrbrain.wordpress.com/hardware/

That board is similar to Revolution or Quanton.
I've done porting of the TauLabs code and work well.

The difference between VRBrain board and Revolution or Quanton, is that MS5611 work by SPI bus and flash is atmel AT45DB161D.
For this I added two new drivers:
pios_at45_flashfs_objlist.c
pios_at45_flash_jedec.c
pios_ms5611_spi.c


So far I've tried flying in Position Hold and Return to Home.
http://www.youtube.com/watch?v=kTFpVW7EtvQ
http://www.youtube.com/watch?v=JWmuaAhO-mE&list=UUaT25BYqLWgAbnuZWJw9erg&index=1

Is still more work to do, but hopefully with your help I get:-)

CheBuzz

unread,
Apr 9, 2013, 11:25:01 AM4/9/13
to phoeni...@googlegroups.com
Well done!

But may I suggest starting a new thread on this topic?
Reply all
Reply to author
Forward
0 new messages