We're moving to a new documentation platform and this is your opportunity to give us feedback and help. There has been a huge amount of work going on behind the scenes on these over the past three months, including the 30 volunteers working within the Documentation User Group. It's now time to include the full community.

You can see a glimpse of the team's work in the betas of the new ArduPlaneArduCopter and ArduRover sites. Click on the "Instructions" tab to see what the new manuals will look like. 

Right now most of the work has been in creating new graphics and design elements to make the manuals easier to read and use, with some work on simplifying and updating the content. But because they're based on a Wiki-plugin for WordPress, it's also a much more powerful and flexible collaboration environment than the current Google Code wiki for community participation, and we can now take this opportunity to update and improve every page of the manual. 

Just a reminder that these sites are still in beta, and we won't be steering users to them until the documentation team has had an opportunity to scrub every page. We'll continue to maintain the Google Code wikis for legacy purposes, but the new sites are designed to reflect the model we'll be moving to in the future. 

Please give us feedback in this thread. If you'd like to participate, please join the Documentation User Group linked above. 

Views: 6465

Reply to This

Replies to This Discussion

I've still got my old Heathkit RC system Mark, they literally just don't build them like that any more.

Good catch on the transmitter being turned on first and not off till the battery is removed.

I'll put it in.

When I first took over this Safety section, it was just several non-comprehensive comments pertinent to MultiCopters, but at this point it has evolved into a pretty comprehensive and more generalized list of RC safety.

I think that is a good thing.

I also think the check list idea is worthwhile.

There are lots of them published for General RC use but really nothing relating to our more specialized needs.

The fact is a lot of new and complete neophyte people are going to be entering our not so little group over the next few years and one of the most important things we can do is to make that transition enjoyable and painless (in all ways).

A pre-flight checklist is a FANTASTIC idea!

Added transmitter turn on first reference and removed "offending" parentheses to Old Wiki

I will do so to New Wiki when its back working again.


You are implying a certain lack of cohesiveness and comprehensiveness.

I can't imagine why, a set of Documents put together bits at a time from people trying to solve their own problems and with not much knowledge of documentation.

What could possibly go wrong?

In fact, all of the points you raise are excellent and, now, with 3DR firmly in the lead on this project and an enthusiastic group of volunteers (myself included) Most if not all of what you brought up will be "fixed".

I for one am printing out a copy of your "suggestions" because I think they are a good reference for my own future efforts.

I, particularly like step by step walk through's and I think a number of them could be useful in spite of requiring quite a bit of text.

I will find a good way to get them into our Wiki.

New Wiki back up, Safety section fixed as above.

Joshua, when the Wiki went down last night I had quite a bit of unpublished stuff, so I block copied the HTML into NotePad++ and this morning when it came back up I re block copied it into the New Wiki and it worked great.

You probably already knew this would work, but it saved me a lot of redo.

I notice I am now a "Wiki Ninja" Thank You Guys.

I'll try to do what I can without "hacking" it up too much.

Challenge accepted.

Kevin, I generally agree, except to the point that the wiki should have to cover old code.  I don't think that should be expected.  Over the past ~8 months, the code has really been excellent performing and fairly bug-free, and there really isn't any need for anybody to be using old code.  There's really no need for anybody to be using old codes, and therefore no need to go back and document old code.

Now, that does still leave the question...  As we move forward, and have code changes that obsolete the now respectable wiki info, how do we manage the transition?

First and foremost, I think Randy's release notes should be stored permanently somewhere in the wiki.

Then, if there are changes to the info in the wiki, such as how a feature works, we should highlight the changes, and retain the old info with a reference to which pertains to which release number.  We maintain info on old code for 2, maybe 3 releases, but that's it.  We can't continue to maintain all the old info for all old codes going back forever, because it just makes it too confusing.

Unless of course there was some way to maintain wikis per each release and the user selects from a dropdown.  When a new code is released, the old wiki pages are cloned into a new code wiki, and then changes made to the new wiki as required.  Make sense?

And in the wiki notes on each release, we could go back add notes/warnings about bugs that have been found in that release.  That's doable.  But that would be *going forward*, not going backwards.  Nobody is going to go back and do that now, I think.

As far as stable releases... the official releases are the stable releases.  We really try to do a lot of beta testing now.  We're not releasing junk.  However, some things still slip through because we simply don't have enough beta testers to find everything.  That is not going to change, I don't think.  It's not just the code, it's all the permutations of parameters, RC system, airframe, etc.  All that can be done here is... well I've made the choice not to jump on the latest release right away on my expensive machines.  Simple as that.  If nothing criticial comes up after a couple weeks, then I'll use it.

Again, we simply haven't had a critical Crash-o-matic bug in like 8 months or more.  The crashes lately are simple user error, bad documentation leading to user error, the APM not being able to solve user setup problems, or the APM not being able to solve user error.

For example, look at the Alt_Hold flyaways.  This isn't a Crash-o-matic bug.  We have people crashing because Alt_Hold doesn't work (because they have vibrations), and they simply don't know how to fly in Stab mode.  IMO, they shouldn't be flying.  Then we had people with poor radio systems, where the Alt_Hold problem instantly took them out of radio range so they can't flip to stab mode.  We've also had people who's response to the Alt_Hold problem was to turn off the Tx to force it into FS RTL, which simply doesn't work if the Alt_Hold isn't working.  Then it was out of range when they turned it back on to try Stab.

Or you have guys like me who let an avionics battery run down, the APM goes into an unknown low-voltage state, and I hadn't set the FS.  That's not a bug.

Was it expensive, and dangerous?  Yep.  Was it the APM's fault?  I don't think so.

Now, what to do with old hardware...  Good question.

If it were up to me, 2.9.1b would be the last APM2/APM2.5 release.  And we'd strip out a bunch of stuff to fit APM1.  And then that's it. 

IMO, the lead developers are spending way too much time simply trying to get 2.9.2 to run on an AVR.  Time that might be better spent getting PX4 working.  2.9.1 is a solid, solid release. We should not be ashamed if that were the end of development on that platform.  But that's just my opinion.

Let me just bring back the checklist part of the thread I like this one from the BMFA.

When you arrive at a flying field and before you start flying, we recommend that you take a few moments to consider the surroundings and the flights you will be making.

Think S.W.E.E.T.S.
S - Sun
W - Wind
E - Eventualities
E - Emergencies
T - Transmitter Control
S - Site Rules

Sun – Where is the sun in relation to where you will be flying? Will it affect your flight patterns? What actions will you take if you accidentally fly ‘through’ the sun? Should you be wearing sunglasses? Remember that low sun in winter can be a particular problem.

Wind – Consider the wind strength and direction. How will this affect your flights? Will you have to modify your normal take-off and, especially, your landing patterns? From your local knowledge, will there be any turbulence with ‘this’ wind direction and strength? And how bad might it be?

Eventualities – What will you do if you hear or see a full size aircraft or helicopter flying at low level near the field? What if the landing area is suddenly obstructed when you are on finals to land? What will you do if a nearby footpath or bridle path suddenly has walkers or horses on it?

Emergencies – You may have an engine cut at any part of a flight so consider where your deadstick landings might be safely made and which ground areas you should definitely avoid. How will you warn other field users if you have an emergency?

Transmitter Control – Is the site pegboard in operation? If not, why not? Where has the pegboard been placed? Are you familiar with the system and understand how it works?

Site Rules – Are there any specific site rules you should be aware of? Most importantly, where are the no-fly zones or dead airspace areas on the site?
The answers to most of these questions are contained within these Safety Codes and your local Club rules but you will be making the final decisions as to whether flights can be made safely. If conditions are poor or a site is unsuitable remember that a decision not to fly can be both valid and sensible.
We would also recommend that you review the sections on the sun and wind throughout the day as they obviously change over time and this may affect some of the decisions you will be making.

All to be found in the BMFA handbook, lots and lots of sensible stuff here no need to re invent the wheel.


Hi Gary,

I like your check list, it has a lot of what we need.

But with 2.4 GHZ, the peg board is an unused relic at our field  (Of course you do have the odd old relic that shows up with an old relic).

And ArduPilot users have some special needs as well as each type of airframe, so I am thinking of coming up with an individual checklist for each type.

If we can come up with a cute acronym, so much the better.

I specially like what is being discussed in this sub-thread :-). 

I haven't gone through current APM code base and do not know how branches are created. I know the latest is going to be considered as the most stable release. But given new features are added while fixing old bugs, IMHO it is little bit difficult to maintain its stability. 

If a relatively stable version - say 2.9.X  - is released, a corresponding 2.9.X branch could be "feature frozen". Only bug fixes could be performed in that branch (also reflected in the trunk). In that way we could have stable branches. (These branches will retire later). All new feature additions could be done in the trunk. 

Nice to see 3dr is working on the documentation. In my experience, while working in an open source software company, we developed as well as maintained the documentation at the same time. 

Just my 2c. 

Hi Gary. I would describe myself has an old relic having flown rc since galloping ghost radio ( google it) lets not forget many FPV pilots fly 72MHz to avoid interference. I have used checklists for 40 yrs and it has prevented severall destroyed models

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service